Subject:
|
Re: light sensor problem?
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Mon, 24 Jul 2000 01:20:40 GMT
|
Viewed:
|
2490 times
|
| |
|
|
On Mon, 24 Jul 2000, Eddie C. Dost wrote:
> > I'm not sure which comments you are referring to- do you have a URL for
> > the lugnet post?
>
> http://www.lugnet.com/robotics/rcx/legos/?n=203
I see. Interesting post. Like Kekoa points out, though, we have no actual
proof that this occurs (even though his logic does seem pretty dead on.)
> > > I doubt we need this very fast reading of sensors. This makes implementing
> > > more sophisticated events like change over time and such harder.
> >
> > You mean change over time of the sensors? Shouldn't that kind of stuff be
> > done in "user space" anyway?
>
> Yes, when we have user space timers...
Well, we do...
time_t current_time = sys_time;
while (sys_time < current_time + the amount of time I want to wait)
{
do nothing;
}
It's not pretty, but it is functional.
> > As far as assembly goes, I have to say that the current implementation is
> > pretty tame.
>
> This is correct, but there are many good reasons for keeping assembly
> low bandwidth, like pitfalls in assembler embedded in c source
> (see our memcpy problem). If the compiler is bad and we need speed, the
> speed argument wins, though.
I have absolutely no idea about how efficient the compiler is. I suppose,
worst comes to worst, we can always re-implement and then test.
One philosophical note: part of what I like about legOS is the very
low-level, close to the metal feel that you can get from it. This includes
overly fast sampling, raw sensor values, etc. While I agree that the base
of the OS needs work, and in nearly all use these "extreme" cases are
irrelevant, I'd still argue against doing anything that removes too much
power from the programmer.* Not that I think that these changes would do
such a thing, but in general this is to be avoided.
*Yes, I am still bitter that I can no longer control On/Off and Run :)
> > Can we also add this to the 0.2.5 todo list? Again, this is a pretty big
> > change (possibly).
>
> Of course. I totally agree to have these ideas collected first, and get
> 0.2.4 out. This keeps a lot of pressure out of the development of new
> things, as it would not be that hard if they work not fully from scratch.
Good. I'm glad we all see eye to eye on this stuff so far. It will be fun
to start on a new cycle.
Luis
-----------------------------------------------------------------------
"Summertime... and the living is easy...
fish are jumping and the cotton is high...
So hush, little baby, baby don't you cry."
-Ella
-----------------------------------------------------------------------
|
|
Message has 1 Reply:
 | | Re: light sensor problem?
|
| (...) This is why I want to measure things in our lab at work ;) (...) And keeps lower prio tasks from running, which they could do if we slept... (...) Oh well, there are some optimizations missing. I just looked at the code generated by (...) (24 years ago, 24-Jul-00, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: light sensor problem?
|
| (...) (URL) > I doubt we need this very fast reading of sensors. This makes implementing (...) Yes, when we have user space timers... (...) This is correct, but there are many good reasons for keeping assembly low bandwidth, like pitfalls in (...) (24 years ago, 24-Jul-00, to lugnet.robotics.rcx.legos)
|
26 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
|
|
|
|
