I2CWRITE not writing anything on PIC18F45K80

[CuriousOne]

These are code parts which insert the empty space when in the array we do have code for ASCII space (32).
And this part of code works just fine.
The issue is that another, non-related part of code is causing problems.
Why changing value of certain variable, which is not used at all, causes issues with another variable?

[Ioannis]

Maybe because you are altering places in memory of the PIC that you are not aware of?

In the above example, if x=0, the

botline[x-16]=32 then a=0

how does evaluate?

Do you see the consequences of?

Ioannis

[tumbleweed]

And this part of code works just fine.
The issue is that another, non-related part of code is causing problems.
Why changing value of certain variable, which is not used at all, causes issues with another variable?

Ioannis gets it. You don't. That code doesn't "work just fine".

Your array index statements are screwed up, so you're accessing who knows what in memory.
That would explain the mysterious "I add unrelated code and things change".

There are any number of places for all that to go south... I don't trust many of those array accesses to be valid.

[CuriousOne]

Well, that is interesting.
As I understand, there is no "index out of bounds" error type supported by PBP?

I've modified that part of code to look like this:

if topline[x]=32 then a=0
if topline[x+1]=32 then b=0 'blanker


if X=>16 and botline[x-16]=32 then a=0
if x=>16 and botline[x-15]=32 then b=0

So far, works fine. Will keep you updated

[Ioannis]

Well, that is interesting.
As I understand, there is no "index out of bounds" error type supported by PBP?

Page 275 of the manual:

7.6.1 The Danger
The techniques about to be discussed are not monitored by PBP during compilation
or execution of the program. This means that you can write some crazy code that
could totally wreck the RAM on the PIC MCU. PBP won't warn you or generate an
error message.

The greatest opportunity for trouble lies in the fact that PBP doesn't monitor (isn't
even aware) of array variable sizes. When you declare an array in PBP and specify
a size, all that really happens is that PBP skips a number of RAM locations after the
base variable name is allocated.

my_array VAR WORD[16]   ' Allocates "my_array" as two
                           bytes, then skips (reserves) a
                           block of 30 bytes in RAM

Even if you blatantly write to a location that is beyond the size of an array you created,
PBP won't complain.

[CuriousOne]

Yes I have read that.
But same manual also says that array size is limited for 16F series and only limited by available RAM on 18F, so I thought that this should work fine, but as it seems, it does not

Now I have another everlasting issue to solve - how to send $FE data via LCDOUT statement (it interprets $FE as command, not data transfer).
Solving this issue will help me to add ability to draw graphics to my ST7920 "Library".

[richard]

But same manual also says that array size is limited for 16F series and only limited by available RAM on 18F, so I thought that this should work fine

how can you interpret that to mean that writes involving array boundary violations are an acceptable programming technique ?

[CuriousOne]

Well, as my experience with ZX Spectrum BASIC shows (In case of array misreading: Error 3: Subscript wrong), when you do something not allowed, you will get an error message.
Even Visual Basic does that check.