Add support for the XH-M194

[TG9541]

New in the mail was a board with the following features:

• STM8S105S4T6 (16K Flash, 2K RAM, 1K EEPROM, 44pin)
• 6 relays 12V/250VAC w/ 6 red status LEDs
• 6 green status LEDs
• 4 digit digital clock-style 7S-LED display
• 6 keys
• DS1302 RTC, half-duplex SPI, backup battery holder
• 12V AC/DC power supply

[VK6TT]

Nice board Thomas. Big thanks to the mailman.

…

_____ From: Thomas [mailto:notifications@github.com] Sent: Saturday, 16 December 2017 5:06 PM To: TG9541/stm8ef Cc: Subscribed Subject: [TG9541/stm8ef] Add support for the XH-M194 (#128) New in the mail was a board with the following features: * STM8S105S4T6 (16K Flash, 2K RAM, 1K EEPROM, 44pin) * 6 relays 12V/250VAC w/ 6 red status LEDs * 6 green status LEDs * 4 digit digital clock-style 7S-LED display * 6 keys * DS1302 I2C RTC w/ backup battery holder * 12V AC/DC power supply - You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on <#128> GitHub, or mute <https://github.com/notifications/unsubscribe-auth/AT7yawkHKYT4MXkxulNLL7G77 yP3DU-Rks5tA4gSgaJpZM4RERwi> the thread. <https://github.com/notifications/beacon/AT7ya9H0LgCdXaeKELa_ss2qabtImV4_ks5 tA4gSgaJpZM4RERwi.gif>

[TG9541]

I took advantage of the 11.11 10% rebate :-)

I think it's a good board for some automation tasks, but since it has no inputs, linking it to some kind of field bus would be a big plus. I'm thinking of something a bit like LIN, maybe with fail-over to optional master nodes. The bandwidth doesn't need to be very high.

[VK6TT]

It looked ideal to me for small scale reticulation controllers. I lose mine to lightning every 5 years or so. Two of these would be considerable cheaper than the commercial equivalent I buy.

…

_____ From: Thomas [mailto:notifications@github.com] Sent: Sunday, 17 December 2017 8:22 PM To: TG9541/stm8ef Cc: VK6TT; Comment Subject: Re: [TG9541/stm8ef] Add support for the XH-M194 (#128) I took advantage of the 11.11 10% rebate :-) I think it's a good board for some automation tasks, but since it has no inputs, linking it to some kind of field bus would be a big plus. I'm thinking of something a bit like LIN, maybe with fail-over to optional master nodes. The bandwidth doesn't need to be very high. - You are receiving this because you commented. Reply to this email directly, view <#128 (comment)> it on GitHub, or mute <https://github.com/notifications/unsubscribe-auth/AT7ya-a4m41_ZzrObLfBtOX5T bRxoBtMks5tBQdwgaJpZM4RERwi> the thread. <https://github.com/notifications/beacon/AT7ya6xvakv_bbx-vQcjM227Bc7S5ZtKks5 tBQdwgaJpZM4RERwi.gif>

[TG9541]

The standard programming would most likely do the job. It would be more fun to brew up a custom firmware, though.
By the way, this was the first time I've heard of "reticulation". Northern Hemisphere English doesn't appear to have a word for it ;-)

[VK6TT]

Hahaha...next time it's +40 degrees I'll see if the word snow appears in our dictionary. It may have been removed since it doesn't exist here

…

