Making It Easier To Build Firmware


Most microcontroller manufacturers give you some kind of free development toolchain or IDE with their silicon products. Often it’s crippled, closed source, and a large download. This is pretty inconvenient when you want to have firmware that’s easy to build and distribute. I’ve found many of these toolchains to be annoying to use, and requiring closed source software to build open source firmware seems less than desirable.

It’s possible to build code for most microcontrollers using command line tools. You’ll need a compiler, the device manufacturer’s libraries and header files, and some method of flashing the device. A lot of these tools are open source, which lets you have an open source toolchain that builds your project.

Setting up these tools can be a bit tricky, so I’m building a set of templates to make it easier. Each template has instructions on setting up the toolchain, a Makefile to build the firmware, and sample code to get up and running quickly. It’s all public domain, so you can use it for whatever you’d like.

Currently there’s support for AVR, MSP430, Stellaris ARM, and STM32L1. More devices are in the works, and suggestions are welcome. Hopefully this helps people get started building firmware that’s easy to build and distribute with projects.

29 thoughts on “Making It Easier To Build Firmware

  1. Only plans to support PIC18 and PIC32? Microchip have been producing their line of C compilers for PIC’s all the way down to 12F, seems strange to ignore everything below PIC 18.

    1. I’d like to contribute both our LPC13xx libraries (the LPC1343 and LPC1347 families have some slight but important differences), and also the LPC176x library. These are all original libraries developed by us (me), offered under BSD 3-clause license, but I’m happy to go with Unlicense. There is currently some good documentation for the LPC1343 library: but not for the others.

      The LPC1343 code is specifically written for the Forebrain LPC1343 dev board, but is written in a way that makes it useable on any LPC1343 board. You donidn’t include

      1. whoops, I meant to say: you didn’t include any contact details in the post, but then I found your twitter handle and stuff via your personal page. Please let me know how best to get in touch with you if you’re interested.

        1. Based on UAir’s work, I’ve done a small amount of work to get things running nicely under Linux:

          It’s no terrible departure from their stock code, but I wrote up step-by-step directions (apologies if UAir has re-published it and made this comment redundant), which might be of interest.

          I’ll also be hacking on it a little more to get it working with the LPC1778 sometime in the near future, and can try to remember to post updates.

          1. You might be interested then in the LPC176x libraries we’re working on, it might be a smaller jump from there to the LPC1778 than from the LPC13xx up.

      2. Should also mention that in terms of the library, there’s only minor differences between the LPC13xx series M3 and LPC11xx series M0, but there are two distinct “generations” that you have to be careful of for each, but other than that, porting code is straightforward.

  2. Honestly, Atmel’s stuff has always been free and non-crippled. The IDE is actually really nice if your running windows. None the less, this will be a great tool, especially for a lot of the new ARM stuff coming out!

    1. That’s not true, it has been free for the past 6-7 years, but before that Atmel didn’t offer the gcc option at all.
      Good thing it went free, it has really boosted usage, compatibility and documentation. It really shows what OpenSource has to offer :-)

  3. I think that we will be able to talk about Open Source Hardware when the architecture of the processor itself is Open Source, like for the COFE processor (open source hardware developped for academical purposes) that could be synthetized on an FPGA. Taking an open source IDE for developing on ARM based processors and others are not enough, but important though.

    1. Yes, an open source architecture that’s actually available in silicon would be very cool. The OpenRISC is one example of an open core, but it’s not widely used since you need to run it on a FPGA. They’re working on an ASIC though apparently.

    2. I’ve seen this advocated, and I can see why it’s interesting, but I can’t see why it’s _useful_, or more useful than a sufficiently accessible and documented platform. For all practical purposes you’re going to want an ASIC.

  4. This sounds wonderful. Especially for my 2 stellaris launchpads, which have remained mostly unused (even with the stellarisware+gcc post earlier, it was just so much of a hassle to build for)

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.