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 of lines of code.

Enter Mecrisp Stellaris.  Both Matthias and Terry have been very kind and of great generosity.  Thanks to them, there is a quite a mountain of example code and other good information online.  The constraints of making 16KB work have been a challenge.  But with a 14KB mecrisp to work with, and really stripping down the code, it has become possible.  With just a handful of bytes of free space left, the ADC has been read and the output scaled and displayed as needed.  

Yes, it is just basically a voltmeter, and yes, this is not rocket-science.  Or is it?  What is the definition of telemetry?  With the addition of BTLE, or in any of a number of ways, the "sampler" can really do quite a lot of meaningful work.

...