embedded systems skills set

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?

please advice. thanks!!

Reply to
Loading thread data ...

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.


Reply to

On 16 Sep 2006 19:13:48 -0700, John wrote: /cut

IMHO best way to learn some architecture is by programming in assembly language.

You are forced to think like a machine. I program my systems in assembly and C. I know a little of C++ but C is OK for me.

Reply to
Mad I.D.

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.



Reply to

In article , Eric writes


Some run an OS There are many OS about from Embedded XP, Unix and clones (ie Linux) and many others down to small schedulers some are Real Time and others are not.

These are from 8 bit to 128 bit systems.

Others have no OS these are also 8-128 bit systems.

There are OS 0n 8 bit systems and some 64 bit systems don't use an OS. Though as a rule the larger systems tend to use an OS.

Not always true. However some 8 bit devices do.

???? Mobile phones use many MCU (usually) more than one. I know a lot of the SIm cards can run Java and they are 8 bit.


Well they are used.... Though the 8051 is far more common.

\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

thanks for all your inputs.

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?

please advice more. thanks...

Reply to

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
Reply to
David Ashley

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.)


formatting link

Reply to
Steve at fivetrees

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:

formatting link

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.

Reply to
Mike Silva

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          | paul@pcserviceselectronics.co.uk
    PC Services
 Click to see the full signature
Reply to
Paul Carpenter

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 ;-)

Reply to
Tom Lucas

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.


Reply to
Henrik Johnsson

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".


Reply to
Isaac Bosompem

As long as they don't use brain-damaging PIC they are OK. HC11 is not that bad.

68000, or similar CISC with index, indirect, etc. addressing modes to illustrate the basics. Neumann architecture is preferable.

To teach basics, it is a good choice. May be even very good choice.

WBR, Yuriy.
"Resistance is futile"
Reply to
Yuriy K.

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.
Reply to
Mike Silva

I would advise you to read Lewin Edwards book "So you wanna be an embedded engineer". This answers a lot of your questions and/or tells you that some of these questions cannot be answered :-)


Reply to
Meindert Sprang

Agreed :) PIC programming makes people mentally crippled.

Ancient processor, motorola bus, high endian, dumb assembly syntax (instructions like 'aba': is it a = a + b or b = b + a?), not so good datasheets and manuals.

An old good PC with DOS is the excellent platform for learning the embedded systems. Cheap, simple, tons of literature, basic peripherals are already on the board.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky


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 ....................
 Click to see the full signature
Reply to
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?

And on the HC11, they're on the chip.

Reply to
Everett M. Greene

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.

-- Darin Johnson

Reply to
Darin Johnson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.