Learning embedded systems from the ground up

Question

Hi,

I am fourth-year studying for my undergraduate in Computer Science, and I wanted to start learning about embedded systems and programming. I have been looking at various university courses (UCSD, MIT, etc.), but there is a lot of focus on hardware.

I don't mind learning the hardware, but throughout my studies, my degree has almost exclusively focused on the software side of things. I want to learn embedded systems the right way (not the "buy a micro processor and try things").

I don't mind going through countless books. I am just confused on what builds off of what.

What physics do I need to know? How specific do I need to learn the hardware?

I would appreciate some guidance.

Thanks

UPDATE

Sorry for the fuzzy-ness of the question. I am interested in RTOS (Real time OS) if that can direct anyones advice.

The input so far has been great. Right now I am reading An Embedded Software Primer. I will probably finish this and then dive into coding.

Again, I love reading and I wouldn't mind a book that guided me through the process of buying/setting up/coding for a specific hardware platform

Answer 1

If your question is about what's different in embedded programming, check out Jack Ganssle's "Embedded Muse" newsletter. The basics of software engineering are the same, it's just that there are different constraints (usually memory and processing power). Things like dynamic memory allocation and virtual functions may be prohibitive to use. You may need to be dealing with interrupt handlers. The programming tools are different (alas, usually much more primitive and limiting) and the bugs you run into are different.

If your question is about the hardware aspects of embedded systems, that's sort of beyond the scope of this website, but check out The Art of Electronics by Horowitz and Hill. Best electronics book I've read. I learned how transistors worked in practice by reading this, at the same time as I was taking the intro electronics course at MIT, where they "taught" us about transistors by throwing all sorts of equations at us.

edit: You can read up all you want, but in the end you will learn much more thoroughly by actually using embedded systems. I've been programming several different manufacturers' parts in the last ten years and for introductory systems I would probably recommend the TI MSP430 series. There are inexpensive development kits, and the free (code-size limited) IAR C++ compiler/IDE is pretty easy to pick up. The MSP430 and TMS320F2800 (DSP) series of parts have been fairly easy to debug. I've used Microchip PICs for a long time and though I really like the hardware, the IDE is less than desirable.

Answer 2

hi Erik,

This is a huge topic :) There are many places you can start. Its even tougher when you consider that the definition for an embedded system is very, very fuzzy. "back in the day", an embedded system was one where the software (or most of it) was burned into ROM. In the early 90's I worked on a point of sale system and controller for gas stations. It was a 'big' 16bit 186 system. It was 'big' in the sense that it had way more than 64k of code spaced - we did that by paging physical ROMs in and out of the address space dynamically.

Today, many things are considered embedded systems, but many are 'softer' in that the software is more conventionally like a PC as is the hardware. For example kiosks and point of sale systems these days are almost always just PCs that present one application (or a controlled UI) to the user.

In my mind, there are two things that define a classica embedded system:

1. where you (the system designer or owner) has access to and can change, the source code to everything in the system.
2. Where resources such as CPU, memory, I/O, and power are constrained in a significant way.

All the best embedded developers I know got their start wrting all the software for an embedded system from scratch - this means all the code, from the code at the hardware rest vector, to the application code. In many cases this meant building a small, but effective kernel.

A good place to start would be this.

1. Decide on something cool or interesting to do.
2. Find some inexpensive hardware that can perform the task. There are TONs of do it yourself bare bones hardware systems out there.
3. Pick one that has decent development tools that let you work in C or C++. I suggest avoiding things that are programmed in basic or other higher level languages.
4. Write all the software for your idea from scratch. Its groovy to use the C/C++ libraries.

This will teach you quite a bit about embedded systems work.

Note, this is not the only or best way to proceed - others will have different suggestions. But, I promise this will teach you quite a bit about embedded systems work.

Added Info

Ok! That's very helpful info. Many embedded systems do not true real time operating systems. Heck, many use a simple main dispatch loop and they work jsut fine.

For your puposes, I would suggesting experimenting with

1. RTLinux - you can do this on a normal PC with very good success.
2. WindowsCE - is also easy to experiment with using the trial version and the tools are very good (as are the linux tools, but hey, I do work for MSFT)
3. PREX looks cool, but I have no experience with it.

One other 1. EBSNet is not free, but it is very good. I used to work with these guys years ago.

Books 1. XINU Operating System Design: The XINU Approach Is an oldie but a goody. Also see the networking book. 2. My favorite thing in this class is MicroC/OS-II The book and the code are great.

MicroC/OS-II works great on PC hardware and will give you all the nitty-gritty access you desire.

Answer 3

Embedded systems programming is a very broad definition. You could be programming for an embedded system using C without even knowing the specifics of your target platform, since somebody else took the time to port your compiler for that platform.

