To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcxOpen lugnet.robotics.rcx in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / *9917 (-20)
Subject: 
RCX 1.0, MacNQC 4.05b OSX 10.4 can't program the brick?
Newsgroups: 
lugnet.robotics.rcx
Date: 
Thu, 21 May 2009 05:27:38 GMT
Viewed: 
20846 times
  
Hi, a blast from the past...

My iBook running 10.4.6 has no problems downloading the firmware from MacNQC
4.05b but when I try to download a program I always get "communications error"
and it fails.  I've tried both the USB IR tower and the serial IR tower through
a USB/serial dongle, no joy.  Does anyone know what could be wrong here?  Is
there something that I've missed?

Thanks anyone who may still lurk here...

DLC


Subject: 
Re: BrickOS Patches and Development
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Sun, 24 May 2009 03:48:52 GMT
Viewed: 
29927 times
  
The Bibo Patch Rollup Collection posted to SourceForge at
http://sourceforge.net/tracker/?func=detail&aid=2773502&group_id=58151&atid=486699
has been updated.

This update adds a handful of patch files--20 through 24.

20: Nice group of Linux error/warning fixes from Carl and posted to
SourceForge at
http://sourceforge.net/tracker/?func=detail&aid=2793018&group_id=58151&atid=486699
Thanks, Carl!

21:  This is a group of bibo paches by Dr. Hoenicke, of which the major
changes relate to makefile, assembly branching, and util man page updates
(plus a documentation typo on my part--sorry! :-).  Thank you!

The above patches were incorporated into the rollup to minimize merge
differences with subsequent patches.

