What microcontrollers offer good/great Linux toolchain support?

[R2D2]

Howdy,

I'm interested in programming microcontrollers in C and assembly under Linux.  What mainstream inexpensive microcontroller families have a good to great Linux tool chain?  I'm at home in a terminal and am looking to go bare metal in my tinkering around.  Any help or suggestions would be appreciated.  I also have access to OS X terminal in addition to Linux.

Thanks! 

[mathias]

STM32 is supported by arm-gcc (https://launchpad.net/gcc-arm-embedded). This has no limits on code size or optimization. There also exist a ST-Link for linux from github (https://github.com/texane/stlink) for programming/debugging. STM32 boards include a debugger onboard and are dirt cheap.

I am using this combo myself for quite some time, and I'm really happy with it. I don't use any IDE, just a text editor (Vim) and the command line tools (Make, ST-util, gdb, ...). Everything works out of the box for me, and that's using both linux Mint at home and CentOS at work.

A great place to stat is this page: http://eliaselectronics.com/stm32f4-tutorials/setting-up-the-stm32f4-arm-development-toolchain/

[nctnico]

Howdy,

I'm interested in programming microcontrollers in C and assembly under Linux.  What mainstream inexpensive microcontroller families have a good to great Linux tool chain?  I'm at home in a terminal and am looking to go bare metal in my tinkering around.  Any help or suggestions would be appreciated.  I also have access to OS X terminal in addition to Linux.

Beter ask which aren't supported. Every CPU core supported by GCC can be used.

[dannyf]

Anything that is supported by GCC would be a good starting point.

If you use IAP, all you need then is the compiler as the chip is self-programming itself.

Google AN2557.

[tszaboo]

Are you seriously buying the coat for the button you already have?

[zapta]

I had good results with avr using Linux and osx.

[Lukas]

From my experience, I can confirm that AVR, MSP430 and STM32 all have rather good linux toolchains available (GCC, avrdude/mspdebug/openocd or st-util). The advandage of maintaining the toolchain using a Makefile yourself is that you don't have to learn a new IDE every time you use a different micro. Make, gcc, and gdb are always the same, only the programmers are different. Additionally, you don't have to leave your favorite enviroment (text editor, etc.) for developing for your mcu. I can encourage everyone to learn the basics of makefiles and create their own workflow, it gives deep understanding of the tools you're using, there's no/less 'black magic' anymore. This really comes in handy if 'it breaks' or you want to do nonstandard things.
Example: The STM32 have a builtin ROM bootloader for USB. In order to make my device less easy brick I shifted the main app by one flash page+512 byte. The 512byte contain a md5 checksum of the main app. (it had to be 512 bytes because the interrupt vectors have to be aligned at 512 byte boundaries) The code in the first flash page, which gets executed on power up calculates the md5 sum of the main app and compares it to the one stored in flash. If the checksums don't match, it'll execute the usb bootloader in order to fix the app. It's been very easy to modify the build process, because with the makefile, you've got full control.

You have to understand make to use it properly, but instead of some IDE's XML rubbish a normal person can understand it.

[dannyf]

it gives deep understanding of the tools

I would argue that for most of us, having a deep understanding of the tools is a waste of time. You don't need to understand how your GPS works to use it; You don't need to understand every intricacy of your cars to drive it or even to drive it well.

To be successful, you just need to know how to deploy your limited resources (time, money and brain power) to where you add the most value and use others where you aren't as gifted (ie. specialization).

The exception, of course, is if you are so exceptionally resourceful or gifted.

a normal person can understand it.

Highly subjective and likely doubtful.

[jancumps]

I would argue that for most of us, having a deep understanding of the tools is a waste of time. You don't need to understand how your GPS works to use it; You don't need to understand every intricacy of your cars to drive it or even to drive it well.

Definitely not the case for embedded. Understanding the compiler is essential. Even your example of GPS is flawed - we have a few projects that use it and the receiver modules are not drop-in parts. To get the best performance you have to understand a bit about how they work.

Understanding the compiler is essential if your job is dealing with situations where having an understanding of the compiler is essential.
But in other situations i'd rather say: nice if you know it. Essential?

[GiskardReventlov]

The advandage of maintaining the toolchain using a Makefile yourself is that you don't have to learn a new IDE every time you use a different micro.

All your advice makes a lot of sense to me and I agree but the IDE is the best reason to use make and the command line.  The last IDE I used for altera env. for FPGA was around 11GB! It was sluggish too.

My complaint with linux toolchain is there are so many sites with info that it's a bit fractured but I'm new to mC and I just need information relevant to the HW I have. So far I found avrdude for actually talking to the chip, I have the chip's datasheet and I even managed to build binutils like avr-ar, etc. I built gcc for target=avr and now I'm stuck on building the libc as it can't find rules to make the .h files.

[Neverther]

Have you tried if your distro has prebuilt packages for them?
avr-binutils, avr-gcc and avr-libc...

If you want to compile them yourself, you could look build scripts from some distro.
Arch has plaintext scripts that are pretty easy to read.

If you continue with avr, try searching for "avr Makefile template", I use it and so far it has been good (my coding environment is nano ).

[GiskardReventlov]

If you want to compile them yourself, you could look build scripts from some distro.
Arch has plaintext scripts that are pretty easy to read.

The tar balls came with a build script but requires internet. The laptop can't get internet.
I can't figure out why libc wants to build new .h when the tar balls came with what looks like all the .h that are needed.

If you continue with avr, try searching for "avr Makefile template", I use it and so far it has been good (my coding environment is nano ).

I see this is for the writing/compiling code stage. Good tip.

[andyturk]

I would argue that for most of us, having a deep understanding of the tools is a waste of time.

Depends on what you mean by "deep understanding", but I'd much rather work with someone who can maintain their own dev environment, than someone who's either dependent upon team members to fix stuff, or has to call tech support on a regular basis. There's probably little need to understand the inner workings of the compiler itself, but knowing how the overall build system works is often very important.

For example, the nRF51 bluetooth/M0 chip requires some non-standard build steps to integrate Nordic's bluetooth code with the main application. It was easy to tackle with a Makefile, but (I think) it would be a real challenge for the IDE-only crowd.

https://github.com/andyturk/nrf_blink/blob/master/Makefile

[nctnico]

I would argue that for most of us, having a deep understanding of the tools is a waste of time.

Depends on what you mean by "deep understanding", but I'd much rather work with someone who can maintain their own dev environment, than someone who's either dependent upon team members to fix stuff, or has to call tech support on a regular basis. There's probably little need to understand the inner workings of the compiler itself, but knowing how the overall build system works is often very important.

I agree. It is one of the first things I show interns because schools never teach how and why a compiler/linker finds libraries and header files. It is something you need to know if you ever attempt to link against a seperate library (even when using an IDE).

[dannyf]

I'd much rather work with someone who can maintain their own dev environment, than someone who's either dependent upon team members to fix stuff, or has to call tech support on a regular basis.

I would rather have my cake and eat it all too,

Seriously, I don't care how one gets his job done. I only care about getting the job done.

There's probably little need to understand the inner workings of the compiler itself,

If we require a "deep understanding" before using anything, we have to die: we understand very little about human brains, for example.

but knowing how the overall build system works is often very important.

Absolutely true. But if you have limited resources, is it more important than getting your job done?

but (I think) it would be a real challenge for the IDE-only crowd.

You can always set up a question so that it is impossible to be achieved by the alternate: try to write a piece of code in your text editor by clicking mouse, for example. It doesn't substantiate the argument but the prejudices of the person presenting that argument.

As to your specific example, what makes you think it would be a real challenge for the IDE-only crowd?

[hans]

You make it sound like any software engineering or electronics is work. For me (and I guess many others here) it also a hobby (or 'therapy').

Sure use the most preconfigured environment you can find where you only have to initialize a library and it does everything for you. Great, you got the application done in no-time. You have full bragging rights. 2 months later, a strange bugs arises and it's inside some library or closed module that you adopted. You don't know anything about how the program gets compiled on the particular platform, optimized, how the library exactly works, etc.

As a a general rule: everything you integrate in your product is something you become responsible for maintaining & servicing, even it's a completely closed box to you. You're just screwed if a serious bug arises and you don't know much about it or better: you are not the person to solve it (because you don't have the source code/schematics). Hooray for dependencies.

