eForth for cheap STM8S gadgets

What is it?

STM8 eForth is among the smallest user friendly Forth systems for µCs: it brings the simplicity of a 1980s style Forth to today's low-cost controllers. The project provides code for STM8 variants, board support for selected low cost targets, and docs. STM8 eForth has a long feature list but it uses very little memory. Innovative solutions, steady support, and an active community makes using it for new projects easy!

The code and binaries on GitHub can be used in many ways:

as an alternative firmware for Chinese commodity boards (e.g. thermostats, DCDC converters, and relay boards)
build embedded systems with an interactive shell (scriptable and extensible)
for creating smart sensors with SPI, I2C, or RS232 and a scripting shell, e.g. for RaspberryPi, Arduino, or ESP8266
as an interactive environment for exploring the STM8 architecture
for learning Forth - it's easy and fun (find out why in the text below!)
...

Why a Forth for Cheap Chinese boards?

Because it's fun: cheap mass-produced imperfection is a playground for creativity :-)

The W1209 has long been my favourite target: it's a rather complete embedded control board with a UI at a very good price. It's as cheap as it looks, and the challenge is in it's imperfections: the guy who designed the board clearly didn't have a connected application in mind, and I had a lot of fun making it do things it was never intended to do.

There are challenges, like the lack of communication ports. The "sensor connector" can either be used as a a 2-wire RS232 "bus" or for sensing. If you need sensing and communication at the same time the project also provides a full-duplex 3-wire RS232 interface through the key pins (while keeping the keys functional). A plug-in system makes it easy to test new ideas, like using the "update connector" as a home brew field bus interface!

Which target boards are supported?

Besides generic targets for STM8S001, STM8S103, STM8S105, STM8S207 and STM8L051, there is currently support for the following boards:

Some more boards can be supported on request, e.g.

@Elliot Williams worked on using the ESP-14 as an IoT deviced (the ESP-14 module combines an ESP8266 with an STM8S003F3P6).

Programmable power supplies based on the XH-M188 and a cheap DC/DC converter are both work in progress. There are also several types of STM8S003F3 based voltmeters that are known to work.

Read more about possible future targets below.

Why Forth?

Again, because it's fun!

Forth starts out as a stack machine with a tiny instruction set and minimal hardware requirements. It fits in a few KiB, and the target, even a lowly µC, can even be used as the development system. The Forth stack machine is a minimalistic VM on a standard CPU, but there are also hardware implementations (e.g. for FPGAs, or a 144 core Forth processor). The VM is ideal for fast context switching and Forth easily meets hard-real-time requirements. It's no surprise that Forth was used in many NASA projects.

Consider this:

compared to other programming environments Forth is easy to understand fully
like Lisp, Forth has a REPL (Read-Evaluate-Print-Loop) which enables software testing in a way impossible with "Edit-Compile-Run-Debug" (e.g. Arduino)
it's easy to build Domain Specific Languages (one can literally program the compiler!)
the stack-oriented "factoring" method results in implicit data flow and modular code
Interpreter-compiler, basic OS functions fit in just 4K code :-)

A Forth programmer is in control of all levels of problem abstraction, a unique advantage in a...

STM8 eForth "Build-Test" moves from Travis-CI to GitHub Actions

Thomas • 02/21/2022 at 06:56 • 0 comments

The free services for Open Source projects by Travis-CI.org were terminated last summer. Since I had a lot of things to do in other projects I didn't "immediately" realize it. Instead of migrating to Travis-CI.com it made much more sense to move on to GitHub Actions, which, of course, required a bit of space in my brain for different concepts yet to be learned. Plenty of reasons to wait a bit longer...

OK, finally I did that step. It turned out that using a Docker container (with tool chain and µC emulator based test environment) for building and testing an embedded Forth was a very good choice. It "survived" hundreds of deployments, several major host OS and tool chain upgrades and when changing the CI provider (from Travis-CI to GitHub Actions) it was the least of my concerns.

