Subject:
|
Re: Some comments (long)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 6 May 1999 21:55:19 GMT
|
Viewed:
|
1574 times
|
| |
|
|
John A. Tamplin <jat@liveonthenet.com> wrote:
> On Thu, 6 May 1999, Kekoa Proudfoot wrote:
>
> > The ROM a/d isr, which is different from the ROM sensor-processing function
> > I mentioned, effectively does the efficient thing you mentioned. It
> > effectively throws a semaphore which causes the firmware's
> > sensor-processing code to run at high priority.
>
> Obviously you have spent much more time deciphering the ROM than I have.
> I wasn't aware that the ROM supported native threads, only multiplexing
> the bytecode streams it executed. How can replacement firmware hook into
> this sensor-processing code?
I've mislead you. The ROM does not support native threads. The firmware
simulates cooperative threads. The firmware selects one of six functions
to run based on priority and whether or not a run flag has been set for
that function. The run flag operates like a semaphore. A function is
selected, then called; it does something, then returns. The process
repeats. This simulates a threaded system. The sensor processing code has
the highest priority.
Technically, I would not call this a threaded system, but it operates just
like a cooperatively threaded system, but without the stack overhead.
-Kekoa
|
|
Message is in Reply To:
 | | Re: Some comments (long)
|
| (...) Obviously you have spent much more time deciphering the ROM than I have. I wasn't aware that the ROM supported native threads, only multiplexing the bytecode streams it executed. How can replacement firmware hook into this sensor-processing (...) (26 years ago, 6-May-99, to lugnet.robotics)
|
42 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
