Subject:
|
Re: Some comments (long)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 6 May 1999 21:27:28 GMT
|
Viewed:
|
1574 times
|
| |
|
|
John A. Tamplin <jat@liveonthenet.com> wrote:
> On Thu, 6 May 1999, Kekoa Proudfoot wrote:
>
> > First, the ROM already contains a significant amount of non-trivial code to
> > process the existing sensor types. I would imagine any you would leverage
> > this code, and you simply did not mention this. To add a new sensor type,
> > you could use the existing raw type and go at it from there.
>
> Unfortunately, the ROM code (as I understand it) does not implement any
> mechanism other than polling. I would like to do things like block a
> thread until a sensor value matched some criteria. The only efficient
> way to do that is to have the A/D-complete interrupt handler signal
> waiting threads that their condition has been satisfied.
What is your point? If you want to make sense of the raw values, and want
to leverage the ROM code to process the existing sensor types/modes, you
need to call a ROM sensor-processing function every time an a/d completes.
That was the point I was trying to make.
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.
The LegOS a/d code only supports polling.
There is no reason the a/d code you end up using can't effectively wake up
a task devoted to a/d processing. This is completely independent from
using the ROM sensor-processing code.
> So, my take is that in general debugging should be performed on the host.
> The only debugging on the RCX would be things to verify that the JVM is
> working correctly, like tracking memory leaks that aren't being garbage
> collected (which can happen naturally with reference loops).
You mean that in general, for the JVM. The other byte code that is being
considered, which is not based on the JVM, and which I was talking about
when discussing debugging methods, would likely use the debugging methods I
described; I don't think you disagree with this, but maybe you
misunderstood - I was not talking about the JVM.
-Kekoa
|
|
Message has 1 Reply:
 | | 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)
|
Message is in Reply To:
| | Re: Some comments (long)
|
| (...) Unfortunately, the ROM code (as I understand it) does not implement any mechanism other than polling. I would like to do things like block a thread until a sensor value matched some criteria. The only efficient way to do that is to have the (...) (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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
