EEprom size

[stevech]

It would be handy to have something like
register.EEsize

to return the size of the on-AVR-chip EEProm for the target chip.

[dkinzer]

Providing Register.PersistentStart and Register.PersistentSize would be more consistent with existing elements (e.g. Register.RamStart and Register.RamSize).

This can be done but it will have to be deferred until a later release.

[stevech]

bueno

I also assume that the VM uses none of the on-chip EEPROM.

[dkinzer]

Actually, 32 bytes of Persistent Memory (on-board EEPROM), beginning at address 0, is reserved for system use. The remainder (992 and 2016 bytes for mega32-based and mega644-based devices, respectively) is available for user programs.

This is described in the appendices of the reference manual, e.g. http://www.zbasic.net/doc/ZBasicRef.php?page=103. It doesn't explicitly state that the reserved Persistent Memory begins at zero but otherwise conveys the information above.

The reserved Persistent Memory is used for things like the "first time" flag, external EEPROM configuration and exception data.

If you plan to access persistent memory directly, you are well-advised to use addresses toward the upper end rather than toward the lower end. When you define Persistent variables, they are allocated beginning at address 32 and working upward. Depending on the particulars of your program, a good starting address might be 100 (hex or decimal).

[stevech]

ah, thanks. I missed that and have been using that area of on-chip eeprom.

I have to use the low level get/put routines because I'm storing arrays of strings or structures containing strings. So for now, as a hack, I copy the characters in the string to an array of bytes inside the structure. then put() the structure to a given rolling address in on-chip eeprom (persistent memory). This is a "history" of the last n events.

I think I'll start my storage at 1+ the address of a one-byte persistentbyte that I declare so I don't code a hard number.

Also - as I recall now, ubound() and lbound() don't work for a byte array within a structure, but sizeof() does.

[stevech]

Re what part of on-chip EEPROM (persistent memory) is unavailable to user program... I coded

dim historyEvents(0 to historyEventsIndexMax) as persistentbyte

historyEvents.dataAddress is 33. This matches what you said.
So I store structures via putPersistent(), at an offset from using
historyEvents.dataAddress. (Can't declare persistentStructure!)

Each structure is a history event. They're stored in a rolling manner through EEPROM, with an ascension number in each. At RESET, I find the youngest record (largest ascension number) in EEPROM and start overwriting backwards from there with new records. The ascension number sequence is continued across a RESET. (I erase the EEPROM area to all ones one-time and check for that "empty" condition too).

I wonder if this could be done in the ZBasic external EEPROM program memory too. But the on-chip is large enough for this application.

This should, I think, accomodate any future changes in the VM, without recompiling my program.

[mikep]

[dkinzer]

[stevech]

Suggest you reference the system-used persistent memory on-chip EEPROM restrictions in the putPersistent() writeup and the description of the persistent data types.