Some time ago I have built a WiFi thermometer with a NodeMCU and a 6Ah recycled nickel-cadmium battery. WiFi is probably the least power-efficient communication methods, but I was curious how long could a NodeMCU run from a big battery pack.
It took some time to get meaningful data…
Continue reading “Practical NodeMCU endurance with a big NiCd battery pack”
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”
I developed an universal SPI driver for XMEGA line of MCU for a battery powered device, where power efficiency was important. To get anything started on new hardware I have started with a simpler code first which uses interrupts and then I began looking at using XMEGA’s DMA controller (that was totally new to me) to improve speed and make the MCU sleep longer. This is a complete driver that can work with any kind of SPI peripherals.
It is also a nice practical introduction to DMA, because XMEGA DMA controller is one of the most simple you can find in microcontrollers (comparing let’s say to Kinetis Cortex-M), yet has all the necessary features.
Continue reading “XMEGA high-performance SPI with DMA”
Character LCD are one of the easiest and cheapest way of adding output to a microcontroller system. The world of character LCDs has mainly standarized on HD44780 controller chip, which was designed to be interfaced with the rest of the system by a parallel bus, but today simple bit-banging does the job.
One of the obstacles to using HD44780 with XMEGA are different supply voltages. Displays usually require 5V, while XMEGA is 3,3V-only. Continue reading “XMEGA and HD44780 LCD”
Call graphs are a visual way of showing relations between functions in a piece of code. They can be useful to analyze dependencies and to get basic understanding of a large, unfamiliar codebase. Tracing program flow can also help in finding bugs.
Continue reading “Making call graphs with GCC, egypt and cflow”
This is a two-in-one device. It can be set up to:
Embedded systems often require permanent storage of some configuration parameters eg. radio channel, volume in a radio etc. All settings must be saved and read reliably, otherwise the device may become unpredictable. Imagine a variable frequency drive (an “electric motor controller”) set to a certain speed, that after a power cut reads bad data from it’s memory and overspeeds an expensive piece of moving machinery leading to physical damage.
Continue reading “Reliable storage of settings in EEPROM”
CRCs are useful for checking if data received from outside or read from memory is not corrupted. This is especially important in embedded systems, as it could take just a single bit-flip to drastically change the configuration of the system. I needed to protect configuration structure of my new project when it is being saved and read from EEPROM. To make sure that the data I read from EEPROM is exactly what I have written I decided to use CRC-16 CCITT across the whole structure.
Continue reading “Using XMEGA hardware CRC generator for CRC-16 CCITT”
Fuses in AVR microcontrollers have a bad reputation among beginners, because a wrong setting can lock you out of accessing the chip. With the right tools they are not scary. 🙂
Fuses are just a special name for three bytes of EEPROM-like memory (they are not “conventional OTP” fuses at all) that set the most low-level features of an AVR like:
Continue reading “AVR fuses for beginners”
Storing backups on NFS is not an officially supported by Apple, but is quite easy to do.
Continue reading “Using OS X Time Machine with NFS”