The STM32 files
Skip the text and go to the project links
Some notes on embedded software development
I've got some personal preferences regarding embedded software:
C code can be written using any suitable text editor. Which one is suitable depends on your personal experience and opinion.
C compilers for popular microcontrollers are free software
printf() rules as an all-purpose debugger
Of course, real debuggers are available and useful at many places
Gnu Make is a great tool
Use a revision control system. Many of them are available as free software, choose one that fits your requirements
Some vendor supplied MCU configuration tools and libraries are very useful in terms of not having to read the fine manual
Everything necessary to build a particular project must be able to be checked in to a source control repository
The top level Makefile of a project must automate all necessary steps to build the binary
UTF-8 and consortes suck! Consider using a 7-bit ASCII charset for your source code
I've made my first experiences in programming micros using paper and pencil as an assembler tool, manually translating
the opcodes to HEX numbers and typing them using a HEX keyboard into a SC/MP machine. Later on, with some stops on
popular Z80 and 6502 based home computers, then
starting with the well known 8051, I've experience with various microcontrollers and tools including but not limited to Intel, Infineon, STMicroelectronics,
NEC and Hitachi which are now Renesas, Texas Instruments and Analog Devices. I've seen various tooling approaches, starting with a
naked assembler up to providing all integrated embedded workbenches.
No matter which particular controller you're using in your project, or even more than one in some kind of heterogenous multi-processing approach
(I made units containing a total of 6 DSPs, 3 microcontrollers and a central processor), there's one major requirement: You must be able to build
the whole project, including all involved processors, by one top level Makefile. You must be able to check out the source tree on any PC providing
the neccessary tools and then type "make" to build the project. Any manual step here leads to failures in the future.
Developing embedded firmware over many years, I've made these experiences:
Commercially licensed tools suck. Their licenses either don't run on another PC or are all taken by your coworkers, eventually must be renewed on a regular basis or place trouble of any other kind on you.
"Free" versions of commercial tools suck. They place nasty restrictions on you, and want to be registered or licensed even for free versions.
Fully integrated development environments suck. You don't know what is running in the background, and there's always at least one step in your build process
left that cannot be automated
You'll need a quick "edit, compile, run" turnaround. Using Gnu make, you can boil this down to a simple "make flash" on the command line
Build your in-the-field update mechanism for the target in a very early stage of the project and make it useable by simple command-line tools.
This will ease your future development, since you'll have a working firmware updater that you can integrate in your automated "edit, compile, run" process.
At a later stage of development, you'll need the updater anyways for your users. This is the time where you might thinking of wrapping your
updater into a nice GUI based tool for your end user.
Linux provides a way much better environment for embedded software development than Windows does. Simply because you have a lot of
well known tools available that help you automating your build process.
Some vendors have useful microcontroller configuration tools that even run on Linux, others have full-blown IDEs providing everything but the kitchen sink.
You'll have to make your own experience to see which one is more useful for you.
Vendor provided peripheral libraries tend to be bloated, they try to cover many use cases. If you need real fast drivers, write your own for your special
Don't rely on your full featured hardware debugger. They are very useful for catching tricky bugs, but sometimes
you'll have to work with real basic tools, lucky you if you've provided printf() debugging facilities in your base system.
Boiling down these experiences and requirements, I've made some non-GUI, non-IDE tools for the STM32 family of microcontrollers.
These integrate some rather unusual combinations of tools and libraries:
The STM32CubeMX configuration tool
STM32 standard firmware libraries and STM32Cube HAL libraries
Gnu ARM toolchain
Most of my pages describe rather general examples and projects intended as starting points for more sophisticated projects. This is the
way I use them, and the reason why I made them. I make some of them available here, hoping they might be useful for someone. These are not
intended as step-by-step instructions for beginners in embedded software development, there's a lot of these things available on the internet.
Links to my STM32 related pages
A quick and dirty blinky LED demo for the Nucleo-F767ZI board
A simple in-application flash updater using ChibiOS and LwIP
Use LwIP, yaffs, ChibiOS and STM HAL to provide ftp and http on a Nucleo-F746
Some demos using the LwIP stack together with ChibiOS and STM HAL
Simple board support for STM32 Nucleo boards using ChibiOS and STM HAL library
An improved makefile template for STM32CubeMX 4.13.0, HAL code, ChibiOS, LwIP and the Nucleo-F746 board
Using the STM32CubeMX eclipse plugin with gcc and make on linux
Using the STM32CubeMX code generator with gcc and make the quick and dirty way
Managing multiple projects for the STM32 Controller family using makefiles
Using multiple ST-Link devices
Expanding the Versaloon universal programmer platform by adding a second target port
Back to Wunderkis.de (German language only)