For example, at work we had this RF modem that locked up occasionally when we switched RF channels/protocol. Some customers were outrageous with our system. We communicated proactively with the manufacturer of the modem, and the response we got after 12-months of troubleshooting back-and-forth (with many stupid did-you-plug-it-in questions in between) was: we have problems with this RF broadband SoC which locks up, and the manufacturer of that chip is unable to fix their firmware problem. Unfortunately our HW does not have the  RF SoC reset line connected to our uC.

A deeper understanding will give more control and flexibility over your projects. I'm still not certain where you're going with this "I only care about getting the job done", in a thread that's clearly about setting up an environment for home/hobby projects, which IMO is about learning & experiencing.


Back on topic:
I'm also getting into Linux, and it seems like AVR & ARM have pretty good GCC toolchains. Microchip supplies a full IDE that runs on Linux, but the compilers are separate installation. I guess you could easily write your own makefiles for them , there is even a command-line debugger utility (not GDB though).

However, for any toolchain I still prefer debug functionality , which especially handy for debugging device drivers. So I probably will try MCP and ARM (STM32F4) first.

[westfw]

What mainstream inexpensive microcontroller families have a good to great Linux tool chain?

Stepping back from the raging debate, I'll go and say that MOST modern microcontrollers can be developed using good to great linux toolchains.  Certainly anything that gcc supports, which is pretty much everything but the 8bit PICs (which have a linux compiler from Microchip) and 8051 (which has SDCC.)
The main complicating factor is that you may have to search, work, and/or struggle to put together the various pieces into your particular flavor of "great."  So you load up netbeans/eclipse/codeblocks as your IDE, and some version of gcc as your compiler, and some Nth-party bit of code that connects your hardware (which you may have to buy) to your debugger, and then you have to do all the configuration so that they work together.  (Did I mention that half of those will have to be compiled from source, sending you down a deep OSSW dependency wormhole that can be ... very frustrating?)

