Ideas for structuring a modular embedded system

[niclash]

I would like to get some ideas on how to go about setting up my Forth in a modular embedded environment.

1. There is a motherboard with power supply, connectors, one MCU slot and 1-7 expansion slots, plus I2C and SPI multiplexers to select which expansion slot is connected to the MCU slot.
2. The MCU slot (at the moment) is a STM32WLE5, which is running Mecrisp Stellaris forth in parallel with the STM32CubeWL library for LoraWAN.
3. Each module for the expansion slots have an EEPROM of 8kB (on I2C), where I intend to put the Forth program (in clear text) that is needed to handle that module. This allows for adding more modules in the future, without the MCU knowing about those module types.

The applications are not time critical, and at first I thought; "Just read the Forth code from the EEPROM and execute it as interactive code". But then I realized "Oh, then I can't do loops and IFs". So how about "Code in EEPROM is word definitions and we load those on power-up into RAM and execute in each 'tick'" but then I realize that those will collide with each other, since it is allowed that many identical expansion modules can be put in the same device, and variables used would collide (but perhaps know that a variable always need to exist in many copies and be addressed according to which expansion slot that is active)

I would be interested to hear about any ideas on how to structure this code wise.

Here is a photo of one of the hardware motherboards, and the software is at https://github.com/niclash/colibri-1dp-mcu1

Example expansion module (back and front);

[MitchBradley]

IEEE Standard 1275-1994 AKA "Open Firmware" is a complete solution to this problem, but probably more extensive that you might be looking for. There is an implementation of Open Firmware at https://github.com/MitchBradley/openfirmware . The basic idea is that each expansion slot has an "FCode" ROM. FCode is a tokenized form of Forth. The system creates a "device tree" with interior nodes for every (possibly nested) expansion bus and leaf nodes for non-bus devices. For expansion slots, the system interprets the FCode program to create a node with methods (Forth words) for driving the device. Those methods live within a namespace private to the node; essentially a separate Forth vocabulary. The device methods can call methods of their parent node in order to perform bus-dependent actions, system methods to perform more generic actions, and methods of support libraries to do things like networking and file system decoding.

Different classes of devices implement specific method names according to their function. For example, mass storage device drivers implement read-blocks and write-blocks methods that serve as the low-level primitives for file system packages, while display drivers implement raster and text operations for use by terminal emulation code.

Open Firmware is well-elaborated, well-tested code that, in its heyday, was used on millions of computers from many different manufacturers. Its device description framework is still alive as the "device tree" that configures Linux on ARM computers.

[MitchBradley]

The Open Firmware implementation cited above sits atop two Forth implementations. The first is a full-featured metacompiled assembly language Forth with versions for at least ARM (32 and 64 bit), x86, SPARC, MIPS, Alpha, PA-RISC, and PowerPC. That Forth system in included in the Open Firmware source tree. The second is cforth (https://github.com/MitchBradley/cforth), a full-featured, efficient Forth written in C, which runs on anything with a C compiler - in short, anything with enough ROM and RAM to support the application requirements. I once gave an Open Firmware training class at Oracle, where each student had a $5 ESP32 module running Open Firmware on cforth. One of the class projects was to write an Open Firmware driver to control a robot car and drive it wirelessly over a web interface.

[quozl]

I agree, Open Firmware would be suitable for the scenario described. It should be possible to shim Open Firmware on top of Mecrisp Stellaris. Clear text could work, but is luxurious. It would depend on the relative size of the 8kb vs the functionality required, and possibly the time to interpret.

I'm available for Open Firmware engineering work. Contact me for quotes or with jobs.

[niclash]

Functionality in on-board EEPROM is for accessing the hardware and handover to an "idealized model" of the outside world. So, typically how to read out values via I2C and how to convert that to a reasonable format.

Sorry, don't have budget for contractors, this is part personal project, part experiment and part "possible startup idea".

[MitchBradley]

@quozl has my full recommendation for work related to Open Firmware. He maintained the version that is used on the One Laptop Per Child computers - which is the most complete and extensive version ever - for many years.

[niclash]

Thanks. I think the key to my issue is lying in this sentence; "Those methods live within a namespace private to the node; essentially a separate Forth vocabulary. "

"Vocabulary" isn't something that I have ever thought of (I have previously only written a couple of games back in early 1980s). Need to study some more.

As for "ESP32" --> Yes I have plenty of experience with it (even personally know the CEO and Founder of Espressif), but the STM32WLE5 has only 64kB (compared to 520kB) of RAM and only 256kB (compared to 1MB+) of Flash, and the LoraWAN stack consumes nearly half of the RAM and Flash. So, I need to be frugal. And changing to another Forth is out of the question, after taking the time to get Mecrisp-Stellaris to run on this variant, and does so very very well.

However; I also have an MCU module with ESP32-S3 in prototyping, intended for ESPHome enthusiasts, where I may come back to this.