Subject:
|
Re: BrickOS Patches and Development
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Tue, 31 Mar 2009 00:10:42 GMT
|
Viewed:
|
27522 times
|
| |
|
|
Matthew Sheets wrote:
> This is a follow up to earlier postings discussing the development status of
> BrickOS. While the Sourceforge project has not had much activity of late,
> I've come across various modifications that, unfortunately, have never made
> it upstream. Even more unfortunate is that as time passes, it seems a few
> more RCX sites go offline.
Case in point: when I first started on this post some weeks(!) ago,
hoenicke.ath.cx wasn't responding.
> After finding BrickOS modifications or patches, there are at least two key
> issues: 1) the changes are not always against the latest version of BrickOS
> and 2) different sets of changes might modify the same section of code.
And it's not getting easier if we've collected different sets of patches
and then make further changes based on those... So yeah, we need to bring
everything that already exists together and then go from there.
> I have assembled a collection of patches that I have used to update my
> version of BrickOS. Some may be more familiar than others, but I have
> listed them all here for completeness. The numbers correspond to the
> numbers in the diff file name in the archive file.
Excellent. I've gone through your set of patches, making sure they compile
without warnings with gcc 4.3.2. The binutils 2.16.1 assembler (on x86_64)
prints lots of annoying warning messages (like "Warning: operand
#0xfffffffffffffffa out of range."), but they appear to be completely bogus.
> 1 - 5. Dr. Hoenicke's patches ( http://hoenicke.ath.cx/rcx/brickOS.html ),
> including gcc33, highmem, performance, Makefile, and tcpcomm
The second, "experimental" version of the performance patch (which adds
CONF_DSENSOR_FAST) also works well with the following patches.
> 6. Carl Troein's signedness patch (
> http://news.lugnet.com/robotics/rcx/legos/?n=3987&t=i&v=a )
I've made some minor (I think) update to this one. Also, it now comments out
the nasty "find /" in the configure script, as I got a bit annoyed when it
printed hundreds of error messages when scanning /proc, /etc and other silly
paths (and even more annoyed when various noisy disks were spun up).
> 7. Outstanding Sourceforge patch - enable Makelx to handle longer file names
> 8. Outstanding Sourceforge patch - update entrypoint specification to the S9
> record (Lego.NET)
> 9. Outstanding Sourceforge patch - address compatibility issues in
> non-Linux/Cygwin environments
> 10. Outstanding Sourceforge patch - serial port init fix for Mac OS X
A line break in the middle of a comment util/firmdl/rcx_comm.c breaks
this patch. My version of the patch is almost identical (but working), and
as a bonus the indentation is consistent with the surrounding code.
[Update: ah, I see the bug is fixed in patch 13.]
> 11. Mark Riley ( http://news.lugnet.com/org/ca/rtltoronto/?n=14996 ) - LDCC
> 12. Brown.edu ( http://www.cs.brown.edu/courses/cs148/old/2004fall/brickOS/
> and
> http://cs.brown.edu/courses/csci1480/old/2005/brickOS/quickstart.html ) -
> LNP printf capabilities
At least with gcc 4.3.2 there's a warning about vsnprintf being implicitly
declared. I've created include/stdio.h with declarations of [v]snprintf and
made a new version of the patch.
> 13. Mike LeSauvage (
> http://tarpit.rmc.ca/mcgaughey/eee243/labs/resources/legoshrink.html ) - LNP
> communication utility; made modifications to reuse existing code and added
> support for TCP communication (such as used by BrickEmu). Please note that
> I have not been able to test these changes for all platforms.
Neat. Good to see that you're reusing existing code. That reminds me that
there's some fairly trivial code duplication between dll and firmdl. It's
not very important, but I'll try to do something about it soon. As for
not tested on all platforms: the code doesn't compile on *ix because of
some calls to open() with the undefined mode flags O_BINARY and O_TEXT.
I've added a test for _WIN32.
> 14. Taiichi Yuasa ( http://xslisp.com/ ) - miscellaneous patches to BrickOS
> that are packaged along with xsLisp
I've added the doxygen update and my edgecount stuff as patches 15-16.
> I have uploaded this collection of patches to
> http://sourceforge.net/tracker2/index.php?func=detail&aid=2601672&group_id=58151&atid=486699
Revised version at
http://sourceforge.net/tracker/?func=detail&aid=2722649&group_id=58151&atid=486699
> This is by no means an exhaustive inclusion of everything that is out there,
> though what remains might require more effort to incorporate.
> [...]
> * ECU.edu (via archive.org -
> http://web.archive.org/web/20070624025341/http://www.cs.ecu.edu/~hochberg/fall2002/brickOS/index.html )
> - task prioritization, task scheduling, memory allocation, designate sensor
> as real-time
I like the idea of being able to reliably get every sensor value, and
to do so without a long and unpredictable delay. A while back I wanted
something similar, but I want for a simpler solution: callback functions
in the sensor handler (one per sensor, called every time the sensor is
sampled), but that's a very fragile and error-prone solution (for one
thing, the user would have to disable interrupts to interact with
whatever struct the callback function uses to store the results).
> * NCSU.edu ( http://moss.csc.ncsu.edu/~mueller/rt/rt05/readings/g1/ ) -
> task scheduling, prioritization, etc.
>
> While probably too large to include in a regular distribution, Olaf Christ's
> TCP/IP-enabled RCX is interesting (via archive.org -
> http://web.archive.org/web/20040324131317/http://users.informatik.haw-hamburg.de/~christ_o/)
It's way cool, but I'm less sure that it'd actually be useful. :-)
> Then, there is Dr. Hoenick's Bibo ( http://hoenicke.ath.cx/rcx/bibo.html ).
> WIth the only real difference from BrickOS being in the task scheduler,
> would future development be farther ahead by using Bibo as the starting
> point rather then the current BrickOS?
That's a very good question. From what I gather the bibo kernel is
quite a bit smaller and simpler than what we have today, but is that
reason enough to switch? Would we miss the features that we'd lose?
And what exactly _are_ the differences anyway, from a practical point
of view?
Another thing: We should have a good asm implementation of the Power
Functions protocol. I've ordered the Emerald Night collection so soon
I'll have some power functions parts and a reason to control them
with BrickOS. Hopefully that will lead to something.
//Carl
|
|
Message has 2 Replies:
 | | Re: BrickOS Patches and Development
|
| Hello, 2009/3/31 Carl Troein <carl@thep.lu.se>: (...) For some unknown reason the address suddenly pointed to the old server again which was shutdown in December last year. I noticed it myself only by chance. It seems that the dyndns record has (...) (15 years ago, 31-Mar-09, to lugnet.robotics.rcx.legos)
| | | Re: BrickOS Patches and Development
|
| (...) I've recently mucked about with the Power Functions protocol, and got a proof of concept running on the RCX using brickOS. The main problem is that it's quite timing sensitive, so this code only worked reliably with interrupts disabled (...) (14 years ago, 15-Jun-10, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | BrickOS Patches and Development
|
| Greetings, This is a follow up to earlier postings discussing the development status of BrickOS. While the Sourceforge project has not had much activity of late, I've come across various modifications that, unfortunately, have never made it (...) (15 years ago, 15-Feb-09, to lugnet.robotics.rcx.legos)
|
29 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
|
|
|
|
