Close

Release 0.4.0

A project log for zeptoforth

A full-featured Forth-based RTOS for ARM Cortex-M

travis-bemannTravis Bemann 04/22/2020 at 02:006 Comments

This release reorganizes the words that related to HERE, so that by default the unmarked words using HERE now use the HERE related to the current compilation mode, and that words that use a specific HERE are explicitly marked with RAM or with FLASH. Note that this does not affect words which do not use HERE, e.g. !, CURRENT!, and FLASH! stay as is. Additionally, more documentation has been added, particularly with regard to multitasking and scheduling.

Discussions

Thomas wrote 04/22/2020 at 05:57 point

When I developed a solution to the HERE dependency I found that one easily overlooks edge cases. A bit of a challenge was VARIABLE. Are you aware of a standard or could you identify a best practice?

  Are you sure? yes | no

Travis Bemann wrote 04/22/2020 at 12:51 point

I am not aware of any (ANS to my knowledge ignores the issues associated with flash memory). My solution was to save the future address of the VARIABLE in flash, then apply all the allotted space for the VARIABLEs at the following reboot. This has worked well for me.

  Are you sure? yes | no

Thomas wrote 04/22/2020 at 19:16 point

That's certainly a good solution for a µC with a fair amount of RAM. Does that mean that you have to erase/write Flash locations often or do you use some kind of log that's flushed every so often?
In STM8 eForth I decided to keep pointers in RAM when in NVM (Flash) mode. Some users had problems with that approach (read: lost changes until the cycle was understood).

  Are you sure? yes | no

Travis Bemann wrote 04/23/2020 at 21:22 point

What I meant is that I precalculate the future address of the VARIABLE in RAM and write that too flash, and then when I reboot I find the last of these precalculated address and ALLOT the memory space for the variables accordingly.

  Are you sure? yes | no

Thomas wrote 04/24/2020 at 05:55 point

STM8 eForth also pre-allots memory but there is a catch: as the dictionary in RAM grows from the bottom and the stack grows from the top (with the pad in the middle), I decided to reserve some memory below the dictionary (but not by using ALLOT, which I will look into). A COLD start (or a semi-warm WIPE) then places the start address for the dictionary again above that memory area used by VARIABLE. The catch is that sometimes WIPE or COLD has to be run before using VARIABLE memory that otherwise would overlap with the (temporary) dictionary in RAM. Variables defined in RAM mode are embedded in the dictionary and can be used right away (there is a direct variant of DOVAR for RAM and an indirect one for Flash memory).

  Are you sure? yes | no

Travis Bemann wrote 04/26/2020 at 16:01 point

I actually think how zeptoforth and STM eForth do things are quite similar here. zeptoforth allocates space for VARIABLEs allocated during flash compilation at the bottom of the main task's dictionary and only ALLOTs space for them on REBOOT. Note that VARIABLEs allocated during RAM are allocated at the top of the dictionary for the current task. Additionally USER variables are ALLOTed from the bottom of each task's dictionary when it is created, except for the main task, where it is ALLOTed after the flash-allocated VARIABLEs are ALLOTed.

  Are you sure? yes | no