I know RTFM, but why?

[Acetronics2]

Will this answer your question ?

http://www.picbasic.co.uk/forum/showthread.php?t=1078

Alain

[Jumper]

WRITE to the internal EE2 does not support writing of word sized variables to the EE2 so you have to write them as you do, byte-wise as you do in your code and then you just decide what way to store them. My problem is that I2CREAD and I2CWRITE will put the HB and LB as HB-LB if i write a single word but as LB-HB if I use the STR modifier for the same commands. Of course i can in the same way as you do switch HB and LB before using a single word read or write BUT why does PBP have this feature. Since someone put it there it must be reason for storing variables as "this order is different than the way variables are normally stored" the manual sais.
Is it possible to "HACK" the I2C commands to make them store variables in the same way? I might guess a HB and LB mixup in your fail-safe RC would create some big surprises for the pilot.

Using the page (STR) mode when writing large amounts of data saves tons of time. Writing 64 words, word by word with a 5 ms delay would take 320ms compared to 5ms if you write one page at the time (24LC512) and we all hate to wait :-)

[Acetronics2]

Hi, Jumper

Having a look to various I2C Datasheets show Word DATAs are read an sent High byte first ...

This simply could be the clever explanation you're looking for.

Back to YOUR own problem ( I do not see the reason, yet : $0000 or $FFFF do not care of byte order ... ), a look at the manual, 4.17.10 section : REV function, could enlight a really fair solution ... consuming very little time.

Alain

PS : I'll use it for my variable array storage ... thanks a lot !!!

[SteveB]

Jumper,
Why not solve your problem by always using the STR modifier? For a single word, just use something like:

a var word[8]
I2CWRITE datapin,clockpin,control,(address),[STR a\1]
.....
I2CREAD datapin,clockpin,control,(address),[STR a\1]

For X Words, use:

a var word[8]
I2CWRITE datapin,clockpin,control,(address),[STR a\X]
.....
I2CREAD datapin,clockpin,control,(address),[STR a\X]

This should keep you from having to think about which order the bytes are stored in.

Steve

[Jumper]

It seems to be a good idea as you point out to always use the STR function. Everybody sais that PbP has few bugs, I would like to call this a bug but since the manual mentions that the I2C command will return different data compared how variables are usually stored it has to be a feature :-)

Thanks for taking time to think about this and if anyone ever find a reson why PBP has decided to go this way I still would like to know.