Thread: Embedded system design

Out of the professionals and academia types we have here I was wondering which of you have or are dealing with embedded system development? Also I was wondering what skills you have found differ from those proposed for pc( I guess one might say macro) development and which skills you have specifically developed as a result of dealing with embedded system design?

Originally Posted by andyhunter

Out of the professionals and academia types we have here I was wondering which of you have or are dealing with embedded system development? Also I was wondering what skills you have found differ from those proposed for pc( I guess one might say macro) development and which skills you have specifically developed as a result of dealing with embedded system design?

• Cost is king; however you can trim code space -- at whatever expense of good coding practice -- do it.
• You best debugging tool is likely an oscilloscope and a couple of free output lines.
• Forget most of the standard library.
• Target dictates language and tools.
• Get to know your timers!
• Develop deep understanding of state machines.
• Global variables!
• We get to use void main(void)!
• Porting sucks; a lot of portable code isn't.
• Realize you're often writing glorified (but certainly more readable) assembly.
• Searching, sorting, linked lists? They're an interest here, but rarely apply.
• Break the rules! Touch memory directly; an int is not 32 bits, CHAR_BIT may not be 8; use volatile, discover the costs of:
  Code:

  char *text = "something"; /* vs. */
  const char text[] = "something";

• Realize that the compiler might be calling functions to do "simple" things like multiply, because no MUL instruction exists.
• Find out that more C can equal less assembly.
• Whatever you can do at compile time, do.
• An int and a pointer may not be the same size.
• Direct bit access!
• Interrupts are very difficult to debug, especially if you need a sequence of events.

[edit]

• When your boss tells you that consuming 10 microamps at idle is way too much.
• Trying to fit PC-oriented protocols into tiny devices is more than meets the eye.
• Operating system? In my dreams.
• Kernel? One of these days...
• Vendors always tell you the best possibilities and omit the drawbacks until you've already prototyped.
• Choosing a processor requires its own Google.

I think there is a flaw in the original question. You see there is no such thing as a standard embedded system.

Dave brings up a lot of interesting and very valid points, however, not all of those apply to all embedded projects. In fact some are the complete opposite in some projects. I have been developing space systems, cost is most definitely not king there, reliability is - the cost of replacing a cheap board on an overhead orbiting 36,000 km away is somewhat prohibitive.

In the last 5 years, my embedded projects have ranged from zero OS/kernel located object running an executive loop and a series of state machines through to boards with a sophisticated multi-tasking OS with a rich API and oodles of resources.

They have ranged from very expensive, small production run, mains powered satellite groundstation components, to very cheap, high production run, battery operated portable units.

Different jobs, different environments, different problems.

Thanks Dave, that was exactly the kind of stuff I was looking for.

To adrian, you bring about interesting points as well. I understand that there is no such thing as standard embedded system development, the nature of the beast prevents that. You'll have to excuse the inadequacy of my questions as in I am not too familiar with the linguo. Basically I was looking for things along the lines of what problems / solutions that one might run across that is different from standard pc development, such as the ones you brought up; where in some cases you may be dealing with a full OS and in some no OS at all.

A friend of mine works at LM on Aegis and conversations with him just got me thinking about this topic. Any further discussion in this area is certainly appreciated as in I am not even sure if I am asking the right questions here.

Thnx for the replies

-Andy