search

TG9541 / stm8ef

STM8 eForth - a user friendly Forth for simple µCs with docs
https://github.com/TG9541/stm8ef/wiki
Other
315 stars 66 forks source link

Add support for the XH-M194 #128

Closed TG9541 closed 6 years ago

TG9541 commented 6 years ago

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

VK6TT commented 6 years ago

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:

TG9541 commented 6 years ago

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 commented 6 years ago

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 https://github.com/TG9541/stm8ef/issues/128#issuecomment-352251976 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 commented 6 years ago

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 commented 6 years ago

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 https://github.com/TG9541/stm8ef/issues/128#issuecomment-352260778 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 commented 6 years ago

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:

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 commented 6 years ago

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

TG9541 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

TG9541 commented 6 years ago

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

TG9541 commented 6 years ago

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 commented 6 years ago

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

hydra commented 6 years ago

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

TG9541 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

TG9541 commented 6 years ago

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

TG9541 commented 6 years ago

Tested:

Not yet implemented:

TG9541 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

The Wiki is now up-to-date.

hydra commented 6 years ago

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

TG9541 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 ;-)