I got an email from Sara, a listener of Embedded.fm and a fairly new embedded developer.

Hi! It's my first job after college, and I was kind of thrown into this embedded world without knowing anything really (it's not what I studied in college). I'm the only one at my company that does embedded development, all my colleagues do web development, with Java, mySQL etc. What I mean to say is that I don't have anyone to ask, and that it's my responsibility alone that my code and my development environment works. It can be scary at times, and I feel that I lack knowledge.

At the moment I just use the development environment my predecessor at the job used and taught be before he quit. It's gcc and Eclipse IDE, and for debugging I simply print stuff on UART/COM.

Could you please talk about development environments and compilers? Would it be better to use Keil or IAR? What is the difference, really? Is gcc bad when compared to Keil or IAR?

And debugging, this JTAG thing everyone seems to talk about. How do you use it? How does it work? What can you do with it?

I got hired because I'm really good at C, but now there's all this other stuff too. I'm eager to learn, but I don't know where to start. You might be a good place to start? :)

/Sara from Sweden

Dear Sara from Sweden,

Have you used VisualStudio, XCode, or GDB to debug a program on your PC? So you can set a breakpoint, step through the code, and inspect variables? That's what a debugger will do for your embedded system. And JTAG is a common form of it (there are other forms of debugging interfaces: ARM’s is called SWD, Freescale’s is BDM, but most people still call them JTAG instead of "debugging interface").

I've done whole projects with debug-through-print and it isn't terrible. But printing takes time and that can mean timing-related bugs appear and disappear with the print statements. A debugger will let you look inside your code instead of standing on the outside. Crashes are much, much easier to figure out with a debugger.

You didn't say what kind of processor (or processor family) so I can't say "and for $60 this could all be yours" but debuggers aren't nearly as expensive as engineering hours. One important caveat, you must have the hardware support for a debugger: the necessary pins have to be sticking out of your board. If you have a schematic, look for TDO (for JTAG) or SWDIO (for SWD). If you don't have a way to hook your debugger to your board, then printing is probably the only way.

There is a good chance you may already have a debugger or something similar, how do you program your code into the board? Do you have a USB widget that looks like one of these and plugs into your board?

Since Eclipse is an IDE (integrated development environment), it can work with a debugger. You'll probably need to run something called OpenOCD to interface between Eclipse and the debugger hardware. OpenOCD is a little finicky but once you learn the voodoo to make it work for your board and IDE, it is better than not having a debugger. Your debugger getting started guide will likely tell you what you need to know; email back if it doesn’t.

Now, on to development environments or IDEs (integrated development environments). Keil and IAR are two of the most popular are a bit more stable and are considered to be better at optimizing code (gcc gets better all the time). They also tend to support new processors before Eclipse does and are somewhat easier to configure for different needs.

Keil and IAR are expensive ($1k-3k). You can get free, size-limited versions of the compilers but it would be a pain to get it all working only to have it fail the next day because you added a line of code. These aren't bad choices but if you are new, well, setting these beasts up isn't easy (though they are often better about working with the debugger hardware so if OpenOCD causes headaches, that’s another time to consider switching). For now, stick with the build environment you have, Eclipse is a little buggy but the price is right.

As for a good place to start... I, err, have a book, intended for people exactly in your situation, it is called Making Embedded Systems. It talks some about setting up cross compiling and debugging (including debugging via printf). There are also some excellent Udemy and EdX courses that might help bridge the gap between CS coursework and real-world embedded systems. Search for the processor you are using on those sites as it would be nice to have a class that is in the same family as your work.

And if you have a question you’d like to see answered here, hit the contact link.