I2CWRITE not writing anything on PIC18F45K80

[HenrikOlsson]

Exactly, we've been thru this before. Your beloved ZX Spectrum runs a BASIC interpreter which interprets and executes the code as it runs. It (the interpreter) can check things like out of bounds errors at run-time, a task that I'm sure makes array-indexing slow as f-k.

PBP is a compiler. It COMPILES your BASIC source into instructions that the PIC executes natively, it's not an interpreter. It is IMPOSSIBLE for the compiler to detect out of bounds issues at COMPILE TIME.

And even if the compiler was built to generate code that DID check array boundries on every access at runtime what do you suggest should happen when such an error is detected? It's not like there's a TV or monitor connected that can display the error message. Nope, the program would just crash with no way to tell the user why. In what way is that better than what it does now?

[CuriousOne]

Yes I know what is the difference between the compiler and interpreter.

And I'm not asking about RUNTIME error handling. I'm asking about boundary checking during the compile.
It can be clearly seen from the code that reading past array boundaries WILL occur in compiled code:

1. Compiler knows that X is starting from 0
2. Compiler knows that array is being read at X-16 position, which is definitely an error.

So some kind of notification like - "possible out of boundary array access" is very well possible and would be great.

[HenrikOlsson]

It can be clearly seen from the code that reading past array boundaries WILL occur in compiled code:

And yet, on 22nd April 2023, you said:

This is not issue of my code, because if I do not declare "topline" array, then "botline" reading works fine.

Clearly putting blame on anything BUT your code, be it the PIC itself, the compiler, the assembler or whatever - just not your code.

But, you're right, some situations could be confidently detected and some could be flagged as "potential" at compile time but it's a "can of worms".

As it is, the rules are clear and they are spelled out in the manual, section 7.6 that Ioannis pointed to earlier. You are responsibly, a fair price to pay for a powerful feature. It is what it is.

[CuriousOne]

Oh yes, XINST issues are solely my code fault too, right?

[HenrikOlsson]

Well, yes!

Since the compiler doesn't generate code for the extended instruction set the XINST config setting is set to OFF in the default configuration files for the devices that has that option.

Are you saying that is not the case for 45K80 and that there's a problem with the default config?

My humble guess is no, probably not. Instead you took a decision to change a default setting without knowing what it does. Things went south and once again it's the tools fault.

I'm not saying PBP and it's documentation is without shortcomings but, as has been proven, people don't read the documentation anyway. For example, can you honestly say that you went looking for XINST in the PBP manual BEFORE you decided to change that setting to ON or BEFORE tumbleweed pointed you the problem?

If you DID look for it in the manual you would've seen that every time it IS mentioned it shows the setting being OFF but you STILL decided to change it to ON and blame the tool.