What microcontrollers offer good/great Linux toolchain support?

[Marco]

I wouldn't call them microcontrollers, but Intel Quark is getting in the same range as the MMU ARMs.

[dannyf]

All you need is to write a first  Makefile and reuse ...

Alternatively, you can click a button and let the IDE do its magic.

[dannyf]

End of the day, it is your knowing where your value-add is and maximizing return on  your investment (time and money and knowledge, etc.)

[TerminalJack505]

It seems like you can always tell the hobbyist programmers from the professional developers by whether or not they know how to use makefiles. 

A hobbyist (or a professional who only works on small, rinky-dink projects) can get by building their software from the IDE. 

Once you have a big enough project that you have to automate the build process then you need makefiles.  (Or a similar build mechanism.)

No one builds using the IDE for automated builds.

[dannyf]

No one builds using the IDE for automated builds.

A more accurate statement is probably this:

No one YOU KNOW OF builds using the IDE for automated builds.

[andyturk]

No one YOU KNOW OF builds using the IDE for automated builds.

Alright, Mr. Contrary... Could you please regale us with a story of doing automated builds/continuous integration with one of those whiz-bang $5K/seat IDEs?

[TerminalJack505]

I don't know why you would even want to use an IDE for automated builds.  Automated builds don't really need the functionality that an IDE provides. 

Ideally, you wouldn't even need to have a monitor hooked-up to the build box.  It would just sit there and run builds, as needed, and notify someone (via email, typically) when something noteworthy happens (the build fails, for example.)

Automated builds do more than just compile code.  They also retrieve code from version control and run unit tests, among other things.

[dannyf]

I don't know why you would even want to use an IDE for automated builds.

Read the earlier posts and you will know.

[nctnico]

I don't know why you would even want to use an IDE for automated builds.  Automated builds don't really need the functionality that an IDE provides. 

Ideally, you wouldn't even need to have a monitor hooked-up to the build box.  It would just sit there and run builds, as needed, and notify someone (via email, typically) when something noteworthy happens (the build fails, for example.)

Automated builds do more than just compile code.  They also retrieve code from version control and run unit tests, among other things.

I agree. At some point it becomes messy to try and support several products with a shared code base using an IDE. Too many things can go wrong especially when working with multiple people.

[zapta]

It seems like you can always tell the hobbyist programmers from the professional developers by whether or not they know how to use makefiles. 

A hobbyist (or a professional who only works on small, rinky-dink projects) can get by building their software from the IDE. 

Once you have a big enough project that you have to automate the build process then you need makefiles.  (Or a similar build mechanism.)

During the day I am working on a ginormous multi language/platform/product code line with all the fancy shmancy tools and systems for automation, testing, analysis, collaboration, productivity, production management, you name it, and on top of it I have my own set of scripts/aliases to make things even easier (e.g. 'm' for 'make' and 'r' for 'run').

Working in the evenings on small open source projects for fun I took a simpler approach, doing my avr/C++ work using the the Arduino IDE.  The needs are different and having a simple development environment that other can easily setup and master makes my projects more open.

Different strokes for different projects.

[TerminalJack505]

It seems like you can always tell the hobbyist programmers from the professional developers by whether or not they know how to use makefiles. 

A hobbyist (or a professional who only works on small, rinky-dink projects) can get by building their software from the IDE. 

Once you have a big enough project that you have to automate the build process then you need makefiles.  (Or a similar build mechanism.)

During the day I am working on a ginormous multi language/platform/product code line with all the fancy shmancy tools and systems for automation, testing, analysis, collaboration, productivity, production management, you name it, and on top of it I have my own set of scripts/aliases to make things even easier (e.g. 'm' for 'make' and 'r' for 'run').

Working in the evenings on small open source projects for fun I took a simpler approach, doing my avr/C++ work using the the Arduino IDE.  The needs are different and having a simple development environment that other can easily setup and master makes my projects more open.

Different strokes for different projects.

I agree.  One person projects rarely need a complicated build system.  IDEs work fine for small, one person projects.

You obviously know your way around a makefile, though, and realize that the IDE isn't always the end-all, be-all with regards to software development.  And that's what I'm trying to say.

[dannyf]

the IDE isn't always the end-all, be-all with regards to software development. 

makefile / commandline [or anything you put here] isn't always the end-all, be-all with regards to software development.

And that's what I'm trying to say.

That's the same thing the other side is saying too.

[TerminalJack505]

I guess we're going to have to agree to disagree on the whole matter and leave it at that. 

Especially since it's completely off-topic to the original post.   

[calin]

OMG !!! I started a religious war ... ultimately everyone uses what he thinks as being the appropriate "hammer" for the job.


Yet I still reserve my right to not hire a C programmer that says does not know Make. Fair enough?

[kshitij]

All this fighting, when the guy simply asked for a list of embedded dev toolchains supported on the Linux platform. Definitely looks like an EE forum.   

R2D2, most toolchains supported on Linux either use GCC or vendor-supplied (aka, patched GCC source wrapped in a BSD-ish license) software. You can find most of the targets here:

http://gcc.gnu.org/install/specific.html

