In NVM mode VARIABLE and ALLOT should refer to RAM storage

[TG9541]

Provide a convenient way for defining variables that work in ROM code:

• the behavior of VARIABLE shall be transparent in a programming / debug / test cycle
• ALLOT shall allocate variable memory when in NVM mode
• pointers to variable memory for Forth code in Flash shall be made persistent when switching modes from NVM to RAM

The behavior of ALLOT will be different in NVM mode, since HERE and the RAM pointer are not the same. A new word for the current RAM location (maybe THERE ?) is required.
See the comments in #5 for more details.

[TG9541]

VARIABLE faces the small problem that in order to avoid an extra level of indirection it must change the pointer to the storage address in RAM, much like DOES> does.

[TG9541]

94d49aa achieves the necessary extra level of indirection for code in ROM by replacing DOVAR with DOVAR @.

"Variables in RAM" works in the following way:

• The Flash location COLDCTOP contains the first free RAM location for variables
• USRVAR is initialized by COLDCTOP @
• USRCP is initialized by 32 COLDCTOP @ + (32 represents the size of the variable RAM pool below the user dictionary in RAM)
• a copy of the new initial USRCP value is stored in USRCTOP for re-linking the Flash vocabulary when the compile memory mode changes from NVM to RAM
• new vocabulary in Flash is re-linked to the RAM address indicated by USRCTOP (instead of linking to the fixed address CTOP, i.e. 0x0080)
• in NVM mode, ALLOT increments USRVAR (instead of USRCP in RAM mode)
• in NVM mode, VARIABLE rewrites the "code field" of CREATE so that an extra level of indirection is applied
• when changing to RAM mode, USRVAR is stored in COLDCTOP for the next COLD or reset cycle

The feature works transparently if the following programming workflow is used:

1. start a session by flashing the µC, or reset
2. write some test code in RAM mode, define and use RAM mode helper words like IVEC!, or define startup words
3. run COLD
4. run NVM to define words or variables in Flash memory
5. run RAM to make pointers to the newly defined words, and also to variable RAM allocation persistent
6. return to 2. (test your code, preferably automated), or to 4. (write more persistent code)

The new feature currently requires about 80 bytes Flash memory but I think that it can be reduced to about 60 bytes.

Here are preview binaries: stm8ef-bin.zip

[TG9541]

v2.2.8.1.snapshot and the develop branch contain a pre-release of the new feature.

[hexagon5un]

This is awesome! I actually encountered this problem in some code and solved it by simply choosing a RAM slot near the end of memory and using it directly. Not pretty, but it worked.

I'll have to try this out soon, when I get some free cycles.

[TG9541]

@hexagon5un RigTig on Hackaday.io already did some preliminary testing. It would be great if you could give it a spin, too!
I also managed to fully compensate the Flash memory needed for the VARIABLE feature, and it's now enabled by default.

[TG9541]

The feature is described in the Wiki here, and in the Hackaday project here.

[TG9541]

Merged to master in release 16 (version v2.2.8).