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 requirements.
  • 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
  • ChibiOS
  • lwIP
  • yaffs
  • zlib
  • Gnu ARM toolchain
  • Openocd
  • 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.

    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 (German language only) ... und ein Zaehlpixel hab ich auch :-)