Andrew Clapp's pages

I apologize for not catching this sooner, but I did not include my process for reading binaries from the chips.   here's a little short post on that.

The commands are all very similar and I'm using the same two config files as before, openocd-1.cfg and openocd-2.cfg.  The commands for reading your binaries off of multiple chips are as follows.  The blurb at the top is the relevant bit from the openocd manual.

# Command: flash read_bank num filename [offset [length]]
# Read length bytes from the flash bank num starting at offset and write 
# the contents to the binary filename. If offset is omitted, start at 
# the beginning of the flash bank. If length is omitted, read the 
# remaining bytes from the flash bank. The num parameter is a 
# value shown by flash banks.


openocd -d0 -f openocd-1.cfg -c 'reset halt' -c 'flash read_bank 0 a5-1.bin 0x08000000' -c 'reset' -c 'exit'

openocd -d0 -f openocd-2.cfg -c 'reset halt' -c 'flash read_bank 0 a5-2.bin 0x08000000' -c 'reset' -c 'exit'

If I run my little script with those commands in it...

./read-binaries 
Open On-Chip Debugger 0.11.0+dev-00546-g5795f4d3e (2021-12-22-14:13)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
debug_level: 0

target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x00003660 msp: 0x20000330
wrote 16384 bytes to file a5-1.bin from flash bank 0 at offset 0x00000000 in 0.155701s (102.761 KiB/s)

Open On-Chip Debugger 0.11.0+dev-00546-g5795f4d3e (2021-12-22-14:13)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
debug_level: 0

target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x00003660 msp: 0x20000330
wrote 16384 bytes to file a5-2.bin from flash bank 0 at offset 0x00000000 in 0.154476s (103.576 KiB/s)

You can see that it starts correctly and reads until the end, giving the correct 16384 byte size files.  And here are the files:

-rw-rw-r-- 1 clapp clapp 16384 Jan 13 18:42 a5-1.bin
-rw-rw-r-- 1 clapp clapp 16384 Jan 13 18:42 a5-2.bin

 Then a quick little reprogram and verify that they run and we now have vetted binary files.

Cheers!

So just a short one today to describe briefly how to change option bytes.  The documentation does not seem to have examples, but I was finally able to stumble my way into getting it working by looking at the methods and steps of a few different articles about changing option bytes for other stm32 chips.

With the stm32g031, you must use the stm32l4x flash driver.  This may vary for your chip, so research that.  Since I found that out the long way round, I hope it saves you time.  Using my new friend openocd, I wanted to enable the BOR enable bit in the option bytes (change from 0xfffffeaa to 0xffffffaa).  It's a one bit change, how hard could it be?

Earlier I showed how you can read option bytes. You can verify they are set at the default. This command:

openocd -d0 -f read-opt-bytes-1 -c "stm32l4x option_read 0 0x20" -c "exit"

gives this result:

Option Register: <0x40022020> = 0xfffffeaa

And this matches the datasheet RM0444 p. 81.  Hooray!

I've tried every combination of option_write and option_load I can think of based on what others had got to work for them, and I was finally able to toggle one single bit in the option bytes. I had to use these two commands in order:

openocd -f read-opt-bytes-1 -c "stm32l4x option_write 0 0x20 0xffffffaa 0xffffffaa" -c "reset" -c "exit"

openocd -f read-opt-bytes-1 -c "stm32l4x option_load 0 0x20" -c "reset" -c "exit"

Then we have the new values: Option Register: <0x40022020> = 0xffffffaa

Recall from earlier, that I had made my own read-opt-bytes-1 config file for openocd.  It basically just sets some defaults, but more importantly, let's me specify exactly which st-linkv2 interface I want to use when there are more than one plugged in at one time.  This is done with the hla_serial line in the config file...

hla_serial "\x55\x3f\x66\x06\x48\x3f\x57\x54\x12\x27\x07\x3f"

It would be nice if openocd could read this style ID instead: 55FF66064887575412270787, but I'll take what I can get. 

Cheers!

... also, *changing* the BOR bits from default settings (BOR turned off) did help with power ups when the supply voltage ramps up slowly.  If you have something like that, be sure to turn on the BOR EN bit.  :-)

