I have some interests in embedded systems and I want to learn more. I expect most embedded systems are implemented in either C or C++. Basically Java is not an appropriate langauge in embedded system. Correct? Also, a good embedded systems programmer is expected to understand software and hardware system well? Is device driver related to embedded system? What kind of skills set you recommend if I want to work in this field?
There are different classes of embedded systems. Some of them are high-end and they can run linux. Others are very small and they have no OS.
The high-end devices can definitely run Java, and I think many cell phones are in this category. But C is by far the most popular language for embedded systems. C++ is used sometimes, also.
Of course, you'll need to learn a lot about Microcontrollers and the various architectures. Although I'm not a fan of PIC devices in general, they are extremely popular and the Parallax company has great learning packages. You could get one of the educational Basic Stamp packages and this will give you a feel for these things.
I completely agree, which is why you'll find a lot of people with hardware backgrounds in deep embedded positions, by which I mean the jobs where one writes bare metal code or low level drivers.
An intimate knowledge of how the hardware works is a definite advantage for those things.
As the definition of 'embedded systems' has expanded (morphed, some might say), it's not uncommon to find applications programmers doing a lot of code - in a cell phone or something running Linux, for instance, there's no need to know the hardware to implement an application that merely uses the resources provided.
Applications programming, incidentally, is just as important as the driver programming; it all depends on just what sort of embedded system one ends up with :)
My personal preference depends on what I am writing; assembly language for where there is no OS, doing boot setups or in some cases where I have to oustmart a compiler that's just a little too smart for it's own good (optimising out some instruction sequences that are necessary at the hardware layer comes to mind where the compiler doesn't necessarily obey the compiler directives ;)
Other than that, I'm personally most comfortable with C, but I've seen Java, C++, C#, .net, and a host of other languages / platforms used in the embedded space.
Since there are different classes of embedded systems, when people talk about embedded systems, it actually can mean low-level system programming, and high-level application programming as well?
Do we consider embedded systems development as hardware development, or software development, or both? It seems to me its a mixture of software and hardware development. And it depends on which area we work on, the more lower level we work on, then it tend to need more hardware background?
I think the essence of an embedded system is that it's invisible, buried inside some widget. The realm of possibilities fitting this is huge, and includes everything you've suggested. What do you want to do -- hardware or software? You can be effective working in embedded systems if you're good at either one alone, or both.
It's not PC software -- people don't need to install it or fight an OS. You apply power and it's just there doing its thing. You don't have monthly updates -- if the thing was so buggy to begin with right off the bat you'll probably tank anyway.
There's no pat answer. The more you know and the wider range, the more effective you can be. You'll be able to apply diverse knowledge to every problem. It's all one of degrees + balance. When you work out, you don't just lift weights with your right arm, do you?
David Ashley http://www.xdr.com/dash
Embedded linux, device drivers, system architecture
I'm an embedded specialist. This means I deal with everything from 8-bit micros running in 8k of RAM, right up to embedded PCs running a BSD variant - even, may dog forgive me, Windows CE. I'm also a hardware guy, so the smaller systems I design myself - but the higher-end systems I buy and bury in a box.
Probably the key thing about embedded is that it's a box with a specific function - it's *not* a machine you can run anything on. It probably won't have a keyboard, screen, mouse, in the accepted sense. It has one job to do - e.g. a temperature controller, or a router, or a washing machine. One tends not to run "Solitaire" on a washing machine. (So far, anyway.)
To add to what others have said, I would recommend that you buy a development board based on a small, simple micro architecture, and start programming it. The 8051, AVR, HC11 or HC12 are some possible micro families. Get a board with an LCD and keypad and some analog IO in addition to the digital IO. Program it to do anything you can think of. To get more ideas, search around the web for class notes posted by the professors of university embedded programming classes. Start programming in assembly, then move to C. Many boards will come with at least a restricted-capacity compiler.
As one example, there's this board:
I've never seen one of these in person, but the amount and kinds of IO make it look like a nice board for starting embedded stuff, and the HCS12 core architecture and instruction set is very clean, making it a good choice to learn assembly programming, IMO. Look around the web and you'll find a great many other board vendors as well.
I have seen problems at aerospace companies, where systems for testing equipment and components, gets messed up too often because they can install screen savers, play games.... Then they wonder why their tester does not work!
Paul Carpenter | email@example.com
I've played freecell on one of TekTronix's more sexy scopes but sadly laundry technology is lagging behind.
When I was working on fast-jet Head Up Displays I did suggest the inclusion of a tetris-style game for long flights on auto-pilot but management seemed to think that that was "unprofessional." Some people have no vision ;-)
I have distant memories of when we played arcade style games like Breakout and Missile Command on HP 16500 logic analyzers. Goes to show I guess that lines aren't always easy to draw, back then a logic analyzer definitely was an embedded system IMO, even though most of the software was loaded from floppies. Today there's often a more or less general purpose OS running on a pretty standard HW architecture.
I must ask what do you guys think about schools using the 68HC11 as a teaching tool? Which processor do you think is best for someone just being introduced to the world of microprocessors/microcontrollers? For example, in my microprocessor class we are being taught how to program the HC11 in assembly. We are also taught to interface with an LCD (16x2) and an ADC and the like. I am in a lesser known University in Toronto (Ryerson, don't laugh). I think the students at the University of Toronto use a full blown Freescale 68000 based system.
The one we have is using a fairly trivial debug monitor over RS232 (Buffalo monitor). Even for breakpoints the host software overwrites the target address with a "SWI" instruction. It is pretty fun to play with it and cause the MCU to go into the so called "la la land".
Personally, I think the HC11 is a good "laboratory" to teach micros, and the HC12 is even better (the instruction set has fewer special cases). The fewer wierd rules and inconsistencies the better. The
68000 has a clean instruction set, but the device might be "too much" for a beginner. That's just an offhand opinion, since I don't have any experience using the 68000 to teach beginners.
I would prefer 6809 based systems but that would always mean more chips on the board (and hence more expensive) to get the equivalent to the 68HC11 I/O availability.
The Levanthal books for each processor are better, clearer references for the intruction set than the manuals.
With either system Forth would help you crawl up from the assembly level and still allow you to include assembler code if necessary to speed things up. This would also allow you to migrate some of the code from 68HC11 to 68000 without too much trauma.
Paul E. Bennett ....................
Big-Endian is definite plus. If you don't like ABA, you can always write a macro. Manuals and datasheets are orders better than some other companies'.
["Big-Endian byte order is known as 'normal', 'intuitive', or 'obvious'. Little-Endian is sometimes called 'perverse', 'annoying', 'dysfunctional', or 'stupid'. These designations do not, of course, imply any bias or preference."
Christopher R. Hertel, "Implementing CIFS" 2004]
Intel products are absolutely terrible as teaching platforms. Why confuse the basics with all the horrid things that Intel did?
Both have their advantages (though to be honest, I have to think a bit before I can think of any advantage to little endian that doesn't contain the word "compatibility"). But big-endian would seem to be much more natural and easy to teach to students where the natural language and arithmetic uses a left to right order.
Some "perversity" comes from trying to force a human representation onto the data. Ie, writing little endian data down as least significant byte first, but each byte is written with most significant bit first. But that's just because a human is writing things down symbolically.