Close

Introducing STM8 eForth Modular Build

A project log for eForth for cheap STM8S gadgets

Turn cheap modules from AliExpress into interactive development kits!

thomasThomas 04/17/2020 at 15:097 Comments

Up to now building STM8 eForth required building and packaging all supported boards as one big monolithic block. As variants of popular boards popped up board configuration had to be added. For the W1209 thermostat board there are now 4 variants!

Some time ago I decided to add the board independent part of the STM8 eForth source together with libraries (the core) together with the binary release. Additionally I factored the Makefile, and the most core is also in the distribution.

It's now possible to create a new board with some files, including build automation with Travis-CI (the MODBUS project was the first to use it).

To illustrate the approach I made a demonstrator with, well, a DEMO board:

Using it is really easy. Enjoy!

Discussions

Andrew Clapp wrote 04/18/2020 at 18:18 point

It seems that PERSIST is to RESET as NVM is to COLD, but are they essentially both implemented at the same level?

  Are you sure? yes | no

Thomas wrote 04/18/2020 at 18:44 point

NVM is the counterpart of RAM - it changes where dictionaries will grow. NVM needs RAM to make dictionary pointers permanent. COLD without RAM will abandon the changes.

RESET removes all words compiled with NVM, and also the 'BOOT vector by loading pointers from a set of shadow pointers. PERSIST copies the current pointers to the shadow pointers, and the next RESET will restore that state.

  Are you sure? yes | no

Andrew Clapp wrote 04/18/2020 at 18:10 point

I'm hoping to run some version of forth on my teensy 3.2 soon.  They use Cortex M4's.  After reading some of the reading materials about forth, and particularly the works of C. H. Ting, I'm thinking I may attempt it as a learning exercise, eventually.

  Are you sure? yes | no

Thomas wrote 04/18/2020 at 19:04 point

eForth is very lean but also a bit "vintage". For STM8 and other "80s style" platforms that "classical touch" is actually good as the system is really lean. One of the more difficult parts to solve for turning the bare STM8EF into something "useful" was dealing with Flash memory. I guess that's not much different in a ARM-Cortex system.

When using a Cortex M4 systems like MECRISP-Stellaris lead the way ( check out @Elliot Williams HaD Edition https://github.com/hexagon5un/hackaday-forth). If you're interested a "fresh start" you might want to have a look at @Travis Bemann 's ZeptoForth.

  Are you sure? yes | no

Travis Bemann wrote 04/19/2020 at 15:53 point

Thanks for the mention! I should note though if one wants a finished, complete Forth implementation that supports a wide range of MCUs/boards, go with Mecrisp-Stellaris. zeptoforth is still very much a work in progress and only fully supports the STM32L476 DISCOVERY and STM32F407 DISCOVERY boards. That said, I would very much appreciate people trying it out, and I would especially appreciate people porting it to other MCUs/boards.

  Are you sure? yes | no

Andrew Clapp wrote 04/17/2020 at 21:53 point

Thomas, you are doing really good things here.  I was able to use this and take a project I had been building off of a modified stm8ef tree for a mindev board, and convert it to this method in no time.  It's also super cool that I'm using sdcc on linux and your Makefile basically worked right out of the box.  I'll definitely be using this in the future and adding some notes about it on my projects.  

  Are you sure? yes | no

Thomas wrote 04/18/2020 at 18:06 point

Thanks a lot for testing this and for writing a log entry in your HaD project!
It looks like this little Forth is now closer to Arduino-grade ease of use than ever, and for automated deployment it's already one step beyond :-) 

  Are you sure? yes | no