*update* Thanks to Paul F. on the openocd chat for catching the error in my build environment.  We're now running openocd 0.11 (the latest release).  And also thank you for the config tips!  You do not need the full path in the config files to get to interface and target directories, and the creation of the dap is automatic.  Now, the new shorter format of my config files are something like this:

source [find interface/stlink.cfg]
source [find target/stm32g0x.cfg]
gdb_memory_map enable
gdb_flash_program enable

adapter serial "\x55\x3f\x66\x06\x48\x3f\x57\x54\x12\x27\x07\x3f"
gdb_port disabled
tcl_port disabled
telnet_port disabled

init

 Cleaner.  Smaller.  Learn something every day!

One of the cool things about using openocd is that you can interact with it, say to figure stuff out for the first time.  Then you can program it to be consistent.  For example, reading the option bytes worked out like this.

1) Make this openocd.cfg:

source [find /usr/local/share/openocd/scripts/interface/stlink.cfg]
source [find /usr/local/share/openocd/scripts/target/stm32g0x.cfg]
gdb_memory_map enable
gdb_flash_program enable
init
reset_config trst_and_srst
jtag configure stm32g0x.jrc -event setup "jtag tapenable stm32g0x.cpu"
jtag tapisenabled stm32g0x.cpu
dap create CPU -chain-position stm32g0x.cpu

2) Now, fire up openocd.

et:option-bytes$ openocd
Open On-Chip Debugger 0.10.0+dev-00937-g8021aef90 (2021-11-03-16:13)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 2000 kHz
Info : STLINK V2J38S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.278873
Info : stm32g0x.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Listening on port 3333 for gdb connections
1
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections

 3) In another window, connect to it via telnet:

telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> jtag tapisenabled stm32g0x.cpu
1
> stm32l4x option_read 0 0x00
device id = 0x10016466
flash size = 16kbytes
Single Bank 16 kiB STM32G03x/G04x/G07x/G08x found
Option Register: <0x40022000> = 0x40600
> exit
Connection closed by foreign host.

I verified that the config worked, and the trap is enabled, just nice to know.  Then I read the option bytes.  Now that I have figured out exactly what was needed to read the option bytes, I don't want to have to fire up openocd and telnet to the instance every time.  That would be great for doing some real time debug work, but I am using forth, which pretty much does that for me already.  So, I want a convenient way to get the option bytes.  I have the command I want the output of, so I just tell openocd to run the command and exit.

et:option-bytes$ openocd -d0 -f read-opt-bytes-1 -c "stm32l4x option_read 0 0x20" -c "exit"
Open On-Chip Debugger 0.10.0+dev-00937-g8021aef90 (2021-11-03-16:13)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 0

Option Register: <0x40022020> = 0xfffffeaa

et:option-bytes$ openocd -d0 -f read-opt-bytes-2 -c "stm32l4x option_read 0 0x20" -c "exit"
Open On-Chip Debugger 0.10.0+dev-00937-g8021aef90 (2021-11-03-16:13)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 0

Option Register: <0x40022020> = 0xfffffeaa

So there it is, running the same process interactively, then programming it to be a scripted command that can be run.  I hope you find this information useful.

Let's suppose that you have written your code, and written it to to memory of the chip, and you now have a chip you can power off and restart and it comes up and does something useful for you in your prototype circuit.  Well, you basically have created a binary that lives in memory on the chip.  If you just read a copy off, you can write it to another chip and you're on your way to production automation.

I bootstrapped this whole process by first writing the mecrisp binary to the chip.  I used st-flash as such:

st-flash erase

st-flash write ~/work/projects/mecrisp/mecrisp-stellaris-stm32g031f4.bin 0x8000000

st-flash reset

You must remember to erase the chip first with some utilities, so I always do it just in case the write command does not.  Once reset, the chip is running forth.  You can now use e4thcom or whatever your preference is to connect to it via serial and begin programming.  Once you have it programmed, you can read off a binary to flash to other chips.

st-flash read ~/work/projects/mecrisp/adc-v.bin 0x8000000 16K

st-flash reset

Now I have a binary image of a programmed forth instance that comes up and measures my voltage at the ADC.  I can program other micros to do the same thing.  I can move my programmer, stllinkv2 or whatever you have, to another micro, and now I can flash that new one, and it will be a clone of all the working code so far.

