Thread: Embedded Programming

How exactly do the companies use embedded programming. For lack of a better word, do they burn the code onto the device's chip? And if so, what kind of processor would the devices have? If it wasn't one that is standardly used for PC's, would the company have to hire asm programmers and write in asm? Basically, how does the entire process work?

P.S. I know it's a lot, but I am curious. A link will do. Also, please don't give me a search google response because I did.

>For lack of a better word, do they burn the code onto the
>device's chip?

In embedded systems programming you can develop your software on a PC. The actual writing of the software can be done on the PC and also the compiling can be done on the PC, using a cross-compiler. When you develop software on a PC you can use a cross-compiler to compile the software for a specific target, for example a 8051 microcontroller, for a different OS etc.

The results of the compilation, the binary code, can be flashed into the memory of the device. Usually devices have a download box which takes care of placing the code into the device its memory.

>And if so, what kind of processor would the devices have?

There is no general processor used in devices. Some devices have their own specific processor. There are processors which are quite general and can be used in several applications. Think about the DSP's (digital signal processors), microcontrollers and also general purpose processors (like the Intel chips used in PC's) can be used to control a device.

>If it wasn't one that is standardly used for PC's, would the
>company have to hire asm programmers and write in asm?

Usually the used processor isn't a standard PC processor. The process of software development doesn't depend on the processor. So it's quite general, the only thing the programmers at the company probably need to learn are the specific technologies used by the choosen processor. And usually the programmers are capable of learning those technologies.

As with other software, also embedded software is often build up in layers of abstraction. The lowest layer is the layer where software directly interacts with the hardware. At higher levels, there is more abstraction. If things change at hardware level, then in a good architecture, only the lowest layer needs to be adapted.

A simple architecture of an embedded system which uses Java:

Java Applications
*
Java Virtual Machine
*
Operating system
*
Hardware

In an ideal situation the interfaces between the layers don't change during the project, though in practice I've experienced that interfaces sometimes do change during the project. If interfaces don't change, this implies that the layers don't really notice changes in other layers.

>Basically, how does the entire process work?

Which process?

I was summing up my post with that last question. Thanks, I understand now.

To MOD's:
You gonna lock this thread?

>You gonna lock this thread?

Huh? Why? Is there something wrong with this thread?

Another question:

Do the chips that go inside the devices contains the same basic instruction codes as a regular computer chip or do you people have to port everything for these chips?

>Although there is no reason why it should not be. At my last
>place we routinely embedded 8086/80286/80486 chips,

Such general purpose processors can be used in devices, though at some applications more specific processors are more efficient. Like using DSP's in a signal processing device.

I've never used the processors you mentioned in embedded devices, aren't those processors having too much facilities on board? So that their prices are too heigh?

>Do the chips that go inside the devices contains the same basic
>instruction codes as a regular computer chip or do you people
>have to port everything for these chips?

When you are going to use a different processor, there can be the need of porting. Especially when parts of the software is written in assembly. The parts written in ANSI C can be re-compiled with the cross-compiler for your new target. But ofcourse there are always specific C constructions and specific libraries.

But this is also for PC chips. Code for a x586 can't always be used on a x386 since the x586 has new instructions.

Usually when writing software for a specific chip, you write code for that specific chip immediately. So there is no porting needed. That's why cross-compilers were invented. On my PC with an Intel pentium, I can write software for whatever processor I want. 68000, 8051, whatever. I can compile it with the cross-compiler, but not run the binaires. So the binaries must be downloaded into the device. Debugging is often done by connecting the device with your PC, using hypterterminal or something. On the terminal you can see the debug-info you build in.