
The Embedded Toolchain – Tools of the Trade - ingve
http://embedded.fm/blog/2016/3/22/embedded-tools
======
Animats
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.

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

~~~
yekim
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

~~~
asteli
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.

~~~
yekim
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.

~~~
iheartmemcache
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/](http://www2.keil.com/coresight/) [2]
[http://www.ecnmag.com/article/2010/07/debug-code-arm-
cortex-...](http://www.ecnmag.com/article/2010/07/debug-code-arm-
cortex-m3-mcus) [3] Cincom Smalltalk notwithstanding. [4]
[http://www.st.com/web/en/catalog/tools/PF260200](http://www.st.com/web/en/catalog/tools/PF260200)

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

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

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

~~~
iheartmemcache
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](https://www.youtube.com/watch?v=-EIaDxSIBYw)
[2] [http://www.theamphour.com/228-an-interview-with-shahriar-
fro...](http://www.theamphour.com/228-an-interview-with-shahriar-from-the-
signal-path-quisquous-quivering-quadripole/)

~~~
TickleSteve
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.