st-flash write ~/work/projects/mecrisp/adc-v.bin 0x8000000

 This is about where some things started to go awry for me.  Option Bytes.  I wanted to read the option bytes and check to see what some of the default settings were compared to what the datasheet says they should be.  I could not get st-flash to spit out the right stuff.  Furthermore, I wanted to program/read/check more than one chip at a time.  The contraption we have built actually has two micros on it that do different things.  I could not get st-flash to correctly index more than one st-linkv2 consistently across my various build/dev/prog environments, a linux pc, a raspberry pi 3, and a pi 4, etc.  But here are the ways you would do this in theory.

Option Byte
st-flash --area=optcr1 read 

# red
echo "flashing red"
st-flash erase --serial 55FF66064887575412270787 adc-a.bin 0x8000000
st-flash write --serial 55FF66064887575412270787 adc-a.bin 0x8000000
# ./st-flash reset
# gold
echo "flashing gold"
st-flash erase --serial 151115002C135437334D4E00 adc-v.bin 0x8000000
st-flash write --serial 151115002C135437334D4E00 adc-v.bin 0x8000000
# ./st-flash reset

 Enter openocd.  It's what everybody's using, but in my laziness, hubris, and impatience, I had previously failed to muster the required activation energy to hurdle the learning curve.  Then I stumbled across this in a search:  OpenOCD for STM32G0 and STM32G4

Next thing you know, I started reading the openocd user's guide.  And it has been very much the best solution for a number of tasks.  There's a bit of a learning curve, but I assure you it is worth it.  Here's what I ended up with, maybe it will save you some time.  First my first config file for openocd:

source [find /usr/local/share/openocd/scripts/interface/stlink.cfg]
source [find /usr/local/share/openocd/scripts/target/stm32g0x.cfg]
gdb_memory_map enable
gdb_flash_program enable
init
reset_config trst_and_srst
jtag configure stm32g0x.jrc -event setup "jtag tapenable stm32g0x.cpu"
jtag tapisenabled stm32g0x.cpu
dap create CPU -chain-position stm32g0x.cpu

Next, the tailored version, one for each programmer, here's one: "openocd-1.cfg".  Some of the items are commented out.  And I'm still not exactly 100% sure if all these lines do what I want/think or if they are all necessary.  But it's working, so there's that.

source [find /usr/local/share/openocd/scripts/interface/stlink.cfg]
source [find /usr/local/share/openocd/scripts/target/stm32g0x.cfg]
...

Let's get to some more real-world examples.  First, we can look at a color-pill.  Pick a color.  If you search for "blue pill" or "green pill" or "red pill" and tac "stm32" on to the search, they all bring up useful information.  Chip availability being what it is, I'd say get yourself something and work with that.  The essentials are the same.  Any STM32 (or MSP430) that is supported by mecrisp will do.  Then all you need to do is mount your chip to a  breakout board with pins, which you can even do with a bit of luck and a soldering iron.  I am partial to the well-made blue boards from Adafruit, with a good solder mask.  They are far easier to work with than the cheap-o green ones.  Or you can pick up one of the many dev boards available... or get a pre-made "blue pill".  For DIY, you can use the suggested caps and pull-up resistor, but for experimenting purposes, I have found the mostly work fine without extra parts, at least in the way I'm using them.  The CH340 and Programmer usb sticks all have 3.3V and 5.0V outputs.  There are 3.3V reg chips on many of them, so for short wire runs, the power is pretty clean, depending on how much heavy lifting you're going to do.  I can run a 4 digit 7 segment display with no limiting resistors just fine.  You need a programmer, and a serial interface, a breadboard will make connections easier, and an LED is nice, maybe a 10K pot if you want to work with the ADC.  I really like having the 7 seg or LCD display to show alpha-numeric stuff on.

For a programming environment, you can use almost any PC or mac or *nix box.  I found that a Pi 3 or Pi 4 is also capable of doing the trick, and linux is a plus as far as I'm counting.  All the tools you need can be installed easily, or built from source by following the build instructions.  I made a lot of good progress using an ST-Link-V2 (SWIM and SWD both work) and a CH340 serial connector.  There are also JTAG specific usb sticks like this one if your mcu bends that way.

