eForth for cheap STM8S gadgets

From the start, STM8 eForth "background task" used TIM2. The consequence is that Timer2 Capture/Compare, e.g. for PWM, has to use the Background task repeat rate, a multiple of it, or otherwise disable the background task feature altogether. Sure, there are alternatives, e.g. Idle Task or low level interrupts, but these have different properties with respect to I/O or freedom-of-interference with the console.

Now I got a use-case where the frequency of the TIM2 PWM2 has to be completely free (1Hz to 150kHz), and still a normal background task is needed. Obviously the background task had to be moved to a different timer, e.g. TIM1 ( @Ivan Alf  I guess you'll recognize the code for the XY-LPWM board even if I changed it a bit :-) ).

Another use case where some hardware abstraction is necessary is the project #MODBUS Things with STM8 eForth : different STM8 devices use a first or a second address range and interrupt vector for the UART (or both). The UART name, however, depends on features and not the address. Since in most cases a common subset of features is sufficient new naming conventions provide a robust solution.

The required changes are in the current STM8 eForth 2.2.24.pre4 "beta".

As announced in the previous log, STM8 eForth now has a Modular Build feature. This doesn't sound like much but it massively reduces the effort of supporting your design!

The repository contains the DEMO board configuration folder which is both how-to and example.

In hindsight, this is a very good example for bad web site design since the most important part of the manual is easily overlooked (even if the technical structure is right).

If you want to try it, a good way of using this repository is downloading the code as a zip file and then make your own repository. The structure is the message, and forking will add little benefit. You can, of course, give credit and star the repo :-)

Up to now building STM8 eForth required building and packaging all supported boards as one big monolithic block. As variants of popular boards popped up board configuration had to be added. For the W1209 thermostat board there are now 4 variants!

Some time ago I decided to add the board independent part of the STM8 eForth source together with libraries (the core) together with the binary release. Additionally I factored the Makefile, and the most core is also in the distribution.

It's now possible to create a new board with some files, including build automation with Travis-CI (the MODBUS project was the first to use it).

To illustrate the approach I made a demonstrator with, well, a DEMO board:

Using it is really easy. Enjoy!

The modular build, first conceived for the STM8 eForth MODBUS project needed a change to the order of default Forth source files to work well with projects that support multiple variants (e.g. boards):

Since STM8 eForth 2.2.24.pre1 some things have been in the making and I decided to make a 2.2.24.pre2. That didn't go so well since one thing, a new RAM address extraction feature in genconst.awk apperently still was "stuck in the making". Fortunately testing the MODBUS project quickly revealed the bug!

As far as I can tell the new STM8 eForth 2.2.24.pre3 is ready for use. The final release will receive better support for STM8S High Density devices (e.g. UART3, data storage in "far memory").

Some of the changes for moving variant code (e.g. UART initialization, background task, global variables) out of the main STM8 eForth file (forth.asm) are still ongoing, others have been merged into master recently.

For STM8S903-like Low Density devices (e.g. STM8S001J3M3, STM8AF6226) a new UART configuration in globconf.inc is now supported that initializes UART pull-up correctly if it's remapped from PD5 to PA3 in half-duplex mode. This is a small change but using the STM8S001J3M3 is much more enjoyable this way, and the STM8S903K3T6C provides 24 GPIOs on 3 sides of the package (as long as you take care not to bring PD1/SWIM into a permanent output mode AND kill the Forth core at the same time ;-) ).

For some reason only product line managers and heads of marketing departments will understand a part of STM8S "high density" chips have been placed in the "Performance Line".

The rationale?

Maybe the 24MHz specs (instead of just 16MHz). OK, the datasheet says "0 wait states @ 16MHz). The datasheet promises 20MIPS @ 24MHz. Big deal - for a chip that's considerably more expensive (at low quantities) than an STM32F103CBT6.

