Subject:
|
Re: Some comments (long)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 6 May 1999 17:49:57 GMT
|
Viewed:
|
1548 times
|
| |
|
|
John A. Tamplin <jat@liveonthenet.com> wrote:
> > I was wondering if any of these projects is thinking in providing
> > enough flexibility that would make possible for anyone smoothly
> > integrate new sensors with the currently supported ones? (Like Dennis
> > Clark's RCX IRPD?)
>
> Absolutely. What I have in mind is that the basic level of access is to
> the raw sensor value of the A/D converter and whether it is active or
> passive. The interpretation of that value would be done by other
> classes.
Not that I disagree with the elegance of being able to define a class that
implements a new way of reading a sensor; however, I thought I'd point out
two issues you might want to consider:
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.
Second, processing a sensor is not always as simple as occasionally
checking the value of the sensor; you typically want to process the sensor
value every time an a/d conversion is complete. In my GCC-only world, I
imagined this being done with a system-defined semaphore that does wakes up
all threads waiting on it every time an a/d conversion completes. You
might want your interpreter to provide something similar so you can sync up
sensor processing with a/d conversion.
> > Sorry to return to this, but any is going to provide some connection to
> > the PC with some library, or even remote debugging capabilities?
>
> One of the reasons for choosing JVM is the development environments already
> available for every platform. For debugging, you simply load the classes
> which emulate the RCX's hardware and everything else is already there.
>
> As for communication between the PC and the RCX, that is a network protocol
> issue that is beyond the scope of the initial project but could easily be
> added later.
My take on debugging is to provide IR support for one or two primitives
that are designed to make remote debugging possible. One might allow you
to control how the interpreter executes commands, providing support for
PC-controlled break, step, next, continue, etc.; another might allow you to
do memory dumps, possibly in raw format, possibly with a specifer
indicating a specific chunk of data, e.g. the register set of the current
thread, or possibly some combination of the two.
I should add that IR opcode support is available to the current firmware
and should likely be available to similarly designed new firmware. Similar
JVM support for such IR control, especially in reference to the debugging
features, seems possible but less likely.
I agree with John; the library on the PC is some later business, to be
written at the appropriate time if and when everything else is in place.
-Kekoa
|
|
Message has 1 Reply:
 | | 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)
|
Message is in Reply To:
| | Re: Some comments (long)
|
| (...) Absolutely. What I have in mind is that the basic level of access is to the raw sensor value of the A/D converter and whether it is active or passive. The interpretation of that value would be done by other classes. For example, I would like (...) (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
|
|
|
|
|
|