And then there's the whole window-compatibility layer that comes with linux.  I run one of the PIC8 C compilers under wine on OSX, and that works fine (it doesn't seem to work with more complicated tools that have a "license manager" layer.  At least, I haven't figured out how to make it work.)

[andyturk]

As to your specific example, what makes you think it would be a real challenge for the IDE-only crowd?

Well, I've worked with some folks that are members of the "IDE-only crowd." These are very smart people with advanced EE degrees from top-notch schools--they can do math that would make my head explode. But they're helpless when it comes to fixing problems outside the scope of what the IDE does for them.

Not everyone who uses an IDE falls into that category, but if you don't know how the underlying toolchain works (sufficiently well to use it directly), then you're probably going to be asking someone else for help on a regular basis.

IMO, a good test is to give someone a blank machine (i.e., fresh OS install) and see if they can bootstrap their dev env without outside help. If they can download everything they need, and build the application given only the URL of the git repo, then they're in the "gets shit done" category, and those are the folks I want to work with.

If you can "get shit done" with your IDE, that's totally cool too.

[dannyf]

Well, I've ...

Thanks.

I am still trying to find out what's so peculiar about the make file you posted that you think it would be a real challenge for the IDE-only crowd.

Any help there would be greatly appreciated.

[calin]

Here is a quick list what i use - hobby and serious work mostly open source stuff:


AVR - avrgcc very good support
MSP430 - mspgcc very good support
ARM - all flavors and manufacturers excellent support (google linaro gcc toolchain)
8051 - supported so so by http://sdcc.sourceforge.net/ .  Only selected chips - for example the CC254x BLE from Texas need IAR to work
PIC - sdcc frree but not for all PIC's and of course MPLAB (which is nothing than the Netbeans IDE with plugins from Microchip)


Advice: Use the MAKEfile Luke !!! let the IDE on the dark side of the force


Take this from a software guy that writes code for the linux kernel and lives from writing device drivers. I use an modern IDE for editing but build is all based on makefiles .. nothing replaces the human brain (even if we don't really understand it )


As for a guy that does programming and is not capable to build an executable without an IDE ... most likely he is working in the wrong field. I never saw a decent software developer or good engineer which is not capable to understand or write a makefile . Sorry for the rant .. but that is a FACT.

[zapta]

Take this from a software guy that writes code for the linux kernel and lives from writing device drivers. I use an modern IDE for editing but build is all based on makefiles .. nothing replaces the human brain (even if we don't really understand it )

Does this provide you easy jump from error messages file/line number to source code?   What about auto completion, while-you-edit error marking, refactoring, etc?  IDEs are not just for batch building of the program, they provide a major productivity boost.

[calin]

Take this from a software guy that writes code for the linux kernel and lives from writing device drivers. I use an modern IDE for editing but build is all based on makefiles .. nothing replaces the human brain (even if we don't really understand it )

Does this provide you easy jump from error messages file/line number to source code?   What about auto completion, while-you-edit error marking, refactoring, etc?  IDEs are not just for batch building of the program, they provide a major productivity boost.

Yes, you get all the benefits. I use now Netbeans C/C++ and used Eclipse .. just switched to netbeans about a year ago as I find it more civilized because it does not stick its nose in my work more than I need. You have code completion (code completion in a IDE is not a function of the build process it is actually the AST/abstract syntax structure which is created by all modern IDE's using clang or llvm) , also you have hoover based navigation and all kinds of other goodies like code re-factoring  using AST.  Jump to the error line is a simple console feature that is built into both eclipse and netbeans - just think errors are actually printed to stderr so is enough to get a line number out from an compiler error. Compiler error messages are somewhat standard for all compilers -- easy.

Beleive me .. i do c by 20 years now and nothing replaces the fine control what you have in a makefile for the build process ... you spend more time scanning around a forest of checkboxes and drop downs scattered around a bunch of tabs than you will just  type an 4-5 chars  option in a makefile. All you need is to write a first  Makefile and reuse ...

[westfw]

Makefiles always seem to expand in complexity till only a few people at a given organization really understand them, and they seem to be based on pretty much a crock of hack of a "language."  (otherwise we wouldn't need automake, right?)

[nctnico]

Here is a quick list what i use - hobby and serious work mostly open source stuff:


AVR - avrgcc very good support
MSP430 - mspgcc very good support
ARM - all flavors and manufacturers excellent support (google linaro gcc toolchain)
8051 - supported so so by http://sdcc.sourceforge.net/ .  Only selected chips - for example the CC254x BLE from Texas need IAR to work
PIC - sdcc frree but not for all PIC's and of course MPLAB (which is nothing than the Netbeans IDE with plugins from Microchip)

Add any 68k based controller (Freescale) and most Renesas controllers to that list.

[westfw]

Also PPC, MIPS, Sparc, and x86.  Though I guess those don't show up as often as "microcontrollers" (excepting PIC32, which is MIPS.)

(I keep expecting x86 microcontrollers to show up.  But perhaps the tools and education advantages are too much advanced toward the very big CPUs.)