All it takes (really!) is to add an Action file to .github/workflows. Building and testing STM8 eForth in a Docker container soon worked. The build steps for publishing binaries to GitHub Releases was a bit harder. Here is the result:

name: build-test
on: [push]
jobs:
  Build-Test-Release:
    runs-on: ubuntu-latest
    container: tg9541/docker-sdcc:V3.9.0
    steps:
      - run: |
          echo "triggered by: ${{ github.event_name }}"
          echo "repository:   ${{ github.repository }}"
          echo "branch name:  ${{ github.ref }}"
      - name: Check out repository code
        uses: actions/checkout@v2
      - name: Build and test
        run: |
          echo "; ##########################################" >> forth.asm
          echo "; # Release info added by GitHub action:"     >> forth.asm
          echo "; #   repository:   ${{ github.repository }}" >> forth.asm
          echo "; #   branch name:  ${{ github.ref }}"        >> forth.asm
          echo "; #   sha:   ${{ github.sha }}"               >> forth.asm
          echo "; ##########################################" >> forth.asm
          make BOARD=test forth
          make clean
          make all
          echo "Job status: ${{ job.status }}."
      - name: GH Release
        uses: softprops/action-gh-release@v0.1.14
        if: startsWith(github.ref, 'refs/tags/')
        with:
          files: |
            out/stm8ef-bin.zip
            out/stm8ef-bin.tgz
            out/stm8ef-rst.tgz
      - name: Keep non-release binaries
        uses: softprops/action-gh-release@v0.1.14
        if: (! startsWith(github.ref, 'refs/tags/'))
        with:
          tag_name: volatile
          files: |
            out/stm8ef-bin.zip
            out/stm8ef-bin.tgz
            out/stm8ef-rst.tgz

I decided to use the plugin "GH Release" from the "Actions Marketplace" for publishing binaries to GitHub Releases. It's well maintained and has a good set of features. After I realized that I can use the publish step from inside a Docker container, publishing the STM8 eForth 2.2.29-pre1 worked like charm. Nice.

The step "Build and test" does the obvious but it also appends version information to the file forth.asm in the workspace. The reason for this is simply that I decided to upload binaries from any non-tag push to the default Git tag "volatile" - and after downloading a binary from the Volatile Release you might want to know what exactly you're looking at, e.g.:

; ##########################################
; # Release info added by GitHub action:
; #   repository:   TG9541/stm8ef
; #   branch name:  refs/heads/master
; #   sha:   8ee3453ce577181ef5e9bddda94f56d448dbf962
; ##########################################

You can use the "sha" field to construct a GitHub URL to the precise version like this:
https://github.com/TG9541/stm8ef/commit/8ee3453ce577181ef5e9bddda94f56d448dbf962

Chat with Chuck Moore in the Forth2020 Zoom Meeting
Thomas • 10/06/2021 at 20:32 • 0 comments

Next Saturday, 9/Oct/2021, Chuck Moore, the father of Forth, will be the guest star of the Forth2020 user group Zoom meeting!

Peter Forth, the organizer of the meeting, told me that all Forthers are welcome!
We're at STM8 eForth 2.2.28 now ... :-)
Thomas • 05/14/2021 at 07:49 • 1 comment

With release STM8 eForth 2.2.28 this "Small Forth" is more "Forth-Standard" leaning. One notable change is the usage of the POSTPONE method instead of COMPILE and [COMPILE]. In fact, the new method for extending the Forth compiler is not only more elegant, it's also more code efficient. The words DEFER ... IS were added - these words facilitate an interactive stile of top-down programming.

Since this is an embedded Forth for small µCs full standard compliance will be out of reach unless there is a standard for implementations that keep their dictionary in an executable ROM. Where code size or speed is concerned compatibility will always be an option to facilitate porting code. A good example is using 1-Wire code for DS18B20 that Brad Rodriguez wrote for CamelForth.