_____ From: Thomas [mailto:notifications@github.com] Sent: Sunday, 17 December 2017 10:50 PM To: TG9541/stm8ef Cc: VK6TT; Comment Subject: Re: [TG9541/stm8ef] Add support for the XH-M194 (#128) The standard programming would most likely do the job. It would be more fun to brew up a custom firmware, though. By the way, this was the first time I've heard of "reticulation". Northern Hemisphere English doesn't appear to have a word for it ;-) - You are receiving this because you commented. Reply to this email directly, view <#128 (comment)> it on GitHub, or mute <https://github.com/notifications/unsubscribe-auth/AT7ya66iSN3TRNbHMV2NCqcRZ 3C54iBsks5tBSoFgaJpZM4RERwi> the thread. <https://github.com/notifications/beacon/AT7yawPKU3wNFMdC8St_Z_CwFdO9Jr1Fks5 tBSoFgaJpZM4RERwi.gif>

[TG9541]

After completing log entries about, well, the W1209 logger, I traced some of the STM8S105S4 pins. It's fascinating that these guys rarely get to the point where they actually use on-chip peripherals more complicated than a GPIO:

• the bi-directional SSI of the DS1302 RTC works with bit-banging instead of using the SPI
• the 74HC595 serial interface uses bit-banging wasting the UART GPIOs

Both could have shared the SPI, easily. I dare say that the whole thing could have been done with an STM8S003F3 and some cheap shift registers.

[hydra]

@TG9541 Any progress on support for this board? Also, have you got a branch with your code changes on it?

[TG9541]

@hydra I have not really started - I traced some of the LED control and found that DP doesn't appear to be connected. For a "star" I could be convinced to get the basics done. The RTC may take a little bit longer, but this could be hugely accelerated by some help from the community ;-)

[hydra]

Ok, I'm gonna pass on this, I got a board thinking the code was ready, but since they're using bitbanged stuff I'll just make my own board.

[TG9541]

The STM8S105S package has 48 pins, and PD1/SWIM controls the "colon" LED elements. Something else will have to be used as serial interface. Sigh.

[hydra]

might be worth updating the wiki page so that others don't buy them hoping for support (yet).

[TG9541]

Done. I'll provide support in the near future.

[TG9541]

The usage of most GPIOs is now known. 5 GPIOs are either not connected, or I don't (yet) understand what they do. See details in the Wiki.
By the way, my LED display is defective (Digit 2 LED-A not working).

[TG9541]

The display is "clock type common-anode". I'll replace my defective display with "standard 4-digit/DP".

[hydra]

@TG9541 Great to see some recent progress. Keep up the good work!

[TG9541]

I'm trying to figure out how to connect the console: the designer did a poor job at using the GPIOs (5 GPIOs N/C and one 74HC595 output unused), and there are no GPIOs easily accessible that aren't also used for something else (not even PD1/SWIM).
For identifying the pins I connected the console to the UART (micro clips at pins 14 and 11 of the 74HC595). A console through the key pins might be an option but it's ugly. Perhaps the most viable thing is still PD1/SWIM (by not using the clock dots while the console is active) if I have figured out what to do to make it work.

[hydra]

my thought would be to find somewhere to cut traces and patch gpios connected to UART2 and SWIM to unused GPIO pins. then use UART2 and SWIM normally

[TG9541]

Communication through PD1/SWIM works. Let's see if I can fix LED MPX.

[TG9541]

OK, the LED display and the serial interface work now. Keys and relay outputs next.

[TG9541]

Tested:

• keys and 7S-LED in background task
• outputs (0b00gggggg00rrrrrr)
• serial interface through swim

Not yet implemented:

• no clock second dots
• no RTC chip

[TG9541]

I'm about to merge XH-M194 code with DS1302 RTC support (see XH-M194/board.fs). The 7S-LED second indicator remains to be implemented (it needs to play nice with the half-duplex serial port through PD1/SWIM).

For convenience, here is a binary:
xh-m194.zip

[TG9541]

The implementation is now complete, and the latest STM8 eForth pre-release 2.2.22-pre2 contains board support code. Using the console through the PD1/SWIM works like charm even if it's shared with the clock colon dots.

A decimal point after the 2nd digit controls the colon dots:

: test ." AB.CD" ;
' test BG !

After a 30s "blackout period" this will be rendered on the LED display as Ab:Cd.

[TG9541]

The Wiki is now up-to-date.

[hydra]

great work, I'll try this on mine ASAP.

[TG9541]

When you try the serial interface better avoid "genuine Chinese" CH340 USB serial dongles: their I/O is worse than anything I've seen: some work out-of-the-box, some require a Schottky diode, a magic spell, and some never work. PL2302 interfaces (even "Chinese knock-off") usually do the job.

I compared the DS1302 clock registers with some other chips: BCD encoding seems to be the norm. It's maybe worth the effort implementing "burst transfer" - an array of BCD values can be easily converted to and from ASCII, or compared with a threshold for programming alarms or events.

[hydra]

ok, I have a selection of Black Magic Probe, J-Link, STLink and USB-UART boards that I use for STM32 development, so hopefully something will work.

[TG9541]

ST LINK v2 should work. I've never tried v1, or any other tool. Stm8flash usually works fine with STM8S medium density devices. I have no experience with windows tools, but @VK6TT Richard uses them.

[hydra]

quick update, today I had time to get stm8ef running on my XH-M194.

I used OSX 10.12.6. Initially i used my Windows box but currently can't compile and don't have a working stm8flash tool, any hints there gratefully received.

Had an issue with the build scripts on OSX, see #197 and pr that fixes it #198

When attempting to compile stm8ef on windows (cygwin64) there were issues with the genalias.awk script, on windows it was complaining that .../target/\ is a directory due to this https://github.com/TG9541/stm8ef/blob/master/tools/genalias.awk#L142

hacking in these lines 'fixed' the problem but are probably incorrect..

 gsub("\\.", "dot", filename)    # replace "." - it's forbidden in Windows filenames
 gsub("\\\\", "slash", filename)    # replace "\" - it's forbidden in Windows filenames

After that the code compiled on cygwin but I have not attempted to run it.

For flashing I used a baite ST-Link V2 with default firmware, I normally reflash these with Black Magic Probe for STM32 development, but today I used it as-supplied. It was the v2 revision, more details here:

https://wiki.cuvoodoo.info/doku.php?id=jtag#black_magic_probe

My XH-M194 had readout protection enabled and could not be read or flashed until it was reset to defaults as follows.

make defaults
stm8flash -c stlinkv2 -p stm8s105s4t6 -s opt -w tools/stm8s105FactoryDefaults.bin 

I noted that the make defaults tried to flash the defaults for the s103 to my s105... probably not a good idea.

After all that I was able to flash the code that I built on my OSX box using

stm8flash -c stlinkv2 -p stm8s105s4t6 -w out/XH-M194/XH-M194.ihx

The 4 digit LED display now reads 4th and that's as far as I've got so far... 😃

[TG9541]

Great to hear, that's some success!

Unfortunately, I don't have access to a Windows machine (unless I take my wife's laptop, which she won't like too much - of course, I could have a Windows machine, but these always remind me of office work ;-) ). OSX is even a bigger problem. Normally I would have suggested using a VM with a modest Debian, and some people successfully used a RaspberryPi (there is even a e4thcom binary for Raspbian), but it's good news that you've got the toolchain running on cygwin.

Where I expect trouble in a Windows environment is the filenames in the lib and target folders. A possible solution is maybe extending the codeload.py tool (e.g. by using a file that contains all the words for #include and #require).

Loading defaults should be possible with make defaults105, which is a bit awkward, of course. Maybe I'll find a better solution by using the information in $(board)/target.inc.

Thanks for the CuVoodoo link. These $1.80 dongles have always looked like a good hacking target (USB and I/O for cheap).

[hydra]

I'd like to get some kind of source-level debugging working, I had a look though the wiki but didn't notice anything about the topic. i found stm8 binutils here: https://stm8-binutils-gdb.sourceforge.io/ and wondered if that's usable? What approach do you use for source-level debugging?

[TG9541]

I don't have any source level debugging at the moment. When I started this little project the STM8 GDB support was not ready (in fact it had been announced for some time). In my past job I collected about 10 years of experience with doing unit testing and seeing bugs in the source code in plain C.

I found some really nasty bugs in C.H. Ting's assembly code, although he had used source level debugging. The Forth approach, however, provides much better unit and integration testing methods (where is the difference in Forth anyway?).

uCsim provides register level debugging. I used it once to track down a bug in uCsim ;-)