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?"
Where I work we are considering Linux for our systems. We attempting to get in on the embedded linux consortum (Not sure of the name) becuase there is only one other non-vender company in on that. We want some influence if we are to use it.
Embedded systems can be anything from a PC monitorying some hardware (I think IBM's mainframe printer uses OS/2 for that) Then there are embedded systems where the comptuer makes the decisions, like an ATM. And CNC (Computer control of metal working equipment) is different.
The product my company is working on is somewhat like a router (I can't give it away), and we have special hardware to get the packet speed up, so the OS only needs to monitor tempatures and change configurations. This is different from CNC where the comptuer has to change which windings on the moter power is going through at the right speed, which depends on how fast the work is spinning, amoung other things. Then there is medical equipment which needs to monitor the health of someone, and adjust drug doses, and call a doctor/nurse if things get out of hand.
Now look at requirements. Marketing assures me that in our case the customer wants relability before all else. Our MTBCF [if you don't know what this means you don't belong in this industry] is 500,000 hour. Some of our componants (harddrives in particular) are not rated for that long, even before you get into statistical analysis. Since our machine breaking could cause every computer in the company to go down we have to meet those numbers. The CNC machine is expected to be reliable, but if it breaks unexpectedly it only costs one person's days work, which isn't nearly as big a deal. The medical device is different. It cannot break in operation, whatsoever. Any problem could cause someone to die, and that is not acceptable. (I know that doctors are not perfect, and for that matter the machine isn't either, but that doesn't change the fact that no breakage is acceptable). That means the device must be capaiable of detecting all faults imeadiatly and sounding an alarm, and preventing any possibility of overdose. (That is if a medicina valves breaks open there better be some other way to shut off the flow) Fortunatly in most cases drug flow can be cut off for a few minutes (meaning that you can sound an alarm if a problem occures and the staff has time to replace the machine)
I could go on, but you quikcly realise that embedded systems have differing goals. I would say that if you want to get into them, write some error recovery. Get involved in detecting memory errors or something, and continuing on. A sig 11 in linux normally means bad memory, (often realted to overclocking) can you find a way around doing a core dump? Of course there is also the functionality. If you want to be involved in the medical mahcine, then I expect you to have some training in medacine, The CNC programer should spend some time in a metal shop. Of course when your linking computers you only need comptuer expirence, but this is a very small portion of the embedded systems market.
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.