eForth for cheap STM8S gadgets

After one year of STM8EF development this release marks an important point: a community begins to form!

• @RigTig contributed code that replaces the dictionary (and most of the compiler code) in Flash with Alias definitions and code in RAM (refer to issue #26 and barebones.fs). All the necessary build switches are in the master branch.
• RigTig reported issue #28: COMPILE sometimes failed when dealing with words in RAM. This is fixed.
• The COMPILE fix was more than compensated by binary size reductions CORE is down to 4040 bytes (from 4087), MINDEV fits in 4963 bytes (5005 before). Guess who spotted potential for optimizations...
• Better comments (issues #36, #34).

Thanks to all contributors for code, comments, and bug reports: @RigTig, @Elliot Williams, @Roy

@RigTig found a very nasty bug that only bites advanced Forthers: the STM8EF compiler uses CALLR (2 bytes) instead of CALL (3 bytes) when called words are within reach of relative addressing. However, the COMPILE instruction, that's normally used in "immediately executed code" (the kind of code in which the Forth compiler is written), assumes that a 3 bytes (absolute) CALL is used. It took a while until I understood what's the issue. Thanks for the patience!

The bug is now fixed, and the additional code was compensated by optimizations (the binary size is still the same).

When I fixed the bug I used uCsim by Dániel Drótos. The latest development version of uCsim has UART support and the MINDEV, CORE, or STM8S105K4 binaries work out of the box (this also means you don't need hardware for testing STM8EF).

Board XH-M188 (Issue #29)

@Elliot Williams contributed initial support for the board XH-M188. Thanks a bunch!

After removing the socketed 7S-LED display the board offers a GPIO breakout, and standard RxD/TxD communication ports.

ALIAS Feature (Issue #26, #27)

@RigTig needs more free Flash memory for his main project. As Forth headers require a lot of memory he proposed loading Forth headers to RAM. With the help of some minor changes to forth.asm (e.g. enhanced NAME>) about 2000 bytes of Flash memory can be recovered. Please refer to the discussion in #27.

Words last and NAME> used in RECURSE example linked

The recursive programming example requires last and NAME> to be exposed. That's fixed now.

Binaries are here - Happy hacking!

Issue #27 on GitHub discusses use case, requirement, and solutions:

• Introduce assembler features
• Extend the compiler (tail call optimization)
• Introduce the ALIAS word class
• Mix STC with DTC (using ALIAS words), or ITC (using a Inner Interpreter)
• Malleable dictionaries
• and more

If Java is like coffee to make you type faster then Forth is like LSD which makes you see solutions in the fractal complexity of the universe!

EDIT: RigTig used the alias method to create a lean-and-mean configuration for the W1209 board: it fits in about 3.5KiB code, almost 2KiB less than the normal W1209 variant, LED display code included!

Check it out here.

The C0135 "Relay-4" board has 4 relays (duh), 4 inputs, and is based on the STM8S103F3P6 (the lower spec STM8S003F3P6 would have done the job just as well).

I now updated the docs in the GitHub Wiki, and added some example Forth code that demonstrates how to use it as a heating / neutral / cooling temperature control (as if there wouldn't be enough Chinese STM8S003F3P6 based thermostats boards).

By the way, right now this board is available on AliExpress for just $7.67, which isn't a bad price for a "Nano PLC.

The HC12 is a Si4463 based RS232-RF modem in 433 ISM band. Compared with the average garage door remote RF solution the Si4463 is much more advanced (range, modulation modes, immunity to noise). It has so many features that the normal way to program it is to use a code generator provided by Silicon Labs, the manufacturer of the chip.

The other chip on the board is an STM8S003F3P6, and that's why I write about it. Some time ago @ajlitt forked the STM8EF repository to work on the HC12. He did the reverse engineering, and wrote first code to make the STM8S talk to the Si4463 (a mix of board-support code, and Forth). However, he had planned to implement a packet radio protocol that needs more RAM than the STM8S has to offer.

I have a much more humble use case: bring Forth into the STM8S of the HC12, and have it communicate with an off-the-shelf HC12 through the Si4463 radio.

Some time ago I ordered 3 x HC12 modules that now have the following roles:

• one with unmodified firmware connected a logic analyzer
• one serving as development target
• one with unmodified firmware as a reference

The HC12 connected to the logic analyzer is necessary to understand, and re-implement the Si4463 API calls and parameters.

I now implement the initialization, and the communication routines. There is an "issue", and some docs on GitHub.

The W1701 is a cheap thermostat that's designed as a "set-and-forget" temperature controller.

At a price of $2.22 it's more expensive than the W1209 ($1.41), and only a bit cheaper than the surprisingly well designed W1401 ($2.48).

The module comes without operating instructions - but that isn't the point - I wanted to find out if it can be used as cheap programmable control device. Of course it can be used (here are the details - if anybody needs code, please let me know), but it lacks the versatility of its more generously designed siblings, even if it's more expensive, and looks like it could be produced for less than $1. It's needless to say that it should never be used for high voltage.

The W1701 is an ugly duckling that won't turn into a swan. I consider it a collector's item.

EDIT: I just closed the "enhancement" issue on GitHub for W1701 board support with "won't fix". However, I also published some Forth code, and a W1701 SWIMCOM binary with initialization, OUT!, and DIP. For collectors, or for those who really need a board that can be configured with DIP switches.

I've had a nice new specimen of Chinese power-circuit-bending on my desk: the W1209WK. The schematics is a good demonstration of "what not to do with a µC and a LED", even more so than the venerable "DC/DC with Voltmeter".

It was quite challenging to work around the worst quirks of the circuit, but the board is now documented, and there is preliminary board support.

In the last log entry I described a feature for number and text output on grouped (structured) 7S-LED displays. In this log entry I'd like to give an example of how easy presenting information is.

The XH-W1401 module has a 7S-LED display grouped in 3 x 2 digits (yellow, large red, yellow). There is no decimal point, but that's a different story.

The following code displays different types of information on the different sections:

FILE
: timer TIM 655 / ;
: ain 5 ADC! ADC@ 100 1023 */ ;
: show timer . ain . BKEY . CR ;
HAND

The word timer returns the 16 bit ticker value scaled to 0..99, and the word ain does the same for the analog input (on the sensor header). show displays the values of timer, ain, and the board key bitmap code from BKEY followed by a CR (new line).

The following session demonstrates the feature:

show 19 28 0
 ok
' show bg !

Calling show directly sends the output to the console. Running the same word in the background displays the values of timer on the left red 7S-LED group, ain on the middle red LEDs, and the board key bitmap on the right yellow group.

Board support code in TG9541/STM8EF has supported boards with 3 or 4 digit LED displays for several months now, and output of text (e.g. numbers) on a LED display is simple.

However, since support for the W1401 was added, there are now devices with "structured" LED displays. With "structured" I mean different color, size, or grouped in rows or columns.

As an application programmer I want character output to be simple, and I want the code to look the same no matter if it outputs to the console or to grouped digits of LED displays (that's also important for testing). In the future there might be devices with LCDs, or serial data output, and code should "just work".

The easiest way to achieve that, is to use whitespace as some kind of "output element separator" ("." and ".R" should have the same effect). <CR> can act as "return to first element". Of course, this will make the code more complicated than simply spilling text over to the next digit, no matter where it is, but it will make writing applications a lot easier.

If someone has a different idea how to do it, I'd like to hear about it!

EDIT1: OK, since I didn't hear about it, I implemented a prototype. It works quite well, but an extra state is necessary to handle CR consistently (whitespace or CR should move to the next display group only once).

EDIT2: I tested the feature on boards with 1, 2, and 3 display groups, and updated the W1219 and W1401 docs on GitHub. Output of numbers and character strings on grouped LED displays is now really easy!