I'm using linux on a Pi 4, and I need some software tools to get the work done.  I used stlink-org's st-flash for programming for a very long time.  I am now very recently an openocd convert.  It is a 200 page manual and worth the read.  I'm not saying it will change your life, but it changed mine.  Get yourself a cup of coffee and the better part of a day and read the openocd documentation and if you don't learn at least one thing you did not know before, I would be very surprised.  You will have to write a config file for openocd for your purpose.  I will share my example, but it may not help you.

You can use e4thcom-0.8.2 to communicate with your chip via serial.  I have a simple wrapper that passes the arguments needed to connect and configure it for mecrisp stellaris.

e4thcom-0.8.2/e4thcom -t mecrisp-st -d ttyUSB0 -b B115200

One thing that is very useful indeed when understanding your mcu, or talking to your microcontroller, with a serial terminal, or programming it, or resetting it, or debugging it, would be the file that describes the chip's guts in detail.  These are the System View Description (SVD) files.  You can read more about that in the CMSIS-SVD page of the mecrisp stellaris documentation.  But basically, you want to find that file for your chip.  Then you can use svd2forth to make everything much more readable.  I did not have space for this, which was a bummer, but it is super helpful if you're lost in your micro.  For example, in the mecrisp source's common/ folder, mecrisp-stellaris-2.5.9a/common/svd2forth-v3/STM32G031.svd, and if you run it through the svd2forth process, you'll get something that is much more 'readable'... and it's basically a map of addresses for all the peripherals and such in the chip.  You might...

Having started off using an stm8s, and then moving to an stm8l, making a batch of gadgets, and having a really good time getting there, then having some supply issues, and now using a smaller stm32, I've picked up some good information over the past nearly two years now and I am interested in sharing some of my experiences.

The project began some time ago, delving into stm8s103f3p6 chips.  The basic idea was to read the ADC, and then display some scaled results on a four-digit seven-segment LED display.  This is a great beginner project!  It gets the programmer familiar with GPIO, reading an ADC, doing some math.  Measurement, Interpolation, and Display... key scientific stuff.  I did a bunch of lift-off work with a breadboard, an stm8s "blue pill", a cheap st-linkv2 usb programmer, and a home-made ttl-serial converter (later replaced by a CH340 chip usb dongle)... Total cost was probably under $20.  There's so much in the way of inexpensive parts for getting started out there.  The information for teaching yourself requires a little determination in some sense, but it is available if you seek it.

The code started out in C, as that was what I was most aware of at the time.  I did not even major in CS or EE but I still ended up getting C and C++ courses in my various swaths of college life.  I explored using several of the various IDE's, including the popular one that starts with an A.  Quickly it all fell back into using GCC/SDCC and make with my comfortable shells and scripting, a build-your-own approach.  It's not a large project, so It barely needs a source file and a header file, maybe a few hundred lines of code at the most.  But it was an easy entry into the world of programming small micros.

Then I heard the term "bare-metal programming", and I realized I had heard it with new ears.  And I got into trying out various things with stm8ef and very quickly, I had a prototype written in Forth.  Thomas (TG9541) was most generous with his time and chatting with me and I learned a good deal about stm8ef.  All the while, I was keeping both the C code and the Forth implementation concurrently active in case one proved better in the end.  Back in my early school days, we had Apple IIe's, and you could access the built-in assembly programmer with "call -151" and we used to do all kinds of fun and questionable things with that, so I was pre-dispositioned towards something, well, simpler, smaller, more efficient.  

It may come as a surprise to some of you, but Forth won out in the end.  The "IDE" is built in.  It is also just swimming in assembly so it "feels" close to the metal as well.  I have picked up a bit of assembly along this journey, but I'm still not an assembly programmer by any stretch.  But it makes more sense than it ever did before.  The forth code allowed more control over all the aspects of the whole, the timing of the display, the interactive approach for debugging, the programming of the chips, etc.  It has just been less work for a better product.

