Slashdot Mirror
Learning Embedded Systems Programming, Cheap?
LordNimon asks: "I'm interested in learning embedded systems programming, but I don't want to spend a lot of money on hardware and software to get that experience. I already know device drivers and BIOS, and I know about LinuxDevices.com, but I don't know Linux programming (yet). I was hoping someone experienced in this field could tell me what the cheapest way to get started is. I assume I should use Embedded Linux, but what about the hardware?"
While I am currently pushing for using Linux on some of our next generation of products where I work, Linux as an embedded OS is not the answer to all problems. We have systems in developement that use both 8 bit and 16 bit CPUs with very limited memory footprints (10's of Kbytes). In once case there is no embedded OS - just a big loop and the entire executable is less than 20k in size.
;-)
In the embedded world - VxWorks is currently the most popular OS. Behind that is pSOS. Both are now owned by Wind River. Both also cost big bucks to get into. ($2k+) Although I seem to remember a big educational discount being offered - look here for more info: http://www.windriver.com/grad/
Learning on the cheap - embedded Linux is probably as good as anything because of the price.
Below are the biggest differences I see in programing "style" between a normal application on a normal OS and an embedded application.
1) You do not normally have access to a gui, or sometimes even a normal console. There may be a serial port, but it may be consumed communicating a specialized command line language.
2) Memory and CPU power are tight. Typically more of both of those add cost to the final product, and also add power consumption - both of which are limited in an embedded system. Making do with less is normal. Because of this, lots of dynamic allocation of memory is usally a no-no. Fragmented memory can't be easily cleaned up with a reboot.
3) Most embedded OS's do NOT do memory protection or virutal memory. The RAM you have is all that you have. If you aren't careful - you write on another task/thread/process address space and mess everything up.
4) It is usually a closed system. This means that you don't have some of the worries of having to run hostile applications. After all - you don't load new applications into your anti-lock brake controller do you? This unfortunately means that some designers take shortcuts that lead to future problems.
5) Real time aspects. Many (most?) embedded applications have some real time constraints. Some applications are more hard real time than others. i.e. a pacemaker had better deliver the pulse at EXACTLY the right moment +/- micro-seconds where a router might have milliseconds to make a decision on some things, and maybe seconds to handle routing updates. Fortuanately many embedded applications have a few hard real time constraints and then a lot of management code that is less constrained in it's real time requirements.
6) Crashing is not an option in most cases. If you've ever worked with someone coming from the Windoze world of programming into embedded world they have a hard time understanding that when you reboot you take down telephone service (and 911) and this is a "bad thing". Anything that can be possibly done on the fly without affecting the operation of the system is done that way. This includes software upgrades.
7) You debug on a system that is different than where you do your editing, compiling, etc. There is a little different mindset when every time you change and compile you also have to download to a target system. Also means that you get to read a different assembly language sometimes.
8) You interface with devices. This might be a motor, a switch, an LED. The motor won't turn on the instant you hit the bit to turn it on. The switch will need to be debounced. You can't see the LED flash when you pulse it for only a few clock cycles. All these things present unique challenges. These real devices can be fun and dangerous. Ask my friend you recently let the reset line on his board touch a 100V line on the power supply..... smoke
If you are looking to do a real embedded project - look at some of the robot contests out there. There are some relatively inexpensive evaluation boards that can be used to control remote control cars, or other robotic thingys. Going this route will almost undoubtably mean that you end up with a 8 or 16 bit CPU and a bunch of "real world" things to interface with. It will get a pure software geek to get their hands dirty with the hardware.