Debugging @ 5.3Mbit/sec (5333333 Baud) on stm8s microprocessors

  • In Debugging @ 5.3Mbit/sec (5333333 Baud) on Arduino and other Embedded systems  I describe how I handle debug print on Atmega processors like the one used in Arduino and 3D printers, basicly I let the embedded CPU transmit as fast as possible and let the rest of the world adjust to whatever speed that happened to be. It works great and is now my goto solution to get a project of the ground.

Lately I have been tinkering with boards which use the stm8s processors.  Not because they have got something special to offer (except the price), but there are many very cheap gadgets available from China which use this processor, like thermostat, voltmeters, programmable power-supplies or relays. Have a look at github.com/TG9541/stm8ef. I see these boards as half-baked solution to many of my projects, if they just had f.ex. a way to be networked or…. – they need to be HACKED.

The stm8s architecture is as simple as it gets, it has the same register set as the venerable 0ld 6502 microprocessor from 1975, with the registers updated a bit.

6502 A 8bit X 8bit Y 8bit SP 8bit PC 16bit status
stm8 A 8bit X 16bit Y 16bit SP 16bit PC 24bit status

The stm8s is not supported by GCC, but the SDCC compiler has it covered, not C++.  I am more of a standard C guy anyway, so not a big thing for me. To get going you need to:

For a detailed guide on how to do this please see TG9541 STM8S-Programming

The cheapest stm8s103  is a 20pin version with 8kbFLASH/1Kb RAM $3.28/10pcs delivered this is also the most common and will be used here.

It was actually quite tricky to get consistent bit timing.  The cpu uses a 32bit bus internally, the instructions are between 1 and 4 bytes long, and the cpu uses 3-stage pipe-line to increase speed. Hence it is important to get the instructions properly aligned.

The functionallity of dprint() implemented here is the same as I described in Debugging @ 5.3Mbit/sec (5333333 Baud) on Arduino and other Embedded systems so it might be a good idea to read if you haven’t already.  The main difference is a different instruction-set, a different compiler, and a slightly different language.

Device atmega2560 atmega328p stms8103f3
Package 64pin 28pin 20pin
Flash 256kb 32kb 8kb
RAM 8kb 2kb 1kb
EEPROM 4kb 1kb 640
Language C++ C++ C
Compiler gcc-5.4 gcc-5.4 sdcc-3.8.0

Let us have a look at the source code, as usual an init-routine and a printc() routine written in assembler.

if you wonder what PUBLIC and GLOBAL means in the above code you will have to stick around until the end of this article.

Since we are not using C++ there is no operator overloading, so we need different named routines for different data types, but otherwise it is business as usual

Likewise the header file that do the conditional dprints are a little different too

Here is an example of how dprint could be used:

Makefile

I always use Makefiles to compile my code, they have become more and more sophisticated, maybe you can get some inspiration from this Makefile

If the tools used are not just standard tools I tend to install them with a Makefile too, that way I have documented where I found it, and how it was installed,

Here we have to get get hold of some header files and get an compile stm8sflash, the details are here:

I have always detested the include-file hell with functions prototypes and extern for global variables, so I generate header files on the fly, like having the .h embedded in the .c file

  • Defines which is needed in other files goes in the beginning of the .c file
  • Variables that need to be accessed from elsewhere are marked with GLOBAL
  • functions which can be called from elsewhere are marked PUBLIC
  • it is often a good idea to mark local functions as static, the compiler likes it.

The shell-script below extract-header.sh creates the header-file

I really like to see how the size of my my code evolves, so I have created sdcc-size.sh which is the equivalent of avr-size in the gnu world

I like to be able to keep an exact copy of the source-code to each and every code there exist in the devices around my house, Years ago I created a small tar-archive of the source-code whenever I flashed a device, these day I use git.

To get a revision numbering scheme i create a git branch whenever I flash some permanent code, The Makefile can still generate a tar file of the current software-revision so a workflow might be like this.

  • make # compile
  • make flash # upload the code to the microcontroller
  • make com  # connect to the microcontroller via a serial UART @ 5.33 Mbaud
  • git status # to see what has change
  • make tar # creates a full backup of all the files used
  • make commit # save all changes in git and makes a new branch, ready for the next change

You can download a copy of the current source dprint_enabled-r7.txz, feel free to use it as you see fit – licensed as beerware

Although most of dprint.c has been presented above you can see the complete file below

Print Friendly, PDF & Email
This entry was posted in Embedded. Bookmark the permalink.

1 Response to Debugging @ 5.3Mbit/sec (5333333 Baud) on stm8s microprocessors

  1. Pingback: Debugging @ 5.3Mbit/sec (5333333 Baud) on Arduino and other Embedded systems | Peter Lorenzen

Comments are closed.