Making graphics and fonts for embedded systems

Microcontroller systems with graphical displays require a way to display text. In case of alphanumeric displays (like HD44780) it is easy – just send your ASCII bytes to the display. Graphical displays operate on individual pixels, so firmware must generate the graphics and texts on the fly.

In this post I show the complete multi-step process from a TrueType (.ttf) font file to autogenerated C code that can be used by a graphics library to display texts on a microcontroller. All code (including the embedded graphics library) is available on Github.
Continue reading “Making graphics and fonts for embedded systems” →

Hard fault in __libc_init_array

When starting my STM32 makefile project for the first time I encountered a very early hard fault in the startup code. It happened exactly when calling libc function at

The whole startup code came straight from ST, so I did not suspect it to be faulty. Here is what I have found out to fix the problem.
Continue reading “Hard fault in __libc_init_array” →

Reading OBD2 data without ELM327, part 2 – K-Line

K-Line is another popular OBD2 interfacing standard, that has been used in European cars before CAN bus became common. There are a couple of physical variations (K-line, K+L, KKL) and slightly different protocols (KWP2000 or Keyword Protocol, and ISO 9141) running on those lines. Basically all you need to talk to an older car is an MCU with a UART and a single transistor. 🙂
Continue reading “Reading OBD2 data without ELM327, part 2 – K-Line” →

Reading OBD2 data without ELM327, part 1 – CAN

All modern cars have an OBD2 diagnostic connector that allows reading many engine and drivetrain parameters like RPM, vehicle speed, temperatures etc.

Most of car interfaces use a special protocol translating chip like ELM327 or STN1110 to convert different vehicle protocols (that depend on the age and brand of the car) into an easier to use serial protocol with AT-commands.

I wanted to build a datalogger that would fit into a OBD2 connector. There was no space to fit my microcontroller and another chip to do protocol conversion, so I investigated and reverse-engineered the most common OBD2 protocols to be able to implement them directly on my MCU.
Continue reading “Reading OBD2 data without ELM327, part 1 – CAN” →

FreeRTOS on Kinetis E Cortex M0+ : easy porting tutorial

FreeRTOS is a popular, open-source operating system that can run on a variety of microcontrollers. This post shows how to make a minimal working setup with two tasks on a new MCU without starting from a complete demo code or code generators (like Processor Expert) on an inexpensive development board FRDM-KE06Z from NXP. All examples use static memory allocation. Most of the procedures and tips mentioned here apply equally well to all Cortex-M microcontrollers.
Continue reading “FreeRTOS on Kinetis E Cortex M0+ : easy porting tutorial” →

XMEGA power down mode for battery powered devices

This post describes how to implement firmware-controlled device power switching on an XMEGA. I am working on a portable device that is powered from a Li-Ion cell, has an USB socket for charging, MCU, couple of LEDs and a button. I wanted to keep the design as simple as possible, so there is just one button connected to the MCU and no separate power switch. Most of the information applies equally to all AVR MCUs.
Continue reading “XMEGA power down mode for battery powered devices” →

Kinetis – relocating variables to upper SRAM

NXP Kinetis microcontrollers have an inconvenient architectural feature – split RAM. The memory is split into two areas of equal size. You can run into this issue when the size of all RAM variables (data+bss) approaches half size of available SRAM. It manifests itself with a linker error looking similar to this:
ld: region `m_data' overflowed by 132 bytes
I will use an MK22FN512 as an example, but this post applies equally to all Kinetis K-series MCUs.
Continue reading “Kinetis – relocating variables to upper SRAM” →

XMEGA USART driver with TX DMA

This is a quite universal, non-blocking UART driver for XMEGA. It supports both transmission (with optional DMA) and reception. Receive side can deliver callbacks whenever a complete line (terminated with \n) is received or received bytes can be retrieved one-by-one from a ringbuffer (more useful for GPS units). This driver can support multiple hardware USARTs in a single application.
Continue reading “XMEGA USART driver with TX DMA” →