However, at the same time you could be programming an specific device embedded driver (LCD, buttons, USB bridge, etc) in which case you will basically sleeps with the hardware you are bringing to life. You will be working with specific registers, address, instruction sets, etc. But that totally depends on the hardware itself.

In my opinion embedded programming is very broad. I have work on more than 10 embedded projects in the past (most of them on different platforms) and I needed to learn a lot about the hardware. That's made me a good embedded programmer? I don't think so. If I need to develop an embedded application tomorrow, I think I will need to start from scrath since hardware is constantly changing. But my programming skills should be better. :-)

Answer 4

I learnt it on the job, and the company provided me with the basic tools and backed me all the way to complete the project.

Embedded systems itself is a wide field and ranges from mobile device programming, microcontroller programming , Vhdl etc. I don't want to scare you off here!.. just mentioning ground realities.

Very often in the real world embedded systems would interface with analog circuits , so a bit of background in that would be of real help.

If you want to go into microcontrollers you have a wide array of options. The tools required for it would range from a programmer/debugger which can be interfaced to a PC to help you build your projects.

Unlike Computers, embedded systems need some external hardware environment to work on, this could either be a test board or a starter kit.

To name a few: Atmel Corporation has this.

Microchip Technology has this You would also need an In-Circuit Debugger ICD2 along with this starter board to program and debug your firmware.

You could also look into Renesas, Freescale, Texas Instruments, National Semi for their ranges.

Hope this helps you to determine which way you want to proceed.

Good Luck!

Answer 5

Hate to say it, but "get a microprocessor and try things!"

Check out the Beagle Board and work on some practice projects (there are many samples on the internet).

Answer 6

The best thing you could do is start at the beginning - bare board, preferably one simple enough to put together yourself so you know what's in there (a PIC or something). Embedded systems is really about understanding what's really happening in the system - when I was at Uni, you designed your own board then wrote the code to run on it, and that's not a bad approach - any ES job is likely to require you to understand what the hardware is doing in more detail than most other areas of programming. It's important to get this experience in early, or you won't get the right frame of mind to approach ES (I've seen countless PC/server programmers flounder badly when they come up against an embedded project relatively late in their careers).

The major softy area's to get to grips with are assembler (sorry, in an ES you will need it sooner or later), interupt and cache architectures. How to read circuit diagrams (not hard, but crucial) and how to drive a scope/logic analyzer. BDM/ICE/Jtag debugger use. Then you can start looking at scheduler theory (types of realtime, etc) - not everything is Linux, and in fact most ES is likely to be something else entirely (possibly even no os at all) it's worth having an afternoon reading the source to one of the simpler RTOS' (ucos or the like).

Don't obsess over one CPU or bit of hardware though - in 6 monthes, it'll be a different one, and the spread is much wider than pc land (arm,sh4,ppc,MIPS,tms320,a sack full of microcontrollers and some truly insane hugely parallel multicore stuff from NEC are all in regular use these days).

Answer 7

You need to know about impedance, voltage, current, digital logic, and have some loose notion of transistors.

You need to know C.

Your best bet is to have a physics book, a digital logic book, and a circuits book. Real-time Systems by Liu gets you a notion of the theoretical scheduling aspects.

But those just get you what a CS degree doesn't teach you about the theory.

Take a look at Embedded.com. Those gentlemen are very practical. Theory isn't the concern. You will need to snag a microprocessor dev board and start writing stuff. Personally, I'd suggest writing a multitasking OS kernel. Then do something fun like a serial-cable controlled car.

Answer 8

As other people have commented here, the best way to learn about embedded systems is to build one.

Start with a development board and a free C compiler, and experiment.

As you've found, there is a real shortage of university courses - and indeed, books - that deal explictly with embedded systems, so you may have no choice but to learn on the job.

Bear in mind that a large proportion of embedded programmers have degrees in electronic engineering, rather than software, and so people like Jack Ganssle (see his website, and his articles on embedded.com) are now trying to close the gap between the programming taught on these degrees, and good software engineering practice.

Coming from a software background, you are in a good position to apply what you've learnt in an industry that still has some catching up to do.

Your challenges, then, are:

• If you're going to be doing electronic design, then you'll need to learn about that - possibly from books or courses, and from your future colleagues.
• To learn how embedded software differs from what you've learnt so far.
• To learn about microcontrollers. As others here have said, you'll be exposed to many chips in your career, so it doesn't matter which one you start with!

Regarding knowledge of physics: I'd suggest focussing on topics directly relevant to electronic & electrical engineering.

PS: to put this in context: my degree was entitled "computer systems engineering", which covered both computer science and electronics, though I focussed mainly on the former.

