-
I know RTFM, but why?
Hi,
I am storing word-sized variables in an External EE2 using I2C and later reading them back for use later. Can anyone explain why if you write/read one word it is stored and read back HB first, LB last but if you use the STR modifier you store and read back LB first, then HB. So if I load an array by stepping thru the adresses in a for-next loop i get HB,LB stored in my array variable. If i instead READ the same adresses straight into the array with STR the result is LB,HB. What you gain in speed you loose in ........
It is usually hard enough to remember where things get stored but this way you also have to remember how they got there and how to get them back or you will get the HB and LB mixed.
RTFM is not the answer i am looking for. How do others do when they mix page modes and reading and writing single words. Of course you can change HB and LB before useing the single word I2CREAD and I2CWRITE so the result in the EE2 is always the same (LB,HB).
Since these finstructions are made by someone much more clever than me there must be a really great reason for it, I'd love to know it.
-
Not in the manual
-
Not really :-)
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 :-)
-
PbP joker
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 !!!
-
Jumper,
Why not solve your problem by always using the STR modifier? For a single word, just use something like:
Code:
a var word[8]
I2CWRITE datapin,clockpin,control,(address),[STR a\1]
.....
I2CREAD datapin,clockpin,control,(address),[STR a\1]
For X Words, use:
Code:
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
-
I will
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.
