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.)

[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. ;-)

[andyturk]

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

I've used both ANT and Make, but wouldn't really consider ANT for firmware builds because it pulls in a bunch of "moving parts" related to Java. ANT is great for server-side Java work though.

The "What's wrong with Make" has a few good points--the tool ain't perfect. But if you can standardize on GNU make, it's possible to have makefiles that are fairly portable (if you're willing to dip into semi-obscure conditionals and functions). The biggest problem I've had with cross platform make is getting it to work well on Windows. Some ports of make will bring a Windows box to its knees while trying to figure out which rules to apply. Oddly enough, the one that comes bundled with TI's Code Composer Studio works pretty well.

[calin]

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.

True ... i could not have said that better myself . How anyone can call himself a C or UNIX/Linux developer wen he is not able to write a makefile ? answer is simple .. the guy is giving you bull^@% for sure.

 And yes ... i have a say in the hire process; where I am now you pass by me and you are in. And I am not a manager, nor i ever behave like one now or in future .. just that i am decent at what I do and my say matters a lot. Lucky ..

yes, make suks but still is the most used build tool for C/CPP by far; sooner or later you will have to "make" something no matter how much you dance around. ..use scons, cmake, .. use ant .. use whatever your heart likes.

[Kjelt]

Depends on the job, in our line of business we never hire a c programmer if he can't read and understand an electronic schematic, without electronics knowledge he is useless as a close to the hardware, embedded software programmer. Does not matter if he can make a makefile, enough other people to do that, as long as he can get his specific job done. I agree linux programmers are a different ballgame.

[nctnico]

About 2 decades ago I was asked to write a makefile as part of a test. After a bit of brain crunching I came up with this:

Code: [Select]

all:
cc in.c -o in.exe
It was a bit frowned upon but they had to admit it would work  O0 Today I'd still need to use a manual to put a makefile together if I want to use the more advanced option. Most of the software I encounter uses a (generated) makefile to build. Oh and I didn't take the job; I found something more interesting.

[dannyf]

-our line of business we never hire a c programmer if he can't read and understand an electronic schematic, without electronics knowledge he is useless as a close to the hardware, embedded software programmer. -

bingo!

that's knowing what is important about ones value-add.

make or not, I need a guy who can code to the job. Nothing else matters.

[ve7xen]

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

Not sure I agree. Getting a simple LED blinker is much much more difficult on a small ARM than on AVR or PIC. To build code that will run at all, you need to write a linker script for your target. Depending on what libc functions you want to use, you may need to provide implementations of stubs like kill and putc. You need to initialize clock distribution, power management, possibly watchdogs and PLL to get full clock. The chips, and build environment are a lot more complicated to set up. Once set up, I agree, but as a hobbyist with a comp sci education it took me at least a day of hobby time to get it all working together the first time around, which was pretty close to giving up and using something I was familiar with already.

Of course if you use the vendor's tools, you don't have to do any of that, or it will be mostly automatic.

[dannyf]

- a simple LED blinker is much much more difficult on a small ARM than on AVR or PIC. -

absolutely true. Getting the tools up, understanding the environment, going through library documents and chip documents and be familiar with the registers and having your own framework to coding are difficult for a newbie.

 

-of course if you use the vendor's tools, you don't have to do any of that, or it will be mostly automatic. -

equally challenging with a commercial tool.

[GiskardReventlov]

What 32-bit uC can plug directly into a breadboard? I did a quick look and don't find any.  Don't know if that matters to the OP but it's worth considering.  There are adapters, but they are expensive, that allow those packages to go into a breadboard. The drawback to those all-in-one demo boards is that it's a one-chip pony. Now there's a lot of technology in those chips so might keep you busy for a long time but it is a limitation.

[ve7xen]

What 32-bit uC can plug directly into a breadboard? I did a quick look and don't find any.  Don't know if that matters to the OP but it's worth considering.  There are adapters, but they are expensive, that allow those packages to go into a breadboard. The drawback to those all-in-one demo boards is that it's a one-chip pony. Now there's a lot of technology in those chips so might keep you busy for a long time but it is a limitation.

http://www.nxp.com/products/microcontrollers/cortex_m0_m0/lpc1100/LPC1114FN28.html

Not sure why they'd choose to do that, but hey, it's pretty cool. About the same price as an ATmega8, programmed via UART with built-in bootloader. Haven't tried one yet, but pretty nifty, then you can easily migrate to another LPC111x for production in SMD.

[Kjelt]

What 32-bit uC can plug directly into a breadboard? I did a quick look and don't find any.

embeddedartists.com and Olimex.com boards most of them have the standard 2,54mm headers on the sides, solder a row of pins in and you are ready to go. Not all signals are available though.
ah misunderstood the question. 

[westfw]

There are quite a few PIC32 chips in DIP28.
And a bunch of modules for otherwise SMT chips.

[ElektroQuark]

What 32-bit uC can plug directly into a breadboard?

Some of the PIC32 range.

[nctnico]

I'd go for a module if you need a dip layout. A high speed CPU in a DIP package is asking for power supply decoupling problems.

[GiskardReventlov]

Haven't tried one yet, but pretty nifty, then you can easily migrate to another LPC111x for production in SMD.

That is nifty, good find, very cheap!

I only did a search for atmel and stm so didn't find any.

[GiskardReventlov]

There are quite a few PIC32 chips in DIP28.
And a bunch of modules for otherwise SMT chips.

Ok, lots of options!

Right now I want to avoid modules for two reasons, price and DIY.  As a naive enthusiast it's hard to learn about the subtle aspects of this craft. I feel in my bones that when I buy pre-made I miss out on acquiring those little bits of knowledge you get from DIY that you might not get right away with pre-made.

[GiskardReventlov]

A high speed CPU in a DIP package is asking for power supply decoupling problems.

I'm not sure what you are talking about. But here's what I think you mean. You're saying that due to the coarse nature of a breadboard that a chip operating at high frequencies might go too fast for the power supply to respond and thus introduce "craziness" into your breadboard circuit and thereby limit the usefulness of laying it out on a breadboard. i.e. a failure from the start
Am I close?

I guess the question becomes at what frequency does the breadboard become a hindrance? 50MHz?
The atmega32 I have runs at 16MHz and I haven't done anything other than blinking LEDs.

[nctnico]

A high speed CPU in a DIP package is asking for power supply decoupling problems.

I'm not sure what you are talking about. But here's what I think you mean. You're saying that due to the coarse nature of a breadboard that a chip operating at high frequencies might go too fast for the power supply to respond and thus introduce "craziness" into your breadboard circuit and thereby limit the usefulness of laying it out on a breadboard. i.e. a failure from the start
Am I close?

Yes very close. You might get away with soldering a 100nf MLCC capacitor to the power supply pins directly but it's still far from ideal. You may end up chasing problems caused by using a breadboard.

[Rigby]

I guess the question becomes at what frequency does the breadboard become a hindrance? 50MHz?
The atmega32 I have runs at 16MHz and I haven't done anything other than blinking LEDs.

This is where a pulse/function generator and an oscilloscope would come in handy.  I don't remember where, but I seem to remember reading or hearing that breadboards are useless starting at around 1GHz.  That seems high to me, and it might have only been 1MHz.

If you have a function gen that can go to 1MHz or more, and an oscilloscope, you can test it.  Pop a square wave on two adjacent channels on a breadboard, then, as far away as you can, and still be in that channel, hook up a scope probe.  Put channel 2 as near to the function gen as you can.  Then, I would put CH1, CH2, and the difference between CH1 & 2 on screen all at once.  Observe as you turn up the frequency.  When the squareness of CH1 goes away or the signal is attenuated by 3db or more, you've exceeded the bandwidth limit of the breadboard.

I honestly don't know what frequency this would be.  I'm going to test it tonight and see.

[Rigby]

.. I think.  Anyone correct me if I'm wrong on that measurement technique.

[suicidaleggroll]

This is where a pulse/function generator and an oscilloscope would come in handy.  I don't remember where, but I seem to remember reading or hearing that breadboards are useless starting at around 1GHz.  That seems high to me, and it might have only been 1MHz.

It's definitely higher than 1 MHz.  I'm working on a programmable load that's currently breadboarded up, and the SPI link between the uC and the DAC/ADCs is running at 4 MHz without issue, even through a couple of daisy-chained 6" jumpers.  The uC itself had no issues running at 16 MHz flipping a couple of pins, but once I added the display and started flipping entire ports at once I started to get some fluctuations in the power supply that kept the display from working properly.  Some extra decoupling caps and moving the linear reg right next to the uC all but fixed it.  I still get the occasional hiccup now, but it's running well enough to test and develop the firmware before moving to the final PCB.

While the breadboard and DIP uC did complicate things a bit, it was by no means a dealbreaker.

[GiskardReventlov]

Some extra decoupling caps and moving the linear reg right next to the uC all but fixed it.

Can you share a picture of your setup? I've heard they're worth a thousand words. You can consider I have just started using a breadboard within the last month so seeing different setups helps a lot.

[dannyf]

It's definitely higher than 1 MHz.

I have breadboarded (digital) circuits running off 50Mhz oscillators.

I think this side of 10Mhz is fairly easy. North of 32Mhz, you want to be careful with those wires.

[suicidaleggroll]

Can you share a picture of your setup? I've heard they're worth a thousand words. You can consider I have just started using a breadboard within the last month so seeing different setups helps a lot.

Picture a rainbow-colored rats' nest with a 128x64 graphical lcd in the middle, and you're 95% of the way there.  I typically don't bother cutting and trimming every wire to the exact length when I'm breadboarding, since it's just a temporary setup anyway, and I'm usually rearranging things pretty often.

I'll see if I can grab a decent shot tonight.