22: This patch changes kexeci's argv argument from type char** to type
void** and is based on some (now old) feedback from the Lego.NET folks (
http://www.dcl.hpi.uni-potsdam.de/research/lego.NET/ ).  Some delegate-type
functions aren't (yet) implemented for Lego.NET, but the capability should
be there for wait_event-type delegates.  For the case of kexeci, the
Lego.NET delegate's argv would not be of type char**.  From what I can tell
by reviewing the code, the type of argv does not matter to the BrickOS/Bibo
kernel, so it should be safe for a Lego.NET delegate to pass a non-char-type
argv.  If anyone has any deeper insight, I would welcome the feedback.

23: Back to work on LNP.  Implemented some code and ideas from
http://lnphost.sf.net/ , which was designed as a replacement for lnpd.
While there are a few drawbacks due to implementation differences (no
tty_type_t support, no sharing/reuse of lnp and lnp-logical with the kernel,
a small documented problem that "in some rare cases lego packets might not
be detected correctly"), it does have some nice features, including handlers
for standard Lego messages and a nicer hexdump routine (shows both hex and
ASCII-printable characters.  That hexdump routine has been incorporated,
replacing the existing one.

LNP was updated to include a handler for standard Lego messages (this is in
addition to existing functionality), and the ability to send "Lego remote
codes" was added.  The lnpmsg program also received several updates.
Support was added for both displaying and sending both standard firmware
messages and Lego remote codes.  The LNP message output format was changed
to use the updated hexdump routine (instead of just a text string), which
should make it easier to monitor non-text LNP messages.

24: Improved the keepalive capabilities to remove some of the keepalive
burden from programs that might use rcx_comm.  Unfortunately, I'm not setup
right now to test either a serial IR tower or an NCD port, but I did try to
setup a dummy NCD-like tty for testing.  Keepalive works of a signal and
alarm, with code in place to prevent a keepalive byte from being sent while
either writing (rcx_nbwrite) or actively reading (rcx_nbread).  I would be
interested in feedback from anyone using a device that needs a keepalive.


Thank you again to those who have responded or provided feedback.  If you
ever catch a few more free moments, Carl, I would be interested in a Bibo
version of your edgecount patch.  :-)


Thanks,
Matthew


Subject: 
Re: BrickOS Patches and Development
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Sun, 17 May 2009 22:10:04 GMT
Viewed: 
28058 times
  
Matthew Sheets wrote:
I've again updated the Bibo Patch Rollup Collection posted to SourceForge at
http://sourceforge.net/tracker/?func=detail&aid=2773502&group_id=58151&atid=486699

Wow, Matthew, you've done a great job with this. Kudos. :-)
I've been meaning to contribute more, but all too rare are the
moments when my kids are asleep and a decent chunk of my brain
is not. But anyway: I've fixed one little bug that stopped
rcx_comm.c from compiling on Linux, plus some warnings and
stuff. Patch posted at
http://sourceforge.net/tracker/?func=detail&aid=2793018&group_id=58151&atid=486699

//Carl


Subject: 
Re: BrickOS Patches and Development
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Sat, 16 May 2009 21:25:03 GMT
Viewed: 
27731 times
  
I've again updated the Bibo Patch Rollup Collection posted to SourceForge at
http://sourceforge.net/tracker/?func=detail&aid=2773502&group_id=58151&atid=486699

This update adds two new patches--18 and 19.

18: For the host utilities, this patch attempts to standardize the command
line arguments and their processing.  There is also some additional cleanup
in lnpmsg, plus the addressing of a gcc 4 warning that was brought to my
attention.  The original lnpmsg (actually LegOShrink) supported logging to
file, sending from file, and filtering LNP addressing messages based on
destination host and/or port.  To ease the process of standardizing the
common host utility code, some of those features were trimmed out; however,
some of the supporting functions remain in place, including SendFile() and
LogString in lnpmsg_comm.c

19: The assembly file dccasm.S with functions necessary for DCC operation
was moved from libs/dcc to alongside kernel/dcc.c.  As has been the case
dcc.c, the code in dccasm.S now builds based on whether or not CONF_DCC has
been defined.  The folder lib/dcc may be deleted.


Thank you,
Matthew


Subject: 
Re: BrickOS Patches and Development
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Tue, 12 May 2009 01:44:54 GMT
Viewed: 
27998 times
  
I have again updated the Bibo Patch Rollup Collection posted to SourceForge
at
http://sourceforge.net/tracker/?func=detail&aid=2773502&group_id=58151&atid=486699

A big change this time is the consolidation of the code bases of util/firmdl
and util/dll-src.  Working with all the similar-but-different code was
getting a bit cumbersome, so I finally decided to try to clean it up.  This
should make enhancing or creating other host utilities much easier.

Point by point, updates since the last lugnet posting are as follows:
* Kudos to Joe for identifying the source of the IR tower problem in Linux,
as he tracked it down to the O_NDELAY flag.  For now, this flag has been
removed.
* Made NCD tty types a runtime option instead of a compile-time #define.
* Merged patches for BrickOS with Bibo, including LDCC, lnp_printf, and
lnpmsg (formerly LegOShrink)
* Reworked firmdl3, dll, and lnpmsg under utils as well as lnp and
lnp-logic in the kernel to facilitate better code reuse, remove essentially
duplicate code, and establish a set of common functions for rcx_comm and
LNP.  Merged the resulting code into util/host, deprecating util/firmld,
util/dll-src, and util/fontdesign.c.
* Util dll--made fast mode a runtime option instead of a compile-time
#define.
* Added ability to send LNP messages directly from the lnpmsg command line.
* Added ir-server from Jochen Hoenike's BrickEmu package and used the code
reworked from above to add support for tty downlinking (e.g. serial, USB,
TCP) or TCP uplinking.


Notes and issues:
* If lnp_integrity_byte() is processing firmware download communication on
the host (e.g. if lnpmsg is listening on an ir-server repeating the firmware
download), a segmentation fault will eventually result.
* Command-line argument format and command-line argument processing - the
various programs use different methods of processing command-line arguments,
resulting in similar argument being handled differently by different
programs.  Ideally, this would be addressed in another round of code
cleanup.
* I am not currently setup to test either serial IR towers or NCD serial
connections, so any reports for these devices would be welcome.

Using the updated ir-server, I have actually been able to send firmdl3 to
ir-server (instance A) to ir-server (instance B) to USB IR tower to physical
RCX.  I then used
dll to send helloworld_lnp.lx up the same route.  Finally with one instance
of lnpmsg listening on ir-server (A) and another instance of lnpmsg
listening on ir-server (B), I ran the helloworld_lnp program on the physical
RCX.  I did have to increase RCX_TIMEOUT to 500, but everything otherwise
works as expected.

I also tried the same sequence using BrickEmu (with a ROM image from my RCX)
instead of the USB IR tower.  The only anomaly was that "unlock firmware"
fails, but everything else seems to work fine.


Thanks,
Matthew


Subject: 
Re: Preserving old-school Mindstorms resources
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Sat, 9 May 2009 12:14:06 GMT
Viewed: 
28378 times
  
Hey folks

I've created a very basic site here: http://www.rcxzone.com/

When I say very basic I mean VERY basic.. it's just an empty instance
of mediawiki, but I'll look to adding content when I get a chance.
Any help appreciated.

Cheers
Tom

On 20/04/2009, at 6:29 PM, Joe Bradley wrote:

Revised version [BrickOS patches] at
http://sourceforge.net/tracker/?
func=detail&aid=2722649&group_id=58151&atid=486699

Now for Bibo....  I have merged these patch rollup collections
with Bibo
(where appropriate) and have posted the resulting diff files to
http://sourceforge.net/tracker/?
func=detail&aid=2773502&group_id=58151&atid=486699

I have found two problems with the patches. I narrowed down the
problems to
specific patches from the Bibo set. However the symptoms are
identical under
BrickOS so I assume they would be linked to the same patches there.

Patch 10: Under Ubuntu with the usb tower, this causes firmdl3 to
exit with
error "read: resource temporarily available". However the light
does light up on
the tower for a small moment.

Patch 11: This seems to do something funny with the motors. Power
does not seem
to be supplied to the motors. when running the motor, the arrows
appear on the
lcd however there is no power being outputted.


Subject: 
Simple Lego traffic light
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Thu, 30 Apr 2009 22:12:00 GMT
Viewed: 
27560 times
  
After all the amazing post across lugnet the past few weeks, it feels
a bit lame putting this one up:

http://rubyredbricks.com/2009/4/27/simple-traffic-light

I guess once it's running up on an RCX it'll be a bit more interesting.

On the topic of RCX - and the whole old-school Mindstorms
preservation idea - I haven't forgotten about it. I've registered a
domain and will aim to get a wiki up and running over the weekend.

Cheers
Tom


Subject: 
Re: BrickOS Patches and Development
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Wed, 22 Apr 2009 02:50:53 GMT
Viewed: 
27327 times
  
I have updated the Bibo Patch Rollup Collection posted to SourceForge at
http://sourceforge.net/tracker/?func=detail&aid=2773502&group_id=58151&atid=486699

The primary changes are in Patch 11, which provides DCC support, and the key
change in that patch was the modification of some assembly code that
performed motor controller bitmasking.

Still known to be outstanding is an issue using firmdl3 on Linux when using
a USB IR tower.


Thanks,
Matthew


Subject: 
Re: Preserving old-school Mindstorms resources
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Tue, 21 Apr 2009 04:16:09 GMT
Viewed: 
28636 times
  
Patch 10: This works for me under Cygwin with a USB tower, but some of the
files such as rcx_comm.c have a bit of platform-specific code.

Patch 11: I've noticed that the linker command file is a little different in
Bibo than it was in BrickOS.  If _motor_controller is 0x00 in bibo.ld and
dm_mask is set to 0x00 in dmotor.c dm_init(), there is "regular" motor
output; if _motor_controller is the BrickOS value of 0x80, DCC motor output
functions as expected.


Subject: 
Re: Preserving old-school Mindstorms resources
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Mon, 20 Apr 2009 18:29:14 GMT
Viewed: 
28165 times
  
Revised version [BrickOS patches] at
http://sourceforge.net/tracker/?func=detail&aid=2722649&group_id=58151&atid=486699

Now for Bibo....  I have merged these patch rollup collections with Bibo
(where appropriate) and have posted the resulting diff files to
http://sourceforge.net/tracker/?func=detail&aid=2773502&group_id=58151&atid=486699

I have found two problems with the patches. I narrowed down the problems to
specific patches from the Bibo set. However the symptoms are identical under
BrickOS so I assume they would be linked to the same patches there.

Patch 10: Under Ubuntu with the usb tower, this causes firmdl3 to exit with
error "read: resource temporarily available". However the light does light up on
the tower for a small moment.

Patch 11: This seems to do something funny with the motors. Power does not seem
to be supplied to the motors. when running the motor, the arrows appear on the
lcd however there is no power being outputted.


Subject: 
Re: Preserving old-school Mindstorms resources
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Sun, 19 Apr 2009 03:02:41 GMT
Viewed: 
28062 times
  
A very useful site is the cs university page here:
http://www.cs.brown.edu/courses/cs148/old/2004fall/brickos.shtml
Agreed.  There is also a set of pages from the following school year at
http://cs.brown.edu/courses/csci1480/old/2005/brickOS/quickstart.html .
Unfortunately (at least from a code merge perspective), their "version 1.2"
is based on BrickOS 0.2.5.  The lnp_printf functionality has been adapted
and included in the recently-posted rollup patches, but incorporating other
modifications, such as "Reliable LNP," is more involved due to the
difference in BrickOS versions.

A page of patches: http://carl.troein.com/
[@Carl]: Please correct me if I'm wrong, but I believe these patches are
already included in the rollup posted to SourceForge?

If the SourceForge project wiki for BrickOS could be enabled....

I've noticed another thing that is disappearing is the custom sensors and
multiplexor boards that were created for the RCX....


Thanks,
Matthew


Subject: 
Re: BrickOS Patches and Development
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Sun, 19 Apr 2009 02:38:55 GMT
Viewed: 
26310 times
  
Now for Bibo....  I have merged these patch rollup collections with Bibo
(where appropriate) and have posted the resulting diff files to
http://sourceforge.net/tracker/?func=detail&aid=2773502&group_id=58151&atid=486699

Most of this follows the pattern of the previous patch rollup collection for
BrickOS, with the following notes:
* 00 - Update configuration and make slight makefile modifications to work
with Cygwin
* 10 - As Carl noted, there are similarities between rcxtty.c and
rcx_comm.c.  I updated this patch to add code to rcx_comm.c that previously
was only in rcxtty.c.  There are still some differences (such as in return
types, use of exit(), and FileDescriptor handling), but this should reduce
the gap.
* 13 - I originally added LegOShrink as lnp_shrink (due to the OS naming
issue) but have added it here as lnpmsg.
* 16 - [@Carl]: I have not included the edgecount patch.  Most of the
edgecount code appeared to be fairly straightfoward to incorporate into
Bibo; however, the assembly code in ds_interrupt in dsensor.c is a little
different, which could impact the edgecount patch.  If you have the time to
take a look at it, that would be great, as it would be nice to have it
included.


Thanks,
Matthew


Subject: 
Re: Preserving old-school Mindstorms resources
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Sat, 18 Apr 2009 09:24:44 GMT
Viewed: 
27334 times
  
A very useful site is the cs university page here:
http://www.cs.brown.edu/courses/cs148/old/2004fall/brickos.shtml
Plenty of useful tutorials and instructions. It would be unhelpful to have it
disappear.
All of the stuff at the legos/brickos sourceforge pages, however a backup
probably isn't needed of these.
A age of patches: http://carl.troein.com/

These are just the ones off the top of my head.


Subject: 
Re: Preserving old-school Mindstorms resources
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Tue, 14 Apr 2009 02:31:38 GMT
Viewed: 
27418 times
  
A list of all the current versions and patches, along with links and
perhaps backups would be very useful.

Nice to see a few of us share the interest.  :-)  The best I can offer for a
list of patches is what I listed in the post here [
http://news.lugnet.com/robotics/rcx/legos/?n=4032&t=i&v=a ], along with
Carl's follow-up post.  That list was culled from links I've collected over
the years.  As was noted, there are different patches out there for
different versions of BrickOS, and those two posts are an effort to merge
together appropriate patches against the latest SourceForge version of
BrickOS.  From Carl's post, the link to download the latest version of this
collection of patches is
http://sourceforge.net/tracker/?func=detail&aid=2722649&group_id=58151&atid=486699 .
The patches are numbered and are intended to be applied in numerical order.

As was also noted, patches yet to be merged deal with "reliable LNP," task
prioritization, task scheduling, memory allocation, real-time sensors, etc.

To the tools versions--
* binutils: 2.16.1 - h8300 COFF support was dropped from subsequent
releases, so unless BrickOS is updated to h8300 ELF, we will have to stick
with this version
* gcc: 3.4.6 - this is the version that I use; I think Carl has had some
success with some releases in the version 4 series

Dr. Jochen Hoenicke's Bibo is also worth considering as a "next version" of
BrickOS.  I have started going through that list of patches to carry over
any relevant changes to Bibo.  If I can get them ported over to Bibo, I
expect I will base any of my future "legOS" development on Bibo.

For some 404 pages, http://www.archive.org/ might be your friend; no
guarantees, though.


Hope this helps,
Matthew


Subject: 
Re: Preserving old-school Mindstorms resources
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Mon, 13 Apr 2009 14:30:17 GMT
Viewed: 
26625 times
  
After surfing through many sites, and (sadly) even more 404s I have been
unable to find a definitive list of gcc, binutils, BrickOS etc. versions and
patches that I should and could be using.

Presumably everybody here has up to date versions of all the necessary programs
working with BrickOS.

What would be very useful would be to have a solid list of patches, version
numbers, problems as of now.

I spotted the patch list on the first post of "BrickOS Patches and Development"
and found it very handy.

The main problem in getting everything together is that every site I visit seems
to have been left unattended for many years, and are all recommending old and
outdated versions of compilers and patches.

A list of all the current versions and patches, along with links and perhaps
backups would be very useful.


Subject: 
Preserving old-school Mindstorms resources
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Sun, 12 Apr 2009 23:57:16 GMT
Viewed: 
26294 times
  
Hi all

Lately I've noticed a lot of old-school Lego Mindstorm resources are
starting to disappear from teh webz. I've blagged about wanting to
preserve this stuff here: http://rubyredbricks.com/2009/4/12/back-to-
the-brick

If anyone knows of any resources you think should be maintained
please let me know. I'm going to do my utmost to make sure stuff
doesn't just "blow away". TIA

Cheers
Tom


Subject: 
Re: BrickOS Patches and Development
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Sun, 5 Apr 2009 02:31:22 GMT
Viewed: 
26295 times
  
It is really hard to find a working binutils version.  The newer ones
do not officially support the architecture any more and with many of
the older versions I was hit by some bug that produced buggy code
without even issueing a warning.

binutils-2.16.1 has problems with local labels ("bne 1f ;....; 1:"),
so make sure they're not used in inline assembler code.  I removed
them from my second performance patch, but they are still in bibo at
several places.  I'm not sure if they will lead to crashes there.

I have found the following related to the removal of h8300-*-hms from
binutils:
1)
http://ring.nict.go.jp/archives/NetBSD/NetBSD-release-4-0/src/gnu/dist/binutils/binutils/NEWS
2)
http://www.nabble.com/The-situation-of-gcc-h8300-hms-and-related-packages-td6455838.html
3)
http://www.nabble.com/Bug-387772:-Can-binutils-h8300-hms-be-removed--td6956460.html

