Thomas TG9541

The first 1-wire low level sketch was nice - but since Brad J. Rodriguez has implemented high level code, e.g. the 0F0h "ROM Search" algorithm, for CamelForth it's maybe a better idea to re-use it!

The "onewire" source archive contains the CamelForth source file "onewire.f", MSP430 assembler code and some documentation. The assembler code implements the primitives OWRESET (reset the bus) and OWSLOT (write and read a bit).

Unlike the MSP430 files the low-level code doesn't need to be compiled into the kernel, and the configuration doesn't need to be fixed.

Here are the primitives in STM8 eForth (the words gpio.d and gpio.i carry the GPIO configuration into the code):

\ STM8 eForth "1-Wire" communication primitives

Devices and chips that use the Dallas/Maxim 1-Wire protocol, e.g. iButton have been around since the 1990s. The DS18B20 temperature sensor is still very popular (although it's more likely that you get one of its clones).

This page contains 1-Wire primitives for STM8 eForth. Higher level words, e.g. ROM scanning or the DOW-CRC8 will be added when required.

\ STM8 eForth "1-Wire" communication primitives

\res MCU: STM8S103
\res export PB_DDR PB_IDR
#require ]B!

STM8 eForth: IR Remote Control for an RGBW LED Bulb

These days IR remote control is still the cheapest option for consumer electronics. I've long had the idea that Forth is ideal for scripting IR remote-controlled devices and I used the light bulb at my desk to learn how to do that with STM8 eForth. LED lamps of relatively high quality with a combination of white LED and RGB LEDs have a remarkable low price tag: the set below costs no more than a regular white LED lamp. In my experience service life is much better (maybe due to a switched mode power supply with constant DC voltage and µC PWM control). The option for occassional colorful illumination is a bonus.

This writeup covers analyzing light bulb IR remote control codes and using it with STM8 eForth . The code below also is a showcase for the expressive power of STM8 eForth on a cheap 8bit µC (e.g., STM8S103F3P6 w/ 8K Flash and 1K RAM).

![image](https://user-images.githubusercontent.com/5466977/10

The STM8 I2C Peripheral

The STM8 family I2C comes in two variants: one with basic features for 100 or 400 kHz "I2C master and slave" in STM8S RM0016 and STM8L RM0013 devices (e.g. STM8S103F3 and STM8L101F3), the other in STM8L RM0031 devices (e.g. STM8L051F3) offers more features (e.g. two slave addresses, DMA, SMB 2.0 and PMBus modes). The experiments with STM8 eForth here target the basic features common to both variants.

In my first tests I used @eelkhorn's code. It turned out that "polling" is needed for I2C pe

STM8L051F3: a low power Forth console

In the stopped state the STM8L needs just a few µA - but in this state the console can't wake up the device: the USART gets no clock. Only GPIO interrupts and peripherals that are clocked from the LSI or the LSE will work! A possible solution is a pin-change interrupt on RxD for waking the core - and the USART - up. In "Active-Halt" mode RTC and WUT peripherals run on 38kHz LSI or 32.768kHz LSE clock (see here). This means that it's possible to have a background task without keeping the core busy.

One of the challenges ist that STM8L docs doesn't describe the USART behavior if the clock is turned on after the start-bit edge, i.e., if the character that wakes the core from "Active-Halt" can still be received.

A pin change interrupt

STM8L051F3: Experimenting with LSE, BEEP, RTC and WUT

The low-power STM8L family has the LSE (Low Speed External) oscillator that uses a 32.768kHz crystal to clock peripherals like the RTC. For my experiments I use the nrf24stm8l board I made some time ago: it's basically a STM8L051F3P6 breakout board with an nRF24L01 module header and a clock crystal:

Not all of the 20 MCU pins are broken out (it uses PC5/PC6 for the crystal and PB2/PB4 for the nRF24L01 header). A chip on a standard "green 10c TSSOP20 breakout PCB" with a crystal soldered to pins 1 and 2 also works (caps were not needed when I tried it).

This write-up is based on all free software, and the compiler/interpreter runs on the STM8 chip. The STM8L051F3 image from the [STM8 eForth 2.2.26 release]

Experiments with OPENOCD and GDB for the STM8

Attempts to support the STM8 with OPENOCD, a standard hardware debugger front-end, and GDB, the GNU Debugger, was a long while in the making. Both OPENOCD and GDB are powerful tools that are often packaged by tool vendors (integrated in a turnkey IDE) or independently used by a community advanced users. Usuage examples for µCs often barely scratch the surface, don't mention testing procedures, modes of operation, or which features are supported.

Here is a list of features that worked so far:

flashing a binary in ELF format to an STM8S003F3P6
running, interrupting and continuing execution
setting breakpoints
reading registers

	\ LDF A,($50000)
	\ BC Extb MS LS RET
	\ sp@ SP+4

	$8105 1024 256 M* .S
	0 1 0 2 -32507 0 4 <sp ok
	sp@ 10 dump
	1642 0 4 0 0 81 5 0 2 0 0 0 1 0 0 8C 81 ________________ ok

	\ STM8eForth : BF! and LEBF! TG9541-200717
	\ ------------------------------------------------------------------------------

	\ Write bit to a bitfield stored in one or more cells (16 bit words)
	\ Set/reset bit #u (0..8191) in a cell array starting at address a to bool t
	#require DOXCODE
	#require A>
	#require ALIAS
	#require :NVM

	\ STM8 eForth buffered UART receive

	\ the code assumes that the target CPU resource was loaded
	\ e.g. \res MCU: STM8S103
	\ and the RX buffer length was defined as a constant
	\ e.g. 8 CONSTANT RBLEN
	\ more in the example at the end of the file

	\res export INT_UARTRX UART_DR UART_CR2