Most of the issues in embedded programming involve asking "what's going on in there?" In small embedded work, you usually can't print, you may not have a display, everything is time dependent, and you're directly connected to hardware. Debugging may involve an oscilloscope and a logic analyzer. Using a debugger means halting the machine, and isn't helpful if the problem is timing dependent.

For some jobs, you need a simulator that lets you debug in a more friendly environment. There's one for an entire Android phone, for example.

This article offers a high level description of the various parts. While a decent read for the curious, I don't think it's necessary even for those going into embedded work.

My experience jumping into some point-of-sale work after college is that anyone with even minimal programming experience can pick this stuff up as they go. Even the worst platform I developed for had built in guides and an IDE.

Depends on how deep down the embedded rabbit hole you want to go.

Personally, an article like this, with its main diagram and high level descriptions, would have been enormously useful back when I was just starting to learn the dark arts of computer programming.

If your Point of Sale systems are running some embedded form of Linux, and all HW access is abstracted away from you, then you're probably right.

On the other hand, if you are writing code that deals with external HW signals, performant memory access, ISRs, an RTOS and their many features, etc, then this article serves as a good basic foundation for the "software" side of things. Ie what actually happens when you hit the "build" button in your IDE.

From, a long time embedded software engineer

Also depends on which rabbit hole you choose.

I'm an electrical design guy, dilettante wrt embedded software. 8-bit AVR controllers were a breeze to work with at a bare-metal level.

Now that I'm attempting to acquaint myself with the STM32 environment and the requisite libraries, I'm finding the toolchain and environment a lot more challenging than what I remember from working with AVR.

True, to an extent.

I'm assuming you are referring to the Arduino family when you say "8-bit AVR controllers"? If yes, they do in fact do a great job at making things somewhat easy for the dabbler, and have many resources available online to peruse for help.

Taking the next step to full-on embedded development (STM32 in this case), as you are finding out, is quite a big leap. Not that it can't be done, but that it really is challenging.

Guess it depends on your background and your familiarity with software development and/or hardware in general.

Not really challenging at all. ST subsidized the release of Keil IDE with a pretty decent amount of functionality. Use uVision Core[1] and you get a Crazy amount of control over everything (CMSIS is worth paying for, and if you're an academic, discounts are offered.). No licensing fees at all. Works with the standard ULINKs. What used to cost tends of thousands of dollars for a bond-out chip in the 80s.

The Cortex M3 (and any of the other ARMs that offer ETM[2]) is as good if not better than any debugger I've ever used[3], software, hardware, micros, CPLD's, FPGAs. You need to throw a few hundred down for the ULINKpro, but the Segger ST everyone uses I think speaks ETM. Making the jump from Arduino to UL certified production run consumer products with injection molded custom casing holding your 6 layer board has never been easier.

ST even offers documentation on how to use FreeRTOS[4] if you need hard scheduling requirements (though I'd go with Micrim, Wind River, or one of the usual suspects that has already been vetted if you're going to market in, say, the medical device industry).

[1] http://www2.keil.com/coresight/ [2] http://www.ecnmag.com/article/2010/07/debug-code-arm-cortex-... [3] Cincom Smalltalk notwithstanding. [4] http://www.st.com/web/en/catalog/tools/PF260200

He said that he was doing bare metal work on the AVR so I assume he wasn't referring to Arduino. Arduino aside, the default toolchain for 8 bit AVRs is really simple to get running. Just install AVR-studio with its built in GCC compiler and libraries. It was something I was always jealous of on the Microchip side of the pond.

As it is, I'm in the same boat as the grandparent comment. I'm moving over to STM32 and I'm loving nearly everything about it. While there are more toolchains and less hand holding the possibilities are much more exciting. All in all, it's a great time to be doing embedded development.

This set of tool chain is typical and will work successfully, particularly for a simplistic system. For a more complex system, the tool chain could get more complicated. You could add

* A unit test framework for unit testing the software modules before integration. ie Cmocka or Ceedling

* A graphical state machine design tool. Useful for generating application code. ie MathLab's Simulink tool.

* many more.

It all depends on what industry you are working in, how much money you have and how many engineers is in your team working on the project.

A lot of embedded debugging is either using a debugger (if you're lucky) or using various side-channels to infer the state of the machine. For example, you could make a task toggle a pin on the device and hook it up to a scope to figure out if it's being scheduled properly.

If you're interested in electronics, embedded.fm and theamphour.com are both fantastic podcasts.

A very superficial description of embedded development but a view that isn't presented in many places...

(BTW: the podcast is worth a listen tho).

LadyAda (of Adafruit, former design engineer of AVR) went into a recent amount of detail w/r/t low-volume production runs/programming rigs/custom testing jigs[1] where it's not budget-friendly for you to design a bed-of-nails against TPs after all's reflowed and ready to go into your enclosure. Most of the EE vlogs/podcasts, minus a few episodes (e.g. TheAmpHour with guests that actually challenge Dave, like The Signal Path[2] founder/milliwave RF lead engineer for Bell Labs NJ, or the EEVblog episode with Jack Ganselle/the episode where he interviews some guy who made his own spectrum analyser) are really pretty lacking in insight. The episodes where you get 45 year old (usually with PhD's) engineers talking is where the real interesting engineering podcast porn is found (e.g. mikeselectricthings, The Signal Path[PhD], AvE[PhD], Applied Science[no idea, but Ben rules either way]).

[1] https://www.youtube.com/watch?v=-EIaDxSIBYw [2] http://www.theamphour.com/228-an-interview-with-shahriar-fro...

I'll give them a listen... but Dave@TheAmpHour is one of the more annoying podcast hosts, he's very under-educated on anything but his specialist subject and semi-depressing most of the time.