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.