There is an open issue that collects small Forth-Standard compatibility additions.
So far we're here:

One notable difference will be "pictured number output": Forth Standard compliance requires # ( ud -- ud) instead of # ( u -- u) (double instead of single math). Although this increases the code size only marginally it makes printing numbers in a background process slower. Instead there will be a change in the upcoming release 2.2.29 that speeds up printing numbers (by a factor of 2.5 to 7). Words for dealing with double numbers will be added as an option.
Another notable change is a re-write of CREATE ... DOES> that makes using this key feature both code efficient and fast.
STM8 eForth 2.2.27 released
Thomas • 03/15/2021 at 18:51 • 0 comments

Last week I released the 27th release of the this Small Forth for simple µCs (by today's standards - what's "simple" today would have been the stuff of dreams in the 1990s).

STM8 eForth 2.2.27 contains nifty features, e.g. an easy to use "compiler overlay" for structure words (e.g. IF ... ELSE ... THEN) with relative branches. This is useful for e.g. for the ISR programming or for relocatable code. Mixing Forth code with assembler instructions is now an really easy thing to do.

That 40 years old bug in UM/MOD I wrote about the other day: it's been fixed now, but it almost deserves a place in a museum of computer history!
Using the 1-Wire Thermometer Chip DS18B20 with STM8 eForth
Thomas • 03/04/2021 at 20:12 • 0 comments