Assuming you are a beginner, just pick one with good documentation (this means actual documentation, for e.g. AVR-Libc, ARM, MSP, PIC etc. , not the GCC compiled docs) and nice forum support (PIC, AVR, MSP, some ARM vendors). Do not bother with the toolchains which go with the 'ask-our-mailing-list' routine.

To make life easier, maybe start with a 8 or 16-bit device, before moving on to 32-bit. To avoid the command line, use the vendor's IDE (most of them are free). I can't guarantee that all IDE's support Linux, though most do, by using plugins for Eclipse/NetBeans.

To have fun, post another thread asking for the best microcontroller on this forum.

[andyturk]

To make life easier, maybe start with a 8 or 16-bit device, before moving on to 32-bit. To avoid the command line, use the vendor's IDE (most of them are free). I can't guarantee that all IDE's support Linux, though most do, by using plugins for Eclipse/NetBeans.

This advice is pretty common around here, but I don't understand it.

From a hardware perspective, many of the modern 32-bit mcus are super-simple. Give 'em 3 volts, maybe with a few decoupling caps, and you're good to go. Sure, you may have to learn how to solder a QFP, but that's a pretty low hurdle. From the software side, the most complicated thing is the reboot sequence, and that's almost always handled by vendor supplied code or an RTOS.

Once your main() is running, the 8- and 16-bit processors are *harder* to program than a 32-bit mcu. One reason is because C works most naturally on architectures where the size of a pointer is the same as the size of an integer. Another is that the smaller mcus sometimes require bank switching gymnastics to address anything more than a trivial amount of memory. 32-bit architectures almost always have memory-mapped peripherals, so you don't have to mess around with assembly language instructions. In fact, on ARM Cortex, it's possible to boot the processor and run your application without requiring a single line of assembly code. That's very cool. And getting back to the topic of this thread, going with a 32-bit mcu means you can use GCC.

IMO, beginners should start with 32-bits now unless they have a very specific reason to use a rinky-dink, legacy processor.

[dannyf]

From the software side, the most complicated thing is the reboot sequence,

Try to get the adc to work on earlier LM4F120 or those luminary chips; Or ethernet on those same luminary chips.

You may lose hair, potentially lots of hair.

[nctnico]

The STR700 series from ST is another fine example of a complete joke. Fortunately you don't have to use those. There are many good ARM controllers with proper documentation and libraries for USB, ethernet, etc.

[jancumps]

OMG !!! I started a religious war ... ultimately everyone uses what he thinks as being the appropriate "hammer" for the job.


Yet I still reserve my right to not hire a C programmer that says does not know Make. Fair enough?

if you have a say in who's hired: yes. You can do as you please.

[zapta]

Yet I still reserve my right to not hire a C programmer that says does not know Make. Fair enough?

If you want to give such a high importance to arcane and counter intuitive technologies like Unix Make it is your perogative.   ;-)

http://freecode.com/articles/what-is-wrong-with-make

Compare it for example with a more modern build system with a rich library of task oriented rules

http://ant.apache.org/manual/index.html

Back to the topic:  OP did you get the information you looked for?  Which MCU family do you incline to use?

[jancumps]

...Compare it for example with a more modern build system with a rich library of task oriented rules

http://ant.apache.org/manual/index.html
...

Ever had a peek into the CONTRIBUTORS file in the root of your Ant installation ?

[suicidaleggroll]

If you want to give such a high importance to arcane and counter intuitive technologies like Unix Make it is your perogative.   ;-)

You're missing the point.  While I can't speak for calin, I can speak for myself, and I have the same rule.  It's not about testing whether or not they know make, make isn't the end-all of build tools, and any decent programmer should be able to adapt to whatever environment they're placed in.  It's about testing their programming experience level and comfort with standard build tools.  As I have found (and I assume calin has also found), most "programmers" who only know IDEs (and usually just one specific IDE) and have no experience with vi, emacs, make, gcc, etc. aren't actually programmers.  They suck at algorithm development, troubleshooting, working through problems, etc.  They google for a command, plug it in verbatim in the IDE, and when it doesn't work they run back to their supervisor to ask for help.  It's like hiring a mathematician who needs to use a symbolic math tool to solve for 2x=4.

[dannyf]

-While I can't speak for calin, I can speak for myself, and I have the same rule.  -

what's the point of having a rule or right if you don't get to exercise it?

I for one care about getting shit done, not how someone gets it done.

if I ever get a micro manager who insists on a way to do things, I will fire him or her on the spot - if a manager is so micro focused, he has no brain and has no vision. You will never learn anything from him or her so better move on now.



  -.  As I have found (and I assume calin has also found), most "programmers" who only know IDEs (and usually just one specific IDE) and have no experience with vi, emacs, make, gcc, etc. aren't actually programmers.  -

I have to confess that that has never been my experience.

this whole discussion boils down to where you think your most value add is.

[Rigby]

If they insist on a particular way to do something WITHOUT A GOOD REASON I think you mean.  sometimes there's a very good reason the build process is the way it is.

[andyturk]

From the software side, the most complicated thing is the reboot sequence,

Try to get the adc to work on earlier LM4F120 or those luminary chips; Or ethernet on those same luminary chips.

You may lose hair, potentially lots of hair.

Heh. Most of my hair went years ago, and much of it to digging around in Eclipse/CCS. ;-)