Embedded Elixir

If you are not super new to Elixir, you may have read this blog post by José Valim. If you haven’t read it, you may want to check it out. This post references it frequently.

Nerves puts a lot of focus into spending as much time developing your application on your host machine. This means you can rapidly develop your application, write tests, etc. When you feel it is ready you can then burn your firmware to a device and it will just work. This has an issue though.

When you’re starting out with Nerves, you may have connected to your first projects over the network using nerves.local. Libraries like nerves_init_gadget make this easy and when you’re starting out, it’s really convenient. Don’t know the IP address that your device was assigned? Try nerves.local and you’re good to go.

And then you add a second device to your network. nerves.local isn’t looking so convenient any more.

We are thrilled to announce Nerves v1.0 is finally out. This has been 4219 commits by 102 contributors since the initial commit on October 29th, 2013! This would not have been possible without our corporate sponsors and individual backers.

Deployed a firmware image that doesn’t quite work? Made a mistake in development and don’t want to remove and reprogram the MicroSD card to go back? No problem. If the previous firmware image worked fine, then just revert back to it.

This is one of those features that has been possible since the beginning of the Nerves project, but we didn’t make it easy. That’s changing.

Most Elixir developers prefer Mac or Linux, but Windows is historically the platform of choice for embedded development. Therefore as Nerves continues to grow, a Windows solution is needed.

There are 2 fundamental approaches to Nerves-on-Windows:

1. Pretend it’s Unix
2. Run it as a Windows app

Unfortunately, there is no “silver bullet”–each approach has its trade-offs.

Happy New Year from the Nerves team!

We’re marching ahead with our 1.0 plans and methodically going through our constituent projects to get them across the “finish” line. Work priorities have forced some Nerves development on tangents, but some of those may be of interest as well. Here’s a summary of what’s been happening:

While working on a Nerves project, you will likely do most hard work in the host environment. This means you get to develop features quickly, and when are ready, you simply deploy your known working firmware to your embedded devices. This however can lead to a situation where the code runs really well on your i7 powered beast computer, but when deployed on a less powerful Raspberry Pi 0, for example. Nothing will be broken, but things are just too slow. There are a number of solutions to this problem and in this post, I will walk you through a simplified real world example of one possible solution of using an Erlang NIF to speed up one particular functionality.

Wondering what’s happening on the Nerves project? You’re not alone. We’re planning semi-regular updates so that you don’t need to lurk on the elixir-lang Slack’s #nerves and #nerves-dev channels all the time.

Before the updates, I’d like to thank our Open Collective backers, Le Tote and FarmBot, since they’re majorly helping all of us make this project sustainable for the long term.

Alright, here are the highlights:

This is not an Elixir post, but it comes up when working with custom Nerves systems. The problem is how to deal with custom patches to Buildroot, Linux, or any of the non-Elixir libraries that your application might use. You may have seen patch files like these. These patch files are used to create local changes to projects when modifications either can’t be sent upstream (partial workarounds, hacks for specific systems, etc.) or haven’t been integrated yet. This post describes a way to create them.

One of the most common questions we answer in the Nerves help channels is how to store persistant data across reboots. Since the file system is read-only, the normal avenues usually will not work with Nerves.

There are several solutions that have yielded varying levels of success accross projects. Before we dive too deep into SQLite, lets take a look at the other options: