Subject:
|
Re: Proposals, Bug Fixes, etc and tracking them with SourceForge
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Mon, 25 Mar 2002 03:52:06 GMT
|
Viewed:
|
1770 times
|
| |
|
|
In lugnet.robotics.rcx.legos, Mark Falco writes:
> I read over the proposed release changes for 0.2.6, just a few ideas.
Thanks for reading it.
> I recently picked up a second RCX and found it quite difficult to do
> development using legOS on two RCXs.
I'll need time to play with this. It seems to me this is not the
first time this has been mentioned in this news group.
Has anybody thought of using the downloader as a means for setting
the RCX id? Seems to me it would make sense during the download
moreso than during the kernel build. It probably will take time
to adjust the code to deal with this. Can we do something in time
for this release? Could be easy if somebody were to focus on it.
I'm not familiar with the LNP stuff but have a great desire to be.
Hrm... we've so many opportunities and so little time in a day ;-)
> Also the release change notes mentioned adding support for third party
> sensors. I've written LegOS user space drivers for a couple 3rd party sensors
> i've purchached. If there is interest I could polish them up for possible
> inclusion.
>
> The senors I've written drivers for are:
>
> swmux - techno-stuff.com, this sensor has nine states, driver makes it easier
> to decode
> dirpd - techno-stuff.com, simple translation (left, right, center, none, error)
> active mux - mindsensors.com, complex driver for active multiplexor. I've
> mentioned this before, and will shut up about it now :)
I personally would like to see support for these sensors. I think, also,
that we must be careful to not bloat the kernel for the majority users.
Any thoughts on how to do both?
I'd like to see more people weigh-in on this 3rd party sensor issue.
I'd say prepare them and file them as patches as you did with
mux1 (against a fresh 0.2.5). This will give us time to listen
for comments. And it gives time for others to play with and review
your changes. From a work-effort perspective, if we are to merge
any patches having a couple more is not significantly more work
(if your work is like your last, concise and functional.:)
It's an interesting tension because I'd also like us to get the
main content in place in CVS as soon as we can. So, it's hard
for me to suggest anything that might delay... ;-)
This approach sound OK?
Regards,
Stephen
|
|
Message has 2 Replies:
Message is in Reply To:
22 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
|
|
|
|
