eForth for cheap STM8S gadgets

ST offers a new STM8S device: the STM8S001J3 in an SO8N package. It's more powerful than the ATtiny85: same Flash, double the RAM, less EEPROM, better peripherals (ADC, 1x8bit+2x16bit timers, UART, I2C and half an SPI), and at a price of $0.20 it's much cheaper than the ATtiny85. It's even cheaper than the ATtiny13!

It has another advantage: there is an interactive (untethered) Forth for it! The dataasheet is very similar to that of the STM8S003F3P6, and I hope to receive samples soon. There is a new Wiki page with a feature comparison of different STM8S Low Density Devices. The bottom line is this: other than the pin count there aren't many differences!

The reason for the somewhat confusing list of pin properties is that multiple GPIOs are bonded to a pin (with the exception of pin 6). When GPIOs are used in parallel, pin8 can drive up to 80mA within the spec of the device!

One can argue that compared with 8pin AVR chips it has one pin less to play with (Vcap), but NRST (reset) obviously isn't needed for in-circuit-programming, and on the ATtiny85 side working without the RESET/dW feature isn't really fun. An untethered Forth for the ATtiny85 could settle the score but I couldn't find any.

For most applications the STM8003F3P6 is a better choice ($0.24@10pcs), but SO8N is so much easier to solder that it ranks high in the gadget rating ;-)

@richard published a HaD project with an interesting new use case for the notorious W1209 thermostat: measure the internal resistance of lead acid batteries in a battery reconditioning set-up. All the hardware features of the W1209 are re-used: relay, LED display, keys, sensor input, and even EEPROM storage!

On Richard's project page there is also a video clip of the device!

The resistance measurement uses the relay and a 1A constant current circuit (a 7805 5V regulator and a 5R resistor), and calculates the resistance by comparing the open-circuit battery voltage with the voltage under load.

Check out Richard's blog - there is a ton of great hacks!

Besides some experimenting with the library structure there are no big changes since the pre-release v2.2.13.snapshot. I did some editing, and also made the W1209-FD "official", and also the README.md on GitHub looks a bit friendlier now.

The most noteworthy change is maybe the adoption of the e4thcom method for resolving dependencies (#include, and #require), and a method for temporary vocabularies in RAM.

Check out the releases page for more infos!

When I started extending Dr. C.H. Ting's STM8EF with board support (e.g. the venerable W1209) I wrote low level HW abstractions in assembly code, taking full advantage of the STM8 instruction set (e.g. bit set/reset operations, memory-to-memory moves).

I takes a while until one understands that in Forth a lot more is possible than in traditional interpreting (BASIC) or compiling (C) language approaches. It's easy to write compiler extensions in Forth, very easy in fact!

Here is an example:

The BSET/BRES instructions have the following opcode/adressing structure:

72 1n MSB LSB 
BSET: n: 2*b
BRES: n: 2*b+1

Bit adressing is very for working with µC peripherals (in most cases read-modify-write can be used, too, but changing individual bit that takes more memory, and more cycles).

One of the first things I added to STM8EF last year was the B! instruction, that builds a BSET or a BRES instruction on the stack, and runs it. This takes a lot of cycles, but it allows using bit instructions with non-immediate addressing. 

Now, sometimes just immediate addressing is required, and storing bit value, address, and bit position is all but a waste of memory!

: PC_ODR $500A ;
: PC5set 1 PC_ODR 5 B! ;

The solution is compiling BSET/BRES instructions directly into the execution code, just like an optimizing C compiler would do it:

\ STM8S assembly words
\ (c) TG9541, refer to license at github.com/TG9541/stm8ef
: bit! ( b a c -- )
  rot 0= 1 and swap 2* $10 + + $72 c, c, , 
; immediate
: bres ( a c -- ) [ 0 ] [compile] bit! ; immediate
: bset ( a c -- ) [ 1 ] [compile] bit! ; immediate

The PC5set example above now looks like this:

: PC5set [ PC_ODR 5 ] bset ;
' PC5set 10 dump            
  F9  72 1A 50  A 81 65  1  4 64 75 6D 70 65 74  0  0  r_P__e__dumpet__ ok

As the dump shows, this definition compiles to the assembly instruction BSET PC_ODR,#5.

Using the new library features in the upcoming STM8EF v2.2.13.snapshot the above "inline assembler" words can be loaded into RAM, and the words bit!, bres, bset take up no space in the Flash ROM.

The 84x48 LCD module I bought about 3 years ago (just in case) was so well stowed away that I found stuff I had been missing for months before I finally found it. I needed something to test layered #include files:

  register names ← SPI routines ← LCD primitives ← character output.

It works as advertised, but I have no intentions of posting yet another PD8544 84x48 LCD picture. If someone knows of a 3x6, 3x8 or 4x8 bitmap font that's in the public domain I'll add it to the STM8EF lib/misc folder. Otherwise just drop me a note if you want to give it a try.

Library functions, and the upload utility in e4thcom with its #include feature make programming a STM8S103F3 demo board much simpler.

Here is an example:

#include utils/rammark.fs
RAMmark
#include regs/opt.fs
NVM
#include hw/opt.fs
\ set option bits to enable PC5 TIM1_CC1, and PC6 TIM1_CC2
: OptInit ( -- )
  OPT2 DUP C@ $01 OR SWAP OPT!
;
RAMdrop
RAMmark
#include regs/timer1.fs
NVM
#include hw/pwm.fs
\ timer1 init to 1MHz clock and 20ms period
: ServoInit ( -- )
  15 T1PwmInit
  20000 T1Reload
  1500 PWM1  \ PC6 pin 16
  1500 PWM2  \ PC5 pin 15
  1500 PWM3  \ PC3 pin 13
;
RAMdrop
\ Done!
\ run OptInit to configure GPIO functions **once**
\ run ServoInit
\ set servos with y PWMx | y: 1000..2000 [µs], x: 1..3

This demo works with STM8EF v2.2.13.snapshot (the include files are in the lib folder).

Steps for using it:

• unpack the v2.2.13.snapshot binary
• put servo.fs into the release base folder
• install e4thcom, and put the e4thcom STM8EF extension into the release base folder
• run e4thcom with e4thcom-0.6.1 -t stm8ef -d ttyUSB0 (or whatever your TTY is)
• in e4thcom type #i servo.fs
  
• follow the instructions in the last comment lines (run means 'type and press enter' :-) )

