At 11:39 PM 8/8/01 -0700, you wrote:

>1. what is embedded system? what is the difference
>between a normal electronic system with a uC, with an
>embedded system?

There are arguements about this on USENET regularly,
as in comp.arch.embedded. The difference is clear, not
so clear, then clear again. A PC can be an embedded
system in some circumstances.

>2. i am used to programming pic16F84 and 68hc11. the
>procedure is like this. key in the assembly in an
>editor, them assemble them to hex file, then download
>them to the uC. that's it. the uC can be brought
>everywhere and still function the same.

Rightt....

>My question is, why people are telling me that i need
>a RTOS ( Real Time Operating System ) to develop an
>embedded system? They are telling me that drivers need
>to be written, so on and so forth. Why?
>What role does the RTOS play?

Provides system services (the OS part) specifically
related to real time work (the RT part). You do the
same thing in a crude way when you set up a periodic
interrupt on your PIC, then slice the work between
different tasks depending on a state byte. You can
even get RTOS systems for the PIC, see the "salvo"
product (I have not tried it, but would be interested
in any feedback). Look at the available
services to see if you could use this. At the lowest
level, the RTOS will use some hardware resources of
the chip (a timer, say) and everything will be keyed
off of that (it will use a bit of RAM to keep track
of things. There's nothing magic about them, you
could write your own, given the time and inclination.

>i don't get it, cause i am still looking things at the
>binary level.

It is all 1's and 0's (with the occasional indeterminate
bit) if you get close enough.

>3. Another issue is the driver issue. When someone
>told me that driver need to be written for certain
>embedded component, i start to go blank. how should i
>start?

These terms assume a level of abstraction that doesn't
always exist in small micro programming. If you take
the section of code that goes between your application
and something external, make it a seperate program and
document the interface to it, that's a driver.

>Another senior engineer told me that i have actually
>been writing drivers without knowing it. really?

Probably you've been doing the hard part, but unless
the program interface to it is documented and perhaps
encapsulated in some way, I wouldn't call it a driver.
You'd normally do this anyway, even in assembly, so
as to be able to re-use your code.

Best regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu