5 Steps to Getting Started with Embedded Programing

I’ve been getting asked the question, “So how would I get started with embedded development?” more and more often lately.

This is actually a really tricky question. It’s not like, “How would I get started with Haskell?” or “How would I get started with Rust?” Embedded development is such a weird and diverse thing that it’s almost like asking, “How do I get started with programming?” except in an alternate universe where 128k is still a lot of RAM. I’m not sure where to even begin.

Read more on 5 Steps to Getting Started with Embedded Programing…

6 Reasons to Build a Firmware Test Suite

At Atomic, we build a lot of systems that incorporate device firmware talking to software. We also commonly interface with other firmware or software teams.

I believe every project that involves firmware talking to software should include a high-level suite of tests that are written against the firmware’s interface to the software (e.g. Bluetooth, Ethernet, USB, etc). Read more on 6 Reasons to Build a Firmware Test Suite…

Travis CI Now Monitoring Ceedling and Friends CMock/Unity!

We have updated Ceedling and release a new Rubygem to bundle the latest TDD counterparts, CMock and Unity, to utilize Travis CI to monitor the health of our tools at the ThrowTheSwitch GitHub organization!

Atomic Object has blazed the trail of bringing effective test-driven development (TDD) and continuous integration (CI) to C development for nearly a decade. When we embarked on this journey, very little (if any) support existed for the C language, so we rolled up our own.

  • Unity is a basic testing framework. It’s portable C, easy to configure, and runs on almost everything.
  • CMock is a framework that works with Unity to help you create mocks and stubs of interfaces to simplify testing.
  • CException is simple exception handling in C. It is significantly faster than full-blown C++ exception handling but loses some flexibility.
  • Ceedling is a build system that rolls up all the above into single Ruby gem!

Read more on Travis CI Now Monitoring Ceedling and Friends CMock/Unity!…

Callaloo Radio System: Part 2 – Building a Homebrew USB Device

At the end of part 1, the radio link between the receiver and the bathroom doors’ transmitters was working, but how does the receiver get its data where someone else could see it? I could have put a couple red/green LEDs on the receiver board itself, or wired it to some sort of display, but that doesn’t give much room for future expansion. (We may be remodeling the downstairs floor in a couple months, and adding another bathroom is likely. Other sensors could also use the same radio link.)

Read more on Callaloo Radio System: Part 2 – Building a Homebrew USB Device…

Callaloo Radio System: Part 1 – Setting Up a Radio System from Scratch


The bathroom on the main floor of our office is down a short hallway, so we can’t see whether the bathroom is available without looking around the corner. To solve this problem, we made an Arduino-based monitor for a reed switch (a magnetic switch) on the door, setting an LED red or green to indicate whether the bathroom is occupied or available.

Read more on Callaloo Radio System: Part 1 – Setting Up a Radio System from Scratch…

Inexpensive Ethernet JTAG Adapter with Raspberry Pi and OpenOCD

I recently wanted an ethernet JTAG adapter for a project I was working on. Unfortunately ethernet JTAG adapters can cost upwards of $300, and even then they can be specific to particular chipset and toolchains.

However, were already using OpenOCD with ST-LINK/V2 programmers to communicate with out hardware, and it turns out that it’s very easy to set up OpenOCD on the Raspberry Pi. You can then plug the programmer into the Pi, connect a debugger (gdb in our case) to the OpenOCD instance, and debug your firmware remotely! Read more on Inexpensive Ethernet JTAG Adapter with Raspberry Pi and OpenOCD…

Getting Started with MQTT

As more and more things around us become networked, the communication protocols tying them together need careful rethinking. This network of devices, sometimes called the “Internet of Things” or “Machine-to-Machine” network (though it could also just be called “the Internet”), includes many embedded devices with very limited resources.

Protocols designed for typical ethernet networks, such as HTTP, are based around assumptions that no longer fit: they expect more bandwidth, processing power, and network reliability than may be available, and that networked devices will be on most of the time.

There is a more appropriate alternative, however: MQTT. It’s much lower in overhead, with only a 2-byte header for many messages. Its design suits devices that are suspended most of the time, with only occasional network activity. It also has support for reliable delivery built into the protocol, so simple sensors can just flag an outgoing message as requiring confirmed delivery and let the message broker take care of delivery reattempts. Using a standard messaging protocol for all communication also greatly reduces the surface area for possible security vulnerabilities. Read more on Getting Started with MQTT…