The world of embedded software development can feel like a very isolated place. Earlier in my career, when I was doing mostly embedded work, I remember often feeling jealous of my colleagues who were working on mobile and web applications. I would constantly hear them talking about exciting new libraries, frameworks, and tools with catchy names that supposedly made their lives easier. I was saddened by the lack of excitement and advancement of tools for those of us writing C. Read more on Cedux: Experimenting with the Redux Model in C…
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.
After successfully automating the reporting and watering of my garden last summer via my GardenPi, I wanted to rev on the idea this summer. Since this is as much a learning project as it is an automation project, I decided to improve on both fronts. Introducing: Garden KnowEms™. Read more on Spy on Your Garden with Garden KnowEms…
In professional software development, version control systems (VCS) are a critical part of our daily routine, because they allow developers to:
- keep an accurate record of the entire history of a project
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…
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!
Part 2 finished with the radio receiver circuit’s data made available via a UART-to-USB bridge and a libftdi-based client on the host computer. The data may be available on the network now, but how do people access it?
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.)
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.
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…