Refer to the e4thcom docs for more information.

Connecting the W1209 is now really easy:

It's no longer necessary to modify the W1209!

It's been a while since the last release, maybe too many interdependent steps for speedy development. Anyway, most is now tested, and ready to use:

• dictionary headers can be selected on a board-by-board basis (issue #32 )
• make BOARD=xxxx forth target uses tools/codeloadTCP.py and uCsim for code generation with #include feature (issue #32 )
• software full-duplex serial interface, e.g. for e4thcom (issue #41 )
• board W1209-FD with full-duplex serial interface (issue #42 )
  • key "+" / PC4: RxD
  • key "-" / PC5: TxD
• default HAS_ALIAS=1 allows immediate words in RAM while compiling to NVM (issue #43 )
• a Forth library has been added to code repository, and binary release (issue #43 )

Check out the GitHub Releases page (binaries are included).

One year ago I published an initial version of STM8EF on GitHub. I was then a near total Forth newbie, and I had no idea where the journey would take me. In just one year STM8EF turned into a very lean but rather complete self-contained Tiny Forth with support for some super cheap Chinese boards with a small but active community!

The latest additions are:

• a Build Framework with include file support, that compiles Forth code into a target binary
• a ucSim based µC simulation with a Forth console
• upcoming STM8EF suppory in e4thcom
• the very beginning of a library
• a decomposable core (linking, and core word includes are optional)

Future work will go in this direction:

• better support for applications that require very high code density (e.g. hybrid STC/ ITC)
• a library with basics like hardware drivers, math, etc (maybe in the form of packages)
• more exchange with the Forth community
• Script-Kits (sic) for typical applications (power supply, lab automation, why not thermostats ;-)

One more thing that happened in just one year: I have to be super careful not to forget how it is not to be a Forther - otherwise the whole thing will be of very little use for the average HaD guy. I guess that there is a need for more spin-off projects that are really easy to build, and simple to understand.

In the project's Issue section on GitHub, someone proposed supporting the "ZFC39" Fan Speed Controller.

Check the link above, and join the discussion if you're interested!

My project team here on HaD discussed requirements for a build Framework:

• board support code in Forth should be part of the binary release
• build, and test automation should possible for board support code
• selection of core words should be possible on a "per board" basis
• Forth code should be stored either in library folders, or in the board folder
• Uploading Forth code should be supported by an "include" feature

Thanks to the active support of all team members, and of the author of uCsim (a component of the SDCC toolchain) we're now a great deal closer to this goal.