contemplating a arm dev board.

[blewisjr]

I don't know I think debugging is important especially for someone new to the realm even if it is just a simulator.  Easy to make errors when new to something.

There is a simple solution for that: Take a working example and modify little bits. If it stops working, the last change messed things up. It also helps a lot to debug / verify code on a PC first. Debugging on a PC is infinitely faster and comfortable than debugging on a microcontroller.

but again you can only debug on the PC if you a have a simulator or an interface that reads everything from the chip and feeds it to gdb like ice, jtag, or debugwire.  There is the other option of serial writes if you can get a USB to serial converter that works.

[andyturk]

Dude, just go buy a board already a blink an LED. STM32 Discovery boards are less than $20.

[BravoV]

Should you choosed TI's path eg: Stellaris Launchpad and don't like selling your soul to  the TI's offered free toolchain  , here are few tips on setting the toolchain under GNU/LINUX and its also using gdb + openocd for debugging.

Building the toolchain
Debugging
Eclipse setup

[nctnico]

I don't know I think debugging is important especially for someone new to the realm even if it is just a simulator.  Easy to make errors when new to something.

There is a simple solution for that: Take a working example and modify little bits. If it stops working, the last change messed things up. It also helps a lot to debug / verify code on a PC first. Debugging on a PC is infinitely faster and comfortable than debugging on a microcontroller.

but again you can only debug on the PC if you a have a simulator or an interface that reads everything from the chip and feeds it to gdb like ice, jtag, or debugwire.  There is the other option of serial writes if you can get a USB to serial converter that works.

Most of the code which runs on a microcontroller doesn't deal with hardware at the low level. All of that can be tested on a PC. The parts which deal with hardware can be tested using an oscilloscope and a command line interface. I have been developing embedded firmware this way for 20 years and I'm not the only one working this way. Debugging the software inside the microcontroller may seem nice but IMHO its not worth the hassle to set it up. Recompiling and uploading the code is still much slower than starting the software on the PC. And you don't need a simulator. C code will compile & run on a PC just like it compiles & runs for a microcontroller.

[blewisjr]

Ah I see what you are saying now.  Yes I can see it being beneficial extracting out the standard code to ensure the logic works properly.  Then uploading and using an oscilloscope to ensure the perifs are operating as expected for the results.  This actually would solve my problem right off the bat with avr on Linux. Assuming I know what the scope should show me.  That is an excellent tip I would have not expected to get from this thread.

edit:

after thinking about it this tip would easily solve all the issues I have had with in circuit debuggers.  They seem to always hang up and stall out even with the pickit3.  So essentially this tip allows me to save money by ditching the pic which pigeonholes me from my prefered dev environment of vim/make and get back into C with the avr where I want to be.  Also use my arduino as a programmer and develop c on my attiny2313a's and still be able to debug without the need of all the crappy hacks and take my time getting to arm.

[TheDirty]

Saying 'no' to in circuit debugging just sounds like you are giving up on a major resource just for the sake of it.  It just screams old man holding off progress because it's 'a hassle'.  The 20 years comment just backs that up.  If you have 'constant problems' then by all means find a way around it, but you are absolutely in the minority if you think it's easier just to toggle led's and run a dedicated uart for debugging.  Once people here have 20 years of microcontroller experience they might find it not as useful as well, at this time though, giving up an unquestionably useful resource is not good advice.

