You may have heard the news: Atomic Object is moving to a new building later this summer. We’re excited about designing the new space. For my part, I found an opportunity to try out a technology that I have not worked with before, the wireless networking system XBee. Read more on Get Started with XBee – A Beginner’s Tutorial…
I’ve written a few posts on using Rust for embedded projects:
- Rust Sysroots for Easier Embedded Projects
- Using Rust 1.8 Stable for Building Embedded Firmware
- Generating Rust Bindings for Embedded Libraries
- Embedded Rust Right Now!
I think they gave a decent overview of a couple of tricky parts, but as always, the devil is in the details. To help with all the gritty details, I’ve written up a more complete example.
Read more on Using Rust in an Embedded Project: A Simple Example…
Rust now has usable support for Rust sysroots. This makes it must easier and useful to use cargo to build your embedded projects. You should be able to even use stable rust once 1.9 is out, but you will have to use a nightly for now.
Since Rust 1.6 was released,
libcore is now stable, and
nostd is now a stable feature. This means we can now build Rust libraries for our embedded firmware using the official stable version of the compiler!
Computers are amazing machines. They can perform massive amounts of stuff every second, and they’re being put into everything around us to make the things we interact with on a day-to-day basis smarter and better.
This is made all the more remarkable by the fact that computers are astonishingly dumb. My favorite explanation of just how dumb computers are can be found in one of my favorite recorded talks, Richard Feynman’s lecture about computer heuristics. (Start around the 10-minute mark for the particularly relevant bit.)
One of the secrets to making these dumb machines do smart things is the way applications get loaded and executed within your OS. But have you ever thought about who loads the code that loads your code?
Read more on Assembling Your Computer’s Brain, Byte by Byte…
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.
On my current project, we’re building the GUI in Qt 5. It’s (mostly) open-source, has some really intriguing platform support, and Qt Quick 2 has a fairly advanced model for both keyboard focus and transitioning focus between widgets just with the keyboard.
When I started work on a spike to prove out some ideas I had about using a Qt Quick StackView to structure the navigation of our app, I still managed to run into some problems with transitioning focus between widgets. Read on for my solution. Read more on Focus-Handling Methods for Qt Quick StackViews…
As I talked about in my last post, Embedded Rust Right Now!, you can call C functions directly from Rust without much difficulty. However, you normally still need to provide Rust types and prototypes for the corresponding C types and functions you want to use. This can be a time-consuming and error-prone process.
Fortunately there is a tool call rust-bindgen that can generate bindings automatically directly from C header files! It’s a little trickier when you’re cross compiling to target embedded systems, but you just need to pass some extra clang flags to bindgen. Read more on Generating Rust Bindings for Embedded Libraries…
Since joining Atomic, I’ve worked on quite a few web projects, where rapid prototypes are common and quite easy to produce. Unfortunately, not all domains we deal in have such luxuries.
My latest project is a lightweight embedded linux device with a GUI and physical buttons. In such a stack, it can be hard to get rapid feedback cycles on your UI and UX. To try and alleviate this problem, I came up with a method for scripting interaction with rapid prototypes using a display attached to a Raspberry Pi. Read more on Rapid Prototypes for Devices with Raspberry Pi…
Because I’m an embedded developer, I often work on projects where I need to store some data on an extern EEPROM or Flash chip. The internal memory of these chips is usually divided up into fixed sized
pages. It’s often the case that you’re not allowed to write more than a
page at a time. This makes things complicated if you want to do a
write that spans multiple pages. It’s even more tricky if you want to support wrap-around, which turns out to be very handy in certain situations.