Subject:
|
Re: Some comments (long)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 6 May 1999 19:00:06 GMT
|
Original-From:
|
John A. Tamplin <jat@liveonthenet+spamcake+.com>
|
Viewed:
|
1590 times
|
| |
|
|
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.
In my opinion, there should be no interface that only supports polling/busy
waiting. It is ok to make that interface available for people who are more
familiar with it, but there should be interrupt-driven interfaces for
everything.
> 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.
See above.
> 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.
The Java API has extensive support for debugging. However, I think the
reflection API and related elements will not fit into the space available,
as it also reduces the ability to offload some of the class information
to the host.
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).
> 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.
The level I would expect to have in the OS/native methods would simply be
buffered send/receive bytes through the IR. Any protocols and "server
ports" on the RCX would be added later and could be loaded only by those
people that want them.
John A. Tamplin Traveller Information Services
jat@LiveOnTheNet.COM 2104 West Ferry Way
256/705-7007 - FAX 256/705-7100 Huntsville, AL 35801
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
Message has 1 Reply:
 | | Re: Some comments (long)
|
| (...) 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 (...) (26 years ago, 6-May-99, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Some comments (long)
|
| (...) 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 (...) (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
|
|
|
|
|
|
