MODBUS Things with STM8 eForth

Unlike many other sources of Chinese modules with STM8 chips the good old C0135 MODBUS-RTU 4-Relay Boards with STM8S103F3P6 chips are still available for a fair price - and with the right software they're still a great stock component for small automation tasks.

I had been invited to talk about how to interactively develop MODBUS Server an applications with STM8 eForth. In MODBUS lingo a "server" is a node that listens to a MODBUS Client. 

 
Even if the server does its own thing (e.g., not just issue NEC-IR codes like in the demo above but also, say, react on ambient light or local user input devices), there is still a thing missing: actively send data to anther node. We can call that a MODBUS client - but why not to call it a peer?

It's true, the MODBUS-RTU protocol was never designed for multi-master operation but that doesn't mean that with a tiny bit of protocol and timing on top it can't be used to freely share bits of data between nodes.

First experiments are very promising (requesting and receiving data works). While experimenting with the MODBUS client code I found and fixed a bug that made the node release the bus too early in the first transmission after reset.

In order to enable implementations of FC23 ("Read/Write Multiple Registers") the FC->XT table encoding was improved.

As mentioned in the last log entry, I fixed a minor issue with the RX/TX LED of the STM8S001RS485 MODBUS node and ordered the $1.65 PCB together with my latest key-chain Forth USB dongle so that the amount of the order was above the threshold where I deem it ridiculous (well, at $3.65 including shipping it maybe still is). Shipping through USPS would have taken >5 weeks (plus up to 12 days for making the PCB of course), and I was totally OK with that...
... until someone from @oshpark offered me a free upgrade to Super Swift service (5 business days) AND the FedEx "URGENT" delivery services (I knew that these guys are great!).

From KiCad file to "PCBs in a German mailbox" it took just 8.5 days after I pressed the order button!

A request from @niuyingxian for STM8EF-MODBUS support for the STM8S001J3RS485 board was a good reason to finally apply some of the improvements in STM8 eForth 2.2.26 for improving board support. One of the challenges addressed by the current STM8 eForth release was dealing with STM8 device hardware dependencies. While working on the code I realized that moving from Ubuntu 16.04 to 20.04 removed Python 2.7 support, which made using the current development version 2.2.27.pre2 necessary. STM8EF-MODBUS uses the "modular build" method, and "make depend" automatically loads the configured STM8 eForth release.

The top level Makefile now handles multiple board variants at the top level, and targets are split between "MODBOARD" and "BOARD" targets:

• The MODBOARD targets work on the STM8EF-MODBUS level: targets work on the Forth code level, but they also build the Forth core for a board configuration folder: "make MODBOARD=C0135 load" first builds and transfers the code (using stm8flash and an ST-Link V2 dongle), then it uses codeload.py to transfer the code
• Building the STM8 eForth forth.mk targets still work by setting BOARD, e.g. "make BOARD=C0135 flash"
• The target for starting an interactive e4thcom session is "make term" and there is also a target for build, loading and binary generation of all supported targets using uCsim and simload.sh (e.g. in Travis-CI using a tg9541/docker-sdcc container, that's how the GitHub binary release is made)

On the target support side, I added a board.fs and BUSCTRL for the STM8S001J3RS485 board:

The Forth console communication works with a simulated serial interface through PC5 (J2.4). The way the UART is used for the RS485 communication (RX/TX through PD5 in "half duplex mode" and direction through PD6) created a spurious RX receive event when switching the bus from TX back to RX. A dummy read of UART_DR and toggling the RX interrupt enbale in BUSCTRL solved the problem.

There is one minor hardware issue with the RX/TX LED: it has the bus activity the wrong way, i.e. it's lit when the RS485 bus is idle. A new board revision V1.2 will fix that.

I also tested the code with a C0135 - everything should work as expected.

STM8S001J3M3 chips are easy to solder and they're powerful enough for small MODBUS nodes, and for interactive STM8 eForth nodes, too.

Since free shipping from China has almost tried up, these chips have become more expensive. A good price with free shipping is an opportunity for stocking up worth sharing.

This chip can be used with the very small MODBUS board available from @oshpark, three of which cost just $1.65 (but at that price please order some more OSH boards or else the PCBs will feel really lonely in the large bag).

For the C0135 relay board there is now a beta release that implements the following FCs:

FC01     Read Coils
FC02     Read Discrete Inputs
FC03     Read Holding Registers
FC04     Read Input Registers
FC5     Write Single Coil
FC6     Write Single (Holding) Register
FC15     Write Multiple Coils
FC16     Write Multiple Registers

I ran tests with QModMaster and also made sure that the installation is feasible for people who don't care much about the implementation :-)

The entry point for "general audience" is the link to MODBUS RTU releases on the C0135 Relay Control Board page in the STM8 eForth Wiki.

I just added the STM8 eForth MODBUS pre-release 0.16 that not only supports FC-2 "Read Discrete Inputs" but also actually reads C0135 "4-Relay Board" inputs (finally).

Unlike writing board outputs with OUT! words for reading inputs have never been part of the STM8 eForth core. It's been a while since output words coded in assembler were moved into boardcore.inc. Since the new modular build supports binary GitHub releases with Forth code there is no reason anymore for coding board support words in assembler.

I just added IN@ in Forth for supporting low-active inputs (NPN in PLC lingo):

\ opcode: rotate C left through TOS lsb
: RLC(1,X) $6901 ,  ; IMMEDIATE

\ read C0135 inputs - connect INx to GND to get a "1"
: IN@ ( -- n )
  -1  \ inputs are "NPN" (in PLC speak), start with all bits 1
  [ ( IN4 ) PC_IDR 6 ]BC RLC(1,X)  \ some simple STM8 assembly
  [ ( IN3 ) PC_IDR 7 ]BC RLC(1,X)  \ to load bits to C
  [ ( IN2 ) PD_IDR 2 ]BC RLC(1,X)  \ and rotate them into the
  [ ( IN1 ) PD_IDR 3 ]BC RLC(1,X)  \ Top Of Stack low-byte
  NOT
;

Ok, I have to admit that this is almost assembler but IN@ is more readable than an implementation in C. I like C but low level routines, and the code they produce, are a frequent source of concerns, compiler bug reports, #pragmas, syntax extendsions and idioms without adding the least bit to portability (even if your intent is to exchange compilers, not hardware).

Using this is as simple as always: IN@ will return a bitmap containing the inputs.

The following "program" will activate a relay if the corresponding input is pulled low:

\ copy inputs to outputs
: doit ( -- )
   IN@ ( n ) OUT! 
;

' doit BG !  \ run in background

The background task makes this task surprisingly easy. Note: everything ( in brackets ) and after "\"  are comments.

Adding a simple state machine already allows doing some interesting things.

I got a reminder from Down-Under not to leave things half-finished: the C0135 board, using the STM8 eForth SWIMCOM binary would communicate but it wouldn't switch any relay.

I must admit that for finishing that job the learning curve for anyone "not I" is a bit too steep. Also I left the new STM8 eForth Modular Build virtually unused for a long time. Sorry to say that but for some people it takes a global pandemic to get some quality time for their hobbies.

Long story short, the STM8 eForth MODBUS repository is in better shape than before, and due to the new automated binary release process there is, well, a binary release for the C0135.

Some more features are planed, e.g. an old-style unified "holding register" address space for "coils", inputs, process values and EEPROM. Currently there are no inputs for the C0135 but that's just about 20 lines of code away (lazy me).

Reminding me helps.

I just tested the newly assembled "Mini RS485 Node" based on the smallish STM8S001J3M3 µC. The board has just 1/3 of a square-inch (and a good deal of that are connectors).

The board has components on both side, and this time I also populated the DS1621S thermometer chip.

Here is the "board" in profile next to my new CH340E RS485 dongle:

The dongle provides 5V power from USB - since the MODBUS "board" has a 3.3V regulator bus powered systems measurement systems are possible.

That's certainly not cost efficient for any series production item but I wanted to know what's the smallest stuff I can handle. To be honest, the MSOP10 chip was a bit of a challenge, more so than soldering a STM8S207RBT6C in a LQFP-64 with 0.5mm pitch (ST makes the gaps wider than the pins - 0.22mm to 0.28mm - the CH340E pins appear to be a bit wider).

I populated and tested the first USB-RS232 board - it works! To be honest, I still can't believe that I hand-soldered the CH340E in MSOP10 without completely messing it up!

The switch on the backside is for activating a "local echo". I'd like to have that feature for operation with e4thcom (just as any other terminal program it expects an echo!). Standard RS485 behaviour doesn't read the bus while sending. I guess that this is for compatibility of RS482 with RS422. It would have been better to read the bus while sending since this would enable collision or error detection.

The PCB arrived from @oshpark , including STM8S001J3RS485 V1.1

Timeline so fo: ordered 03/Nov, shipped 11/Nov, arrived 21/Nov (including customs).

I'm still waiting for most of the components for the USB-dongles, ordered from Aliexpress around the same time or just before.

The USB-dongle layout is really crammed, and there isn't much space left for aditonal components. The USB-A connector (standard item, $0.68 for 10pcs) fits the KiCad footprint perfectly!