> My question is, why people are telling me that i need
> a RTOS ( Real Time Operating System ) to develop an
> embedded system?

Trying to sell you one, perhaps?

> They are telling me that drivers need
> to be written, so on and so forth. Why?
> What role does the RTOS play?

On very small resource limited systems like PICs, an RTOS is just plain
silly.  Yes, I know there are vendors out there who actually sell RTOSs for
PICs, and some of them are on this list, but that doesn't change my opinion.
Most things an RTOS does for you aren't necessary on a PIC, and the ones
that are useful for a particular project are easy to implement yourself.
I've done over two dozen PIC project and never once wished I had an RTOS.

However if the embedded system is using a more "complicated" processor, like
an embedded Pentium or PowerPC, then an RTOS can be useful and will do
things for you that you actually need done.  These systems also have more
resources like RAM, stack, etc, so that you can afford to have an RTOS use
up some of them.

> 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?
> Another senior engineer told me that i have actually
> been writing drivers without knowing it. really?

Probably not.  You have probably been writing routines that present a
somewhat generalized procedural interface to specific hardware.  These may
look a lot like driver code, but I don't consider them to be drivers.  I
think of a driver as the device-specific code that implements a common
device-independent interface for I/O or whatever.  The application can then
use a common set of routines to access different devices, like hard disk
files, CD files, serial ports, etc.

It is very unlikely that you took your PIC code to this level of
abstraction.  For example, I commonly encapsulate PIC serial I/O in a UART
module which presents the UART_PUT and UART_GET subroutines to the rest of
the system.  This is short of a true driver because the generalized I/O
abtraction layer is missing.  These are still very much UART routines, and
there are no common device-independent PUT and GET routines.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olin@embedinc.com, http://www.embedinc.com

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