The C standard library (libc) is a component that gets little attention. It is just there. However for embedded systems it brings some challenges and overhead in terms of code size. As firmware size is often critical, it sometimes makes sense to use a trimmed version of the standard library or to remove it entirely. I will focus on reducing the code size that may be beneficial for a small application like a bootloader.
Continue reading “Reducing firmware size by removing libc”
Link-time optimization is a powerful output size reducing feature. Even though (as of 2018) still regarded as somewhat experimental, LTO is worth trying, if the binary size is very important and the application can be reliably tested afterwards, as link-time optimized code is hard to debug. A bootloader can be an ideal example. LTO is very easy to enable, but there are some small quirks that have to be taken care of. I will use GCC 7.2.1 from GNU Arm Embedded as an example.
Continue reading “Fixing Cortex-M startup code for link-time optimization”
Running out of disk space is a common problem for unattended Linux boxes like database servers or backup storage servers. Usually I would use Zabbix (or Nagios) do to the monitoring, but it would be an overkill for a Raspberry Pi or a single NAS, so I made a small Bash script. This script runs df, checks disk usage and sends mail in case the free space is running low.
Continue reading “Disk space monitoring & e-mail notifications with Bash”
Fourier transform is a vast domain of knowledge with many practical applications within signal processing. Virtually all communications protocols use Fourier transform at one step or another (including LTE, GPS and WiFi). Another popular example are the “jumping bars” in music players showing levels of low and high tones in real time. In this post I show the basics of obtaining spectrum of an audio signal on an EFM32 Cortex-M3 microcontroller. No scary math!
Continue reading “Practical FFT on microcontrollers using CMSIS DSP”
Bell 202 is a quite old modem standard that is still used today in amateur radio for data transmission over VHF (Packet Radio and APRS) and industrial automation (HART). It is a very simple FSK modem. The speed is limited to 1200 baud, which makes it very easy to implement on any small microcontroller. My implementation is built on top of sinewave generator code for XMEGA described in a previous post.
Continue reading “Bell 202 modem for AVR and other MCUs”
The XMEGA is quite a leap from the “classic” AVRs. Some of the interesting features are the DAC and DMA. When combined, they can be used to generate all kinds of useful signals in the audio range.
This example uses the DAC, DMA, timer and event system to generate 1200 Hz and 2200 Hz sinewaves. I’ll show how to make a Bell 202 modem (think: APRS and AX.25) in another post.
Continue reading “Making sinewaves with XMEGA DAC”
Most popular microcontrollers come with IDEs and tools provided by the manufacturer, like NXP, STM, TI or Silicon Labs. IDEs are commonly based on Eclipse and creating a project for almost any chip in those IDEs is usually just a click away, so why would you ever want to make such a project from scratch, gather all header files, libraries and scripts? Read to find out why and how 🙂
Continue reading “EFM32 Cortex-M firmware project from scratch – step by step”
I use Git for version control of all my projects. Every repository of course has many branches that I try to systematize like: stable, devel, experimental, per-feature etc. Many times I have run into the problem of committing my changes to the branch I did not intended to. Git shows you the branch and changed files when entering the commit message, but when you do that 50 times a day you are doomed to loose focus (and commit your experimental stuff into a stable branch 🙂 ).
My solution to this problem is a simple pre-commit hook that reads the name of the branch and prompts for confirmation, if the name of the branch is on a watchlist.
Continue reading “Git – confirmation before commit”
Most STM32 microcontrollers feature an internal EEPROM. It is useful for storing settings or calibration data. Regular flash (that stores code) can also be used, but the EEPROM can be updated byte-by-byte and is independent from regular flash. This may come handy during application updating, as whole flash can be simply erased without affecting the EEPROM.
I wrote a generic driver for keeping settings in the EEPROM based on the standard peripherals library for STM32L, that is easier to understand than the official demos from ST. It was tested on an STM32L151RC.
Continue reading “Using the internal EEPROM of STM32L”