EEPROM:- possible to read/write bit by bit rather than byte by byte?

moorea21

Senior Member
It struck me today that, if it were possible, it might be handy to store and retrieve information from a picaxe eeprom bit by bit, rather than byte by byte, if memory space was an issue.
Is this possible to do directly? Or would it involve concatenating the 'bits' into bytes, in order to write them to the eeprom, and then decoding them afterwards for reading/using? For instance, instead of storing decimal 31, 4, 3 as separate bytes, I could simply write '11111111' to the eeprom, and then chop it into the correct word lengths in code to extract the data. Would be handy if I could address each bit individually though, as 31, 4, 4 would overrun into the next byte...
 

lbenson

Senior Member
The first 32 bits of RAM are individually addressable as bit0-bit31. These are the constituant bits of b0-b3, and/or w0 and w1. EEprom cannot be addressed by bit, but you can read eeprom bytes or words into, for instance, b0 or w0 and then either access the bits individually or with further mathematical manipulation, break out groups of bits.

If your strings of bits are variable in length, then you need to know how each chunk is to be handled. With fixed-length chunks, it would be easier. For instance, if all of your values were between 0 and 31, you could handle the data as "nybbles" (half a byte). So you retrieve your eeprom data into b0, and then say "var1 = b0 / 32", and "var2 = b0 & $0f".

In what circumstance do you envision needing to do this? If you run out of eeprom, for 2 data lines you can add an i2c eeprom, and for one data line you can add a UNI-IO device and use UNIIN and UNIOUT.
 

moorea21

Senior Member
About 2 years ago I designed a circuit using a 20m2, that ended up needing a lot of memory to work, and it was suggested that storing data in the eeprom would help. I recently built the circuit with a view to testing how much data I can pack into the onboard eeprom. I had thought of using "nybbles", although I had no idea they had a name.

I'm not sure I understand "var1 = b0 / 32", and "var2 = b0 & $0f"...

var1 = b0 / 32
var2 = b0 & $0f

Does dividing a byte by 32 return the first 4 bits? Not sure what '& $0f' is, although 0f I assume is a hex address? If this divides a byte into 'nybbles' and assigns their values to variables, then that's exactly what I was looking for.

Thanks for that.
 

hippy

Technical Support
Staff member
That divide by 32 was I think just an inadvertent mistake. Nibbles are 4-bit and hold values 0 to 15.

var1 = b0 / 16
var2 = b0 // 16

or

var1 = b0 / 16
var2 = b0 & 15

will get the top 4-bits into var1, the lowest 4-bits into var2. That 15 can also be represented as $0F or %00001111.
 

moorea21

Senior Member
Actually, would this be possible?

var1 = b0 / 32
var2 = b0 // 32

so that var 1 could be 0 -31 and var2 0-7?
 

hippy

Technical Support
Staff member
That would work but var1 would be 0-7, var2 would be 0-31

256 / 32 = 8 => 0 to 7
 

AllyCat

Senior Member
Hi,

..ended up needing a lot of memory to work, and it was suggested that storing data in the eeprom would help.
That's not often worthwhile. The 20M2 has 512 bytes of RAM (addressable via PEEK/POKE or @bptr) which are as easy to use as READ/WRITE. There are only 256 bytes of EEPROM (plus another 256 of TABLE for Read Only). Then there are the 6 or more S_Wx word variables and bptr, etc..

Also beware of using EEPROM as "RAM" because it may ultimately "wear out". Sometimes it's better to group bits or even bytes together before writing to EEPROM, because the write operation may involve an erase/write cycle of a "block" of multiple (e.g. 16) bytes.

Cheers, Alan.
 

hippy

Technical Support
Staff member
Bottom line is that the best way to do something can only really be determined from what one is actually trying to do. And even then 'best' can rest on a whole range of things which may pull in opposite direction; speed, compactness, cost, complexity, effort.

The original notion of packing data into EEPROM ( or RAM or Scratchpad ) is valid, but it will usually require more program code to handle that data and that will take longer to execute. There are potential optimisations but that depends on the nature of the data itself. Fixed sizes will usually be easier to handle than variable sizes, but that might not maximise data storage.
 

moorea21

Senior Member
Just replied but it doesnt seem to have appeared, trying again:

The problem of running out of memory with the original software I wrote was largely due to my poor coding skills; it turned out to be possible to compact it down from the approx. 2500 bytes I started with, but there was still a problem finding space for all the read only data that was needed, hence using the eeprom. As it's read only, it might be an idea to use eeprom table;- not looked into that yet.

As it happens, I'm having to rethink the code from scratch anyway, as the analogue side of things isn't working as I expected, so I'm unable to be specific about what memory will be required. Rewriting to account for all the new variability due to the analogue sensors being a lot more complicated than I thought means it's definitely going to need more memory than before though, hence asking about how to wring the most use out of a byte.
 
Top