4 days ago •
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?
11/21/2019 at 10:05 •
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 ;-)
10/20/2019 at 20:21 •
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).
08/28/2019 at 19:44 •
Edit: there is now a HaD project for the STM8S001J3RS485 breakout!.
It's been a while since I last worked with STM8S001J3 chips - ST's contested take on SO8 ATtiny85-like µCs.
The STM8S001J3 is a member of the "STM8S Low Density" family but it's based on the "STM8S Access Line" cross-breed STM8S903 that offers some (undocumented) goodies.
I ordered a 10pcs lot for $2.90 including shipping, and decided to make small RS485 nodes (e.g. for MODBUS RTU) with DS1621S thermometer chips that I happen to have lying around.
I made my last PCB with KiCad5.0 - updating to the latest version, especially the library handling, required some reading (I'm now using 5.1.4).
A µC with merrily 5 GPIO pins is a good shield against feature creep, but the following things "had" to be included:
- narrow PCB for a cylindrical sensor with less than 8mm diameter
- 5V supply, 3.3V internal power supply
- basic signalling LEDs
- most GPIOs, including I2C bus and an analog input available on a header
The design is really simple:
Components occupy both sides of the PCB of 34mm x 1/4" (minimal width supported by @oshpark ).
On the front side is the STM8S001J3M3, a LDO regulator and some caps:
The RS485 transceiver and the thermometer chip live on the backside:
The board has two intended applications: either a stand-alone bus coupled temperature sensor, or a minimal µC component, e.g. for a quick perfboard design.
I ordered from @oshpark - uploading my KiCad 5.1.4 file worked right away, and creating Gerber files wasn't necessary!
08/03/2019 at 09:54 •
When I started this project the STM8S003F3P6, an STM8S Value Line µC with 8K Flash and 1K RAM in a TSSOP20 package, was the cheapest device in its class. Cheap enough to enable an industry of low-cost electronics control devices, e.g. thermostats or voltmeters, with the left-overs of mass production runs. This market for low-mid-range µCs encouraged Nuvoton to market the mostly pin-compatible N76E003AT20, an 8051 family device.
For the initial goal of this project this was bad news: from then on the Nuvoton chip was the go-to device on the spot market, a chip with an architecture utterly unsuitable for a self-contained Forth system!
Right now, however, the STM8S003F3P6 is at a very low price point: I just received 10 pcs for $1.86, which is as low as it gets!
Don't get me wrong, the Nuvoton chip won't disappear and it's very likely to receive a thermostat like the W1209 with an "non-hackable" chip but at least the TSSOP20 package can be soldered with ease.
05/28/2019 at 19:00 •
Don't expect breaking changes - the STM8 eForth core is quite mature now.
The default build environment got an update to SDCC 3.8.6 (but it was tested with SDCC 3.9.0, too), and the binary export from uCsim got an upgrade (it's a nice Python script now instead of a lean-and-mean AWK scriptlet).
More internal constants can be exported with #require, STM8L chip got better support thanks to @Eelco. Coding with inline machine instructions is easier thanks to a number of bit copy and assembly interface words.
And of course, there is more docs.
More info is in the release notes: https://github.com/TG9541/stm8ef/releases/tag/2.2.23
02/10/2019 at 21:54 •
STM8EF-MODBUS deserved a GitHub project, of course with Travis-CI build automation, and docs.
Some of the properties are rather cool, e.g. the modular architecture and the clear separation of concerns between MODBUS protocol and other application logic :-)
Right now, on Aliexpress, the "MODBUS-RTU 4 way relay module STM8S103 MCU" is available at a good price: $6.65 incl. shipping.
01/20/2019 at 10:14 •
STM8 eForth is now a serious alternative to coding C coding for STM8 µCs, especially if Flash space is a premium or if interactive features or configuration in the field are required.
Recently, many other pages got updates. Especially a lot of graft was moved from the STM8 eForth Programming introduction page to improved topic pages in the Wiki.
The Forth VM makes context switching very efficient. In my opinion (I wrote many interrupt handlers for industrial and safety critical applications), implementing interrupts in Forth is easer than in C.
The STM8 eForth Interrupts in the STM8 eForth Wiki explains the bit that there is to know. The MODBUS server and the nRFL01 libraries implement low level code using STM8 interrupts.
As an example, here is the STM8S UART RX handler from the MODBUS library:
\ RX ISR handler :NVM SAVEC \ P1H UART1_DR C@ ( c ) rxp @ ( c a ) DUP rxbuf - ( c a len ) RXLEN < IF ( c a ) SWAP ( a c ) OVER ( a c a ) C! ( a ) 1+ rxp ! THEN TIM tstamp ! \ P1L IRET [ OVERT INT_UARTRX !
This example contains many stack comments (the stuff in round brackets) and just a bit of code for copying characters from the UART to a buffer, protecting against buffer overrun, and providing a time stamp for the MODBUS "end of transmission" detection.
The most striking point is that in this use case Forth is much more used as a macro assembler for a very simple virtual machine than as a programming language. The programmer builds the most simple "machine" that will do the job. No unnecessary abstractions.
Links to these libraries are on the examples page.
01/12/2019 at 09:15 •
I kept STM8 eForth stable for a long time but now there is a good reason for preparing a new release:
For the current work on a very lightweight MODBUS Server in STM8 eForth I needed some data from the target (e.g. clock frequency), and some other aides for low-level programming (e.g. an easy to use and stable interface between Forth and machine code).
The implementation of MODBUS in Forth is a pleasant experience: Moore's problem oriented language approach works quite well for embedded control and protocol implementations. I simply design the machine so that it implements layers of a protocol, and I do that in a language that describes the problem well. Thereby a language emerges, because my abstractions either describe the problem well, or I change it so that it describes the problem better.
It's safe to say that the implementation is very code efficient and highly functional at the same time (thanks to an interpreter-compiler on a MODBUS node).
Before the release of STM8 eForth 2.2.23, I'd like to improve the compilation of Forth code in the continuous integration environment.
01/02/2019 at 17:30 •
Edit: there is now a GitHub project: https://github.com/TG9541/stm8ef-modbus
One STM8 eForth needs something that I had planned to implement for a long time: a basic MODBUS server with RTU communication (serial binary protocol).
Implementing a MODBUS RTU server requires some of the following:
- understanding MODBUS vernacular,
- writing test code (with JAMOD and libmodbus.py),
- ISR timing validation, and
- fixing odd bugs
I wrote the UART ISR code in Forth: on a 8bit µC that's fast enough for 115200 baud full-duplex, or for 240400 baud half-duplex MODBUS RTU!
The diagram shows full-duplex mode at 115200 baud. The ISR do buffer bounds checking and media access control (including MODBUS timing requirements).
A Forth "idle task" builds the MODBUS response. The "background task" is free for local logic (i.e. following the input-process-output pattern).
Right now some simple MODBUS FCs are implemented (FC01 & FC05, some of FC02 & FC16). More FCs will be implemented when the need arises.
The code is very compact: the basic implementation is in 300 lines of Forth code (including debug code). Before optimizations 1.4K Flash are needed .
A (long) discussion around the development is here.