Learning Embedded Systems Programming, Cheap? 10
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?"
Atmel microcontroller (Score:1)
Open source development tools can be found on the "MicroTools for Linux" page (http://medo.fov.uni-mb.si/mapp/uTools/), and a Windows 95 port of these tools can be found on the "Atmel for Dummies" page (http://members.xoom.com/volkeroth/index_e.htm). You can program in gnu C or assembler.
Using the example C programs on these pages I was able to use the 8515 and an old LCD I had to make a functional clone of the LCD Proc device (http://lcdproc.omnipotent.net/).
The board requires a power input of 9-15V DC or 7-12 AC ($7 extra for a power "brick"), and it is quite a nice board. It has a 9 pin serial port, a 14 pin LCD connector, 8 LEDs, 8 switches, sockets, jumpers, connectors, etc. Much fun for a reasonable price.
ok try Cygnus (Score:1)
of course there is the API to learn although there is vendor specific stuff POSIX is the way to go test it under BSD linux and ecos and see if it works portable is always the way to go !
regards
john
a poor student @ bournemouth uni in the UK (a deltic so please dont moan about spelling but the content)
Use your PC (Score:1)
There is embedded in the sense of the handheld computer where only small size matters. For this, program your Palmpilot.
Embedded in the sense of Airplane control stuff, where Real-Time response is the most important. program Lego Mindstorms.
Embedded in the sense of what Intel calls "Applied Computing". This is using PC hardware for dedicated tasks, such as Voice over IP. Check out www.picmg.org for examples. CompactPCI is little more than rackmount a PC. Applied Computing is programming standard PC hardware, but knowing multithreading/Interrupt handling/BIOS/Device drivers like you never wanted to.
Re:Which embedded system? (Score:1)
A long compile/test/fix cycle is also not uncommon. That is probably the one thing that I hammer on the most to try and reduce. Unix machiens that easily allow distributed builds are your friend. An ethernet port that is only on the lab boards is also another friend for speedy download. Burning PROMs is a pain in the *ss - but sometimes a necessary evil.
Re:Would Lego Mindstorms be a good starting point? (Score:1)
I personally went with a small microcontroller from Technological Arts [technologicalarts.com]
I choose the MicroStamp11 (based off of Motorola's 68hc11 processor. The starter kit (includes everything needed to get started) costs ~$65 US. It can be programmed in assembly, sbasic, and c. I have even seena fuzzy kernel for it.
I have a few links available on my site [pittsburghrobotics.org] for other stores/websites/resources/etc..., it might be helpful. (Alot of information can be found on the other sites in the Clubs section I link to (they have been around longer)). I plan on adding more resources/links over time.
Would Lego Mindstorms be a good starting point? (Score:1)
Re:Which embedded system? (Score:2)
Sigh, replying to myself... some things that I just recalled
Things don't go away in the embedded world. One of our key products was designed in 1984. Several years ago the CPU supplier told us they were taling final orders. So we ordered a 15 year supply of CPUs. We had no choice, a 10 mhz cpu looks horridaly slow today, back then it was the best we could do, and the hardware depends on some timeing of when the CPU gets the bus to let other custom parts on the bus. We can't change CPUs (without spending $$$ on a product that is nearly obsete, there are no new cusotmers, but the old customers need more or replacements from time to time)
Anouther poster mentioned the Memory and CPU is generally constrained. We find this less true today then before. In fact we have found that we have to put more memory in than we need because that is all that is avaiable. Then we complain to the supplier that it uses to much power...
My compile/test/fix cycle is up to nearly an hour now. That is After fixing a big and recompiling (which doesn't take any longer) I now have to download software, burn proms, and reboot. Each reboot runs 20 minutes of hardware diagnostics (We are looking at getting that down, but we don't want to do a less then complete coverage) before I can simulate the situation I need. I'm doing some unusal endcases that take time to setup after that.
Still, I like embedded systems. It is a refreshing change form the microsoft crashes often, or linux it can crash though it normally doesn't world. We can crash, but only if we have something redundant to take over.
Which embedded system? (Score:3)
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.
Embedded Linux? - maybe, maybe not. (Score:4)
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.