eForth for cheap STM8S gadgets

The Mr. Mahlow, author of e4thcom and a well known name in the German Forth scene, proposed some improvements to STM8EF:

• CONSTANT with interpret/compile aware operation
• Improved ALIAS, and NVM: ... ;RAM for headerless code
• [ f a b ]b! bit set/reset code generator
• a starting point for defining STM8 bit/address symbols with the e4thcom \res feature

The \res feature is great, but I also need to make it work in codeloadTCP.py. That shouldn't be too difficult, even for a Python newbie like me.

On the CI side I started using the DockerHub Automated Build feature for creating the tg9541/docker-sdcc Docker image. After I realized that build automation only works for new Docker repositories it was easy. Before that it was glorious frustration.

On the bright side, all you need now for STM8 eForth hacking is a web browser. Yes, this will even work on a Windows PC ;-)

Test automation for STM8 eForth is ready!

It works like this:

• a terminal sends test instructions in the form T{ code-under-test -> expected-result }T
• character output is tested like this T{e code-under-test e-> char-count char-sum%16 }T
• testing COLD cycles and data persistence works by setting a start-up word

Travis-CI runs the test for every commit, or pull request

Here is a demo of the same test run manually in e4thcom:

For OpenSource projects Travis-CI provides test automation for free (free as in free beer)!

We're not talking about a reduced "entry level service": it's professional grade, fast, powerful, and very well integrated into GitHub! It can be combined with yet another service that's free to use for OpenSource projects: DockerHub.

Check out the following pull request where you can see an OpenSource DevOps workflow in action:

• Issue "Build test automation" on GitHub
  • discussion with @Lars Brinkhoff 
  • status from test automtation with Travis-CI
  • demo with asciinema
• My Pull Request with
  
  • test automtation by Travis-CI
  • using the Docker image from this Dockerfile
  • comments from @Lars Brinkhoff 
  • review by @Eelco 

Next up: unit- and integration tests for the STM8 eForth core, smoke tests for the release binaries, and finally automatic deployment (e.g. to GitHub Releases).

The bug in $" (compile in-line string) found by @Eelco is now fixed, but there is still no revision information in "HI" (this will be part of the final release).

However, there is some important progress in the QA department: automated quality assurance, using SiL and virtual hardware, is on track!

The following now works:

• there is a Docker image with the build- and simulation tools (see Dockerfile)
• Travis-CI uses Docker to run builds and tests using tg9541/docker-sdcc
• An automated "smoke test" works (compile Forth code with the W1209 binary)

I'm quite happy with the progress but there still is a lot left to do:

• write proper unit tests
• compare string output
• run smoke tests on all of the board specific binaries

Unless uCsim gets a much better hardware emulation, the following tests currently require a "HiL setup":

• test the "software UART" code (it had to be "bypassed" in the current SiL)
• interrupt code
• background tasks
• 7-S LED and key drivers

I guess that such a HiL setup, maybe Raspberry Pi based, can be used from within Travis-CI.

This addresses issue #69 which affects the releases v2.2.13, v2.2.14, and v2.2.15.

The bug is rather sneaky: under certain conditions compiling to Flash (e.g. the sequence NVM : test ; RAM, COLD) worked only once after flashing the binary. It's not clear why it always worked when I tested it, but this incident certainly calls for better QA. Sorry about it!

The release also includes a "runs-on-my-machine" fix for #72 "Containerize the SDCC and uCsim toolchain, prepare improved test automation" to prepare automated release testing using continuous integration ( @Lars Brinkhoff : thanks again!).

Edit: the Docker image is here https://hub.docker.com/r/tg9541/docker-sdcc/

According to The Krihelinator STM8EF fares reasonably well (for being a Forth / Assembly project):

The STM8 eForth hobby project is slowly turning into a community project!

@Lars Brinkhoff recently proposed adding contribution guidelines to the TG9541/STM8EF repository. I made a draft, and I'd like to ask you for comments!

Lars also recently contributed the foundations for continuous integration, i.e.  basic automation of quality assurance:

Travis-CI is great. Thanks Lars!

Maybe the most interesting aspect is that any successful software community project must find the balance between "happy hacking", and some form of shared responsibility and quality assurance. It might even need a board, bylaws, and conflict resolution, but then either something went  extremely wrong, or miraculously well ;-)

On the personal level, I also need to commit to respecting the rules of the community I (and others) try to foster.

The new e4thcom-0.6.2 release supports STM8EF directly!

Thanks to the active support from the author of e4thcom there is no noticeable difference between 2-wire (half-duplex) and 3-wire (full duplex) interfaces (handshake, mirrored <CR> character ignored, <EOL> marker in compile mode, error detection with <BEL>). Forth compilation to Flash is now rather fast.

e4thcom works on Linux on X86 and Raspberry Pi. The embedded Forth systems currently supported by e4thcom are 430CamelForth, 430eForth, 4e4th, AmForth, anyForth, Mecrisp, Mecrisp-Stellaris, and noForth.

For hobby projects like mine, communities like HaD, GitHub groups, or a subreddit are awesome: one gets traffic, and traffic is only way to reach some of the coders who are lateral thinkers. That's a rare species since coding training follows a strict vertical approach.

In some industries, like the one I work in, new approaches are very much needed: vertical thinking, e.g. scaling-out today's solutions, won't cut it. Lateral thinking coders are more likely to be looking at alternatives, and who knows, maybe one of them might be the architect who applies an alternative Moore's law.

In any case, I believe that the Forth community has always had some of the best lateral thinking minds. Learn to know them, listen to them, they'll be needed.

e4thcom Support

e4thcom is a nifty terminal for embedded Forth systems that supports #include and basic dependency management with #require. The author contributed support for STM8EF that works with 2-wire (half-duplex), and 3-wire (full-duplex) serial interfaces. Thanks a lot!

FILE ... HAND is now disabled by default because the method used in e4thcom works better (e.g. a decent error indication with the BEL character, and indication of compile mode with OK like in noForth).

STM8S001J3M3 Support

STM8EF now supports the latest member of the STM8S low-density family: the STM8S001J3M3 in a hobby-friendly SO8N package.

The default configuration uses the STM8S UART1 in half-duplex mode (see issue #57 ) for the console. Connecting a PC-UART works as described in 2-wire communication. Depending on your UART you may need a 10k pull-up resistor. Note that the risk that PD1/SWIM gets blocked is significantly reduced by using pin8 for the console. Alternative use of the pin for reading an analog sensor might work, too.

Faster Compilation in NVM Mode

Let's just say it's faster now (much faster, indeed), and let's forget that it should have been like that from the start ;-)

Forget Release v2.2.14

The binary release was OK, but due to a merge hick-up the source code in master was rubbish. Thanks to @timsoer for reporting issue #59 !

I received STM8S001J3M3 samples from ST, and also a small PCB for the µC and the required capacitors. Assembling it didn't take long (by the way, soldering appears to be an efficient cure for a jet-lag)..As expected, the STM8S103F3 "STM8EF MINDEV" binary worked right away. However, since there is no NRST pin, and pin8 is bonded to PD1/SWIM and PD5/UART1_TX, once the Forth console runs, flashing is impossible unless UART1_TX is disabled (e.g. with the command 0 $5235 C!).