I was asked whether STM8 eForth can support Brad Rodriguez 1-Wire code which was written for the MSP430 and I had a look into it. After familiarizing myself with the time-honored 1-Wire protocol (which I read for the first time at least 20 years ago) I quickly hacked some low-level routines:
That's indeed all that's needed for basic operations.
Brad Rodriguez, a well known name in the Forth scene, did some more than that: he also implemented the ROMSEARCH algorithm, needed for getting all devices on a bus. The code is part of his CamelForth repository.
CamelForth code looks very similar to eForth code (indeed I just had to provide INVERT as an "alias" of NOT, and implement a few words like LSHIFT.
A write-up is here: https://gist.github.com/TG9541/348abfae54c79f1c1c5a4f4ed0dcfdf5
A big fat bug in double/word division... lingering in the code for nearly 10 years!
Thomas • 02/09/2021 at 17:31 • 0 comments

What happens when a user tells you about a bug in a completely inconspicuous part of a software, one that you never touched and that you'd thought of as reliable since you'd been working with the software? It happened to me last week, and disbelieve was naturally my first reaction but the problem in UM/MOD, the "32/16bit-division-with-remainder" was real!
The same user quickly found a bug and provided a fix. I then informed the owner of another project, that started off of Dr. Ting's "STM8EF for the STM8S Discovery", also had never noticed any problem although he had identified and fixed another unrelated bug in UM/MOD!
What started then was a thorough analysis of the code, which unearthed yet another bug related to an edge case. Automated testing with a Python script makes more bugs in that code very unlikely.
The moral is this: bugs happen, and they can be very well hidden under other layers of code that "rescues" the expected behavior but open source software not only leads to much better testing for unexpected things but it can also make skilled teams appear out of thin air!
New e4thcom features (matched by codeload.py)
Thomas • 01/24/2021 at 21:48 • 0 comments
Manfred Mahlow published version 0.8.5 of the embedded Forth terminal and programming tool e4thcom which introduces the source file level keywords #ifdef <name> and #ifndef <name>: they make e4thcom check if <name> is defined in the target dictionary and transfer the rest of the line on that condition

The following example shows the source level keywords supported by e4thcom and codeload.py :
```
#include hw/pd8544.fs \ unconditional uploading
#require ALIAS \ conditional uploading if the word ALIAS isn't in the dictionary

\res MCU: STM8S103  \ use the STM8S103.efr symbol/address file

\ get GPIO registers addresses, insert definitions like `hex 5000 CONSTANT PA_ODR`
\res export PA_ODR PA_IDR PA_DDR PA_CR1 PA_CR2

#ifndef OUT! \res export PB_ODR
#ifndef OUT! : OUT! ( f -- ) PB_ODR 4 B! ;

\\ ignore the rest
 of the file
```
This feature is useful for testing target properties while sending code to the target. Writing device independent low-level code is among possible use cases.

The codeload.py in the STM8 eForth tools folder, very useful for transferring code to the target from the command line, now also supports this feature. There are some more improvements, e.g. better newline handling, better error messages and support of Python3 by default.
Docs for "STM8 eForth Compiler and Assembly" updated
Thomas • 12/24/2020 at 08:05 • 0 comments

After the recent introduction of >REL for control structures with relative addressing the docs for the STM8 eForth Assembler Interface were in need of an update.
I used the opportunity to restructure the paragraphs a bit. Feedback is welcome!
STM8 eForth Pre-Release 2.2.27.pre1 is out
Thomas • 12/22/2020 at 15:42 • 0 comments

I just published STM8 eForth 2.2.27.pre1:

the GitHub release notes list the most important features, e.g. optional relative addressing for IF .. ELSE .. THEN, support for defining the "Background Task" event in user code (e.g. the RTC alarm).
STM8 eForth: IR Remote Controll for an RGBW LED Bulb
Thomas • 12/20/2020 at 06:04 • 0 comments

Today, IR remote control is by far the cheapest option for consumer electronics. I've long had the idea that Forth is ideal for interactive scripting of IR remote-controlled devices, and I used the light bulb at my desk to learn how to do it with STM8 eForth.

PulseView and an IR receiver (a rather dated SHARP GP1UD272XK) revealed that the protocol is a "NEC" variant:After some learning, thinking and coding, entering "7 ir<enter>" is all it takes for switching this $2 miracle on. The solution is quite generic and controlling other devices shouldn't be difficult.
I made a write-up of what I learned, including surprisingly simple working code in this GitHub Gist.

View all 172 project logs

Step 1

Get some cheap hardware (e.g. a STM8S103F3P6 breakout board for $0.65 and a ST-Link V2 dongle for $2). download the binary release, flash it, and have fun!

If you like it, and you want to hack board support code for your favorite STM8China gadget, you need:

eForth for cheap STM8S gadgets

Description

Details

What is it?

Why a Forth for Cheap Chinese boards?

Which target boards are supported?

Why Forth?

Files

2157_stm8ef.zip

Components

Project Logs

Collapse

STM8 eForth "Build-Test" moves from Travis-CI to GitHub Actions

Chat with Chuck Moore in the Forth2020 Zoom Meeting

We're at STM8 eForth 2.2.28 now ... :-)

STM8 eForth 2.2.27 released

Using the 1-Wire Thermometer Chip DS18B20 with STM8 eForth

A big fat bug in double/word division... lingering in the code for nearly 10 years!

New e4thcom features (matched by codeload.py)

Docs for "STM8 eForth Compiler and Assembly" updated

STM8 eForth Pre-Release 2.2.27.pre1 is out

STM8 eForth: IR Remote Controll for an RGBW LED Bulb

Build Instructions

Collapse

Discussions

Similar Projects

W1209 Data Logging Thermostat

STM8 BASIC

Microcontroller Forth cross compiler

Scamp

eForth for cheap STM8S gadgets

Become a Hackaday.io member

Just one more thing

Description

Details

What is it?

Why a Forth for Cheap Chinese boards?

Which target boards are supported?

Why Forth?

Files

Components

Project Logs Collapse

Build Instructions Collapse

Enjoy this project?

Discussions

Become a Hackaday.io Member

Similar Projects

Does this project spark your interest?

Report project as inappropriate

Send message

Remove Member

Project Logs

Collapse

Build Instructions

Collapse