'I say it is spinach . . .'
John Nall wrote:
> So for a
> single user system, such as a PIC, a very elementary operating system
> would not be a difficult thing to write. A user would write his code,
> link it with the OS, and load it into the PIC. Reset would turn control
> over to the OS, which would do the necessaries, and then turn control
> over to the user program. Interrupts would interrupt to the OS. The
> user would only make standard function calls in order to communicate
> with peripherals.
> Once this was accomplished, then I think that a C-like language would be
> a lot more feasible.
Perhaps, but the whole system would no longer be. I think you've forgotten
why a small, cheap microcontroller was used in the first place. An
operating system provides an abstract and device independent interface to
the underlying hardware, but it comes at a cost. On a general purpose
computing platform like a PC this cost is well worth it. On a small
resource limited system, the resource requirement cost of an operating
system can easily exceed the small amount left over for an application.
Operating systems have their place, but I don't want one between my app and
a PIC. The closest I get is occasionally using pseudo-threads on a PIC 16
to handle an I/O stream, a little more sophisticated on a PIC 18, and I use
true cooperative multi-tasking more often than not on a PIC 30. However,
this is a single small module. I just checked and the entire PIC 30 thread
manager of a current project fits in a 289 line module with probably half of
that comments. I wouldn't want a layer presenting a different interface to
the hardware peripherals than what the hardware already presents.
I just don't understand your obsession with trying to take a little resource
limited system designed to do a particular task as cheaply as possible and
dress it up as a general purpose computing platform. I fail to see a
problem looking for a solution. It also shouldn't be any surprise that such
small systems require different tools, and trying to big system tools on
them might not be appropriate. So the tools were modified to fit the
realities of the small systems which makes them look different from the big
system version you are used to. Why would you expect they wouldn't? In
other words, high level languages specifically for small systems are going
to be different than their big system ancestors. It's time to get over it
and move on.
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
Olin Lathrop wrote:
> > I just don't understand your obsession with trying to take a little
> limited system designed to do a particular task as cheaply as possible
> dress it up as a general purpose computing platform.
I doubt we disagree, Olin (and sincere congratulations on the kinder
more gentle approach to responses :-). I was answering a specific
question as to how the differences could be resolved. and that is how I
think they could be resolved. I don't say that I recommend doing it,
necessarily. More trouble than it would be worth, I agree. If someone
were to ask me how to successfully commit suicide, I might well advise
them, but that doesn't mean I think they ought to do it.
More... (looser matching)
- Last day of these posts
- In 2005
, 2006 only
- New search...