As the need for a better ADC became apparent, we moved to an stm8l chip, and the the libraries from ST were a little more unruly, a lot more like stm32 than stm8, and the IDE started to seem like the only way to manage it all.  I kept trying to take a simpler approach and use less library, less code, picking up some more good tricks with GPIO, like using pin-debug, and I picked up a logic analyzer usb dongle.  Now there is such great support for so many devices from Sigrok that it's almost too easy.  Again stm8ef came through and support for the stm8l was added and I got to take a shot at converting the ST library's approach to using the ADC into Forth code.  This ended up working very well.  Keep in mind, it is a small program for a small chip and it should not be realized in a huge binary, or a bunch...

The cheap stlinkv2 usb dongles can be feisty.  Yeah, you can pick them up for $3 with free shipping from faraway if you are willing to wait for them to show up.  And that can really have some appeal to the underfunded programmer.

After finishing the first minimum viable product version of the software for a neat embedded device, the programming apparatus immediately decided to take a long-lunch.  The stlinkv2's in it stopped playing nice.  I started by updating the firmware to the latest from ST, which did not work.  Fortunately, it did not entirely brick the programmers.  After flashing many versions of the official firmware from ST, I have found that the one mentioned here still works with stm8flash for the most part.  It's older, but that's what works for now.

https://www.carminenoviello.com/2016/02/26/restore-st-link-interface-bad-update-2-26-15-firmware/

This software that ST provides is a java app that other folks have written at-length about.  There seems to be a different zip file version of it for every version of the stlinkv2 firmware.  Is that really the easiest way to do it?

The next problem was that it worked, repeatedly flashing onto the same device, but when I plugged in a new device to program, the usb programmers stopped responding.  I suspect because the firmware is so old.

Workaround.  After trying a bunch of different ways to reset the usb device for each programmer before trying to use stm8flash, I found that this one worked pretty consistently.  The usbreset.c code compiled readily on both my main linux box and on the raspberry pi in my flashing apparatus.

https://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line/290519#290519

resetting stlink devices
Resetting USB device /dev/bus/usb/001/005
Reset successful
Resetting USB device /dev/bus/usb/001/006
Reset successful

It's not ideal, but it works.  Flashing devices resumes normally after the reset.

This was too fun not to share.  Today I was chipping away at t problem that I've been at for a few days, and it finally came together.

The start, was the need to have a way of assigning the channel for ADC on the STM8L in stm8ef.  This has been done by the stm8ef peripherals provided by eelkhorn.  And Thomas had a suggestion of which way to go with it.  Thanks to both of them.

The original code:

: setch ( ch -- )
    DUP 8 < IF
       1 ADC1_SQR4 ROT B!
    ELSE
       8 - DUP 8 < IF
           1 ADC1_SQR3 ROT B!
       ELSE
           8 - DUP 8 < IF
           1 ADC1_SQR2 ROT B!
           ELSE
               8 - 1 ADC1_SQR1 ROT B!
           THEN
       THEN
    THEN
;

The ch passed into setch in this case, is a raw numerical channel between 0 and 27.  The ADC1_SQRx registers store the bits (1 on, 0 off) for which ADC channels we're going to read.  This example is pretty easy to follow, and it took me only about a day to get it.  I still have trouble with forth's IF/THEN syntax, but I am getting better at it.

Thomas suggested a totally different approach, which I got immediately.

: setch ( ch -- )
  1 SWAP 8 /MOD SWAP ADC1_SQR1 + SWAP B!
;

After recovering from my initial "mind-blown" moment in awe of how efficient it was, I groked it and tried it out.  If we figure that the raw number address 0 to 27 is encoded with the register number as an offset (0 to 3) and the bit within that register (0 to 7), it starts to work itself out and so I ran it.

And I could not make it work.  And so I broke it down, and looked at it parts, with a real paper stack, a pen, and then I found it.

ADC1_SQR1 = 0x534A
ADC1_SQR2 = 0x534B
ADC1_SQR3 = 0x534C
ADC1_SQR4 = 0x534D

The first thing is that the /MOD already outputs the remainder and quotient in the order we need so that SWAP is not needed.  I took it out.

    1 SWAP 8 /MOD ADC1_SQR1 + SWAP B!

So I ran that, and it did not work.  And then I was really starting to wonder if I was gonna make this work or not.  Sometimes you have to make changes to your mind in the middle of making changes to a block of code.

Second, the memory addresses are a little quirky, as the addresses increase as the x in ADC1_SQRx decreases.  Thanks ST.  So you need to do a little more to get it to work and reverse those.  So here's the final working function, with some explanations in the comments.  It only takes the single numeric channel (0 to 27) as an argument.  And I think you can use it to set vrefint and temp sensor as well (28 and 29).

  1 SWAP ( 1 n )
  8 /MOD ( 1 ch sqr_off )  \ /MOD returns rem quot, rem=chan quot=sqr_offset
  3 SWAP - ( reverse order )
  ADC1_SQR1 + ( 1 ch SQR# )
  SWAP ( 1 SQR# ch ) B!

 So there you have it.  Plan ahead when writing a forth routine.  Think about where you want to end up.  The 1 SWAP in the very beginning is there so you can use B! on the end, and have access to all that other stuff on the top of the stack in the interim.  

Introduction

I've been diving in to forth on and off for a while now.  It's a thing that takes over my whole brain, and I really welcome the distraction from time to time.  And it's for my work, so there's that.  I've been bouncing between writing code in C using SDCC, writing forth on linux, writing C in the Arduino IDE, and back to forth again.  It's all very enjoyably difficult context switching for me, and i'm good at context switching, or at least I once was.  So that's where this idea came from.  I thought, well, if it is difficult for me to context switch to forth after a few months of programming in C using SDCC on linux, then maybe it's difficult for others too.  Maybe someone will find this useful.

My environment is linux.  The chip I started out with was the STM8S103F3, and if you're just trying to write some forth on a micro, this is awesome way to go.  The little $1 boards are great and cheap.  Check out the great write up on Breakout Boards from Thomas.  I used sduino bits added to the Arduino IDE to get started and really made my first go at the project I'm working on in under a week.  Then we needed to change it up and I could not get all that I needed from that, so I also started working with SDCC from the command line in the shell with a Makefile and built the patched STM8 SPL with SDCC and made some better results with control and speed there.  I also was bringing up my ability to use forth, with no small number of chat sessions, emails, forum reads and question posts, and a good old-fashioned mentoring from Thomas, who I owe a mountain of tasty beverages and a nice meal if I ever make it to Germany (or if he ever visits the US).

Then we changed micros for the project, to get the 12bit ADC at the least, and for other reasons, and we went from STM8S103F3 to STM8L051.  The transition from STM8S to STM8L was a rough one, and I'm not sure I'd every wish upon anyone to have to make the context switch between them as often as I've had to do recently.  This cut away the sduino/IDE development entirely, as I did not yet think it was possible (for me a that time, mere months ago) to import the SPL STM8L into the Arduino IDE like in the fashion.  And, yet, now looking back, and with the ability to at least make an attempt at doing it successfully, I would probably not.  If I were going to do something major along those lines, I'd probably focus my energy on helping out the folks over at SDCC and The SDCC Wiki get more work done on their efforts.  I have received tons of good replies and comments and advice from them regarding SDCC, and it is well supported.

Another current project uses yet another chip, the STM8S001J3, which is super cool because I don't have to solder tssop 20's and because it's just so cute.  It is tiny, itsy-bitsy, small, petite, and just plain not very big at all!  Yet, it packs some good functionality, and can be programmed using a few different methods.  Now let's go blink us some LED!

So, without any further comment...

An Example

\res MCU: STM8S103
\res export PA_ODR PA_DDR PA_CR1
#require lib/]B!

: init ( -- ) 
  [ 1 PA_DDR 3 ]B!
  [ 1 PA_CR1 3 ]B! 
;

: OUT! ( f -- )
  PA_ODR 3 B!
;

This was a really great moment for me.  I had already been able to do some basic forth programming, and really written quite a few actually productive, functional bits of code for the other two STM8 micros that I thought this would be fun to write about.  I got forth onto the chip and was able to connect immediately and start testing the parts of functionality that I knew I'd need.  For those who'd like to follow along with their own hardware, I'm using stm8ef running on the STM8S001J3, accessed via usb on linux, and using e4thcom to connect to a modified cheap CH341 serial dongle to program the chip mounted on a tsop-8 breakout board...