| |
Hi Frank,
first, let me thank you for your effort! It's only through collaboration
that we can keep this system evolving.
Frank Cremer wrote:
> I'd like to give you my complements for the development of legOS so far.
> However there still is room for improvement. The first thing, I noticed
> is that whenever a program is stopped, it does not turn of the motors
> and keeps the sensors in active mode (consuming energy). I also noticed
> that the "lnp_addressing_handlers" of the last program were still
> active. I have included a patch (runpatch) which fixes these issues and
> I would like to hear your comments on them.
This looks very well thought out.
Originally, I didn't want to reset motors, sensors or networking,
because it makes for great interactive programming - type a line of
code, copy that into a generic template with #includes and a main()
wrapper, and execute it.
But, we can keep that feature and still enhance behaviour for regular
user programs with your patch. Reset only occurs if a program is stopped
with the RUN button now.
For sensor reset, I prefer calling ds_init directly - there's nothing
evil going on in that routine, might as well use it ;-) lnp_init() was
missing, and you're right in adding that - I'm just moving it to the
sys/ subdirectory, as well as the corresponding motor stuff.
All this will be in 0.2.2. Luis has been pushing me to release
the new standalone makelx tool, so now that I have some patches for
legOS itself, I think I'll call it a release...
> Another thing, I came accross is the rotation sensor. This sensor does
> not seem to work all the time. To correct this, I have measured the mean
> sensor value of every state and calculated the boundaries half way
> between the two sensor values. With these boundaries, you can more
> reliably determine in which state the rotation sensor is. The patch for
> this is also included and so far it seem to work fine.
The rotation sensors... the eternal issue. Seems about a million people
have sent in patches for that by now, and I thought we finally had the
solution. The problem is, I don't have any, so I can't test this. So I
won't do anything about it until people agree on the one true code.
> Finally, I have a simple question: how do you set a sensor in active or
> passive mode without getting the following warning:
> "warning: passing arg 1 of `ds_active' discards `volatile' from pointer
> target type"
Ah, you found an oversight here. I changed the way on-chip modules like
the A/D converters are referenced. This also brought some type changes.
I'm changing all relevant parameters in dsensor.c and dsensor.h to
volatile unsigned * now.
> P.S. Would it be a good idea to include a version number into the kernel
> and user programs so that you can not load a user program on another
> kernel?
Very good idea. The problem is, we also have to take configuration
options into account - people might not have support for rotation
sensors compiled in, for example, people might be using the experimental
motor driver, all this may move adresses. Maybe we should use kernel
length and a kernel checksum as compatibility criteria?
Markus.
--
"Nieder mit den Zitaten!" -Markus L. Noga <markus@noga.de>
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
