Antares: One Bare Metal Build System To Rule All Microcontrollers

antares-build-system

[Andrew Andrianov] has the same itch we do when it comes to the variety of inexpensive dev boards out there. They put hardware in your hands but when it comes to the IDE it tends to be a very mixed bag. Some offer hobbled copies of proprietary software, but in most cases you’re on your own for any kind of open source development environment support. He and a couple of friends are working to change that. What they’ve come up with is Antares: a single build system which can compile code for multiple microcontrollers.

The idea is to make the coding environment agnostic from the compile/burn process. This serves a few purposes; it lets you use the IDE you’re most comfortable with, be it Eclipse or emacs. It also seeks to ease the pain of writing libraries that will work with multiple different chips. So far the package supports several of the usual suspects: AVR, msp430, STM32 ARM chips, as well as AT89,and STC variants of 8051. Other chips can be added as more hands make light work (in other words, roll up your sleeves and help these guys out!). Right now development targets Linux dev platforms but OS X has been shown to work with some patches.

The link above is a rather daunting readme from the Github repo. If you need a better overview before diving in hit up the RC1 announcement on [Andrew’s] blog.

22 thoughts on “Antares: One Bare Metal Build System To Rule All Microcontrollers

  1. Drosophilia: Debugging is specific to your hardware and IDE you’ll use and is out of the scope of the buildsystem. In other words:
    make menuconfig
    Toolchain Settings -> [*] Generate debug symbols
    Then use gdb and whatever integration your IDE has with it.

  2. The IDE used by Arduino is already doing this, it works for Arduino, Teensy, Stellaris, and lots of other platforms by plugging in an new toolchain (well, that could be done better than what’s done today thought)
    But, the Arduino IDE is crappy for people used to Eclipse, VisualStudio and so on.

    But yes, what about debugging?, and proper toolchain for all platforms? (stm32 for instance)

    1. You just place your toolchain prefix in toolchain settings and use whatever toolchain your like. The scope of antares is NOT to build you a cross-toolchain. crosstool-ng does all the heavy lifting here.
      Antares just builds your code, library code, and provides a convenient way to tune library options for you via kconfig. e.g. no more config.h with thousands of lines of messy #ifdefs
      Regarding the debugging – see my comment above. Antares can build you anything you need to start debugging, and even start gdb and stuff for you with the right deployment script. But it is NOT an IDE, so you are free to pick whatever tools you like.

        1. * You do not have to collect from scratch all the components from vendor’s (e.g. ST) source drop, and guess the makefile and the usual set of flags.
          * You can have proper kconfig for even the simplest led-blinker projects at zero effort.
          * You can configure the shipped libraries via kconfig, that is MUCH faster than editing a config.h by hand every time.
          * Library code that comes with antares stays in one place, easy to update and maintain.

          In short, consider antares an overgrown makefiles template + library code with everything to get you started, and started fast.

  3. Now this is newsworthy!! It was about time someone came up with something like this. I do have my own Makefile for building and flashing firmware for the arduino but it would be great to have a standard build for other uCs.

  4. Does this setup have the smarts to compile the STM32 sample projects? They supply a lot of nice demo code but it requires one of those horrible $$$ IDE systems to compile it. I’ve written makefiles for a couple of the demos, but it’s pure ugly tedium.

    For debugging and loading, it would be nice to just specify what kind of debugger unit you have, let it take care of loading the code and setting up gdb.

    I’m happy to see more structure in embedded development. There is a lot of “cowboy style” hacking going on, poorly written spaghetti code, cut-and-pasted code with unintended side effects, etc. Stuff that would not be tolerated on projects for “real” computers. Beefing up the quality of the development environment will help to discourage bad software practice.

    1. Yep, ST periph libraries are all there. USB device kit still needs some love to work, and is planned for some later release, when I’ll have a spare minute or two.
      Check the examples for stm32vl blinky example, that should get you started.
      And make sure you specify the correct density/flash/ram sizes in arch settings, or your code won’t start. If unsure – configure “Deployment -> stm32flash”, connect the stm32flash and run make probe. That will detect the mcu and update the config.

      1. On a side note – if you use some USB bootloader, e.g. maple (dfu-util, mass-storage, etc.), you’ll need to specify the offset at which the code will run.
        STM32F1X series are mostly stable, and well-tested during the eurobot-2013 competitions, while STM32F4X are still very experimental and vitaly untested.

  5. As I am not an electronics/programming guru and astronomy is an interest of mine, I fear the only question I can ask Andrew is: why the name Antares, and does it have anything to with the Red Supergiant?

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.