#223 Support for EEPROM storage class?

open
nobody
None
5
2007-11-27
2007-11-27
Laszlo BORTEL
No

It would be really nice to have built in support for eeprom storage class and eeprom pointers, besides the existing ones. I would like to do things like this:

eeprom int i; //i is stored in eeprom, allocation managed by the compiler
eeprom int* eeptr; //eeptr is a pointer in eeprom address space
void main(void) {
i=123; //compiler would automatically generate eeprom write for assignment
i+=3; //compiler would automatically generate eeprom reads and writes for expression evaluation and assignment
eeptr=&i;
}

Are there plans for such feature? I think it would be a great and useful feature and knock-out any competing compiler.

Discussion

  • Logged In: YES
    user_id=589052
    Originator: NO

    > Are there plans for such feature?

    No.

    While it might look convenient on first sight
    there might be a can of worms standing nearby:

    - int or long (or data structures >8bit) only being
    partially written due to unexpected reset
    - no CRC functionality (or only with severe overhead)
    - possible premature eeprom wear-out. 1 million writes can
    easily be reached within a few hours. I would not
    trust the hardware any more!
    - encourages unstructured/difficult to maintain code
    - no option for eeprom block reads/writes
    - difficult to implement on flash (instead of EEPROM)
    - no nice point to set brake-points at
    - difficult to maintain the same addresses in eeprom
    between different source revisions (for eeprom it
    would make sense that the compiler initializes
    variables from eeprom, ...)

    ... so I'd rather not have this feature:^)

     
  • Maarten Brock
    Maarten Brock
    2007-11-27

    Logged In: YES
    user_id=888171
    Originator: NO

    I agree with Frieder. To hide the complexity of writing eeprom in a simple assignment will probably only lead to sloppy programming and premature device failure.

    Furthermore you would still need to implement the actual read and write algorithm in some special functions, because there is no universal standard way. Some mcu's have internal eeprom, others have it externally with SPI, IIC or parallel interface. And the actual protocol data to perform a read or write action will probably differ too.

    So if you have to write these functions anyway, you might as well use them in your code making eeprom access explicit.

     
  • Laszlo BORTEL
    Laszlo BORTEL
    2007-11-27

    Logged In: YES
    user_id=1063737
    Originator: YES

    While I fully understand all your concerns I still think a disciplined programmer could make good use of even the limited EEPROM variable allocation, exression evaluation and assignment functionality that I proposed. I was not thinking about fancy things like CRC, transactions, checkpointing and keeping of variable allocation between version (new version would just completely reinitialise overwrite the old EEPROM content) etc. Such additional functionality should be implemented according to the needs of the given project. I just imagined an easy way in my project to keep permanent track in EEPROM of counter statistics such as usage count, usage time, number of button presses, low battery and other relatively rare events. All of these produce low EEPROM wear. Of course it is the responsibility of the programmer not to put a loop variable into EEPROM...
    One more argument: Microchip's C30 compiler has already got similar functionality via the 'eedata' storage qualifier. This functionality is limited mainly to the EEPROM allocation, reads are done via special microcontroller features like PSV and TBLRD, writes are done by subroutines, but it is a good start to make EEPROM usage easier and more comfortable. I also understand that Microchip's compiler is not retargettable so they had an easier task.
    I expect that sooner or later EEPROM will be just another address space for the compiler and target specific read/write macros will hide the dirty complexity from the programmer.
    As first step I would very welcome the EEPROM variable allocation possibility combined with read only EEPROM access. The read-only limitation would negate some of your concerns and also ease the initial depth of the development.
    So I would like to ask you to keep this feature request open for a while and wait for other comments. And maybe implement it when the time comes in the (hopefully not too far) future if it gets support from others.

     
  • Maarten Brock
    Maarten Brock
    2007-11-27

    Logged In: YES
    user_id=888171
    Originator: NO

    If I understand you correctly you're only talking about internal eeprom. And in which memory space should the allocation take place? Code memory?

    The problem is not even that SDCC is retargetable, but that eeprom is not part of the 8051 architecture. Where should we expect it to be? What interface should be used to access it?

     
  • Laszlo BORTEL
    Laszlo BORTEL
    2007-11-27

    Logged In: YES
    user_id=1063737
    Originator: YES

    Yes, I strictly ment INTERNAL EEPROM only (external serial/parallel, SPI/I2C are definitely excluded). Internal EEPROM is available on some 8051 variants like on Atmel AT89C51Rx2 for example. Probably it is not considered part of the classic 8051 core architecture therefore there is no standardised EEPROM access - which can cause big headache. But maybe at least read access to EEPROM is (more or less) uniform via registers (like EEDATA, EEADR, EECTRL) - I do not know that much detail about currently available 8051 variants.
    I propose that EEPROM should form a new address space that can be allocated via new 'eeprom' or 'eedata' storage qualifier. It should not be mixed with code memory. Actually it is not my idea - it is the way Microchip's C30 handles it.
    I see that my feature request is not a simple one at all but its advantages are also significant in my opinion.

     
  • Patryk
    Patryk
    2007-11-28

    Logged In: YES
    user_id=1788180
    Originator: NO

    "I propose that EEPROM should form a new address space that can be
    allocated via new 'eeprom' or 'eedata' storage qualifier."
    AVR GCC supports it this way.
    Speaking about new address space - maybe it's also a solution to future request #1714870 __no_init attribute for static variables:
    http://sourceforge.net/tracker/?func=detail&atid=350599&aid=1714870&group_id=599