Subject:
|
Re: BrickOS Patches and Development
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Tue, 31 Mar 2009 16:40:37 GMT
|
Viewed:
|
29014 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
|
|
Message has 2 Replies:
 | | Re: BrickOS Patches and Development
|
| Hi, (...) 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. (...) When I went back through to add TCP support to other things, that "similar but (...) (16 years ago, 4-Apr-09, to lugnet.robotics.rcx.legos)
| | | Re: BrickOS Patches and Development
|
| (...) I have found the following related to the removal of h8300-*-hms from binutils: 1) (3 URLs) current Debian version of binutils-h8300-hms is 2.16.1-8 - (URL) the package page ( (URL) ), there is a downloadable *.diff.gz file. That diff file, (...) (16 years ago, 5-Apr-09, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: BrickOS Patches and Development
|
| (...) Case in point: when I first started on this post some weeks(!) ago, hoenicke.ath.cx wasn't responding. (...) 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 (...) (16 years ago, 31-Mar-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
|
|
|
|