On the other hand, if one wants to use an STM8S005C6T6 (about $0.40 @ 10pcs incl. shipping) with an 10MHz internal clock for peripherals, one can't simply use a 20MHz crystal and add that "1 wait state": the data sheet doesn't mention such a feature (the chip is "Value Line", not "Performance Line" after all!

On the other hand, I've learned to take ST's STM8S datasheets with a grain of salt, or Доверяй, но проверяй!

I quickly typed the following mini-benchmark into an STM8S005C6T6:

NVM

: test TIM 100 FOR 
    32000 FOR 
      I DUP * DROP 
    NEXT 
  NEXT TIM SWAP - .
;

RAM
test 6865 ok

The code does 3232101 (101 * 32001) multiplications  and measures the execution time in background ticks (at a 5ms interval). The time is thus 34.325 s (10.6 µs per iteration).

Now I ignore the description "Option byte 7: Reserved" in the datasheet and instead use the description for setting "1 wait state" from the STM8S207 datasheet:

(base) thomas@w500:~/source/stm8s/stm8ef$ echo "00 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 01 fe 00 ff" | xxd -r -p > set_opt7_to_1.bin 
(base) thomas@w500:~/source/stm8s/stm8ef$ stm8flash -c stlinkv2 -p stm8s103f3 -s opt -w set_opt7_to_1.bin
Determine OPT area
Writing binary file 17 bytes at 0x4800... OK
Bytes written: 17

The STM8S005 restarts and I re-run my simple benchmark:

test 8247 ok

8247 * 5ms = 41.235s, that's a lot slower (12.74 µs per iteration) a clear sign that the wait state works!

A quick check:

6866 / 8247 * 24 MIPS  = 19.98 MIPS.

So, should I use a 24MHz crystal and 1 wait state i'd, have a "performant" (20MIPS) "Medium Density" (STM8Sx05) "Value Line" chip.

EDIT:

Datasheets of automotive "Medium Density" devices, like STM8AF6266, confirm the wait state bit in the configuration location OPT7. The STM8S family (including the automotive STM8AF) appears to have more line managers than chip designs, but if one is interested in STM8S chip properties, STM8AF datasheets are  a good place for testing assumptions.

There, and in old versions of the RM0016 STM8AF/STM8S reference manual, one can also uncover what OPT6 and the TMU is all about. Interesting stuff for protection of IP in production systems, but I'm not sure if it will ever be relevant for hobby projects. One hint anyways: if one doesn't care about TMU one can safely store an arbitrary 8bit value in OPT6 ($480B). 

One more thing I tested in Low Density devices: while a EEPROM cell exists for configuration byte OPT7 in both Low Density chip variants (commercial STM8S103 and STM8S903, or automotive STM8AF6223 and STM8AF6223A), bit0 doesn't cause a wait state.

I noticed that different portions of the docs directly went into technical details before motivating things and orienting the reader.

That's bad style at best. At worst  it's the last thing casual visitors ever look at!

The following sections got a makeover:

• Autostart Forth Code
• Background Task
• Idle Task
• Low-level Interrupts in Forth
• The sidebar

The Idle Task page will later get more examples and a technical details section.

Yesterday I cleaned up the "STM8 low density devics" Wiki page. My initial target was to extend the scope from STM8S to STM8L devices, but I soon discovered that I had not had a clear understanding of the STM8S family variants when I had started that page.

This is no wonder at all, since the ST marketing has employees to invent funny categories like "Value Line", "Access Line" and "Performance Line" when they don't mean "value", "access", or "performance". A good example is the "Value Line" device STM8S007C8 high density (6KRAM, 64K Flash) performant (20 MIPS) µC which they sell at an accessible price. It's a safe bet that the device has 128K Flash and 2K EEPROM and that, as a hobbyist or "maker" you'll find that it operates reasonably well at 120°C.

While I was at it I had a closer look at the STM8S903K3, the "Application specific Line" device that's now quite cheap (around 30ct) and that I had earlier discovered to be the chip in the STM8S001J3M3, the STM8S in a SO8 package. At first sight there are two distinct chips in that line, the STM8S903 and the STM8SPLNB1, a DiSEqC slave chip. The datasheet gives it away as a STM8S903F3P6 chip that comes with an application for DiSEqC (i.e. program), and I assume that the NC pin18 is PD1/SWIM. If that's the case then case most of the function blocks in the datasheet's functional diagram are actually bit-banging software (i.e. there is only one HW I2C, namely SCL2).

I have to admire the boost of creativity, especially in the marketing department!

Overflows of creativity must have had an impact at other places, too, and if you're in the automotive market it's highly needed. Imagine you make a quote for an automotive micro-controller, e.g. a simple device for LIN slaves like the STM8AF6223: quantities are potentially huge but the environmental requirements are harsh (guarantee electrical parameters from -40 to 150°C operating temperature!), there is cut-throat competition, and the guys in the purchase department know their job!

Ah, yes, and there is catch: you must commit to delivering the same device for a long time, let's say 10 years. That, of course, only works if you can make money out of operating a fab for that long!

Also one should be able to "salvage" chips that have grades that are currently on short demand (e.g. chips that stay inside the specs from -40 to 85°C when there is only demand for, say, -40 to 125°C grade chips).

Now it's clear what's the job of the marketing department: find "less demanding" markets that can absorb what's otherwise surplus (if you can find a "more demanding" market that's of course also fine, provided you don't create *any* extra effort for the serious "automotive oriented" production process guys ;-) ).

That said, when I compared the STM8S903 and the STM8AF6223 datasheets I suddenly realized which kind of "application specific" requirements stands behind the luxury of producing two different STM8S low-density devices: the one from large automotive industry customers.

 I re-read the STM8S903 datasheet, and compared the configuration sections. The only real difference is that the UART is called "UART1" here and "UART4" or "LINUART" there. It's a safe bet that the STM8S001J3M3 can act as a standard compliant LIN2.2 slave, including baud-rate synchronization through -40 to +150°C without the need for a crystal. I'm sure that engineers in other markets will find a creative way to use such a nice feature.

Now the question is: why in the world does ST employ people who's job it is the make chips look like they're less capable than they are, why do they sell more for less?

STM8S003F3P6 for €0.16 / $0.17 a piece,  that's cheap. I ordered some, just to be sure that it's for real. Expect more small @oshpark  projects here in the future ;-)

@Ken Yap found a similar offer around 11.11 but the seller wouldn't ship to Germany (for whatever reason), so I missed out.
 

STM8 eForth 2.2.24.pre1 allows creating new board variants in downstream projects.

• the release archives contain source files and scripts for building a board configuration
• the Makefile is now more modular so that application projects can have custom Forth binaries
• the dictionary can be tailored more easily, e.g. for creating temporary dictionary entries for headerless core code

On the application side I'm still experimenting (e.g. in the STM8 eForth Modbus project).