When I started working in industry, I soon found my electronics knowledge was somewhat lacking, but I learnt a lot over a period of time from my colleagues. Conversely, I was able to add to the department's pool of knowledge because of my experience of software engineering.

Answer 9

Mobile phone, PDA and appliance (NAS,PVR) programming sort of merges in with embedded. When you think about it the key difference between embedded and non-embedded programming seems to come down to I/O. Its all about the transducers, parallel ports, serial ports and control networks. The rest is just programming like any other.... PS Its also fun so yes I agree with other comments -get your hands dirty by doing...

Answer 10

While you've still got access to the university and its lab resources, try to register for the digital logic class in the CS curriculum (if you haven't taken it already), or see if the EE department has a class on microcontroller programming. If you feel weak on hardware, electrical engineering classes are your best bet to learn about it quickly.

In particular I mean classes similar to, say, these two, which between them bootstrapped me into embedded development. The lectures were useful, but it was the lab and library access that really paid off; it's hard to get access to such a wide variety of FPGAs, oscilloscopes, and so forth on one's own.

Answer 11

If you want to learn about how an RTOS works, MicroC/OS-II: The Real Time Kernel by Jean Labrosse would be a really good start.

• it's simple,
• it covers the fundamentals well,
• the example software will run on the PC so you can experiment without special hardware
• it'll also run on a variety of microcontrollers, so when you want to go to real embedded hardware, it'll probably go on whatever you choose
• there's good community support

As far as getting going with actual hardware, I'd suggest a devkit from a compiler vendor like IAR or Keil that has the compiler, JTAG, and dev board bundled. This way you'll avoid a lot of the headaches that will crop up when trying to get the compiler, debugger, and JTAG device all talking to the dev board. Usually these kits cost about the same as the hardware alone would anyway. The compilers are crippled in terms of the code size they'll generate, but that's not usually a problem for educational purposes.

Answer 12

You might have luck starting on a higher level and moving down. A good way to do this is to buy a nice target board that can support Linux. You can get some very high level boards (tens of MHz chips) that support linux but also allow you to get a feel for the lower level stuff. Most of these chips will still have SPI, I2C, DIO, UARTs, etc which you will all find in the lower level boards as well. But they'll also typically have ethernet which you can use for programming, flashing, etc. If you already run Linux on a desktop you'll have a heads-up on this (running NFS servers, TFTP, etc).

The best target hardware is probably a WRT54G - a plain ol' Linksys router. You can flash it with Tomato, DD-WRT or OpenWRT and you'll have a nice embedded Linux distribution. You can find a lot of tutorials describing what people have done with it. True, some of it is 'I put a webcam on it' but some of it will be 'I used the discrete I/O to control my thermostat' - that will be closer to what you're looking for. When you get more confident with packages, source, cross-compilers, etc you can switch to buildroot and start making your own images. If you don't like that idea there's the BeagleBoard or LinuxStamp out there as well. You should be able to understand the terminology they use from the desktop world and it'll help you cross over.

Another one of the most fundamental things you can do is to read up on serial protocols. So much of the embedded world is based on serial protocols it's not even funny. You're probably most familiar with RS-232/UART serial protocols - 8-N-1 type of stuff. Read about how the data is transferred, how the clock is structured, how the USART works, parity, etc. Then you'll have a good basis for the synchronous serial protocols such as SPI an I2C.

If you're especially into this the next step is 8-bit microprocessors like the Atmel AVR or PIC. To program the Linux targets mentioned above you need a good idea of Linux programming/C. To program the smaller microprocessors you need to know what registers control what, what each register value does, what timing constraints you're under, etc. It's a black magic sort of world so I wouldn't head for it straight off. You're better off starting with the Linux targets then moving down.

Good luck.

Answer 13

If you have a software background your next step is to learn the hardware. Get a book or take a course in digital logic, computer organization, or computer architecture.

http://www.amazon.com/Computer-Organization-Design-Fourth-Architecture/dp/0123744938/ref=sr_1_2?ie=UTF8&s=books&qid=1265316667&sr=8-2

Answer 14

Normally I would also say, get a micro and get started :)

But in your case, maybe you should get a embedded Linux card (i.e. the Beagleboard). And with that you could start writing some c code in userspace and then move down into the Linux kernel it self.

The Linux kernel has many different interesting parts that you can play with, like device drivers, filesystems etc etc

Then you can go smaller, with some uCLinux stuff (That is Linux on hardware without the MMU...)

And if you would like to go even smaller you have all the nice micros (AVR, PIC, ARM Cortex MX etc etc) Maybe one that is a little bigger so you can run FreeRTOS on it?

And don't forget to build something that you think is fun. (Think a little as the guys at "hack a day")