I'm not certain what tools you've use in the past that have caused so much issue (maybe 20 years ago), but I've never had a problem with in circuit debugging.  It's not 'a hassle' to setup at all (unless maybe you're trying to setup an open source toolchain) and I can't remember ever having a big issue with it other than in the old FT2232 JTAG/SWD days when it was fairly slow.  MSP430, ARM, PIC, the even the old z8E.  Doing a test just now on the project in front of me using my J-Link clone it just registered 0.1 seconds to download and start a 14.7k program.  That's not slow.

[blewisjr]

From my perspective I like in circuit debugging but on Linux my jatagice3 is not well supported.  But that is not what the thread is about anyhow.

[benemorius]

From my perspective I like in circuit debugging but on X my X is not well supported.

That pretty much nails it. In-circuit debugging makes life great, except when it doesn't.

[nctnico]

Saying 'no' to in circuit debugging just sounds like you are giving up on a major resource just for the sake of it.  It just screams old man holding off progress because it's 'a hassle'.  The 20 years comment just backs that up.  If you have 'constant problems' then by all means find a way around it, but you are absolutely in the minority if you think it's easier just to toggle led's and run a dedicated uart for debugging.  Once people here have 20 years of microcontroller experience they might find it not as useful as well, at this time though, giving up an unquestionably useful resource is not good advice.


I'm not certain what tools you've use in the past that have caused so much issue (maybe 20 years ago), but I've never had a problem with in circuit debugging.  It's not 'a hassle' to setup at all (unless maybe you're trying to setup an open source toolchain) and I can't remember ever having a big issue with it other than in the old FT2232 JTAG/SWD days when it was fairly slow.  MSP430, ARM, PIC, the even the old z8E.  Doing a test just now on the project in front of me using my J-Link clone it just registered 0.1 seconds to download and start a 14.7k program.  That's not slow.

A few years ago I attended an NXP seminar where their ARM Cortex controllers where introduced. When asked 50% of the embedded software engineers didn't use in circuit debugging. It is usually possible to use in circuit debugging for open source tools but you have to ask yourself what you want to gain by in-circuit debugging versus the amount of money and / or time spend.

When it comes to the software which deals with hardware: Toggling leds or I/O pins maybe old fashioned but it is the least instrusive way to find out if a program passes a certain point or not. You don't want to break in an interrupt routine which controls some hefty MOSFETs. Using more I/O pins and a logic analyser (with deep memory and support for statistics) you can even do profiling to see how much time is spend in certain routines. The thing is that an in-circuit debugger can show what the software does but when dealing with peripherals / hardware the problem is usually getting the settings right. That involves reading the user manual and using an oscilloscope or logic analyser to check whether the peripheral behaves as expected. Other problems may be things like timing conflicts between interrupts. I doubt a low end in-circuit debugger can help to find such problems.

The rest of the software is just easier / cheaper to debug / verify on a PC. I do that for almost every embedded software project.

For checking status / diagnostics I always incorporate a command line interface. That is not only useful during development but also when a device is installed. Connect the serial port and with a few commands it is totally clear what a device is doing.

Ofcourse you can still run into a problem with a pointer going wrong or a division by zero during the development phase. Fortunately ARM controllers offer a fault handler interrupt. In debug builds I have the fault handler dump a stack trace to the UART which usually reveals the problem area quickly. In release builds I just have the controller reset itself.

[andyturk]

Saying 'no' to in circuit debugging just sounds like you are giving up on a major resource just for the sake of it.  It just screams old man holding off progress because it's 'a hassle'.  The 20 years comment just backs that up.

Them's fightin' words!  %-B

I'd guess that "back in the day," in circuit debugging required lots of $$ for hardware and proprietary software. Successful engineers had to build their own tools to get work done.

Nowadays, JTAG/SWD dongles are cheap (e.g., your J-Link clone) and the software to drive them is much less expensive, if not free (in the case of openocd). The main expense seems to be the time investment to get a toolchain and debugger all working together. If you can compile the tools from scratch, there's no reason to avoid the debugger.

However, for systems where interrupts do significant work within timing constraints, a debugger doesn't help that much. You can put a breakpoint in an ISR, but when it stops there, all the timing dependent stuff breaks. Single-stepping in the presence of ISRs is a pain too (on some architectures) since the debugger can dutifully wander into the ISR even when you don't want to see it.

The implications of nctnico's method are interesting though. To get by with such primitive tools on the mcu, you need to know that your code is mostly working before you flash the device. Doing a big chunk of the code development natively on a PC and then porting it to your mcu, probably seems like extra work to the IDE crowd, but it may be a more effective way to build complex projects.

A friend of mine with several shipping products under his belt goes even farther and unit tests most of his code on a mac (using Ruby no less!). The production build is for an MSP430 based device with 10K of RAM.

[nctnico]

The beauty is that if you use Eclipse you can have the PC development version and the microcontroller version inside the same project or workspace.

[blewisjr]

Saying 'no' to in circuit debugging just sounds like you are giving up on a major resource just for the sake of it.  It just screams old man holding off progress because it's 'a hassle'.  The 20 years comment just backs that up.

Them's fightin' words!  %-B

I'd guess that "back in the day," in circuit debugging required lots of $$ for hardware and proprietary software. Successful engineers had to build their own tools to get work done.

Nowadays, JTAG/SWD dongles are cheap (e.g., your J-Link clone) and the software to drive them is much less expensive, if not free (in the case of openocd). The main expense seems to be the time investment to get a toolchain and debugger all working together. If you can compile the tools from scratch, there's no reason to avoid the debugger.

However, for systems where interrupts do significant work within timing constraints, a debugger doesn't help that much. You can put a breakpoint in an ISR, but when it stops there, all the timing dependent stuff breaks. Single-stepping in the presence of ISRs is a pain too (on some architectures) since the debugger can dutifully wander into the ISR even when you don't want to see it.

The implications of nctnico's method are interesting though. To get by with such primitive tools on the mcu, you need to know that your code is mostly working before you flash the device. Doing a big chunk of the code development natively on a PC and then porting it to your mcu, probably seems like extra work to the IDE crowd, but it may be a more effective way to build complex projects.

A friend of mine with several shipping products under his belt goes even farther and unit tests most of his code on a mac (using Ruby no less!). The production build is for an MSP430 based device with 10K of RAM.

The only issue I see with this method is take for instance 8bit micros.  90% of your code revolves around manipulating the Registers for the perifs.  You can't build AVR code so the PC can run it because avr libc in not a standard libc library it relies very heavily on accessing the addresses where the perif registers reside and a majority of the library involves architecture specific assembler for many function implementations.  You just can't debug this on a PC without a simulator or debug capable dongle.  After looking into it my pervious post is wrong this really will not solve the issue with praying my jatagic3 or pickit3 operates properly.  Like you state if you throw time specific code at them they just puke all over the place stall or hang up and become unfunctional.  So on one hand I like having the dongle but on the other I despise the darn things.

[TheDirty]

A few years ago I attended an NXP seminar where their ARM Cortex controllers where introduced. When asked 50% of the embedded software engineers didn't use in circuit debugging. It is usually possible to use in circuit debugging for open source tools but you have to ask yourself what you want to gain by in-circuit debugging versus the amount of money and / or time spend.

When it comes to the software which deals with hardware: Toggling leds or I/O pins maybe old fashioned but it is the least instrusive way to find out if a program passes a certain point or not. You don't want to break in an interrupt routine which controls some hefty MOSFETs. Using more I/O pins and a logic analyser (with deep memory and support for statistics) you can even do profiling to see how much time is spend in certain routines. The thing is that an in-circuit debugger can show what the software does but when dealing with peripherals / hardware the problem is usually getting the settings right. That involves reading the user manual and using an oscilloscope or logic analyser to check whether the peripheral behaves as expected. Other problems may be things like timing conflicts between interrupts. I doubt a low end in-circuit debugger can help to find such problems.

The rest of the software is just easier / cheaper to debug / verify on a PC. I do that for almost every embedded software project.

For checking status / diagnostics I always incorporate a command line interface. That is not only useful during development but also when a device is installed. Connect the serial port and with a few commands it is totally clear what a device is doing.

Ofcourse you can still run into a problem with a pointer going wrong or a division by zero during the development phase. Fortunately ARM controllers offer a fault handler interrupt. In debug builds I have the fault handler dump a stack trace to the UART which usually reveals the problem area quickly. In release builds I just have the controller reset itself.

Several year ago many embedded programmers didn't even use structured programming.  Not too many years ago, the C/ASM troll threads were the opposite and most people would say that programming in assembler only was just as fast and readable as any C code.  Progress marches forward.  Certainly there are places were the debugger has it's limitations, but it's a great resource, especially for those people new to embedded programming or learning a new architecture.  It's fine to read the manuals, but if you can step through the code even down to the assembly level while seeing the state of all the hardware registers, it's hard to imagine why you would avoid it.

I'm not certain what cost you are talking about here.  The cost is adding a 6 pin header to your project for even just the prototype board.  For the Cortex-M for example the programmers/debuggers for LPC, ST, TI, and Freescale are all less the $30.  It's so simple and cheap and fast that I'm not certain how making up a separate environment for debugging on your PC could save you any time.

It's a useful tool.  It's a cheap tool.  It's difficult to understand why someone would avoid it unless they really want to stick with a specific programming tool and/or a semi supported or unsupported operating system.

Them's fightin' words!  %-B

It was probably a little harsh and Thanks to nctnico for not stooping to my level.

[blewisjr]

A few years ago I attended an NXP seminar where their ARM Cortex controllers where introduced. When asked 50% of the embedded software engineers didn't use in circuit debugging. It is usually possible to use in circuit debugging for open source tools but you have to ask yourself what you want to gain by in-circuit debugging versus the amount of money and / or time spend.

When it comes to the software which deals with hardware: Toggling leds or I/O pins maybe old fashioned but it is the least instrusive way to find out if a program passes a certain point or not. You don't want to break in an interrupt routine which controls some hefty MOSFETs. Using more I/O pins and a logic analyser (with deep memory and support for statistics) you can even do profiling to see how much time is spend in certain routines. The thing is that an in-circuit debugger can show what the software does but when dealing with peripherals / hardware the problem is usually getting the settings right. That involves reading the user manual and using an oscilloscope or logic analyser to check whether the peripheral behaves as expected. Other problems may be things like timing conflicts between interrupts. I doubt a low end in-circuit debugger can help to find such problems.

The rest of the software is just easier / cheaper to debug / verify on a PC. I do that for almost every embedded software project.

For checking status / diagnostics I always incorporate a command line interface. That is not only useful during development but also when a device is installed. Connect the serial port and with a few commands it is totally clear what a device is doing.

Ofcourse you can still run into a problem with a pointer going wrong or a division by zero during the development phase. Fortunately ARM controllers offer a fault handler interrupt. In debug builds I have the fault handler dump a stack trace to the UART which usually reveals the problem area quickly. In release builds I just have the controller reset itself.

Several year ago many embedded programmers didn't even use structured programming.  Not too many years ago, the C/ASM troll threads were the opposite and most people would say that programming in assembler only was just as fast and readable as any C code.  Progress marches forward.  Certainly there are places were the debugger has it's limitations, but it's a great resource, especially for those people new to embedded programming or learning a new architecture.  It's fine to read the manuals, but if you can step through the code even down to the assembly level while seeing the state of all the hardware registers, it's hard to imagine why you would avoid it.

I'm not certain what cost you are talking about here.  The cost is adding a 6 pin header to your project for even just the prototype board.  For the Cortex-M for example the programmers/debuggers for LPC, ST, TI, and Freescale are all less the $30.  It's so simple and cheap and fast that I'm not certain how making up a separate environment for debugging on your PC could save you any time.

It's a useful tool.  It's a cheap tool.  It's difficult to understand why someone would avoid it unless they really want to stick with a specific programming tool and/or a semi supported or unsupported operating system.

Them's fightin' words!  %-B

It was probably a little harsh and Thanks to nctnico for not stooping to my level.

I would not say harsh it is your opinion.  There is a time and place for every tool just like there is a time and place for every chip.  In all honesty it is my own fault for going against the norm and using a Linux OS on all my computers.  That is a choice I made years ago well before the Windows 8 Monstrosity.  It is not my fault that the companies don't really support the OS all that well.  For the most part PIC works pretty well so does AVR.  From what I hear ARM works pretty well to.  The fact remains I still need to work around a lot of various issues because the support is always sub par compared to windows.  For instance MPLABX is not the most pretty environment on Linux and I am not much of an IDE guy was just using it because it worked and I wanted to learn.  AVR/ARM have great Linux compiler support however, AVR lacks a bit on the debugger side but it really lets me use the toolchain setup I learned to love on Linux.  Never been much of an IDE guy.  ARM seems to be pretty solid once you figure out all the separate pieces (still doing that).  Either way I want to learn Embedded Electronics and make projects.

Right now I have invested $68 into PIC, $118 into AVR, and $20 on an Arduino.  Hate the Arduino, PIC has a bad dev environment from my point of view even though it does work for the most part minus all the Netbeans bugs.  Really like AVR but still trying to work out the kinks.  Makes me wonder if I should have listed to everyone that was trying to point me to ARM but I always felt the chips may have been overkill for learning.  So here I am looking into ARM's.

My ultimate goal is to find an architecture that works for me in the environment that I choose and to learn.  So far I am not really there yet.  Right now from what I can see ARM might just be what I am looking for if I can figure out all the pieces that is and even if it is overkill.  It does seem to give tons of room to grow.

(Apologize trying to get back on topic so I don't confuse myself more)

The only real issues I see with ARM is finding the right dev board/chips aka. choosing a company to utilize.
The other issue is when I want to make my own board for a project as a hobbyist it could be tougher to do due to surface mount.  For some reason soldering 64 pins seems a bit tough (in the case of the TI Sellaris I was recommended).  This would also mean perf board is out of the question and I would have to get the board fabricated but this is down the road anyway.

So looking at the general options I have available...

TI Stellaris (good Linux support through gcc and openocd)
SM Discovery (horrid doc with semi decent Linux support)
Freescale Kenetis Freedom (Have no idea can't find much info "may be do to wrong search strings")
NXP (Solid Linux support through proprietary IDE "Not an IDE fan")

Those are really the options I can see and any help narrowing down a solid direction to head would be great and much appreciated.

[TheDirty]

TI Stellaris (Now Tiva) doesn't have any chips out there that you can buy last I looked and the selection is extremely limited.  I think you can rule those out.
After that, I'm not certain about Linux support for LPC, ST32, and Kenetis.

I run Linux as well, but only on a separate box.  It's kinda gone by the wayside now that I don't host things from home anymore and it just runs ZoneMinder.

I have it easy.  I spent $150 on a personal license for Rowley Crossworks about 5 years ago when I got fed up with the Yagarto chain and working with ARM7.  The main problem with the Rowley personal license is that you can't do any commercial development with it, which is a non-starter for most people.  If you can handle that though, they do have a Unix version you can try (never tried it myself).  It works with just about every programmer/debugger out there now except for LPC/Link (LPC just put out their LPC-Link2, which emulates other debuggers) and just about every ARM manufacturer/model.  Crossworks and my JTAG clone $20 are my main investments in developer tools.  Not including the stuff I just buy to play with.  ST discovery boards, TI Stellaris Launchpad, ...

Watch out with a J-Link clones.  Most of the ones you see in the black boxes will be bricked by the latest Segger drivers.

[westfw]

Saying 'no' to in circuit debugging just sounds like you are giving up on a major resource just for the sake of it.  It just screams old man holding off progress because it's 'a hassle'.  The 20 years comment just backs that up.

Saying "no" to the non-open-source tools provided by the vendor seems about the same to me, though from the perspective of a different "religion."
The LCPXpresso IDE is sufficiently full-featured for introductory purposes (128k), and based on open-source tools (gcc, eclipse), so there's nothing stopping you from trying out ARM via an LCPXPresso board, and "graduating" to an open source toolchain later, if you really want.  (if you DON'T "really want", the Code Red tools "full price" is relatively reasonable.)

The LPCXpresso IDE can build an executable of any size with full code optimization, and it supports a download limit of 128KB after registration

(The "mbed", another NXP "introductory" product, is more questionable.   IMO.)

[poorchava]

IMHO debugging software on a microcontroller is of limited use anyway.

That is true when your application works mostly in software. When you have an application which makes heavy use of advanced peripheral functions (which AVR and PICs generally lack anyway) in circuit debugger (together with a scope and a logic analyzer) are vital.

If fact I never used a hardware debugger on an AVR. On PIC you get it for free, plus it is kind of necessary when every other line of code triggers some silicon bug or compiler weirdness.

[blewisjr]

Well like I said my biggest issue is in my choices I want to keep things open source and I have my own personal reasons for that.  It is true however with micro is in general you can only get so open source.  Due to needing often the proprietary libs for the chips.  So if it is a no go on getting TI chips I probably need to re evaluate the other boards and find ways around how I am limited due to my choices.

[nctnico]

A few years ago I attended an NXP seminar where their ARM Cortex controllers where introduced. When asked 50% of the embedded software engineers didn't use in circuit debugging. It is usually possible to use in circuit debugging for open source tools but you have to ask yourself what you want to gain by in-circuit debugging versus the amount of money and / or time spend.

When it comes to the software which deals with hardware: Toggling leds or I/O pins maybe old fashioned but it is the least instrusive way to find out if a program passes a certain point or not. You don't want to break in an interrupt routine which controls some hefty MOSFETs. Using more I/O pins and a logic analyser (with deep memory and support for statistics) you can
The rest of the software is just easier / cheaper to debug / verify on a PC. I do that for almost every embedded software project.

For checking status / diagnostics I always incorporate a command line interface. That is not only useful during development but also when a device is installed. Connect the serial port and with a few commands it is totally clear what a device is doing.

Several year ago many embedded programmers didn't even use structured programming.  Not too many years ago, the C/ASM troll threads were the opposite and most people would say that programming in assembler only was just as fast and readable as any C code.  Progress marches forward.  Certainly there are places were the debugger has it's limitations, but it's a great resource, especially for those people new to embedded programming or learning a new architecture.  It's fine to read the manuals, but if you can step through the code even down to the assembly level while seeing the state of all the hardware registers, it's hard to imagine why you would avoid it.

I'm not certain what cost you are talking about here.  The cost is adding a 6 pin header to your project for even just the prototype board.  For the Cortex-M for example the programmers/debuggers for LPC, ST, TI, and Freescale are all less the $30.  It's so simple and cheap and fast that I'm not certain how making up a separate environment for debugging on your PC could save you any time.

I'm way ahead I like to stay as high-level as possible by hiding hardware behind functions (hardware abstraction layer) and trying not to bother with assembly, registers, etc. You are thinking too much in boxes which say microcontroller A, B or C which need IDE A, B or C. I focus on the software and don't care about the platform. The way I see software is that it is a black box which performs a function. If I compile it for a PC it works on a PC, if I compile it for microcontroller A then it works on microcontroller A. If you make life that simple you don't need to jump through hoops with vendor provided tools. I standarised ALL my software development around Eclipse and use the same set of basic routines (timer, UART and command line) for all microcontrollers. This means there is no extra time involved for testing / debugging software on a PC. It is just a matter of clicking 'compile for PC'. In my world everything is simple because (almost) everything becomes a standard nail for which I can use the same hammer.

[blewisjr]

A few years ago I attended an NXP seminar where their ARM Cortex controllers where introduced. When asked 50% of the embedded software engineers didn't use in circuit debugging. It is usually possible to use in circuit debugging for open source tools but you have to ask yourself what you want to gain by in-circuit debugging versus the amount of money and / or time spend.

When it comes to the software which deals with hardware: Toggling leds or I/O pins maybe old fashioned but it is the least instrusive way to find out if a program passes a certain point or not. You don't want to break in an interrupt routine which controls some hefty MOSFETs. Using more I/O pins and a logic analyser (with deep memory and support for statistics) you can
The rest of the software is just easier / cheaper to debug / verify on a PC. I do that for almost every embedded software project.

For checking status / diagnostics I always incorporate a command line interface. That is not only useful during development but also when a device is installed. Connect the serial port and with a few commands it is totally clear what a device is doing.

Several year ago many embedded programmers didn't even use structured programming.  Not too many years ago, the C/ASM troll threads were the opposite and most people would say that programming in assembler only was just as fast and readable as any C code.  Progress marches forward.  Certainly there are places were the debugger has it's limitations, but it's a great resource, especially for those people new to embedded programming or learning a new architecture.  It's fine to read the manuals, but if you can step through the code even down to the assembly level while seeing the state of all the hardware registers, it's hard to imagine why you would avoid it.

I'm not certain what cost you are talking about here.  The cost is adding a 6 pin header to your project for even just the prototype board.  For the Cortex-M for example the programmers/debuggers for LPC, ST, TI, and Freescale are all less the $30.  It's so simple and cheap and fast that I'm not certain how making up a separate environment for debugging on your PC could save you any time.

I'm way ahead I like to stay as high-level as possible by hiding hardware behind functions (hardware abstraction layer) and trying not to bother with assembly, registers, etc. You are thinking too much in boxes which say microcontroller A, B or C which need IDE A, B or C. I focus on the software and don't care about the platform. The way I see software is that it is a black box which performs a function. If I compile it for a PC it works on a PC, if I compile it for microcontroller A then it works on microcontroller A. If you make life that simple you don't need to jump through hoops with vendor provided tools. I standarised ALL my software development around Eclipse and use the same set of basic routines (timer, UART and command line) for all microcontrollers. This means there is no extra time involved for testing / debugging software on a PC. It is just a matter of clicking 'compile for PC'. In my world everything is simple because (almost) everything becomes a standard nail for which I can use the same hammer.

Ok that makes much more sense why your compile for PC works with so much hardware.  Essentially you are using a multitargeted bsp if I understand what a bsp is.  This way you can flip a compiler flag and bang it just works.  Seems like a lot of extra effort tho but it does give you simplicity in the long run.

[elgonzo]

I'm way ahead I like to stay as high-level as possible by hiding hardware behind functions (hardware abstraction layer) and trying not to bother with assembly, registers, etc. You are thinking too much in boxes which say microcontroller A, B or C which need IDE A, B or C. I focus on the software and don't care about the platform. The way I see software is that it is a black box which performs a function. If I compile it for a PC it works on a PC, if I compile it for microcontroller A then it works on microcontroller A. If you make life that simple you don't need to jump through hoops with vendor provided tools. I standarised ALL my software development around Eclipse and use the same set of basic routines (timer, UART and command line) for all microcontrollers. This means there is no extra time involved for testing / debugging software on a PC. It is just a matter of clicking 'compile for PC'. In my world everything is simple because (almost) everything becomes a standard nail for which I can use the same hammer.

I see what you are hinting at. Cross-platform libraries/APIs for common functionality are certainly the future. However they will not be the "end of it all". Even after decades and with today's homogenized PC hardware, PC developer communities still continue to struggle with cross-platform issues. The more projects grow in complexity (which one can reasonably expect given the advancements and general availability of embedded tech), the harder cross-platform support will become...

[nctnico]

When C was invented they also created a standard C library which became part of the Posix standard (http://en.wikipedia.org/wiki/POSIX). Interestingly when C was invented computers where less powerful than today's microcontrollers so most of the functions are written with low resources in mind. Ofcourse the libraries got bloated over the years but there are still several small sized libraries around like the standard C libraries for the mspgcc (GCC for MSP430) which can also be compiled for ARM. In my experience it is best to stay close to the Posix standard even in an non-operating system environment. What I often see is that people create their own string printing routines because printf sucks in so many library functions. The better solution is to just replace printf with a minimalistic implementation. Several minimalistic printf versions can be found on the internet.

[blewisjr]

When C was invented they also created a standard C library which became part of the Posix standard (http://en.wikipedia.org/wiki/POSIX). Interestingly when C was invented computers where less powerful than today's microcontrollers so most of the functions are written with low resources in mind. Ofcourse the libraries got bloated over the years but there are still several small sized libraries around like the standard C libraries for the mspgcc (GCC for MSP430) which can also be compiled for ARM. In my experience it is best to stay close to the Posix standard even in an non-operating system environment. What I often see is that people create their own string printing routines because printf sucks in so many library functions. The better solution is to just replace printf with a minimalistic implementation. Several minimalistic printf versions can be found on the internet.

On top of what is out there it is not hard to write your own minimalistic libc for various chips.  Hell the best c book on the market imho is k&r and it teaches c by showing how implement various features from the original libc.  The problem is a lot of newer c developer are learning from the internet and never truly learning what c was all about.  I learned from k&r 10 years ago and glad I did.

[elgonzo]

When C was invented they also created a standard C library which became part of the Posix standard (http://en.wikipedia.org/wiki/POSIX). Interestingly when C was invented computers where less powerful than today's microcontrollers so most of the functions are written with low resources in mind. Ofcourse the libraries got bloated over the years but there are still several small sized libraries around like the standard C libraries for the mspgcc (GCC for MSP430) which can also be compiled for ARM. In my experience it is best to stay close to the Posix standard even in an non-operating system environment. What I often see is that people create their own string printing routines because printf sucks in so many library functions. The better solution is to just replace printf with a minimalistic implementation. Several minimalistic printf versions can be found on the internet.

On top of what is out there it is not hard to write your own minimalistic libc for various chips.  Hell the best c book on the market imho is k&r and it teaches c by showing how implement various features from the original libc.  The problem is a lot of newer c developer are learning from the internet and never truly learning what c was all about.  I learned from k&r 10 years ago and glad I did.

If your focus is mostly on performance and complexity levels of 8-bit micros, this approach works nicely.
However, this view is naive if you just look a little forward into the future. Even in the embedded world, you (will) have 64-bit micros with hardware virtualization and multiple GB address space. Talking about minimalistic libraries when looking at the things to come, yeah... well... um...

[blewisjr]

I would see that as quite far into the future even modern PC 64 bit chips run quite hot but by then maybe cpp will have a reason to survive lol.