The current Debian version of binutils-h8300-hms is 2.16.1-8
- http://packages.debian.org/search?keywords=binutils-h8300

On the package page ( http://packages.debian.org/sid/binutils-h8300-hms ),
there is a downloadable *.diff.gz file.  That diff file, in turn, creates
several "*.dpatch" diff files.  At least from scanning the patch
descriptions, I'm not sure that any of those patches address the local label
issue.  I did find this bug that was reported against binutils 2.17 -
http://sourceware.org/bugzilla/show_bug.cgi?id=2101 , but it looks like more
of an issue with hex constants than local labels.


Thanks,
Matthew


Subject: 
Re: BrickOS Patches and Development
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Sat, 4 Apr 2009 14:31:03 GMT
Viewed: 
26865 times
  
Hi,

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.

I had worked to assimilate those patches prior to the second version of the
performance patch being posted, so I'm glad to hear that it also works well.


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.

When I went back through to add TCP support to other things, that "similar
but different code" made things a little more difficult.  There are more
things that could use the addition of TCP support, including xsLisp.  I
think a nice enhancement to the TCP ir-server would be to give it the same
"--tty" interface options as dll and firmdl--i.e., directly with a serial
tower, USB tower, or another TCP ir-server.  This, for example, would enable
a "real" brick and a BrickEmu instance to communicate with each other.

Anyway, the short of it is that, yes, I think a merged communication library
would be very useful.

By the way, I don't know if you monitor the NQC newsgroup, but I submitted a
patch to add TCP support to NQC....


- RE: BrickOS and Bibo
Personally, my feeling is that Bibo improves upon BrickOS and will provide a
better foundation moving forward, and I say that as one who has spent some
time incorporating a number of patches into the latest BrickOS.  I'm not
sure yet how much effort will be involved in working back through them to
apply them to Bibo (I'm thinking in particular of patches 7 - 16), but I
think it would ultimately be worth the effort.  Of course, a few of the
patches to BrickOS may not even be relevant in Bibo, but I would at least be
interested in having the LDCC, LNP printf, and LNP communication utility
functionality in Bibo.


Thanks,
Matthew


Subject: 
Re: BrickOS Patches and Development
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Tue, 31 Mar 2009 16:40:37 GMT
Viewed: 
27759 times
  
Hello,

2009/3/31 Carl Troein <carl@thep.lu.se>:
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.

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 changed back to
the old address on March 12th, and I still have no idea how this has
happened.

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.

Sounds like a 64bit bug: -6 is converted to a 64 bit number and then
it complains that it doesn't fit in an 8 or 16 bit operand :)  But if
it is only a warning one can ignore it.

It is really hard to find a working binutils version.  The newer ones
do not officially support the architecture any more and with many of
the older versions I was hit by some bug that produced buggy code
without even issueing a warning.

binutils-2.16.1 has problems with local labels ("bne 1f ;....; 1:"),
so make sure they're not used in inline assembler code.  I removed
them from my second performance patch, but they are still in bibo at
several places.  I'm not sure if they will lead to crashes there.

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?

The most important difference is that the handlers are more robust, as
they are running in the idle thread with its separate stack, they can
invoke malloc/free, and they can be pre-empted by interrupts.  Another
point is the event-based scheduler:  Processes can register themselves
to wait on events and are scheduled when the event is triggered, e.g.
by a handler routine.  My plan was to make everything triggered by
events. However, to have backwards compatibility I still support the
old wait_event(&cond), which just runs the function cond every 5 ms
(in brickos cond is called, whenever the scheduler is run, which is
done every 100ms or when the system is idle or yield is called
explicitly).  The right way would be to run the function cond  when
sensors are polled or lnp message is received, depending on the type
of event we are waiting for.  However, waiting for a sensor poll is
not (yet) supported.  I would also like to see handlers for sensors in
bibo that get called after the sensor was polled.

Bibo is mostly backwards compatible to brickos, but you have to
recompile your sources against the right include files.  At least that
is the theory, I do not have so many programs to test against.  And I
didn't test if bibo compiles fine under cygwin.  Two of the wakeup_t
functions have been replaced by real event-based waiting functions:
use dkey_wait(KEY_PRESSED,x) instead of wait_event(dkey_pressed,x) and
dsound_wait() instead of wait_event(dsound_finished, 0).  A  known
missing feature is the time-slice scheduling of processes with the
same priority.  It would not be too difficult to add it.  However,
adding a yield at the right position to the user code gives much
better performance in most cases.

Regards,
  Jochen


Subject: 
Re: BrickOS Patches and Development
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Tue, 31 Mar 2009 00:10:42 GMT
Viewed: 
27551 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



Next Page:  5 more | 10 more | 20 more

Redisplay Messages:  Brief | Compact

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR