|
|
| |
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
|
|
| |
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.
|
|
| |
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
|
|
| |
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
|
|
| |
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.
|
|
| |
> 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.
|
|
| |
> 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
|
|
| |
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
|
|
| |
> 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
|
|
| |
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.
|
|
| |
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
|
|
| |
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
|
|
| |
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
|
|
| |
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
|
|
| |
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 upstream. Even more unfortunate is that as time passes, it seems a few
more RCX sites go offline.
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.
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.
0. There is a slight difference between the 0.9.0 source release and the
current Sourceforge CVS
1 - 5. Dr. Hoenicke's patches ( http://hoenicke.ath.cx/rcx/brickOS.html ),
including gcc33, highmem, performance, Makefile, and tcpcomm
6. Carl Troein's signedness patch (
http://news.lugnet.com/robotics/rcx/legos/?n=3987&t=i&v=a )
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
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
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.
14. Taiichi Yuasa ( http://xslisp.com/ ) - miscellaneous patches to BrickOS
that are packaged along with xsLisp
I have uploaded this collection of patches to
http://sourceforge.net/tracker2/index.php?func=detail&aid=2601672&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.
* Brown.edu also includes "reliable LNP" code
* Powolny had several postings in 2008 on serial communication
* 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
* 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/)
As a side note, several programming languages are available for developing
programs that run on BrickOS.
* XS [Lisp] ( http://www.xslisp.com/ )
* Esterel ( http://www.emn.fr/x-info/lego/ and
http://www.emn.fr/x-info/lego/esterel-tools/ )
* Lustre ( http://www.emn.fr/x-info/lego/ ) - The Lustre compiler is no
longer available at the link given on the Lustre page; it appears you now
have to go through
http://www-verimag.imag.fr/~raymond/tools/lv4-distrib.html to get it.
* Grafcet ( http://www.emn.fr/x-info/lego/ ) In French; doesn't appear to
be any software to download
* Lego.NET ( http://www.dcl.hpi.uni-potsdam.de/research/lego.NET/ ) -
Supports a subset of the Microsoft .NET Framework 2.0
Colibri ( http://opensource.se/colibri/ ) has some API's that could
potentially be incorporated. "Version 0.1.1 has a reentrant scheduler,
timer functions, advanced semaphores (enhanced POSIX style), interrupt
handling code, some h8 uart code and a small collection of generic data
types."
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?
Cheers,
Matthew
|
|
| |
> Hi all,
>
> This is great to see there's still some interest. I may not have
> opportunity to post over the next couple days, but I have created some
> patches against the latest Sourceforge CVS (as I believe there are a few
> differences between the CVS and the last release). I have an Open Document
> Spreadsheet detailing the patch changes (source, reason, etc.). When I get
> back, I'll try to upload the files somewhere.
>
> I had also been in the process of gathering and/or creating some patches
> against other BrickOS versions--there was an lnp_printf, lnp_reliable, some
> task-related (priority inheritance, scheduling, resources), realloc....
> After Bibo was released, I didn't pursue these as aggressively.
>
> I've been working with binutils 2.16.1 and gcc 3.4.6--I noticed the same
> disappearance in 2.17.
I think we need to stick with 2.16.1, I don't know whether porting brickos to
elf is really worth the trouble.
Newer gcc versions would be nice, indeed, and brickos also builds fine with
(some of?) these, but I never actually got it to run on the bricks when building
with anything newer than what we currently ship in Debian. If you gather some
patches and Stephen could try them out and gets it to work, I'd happily package
newer gcc versions. I think the problem always was some issue about BSS size - I
had fixed the ld script, but it didn't work anyway. Still, I might just have
been missing the proper patches.
Best,
Michael
|
|
| |
Hi all,
This is great to see there's still some interest. I may not have
opportunity to post over the next couple days, but I have created some
patches against the latest Sourceforge CVS (as I believe there are a few
differences between the CVS and the last release). I have an Open Document
Spreadsheet detailing the patch changes (source, reason, etc.). When I get
back, I'll try to upload the files somewhere.
I had also been in the process of gathering and/or creating some patches
against other BrickOS versions--there was an lnp_printf, lnp_reliable, some
task-related (priority inheritance, scheduling, resources), realloc....
After Bibo was released, I didn't pursue these as aggressively.
I've been working with binutils 2.16.1 and gcc 3.4.6--I noticed the same
disappearance in 2.17.
Cheers,
Matthew
|
|
| |
Stephen M Moraco wrote:
> In lugnet.robotics.rcx.legos, Michael Tautschnig wrote:
> > That's great news so far :-) Some time ago, however, I've tried to get brickOS
> > to run on those old h8300 bricks, but it only seemed to work when using an old
> > tool-chain (which is also the reason why the related packages never got upgraded
> > to newer versions in Debian).
> >
> > Unfortunately, I also don't have any access to bricks at the moment, so if
> > someone still has access to those bricks, it would be great if you could try out
> > Carl's patched packages. If it works out, I'd happily upgrade the Debian
> > tool-chain to newer versions!
From what I can tell, support for h8300-hitachi-hms(/coff) was dropped
from binutils after 2.16.1. I have no real idea how much work it would
take to port brickOS (plus brickemu, preferably) over to elf, but I
suspect that it'd be a lot. Still, I'll have a look at it to try to
at least figure out how long it might take me if I were to try. It'll
have to wait a bit though, because I have a major grant application due
in a few days, followed by a week-long visit by my mother.
> I'm encouraged by your efforts Carl and I don't have time to do the gcc work so
> Michael, I'd like to take you up on your offer. I do have two of the RCX bricks
> and a number of USB/IR towers and Linux machines. Carl, I've limited time so
> rather than applying the patches one by one to replicate the code base your
> using (which we _will_ have to do eventually) can you offer a ready to build
> code set? I'm only asking this to get a first test so we can prove/disprove
> that Michael does have something to work towards. That is that it does run so
> he can work on updating the toolset. What do you think? Other ideas welcome,
> too. I'm trying to enable us to get working without a larger time commitment
> for the time being...
>
> Sound reasonable?
It does indeed. The code with the 9 patches applied is now a tarball at
http://carl.troein.com/res/brickos_patches/brickos-carl-p09.tar.gz
> Again, I really appreciate the time both of you are (or will be ;-) spending!
And I appreciate the encouragement from both of you. :-)
Oh, and I had a look on eBay and found a complete RIS 2.0 that I'll place
a bid on. Mightn't be very expensive, and it can't hurt to have two sets
(especially when one of them resides in a box in a country far away)...
Cheers,
//Carl
|
|
| |
Michael, Carl,
In lugnet.robotics.rcx.legos, Michael Tautschnig wrote:
>
> That's great news so far :-) Some time ago, however, I've tried to get brickOS
> to run on those old h8300 bricks, but it only seemed to work when using an old
> tool-chain (which is also the reason why the related packages never got upgraded
> to newer versions in Debian).
>
> Unfortunately, I also don't have any access to bricks at the moment, so if
> someone still has access to those bricks, it would be great if you could try out
> Carl's patched packages. If it works out, I'd happily upgrade the Debian
> tool-chain to newer versions!
I'm encouraged by your efforts Carl and I don't have time to do the gcc work so
Michael, I'd like to take you up on your offer. I do have two of the RCX bricks
and a number of USB/IR towers and Linux machines. Carl, I've limited time so
rather than applying the patches one by one to replicate the code base your
using (which we _will_ have to do eventually) can you offer a ready to build
code set? I'm only asking this to get a first test so we can prove/disprove
that Michael does have something to work towards. That is that it does run so
he can work on updating the toolset. What do you think? Other ideas welcome,
too. I'm trying to enable us to get working without a larger time commitment
for the time being...
Sound reasonable?
Again, I really appreciate the time both of you are (or will be ;-) spending!
Best Regards,
Stephen
--
|
|
| |
[...]
> Hi Stephen, 2*Michael and others,
> I've (finally) started playing around with brickOS again. My RCX and
> almost all of my Lego is in storage a long long way from here, but
> that may actually be a good thing in this context.
>
> I've applied Jochen's patches and Rodolphe Pineau's OS X patch, fixed
> a few warnings with gcc 4.4, updated the doxygen stuff and added some
> code to count edges in the signals detected by sensors (useful for
> counting the number of times a touch sensor was pressed, even at tens
> of hertz or more - I used it to accurately measure the position along
> a long gear rack). I've gathered the patches at http://carl.troein.com/
>
> The documentation is in need of some loving care, but there's some
> other stuff I'd also like to play around with. We'll see how it goes.
That's great news so far :-) Some time ago, however, I've tried to get brickOS
to run on those old h8300 bricks, but it only seemed to work when using an old
tool-chain (which is also the reason why the related packages never got upgraded
to newer versions in Debian).
Unfortunately, I also don't have any access to bricks at the moment, so if
someone still has access to those bricks, it would be great if you could try out
Carl's patched packages. If it works out, I'd happily upgrade the Debian
tool-chain to newer versions!
Thanks for your efforts,
Michael
|
|
| |
Stephen M Moraco wrote:
> Carl,
>
> Welcome! If you have the time and the interest we welcome your
> spending time on this.
>
> As you can tell there has not been much activity here in a while... ;-(
Hi Stephen, 2*Michael and others,
I've (finally) started playing around with brickOS again. My RCX and
almost all of my Lego is in storage a long long way from here, but
that may actually be a good thing in this context.
I've applied Jochen's patches and Rodolphe Pineau's OS X patch, fixed
a few warnings with gcc 4.4, updated the doxygen stuff and added some
code to count edges in the signals detected by sensors (useful for
counting the number of times a touch sensor was pressed, even at tens
of hertz or more - I used it to accurately measure the position along
a long gear rack). I've gathered the patches at http://carl.troein.com/
The documentation is in need of some loving care, but there's some
other stuff I'd also like to play around with. We'll see how it goes.
Cheers,
//Carl
|
|
| |
In lugnet.robotics.rcx.legos, Matthew Sheets wrote:
> I don't know if this is would be of any help, as it uses a different
> approach, but I thought I'd pass it along anyway....
>
> Bi-directional Bluetooth to IR translator -
> http://www.robotics.sk/maine.php?page=/projects/rcxbt/
> (PDF format: http://www.robotics.sk/projects/rcxbt/rcxbt.pdf )
>
> While this solution doesn't allow both the serial and IR to be active like
> the method that has been discussed, the Bluetooth adapter communication can
> be throttled back to "2400-odd-1" (see PDF page 7). Might this
> communication configuration capability alleviate any of the present issues,
> or has the communication speed limitation related to the other Bluetooth
> adapter been overcome?
>
>
> Thanks,
> Matthew
Dear Matthew
I have found the problem. It was in kernel\lnp-locical.c
-> cheking the echo was the problem
solution: echo OFF
it is a rough solution, but it works
changes
1) rx_handler(void)
...
// echos of own bytes -> collision detection
//
// S_RDR //! serial receive data register
// !< tx_verify: ptr to next byte to verify
if(S_RDR!=*tx_verify) {
// //powo change we have no collision OK rs232 BT bf_flag=1;
if (bt_flag == 0) { // pow 0 infrared return with collision 1=comport bt
txend_handler(); // shutdown transmit and irqs, clear status flags
//tx_state=TX_COLL; //(-1) /!< not transmitting, last xmit was collision
tx_state=TX_COLL;
// if (bt_flag == 1) tx_state = TX_MIST; // pow error TX_COLL (-1)
}
and
-> echo OFF in function
2)
void reset_powo(void){
txend_handler();
tx_state=TX_RESET; //TX_RESET (-5)
}
static void rxerror_handler(void) {
..
time_t new_tx;
if(tx_state<TX_ACTIVE) {
//lnp_integrity_reset(); // pow geändert kein txend_handler();
reset_powo(); // //powo change we have no collision OK
new_tx = get_system_up_time()+lnp_byte_safe;
if (new_tx > allow_tx) allow_tx = new_tx;
} else {
txend_handler(); //
//tx_state=TX_COLL; //(-1)
tx_state=TX_ERROR; // (-2) // 1) TX_COLL_LNP_RESET (-4) //!<
lnp_integrity_reset
}
and in include\lnp\sys\lnp-logical.h
////#define POWO B2400
extern unsigned char test_bt_flag (void);
extern unsigned char bt_flag; // pow if 0 then infrared 1 bt oder com
extern unsigned char empfangs_byte ;
extern unsigned short lnp_logical_baud_rate;
extern unsigned short lnp_logical_parity;
extern unsigned short lnp_byte_safe;
extern unsigned short lnp_wait_txok;
extern unsigned short lnp_wait_coll;
the brick program
... snip
void baud4800() {
unsigned short lnp_byte_time = MSECS_TO_TICKS(3); //!< 4800 baud
unsigned short lnp_byte_timeout = (3*lnp_byte_time/2); //!< timeout waiting for a byte 4,5 ms
unsigned short lnp_byte_safe_temp = (4*lnp_byte_time); //!< delay before transmitting a byte 12
unsigned short lnp_wait_txok_temp = (2*lnp_byte_timeout); //!< delay after good transmit 9
unsigned short lnp_wait_coll_temp = (4*lnp_byte_timeout); //!< delay after collision 18
lnp_logical_baud_rate = B4800;
lnp_logical_parity = SMR_P_NONE;
lnp_byte_safe = lnp_byte_safe_temp;
lnp_wait_txok = lnp_wait_txok_temp;
lnp_wait_coll = lnp_wait_coll_temp;
}
...
void infrared_on() {
//! enable IR carrier frequency.
//extern inline void carrier_init(void) { }
T1_CR =0x9;
T1_CSR =0x13;
T1_CORA=0x1a;
}
void infrared_off() {
//! disable IR carrier frequency. // carrier_shutdown();
//extern inline void carrier_shutdown(void)
T1_CR =0;
T1_CSR =0;
}
int main ( int argc, char **argv ) {
....
lnp_logical_shutdown(); sleep(1);
baud4800();
lnp_logical_init();
infrared_off();
bt_flag=1; //NO echo tx ok
..
best regards Bernhard
|
|
| |
I don't know if this is would be of any help, as it uses a different
approach, but I thought I'd pass it along anyway....
Bi-directional Bluetooth to IR translator -
http://www.robotics.sk/maine.php?page=/projects/rcxbt/
(PDF format: http://www.robotics.sk/projects/rcxbt/rcxbt.pdf )
While this solution doesn't allow both the serial and IR to be active like
the method that has been discussed, the Bluetooth adapter communication can
be throttled back to "2400-odd-1" (see PDF page 7). Might this
communication configuration capability alleviate any of the present issues,
or has the communication speed limitation related to the other Bluetooth
adapter been overcome?
Thanks,
Matthew
|
|
| |
Hi,
Once again i am back about RCX and BT-Connection.
Receiving messages from the PC via BT to the RCX is OK.
But if I send messages from the RCX to the PC with 4800 Baud i get only 4 Bytes.
So I go back to 2400 Baud, forget BT and make a serial Connection via RS232 to
the PC.
Now i got only to bytes via rs232 in the pc.
1) I checked the result of the send procedure :
Oh i get -1: means tx/rx Collission
void SendInt()
{
int result;
unsigned char buf_integrity[8];
buf_integrity[0] = 'A';
buf_integrity[1] = 'B'; // no more will be send
buf_integrity[2] = 'C';
buf_integrity[3] = 'D';
buf_integrity[4] = 'E';
buf_integrity[5] = 'F';
buf_integrity[6] = 'G';
buf_integrity[7] = 'H';
result = lnp_integrity_write( buf_integrity, sizeof(buf_integrity));
lcd_digit(RxNr);
lcd_int(result);
RxNr++;
if (RxNr > 9) RxNr=0;
}
I remember about the thread 4018 from Claude Baumann
I take a camera (you can see if the IF-leds on the rcx are flickering if TX) and
I see: the rcx is tx via the IF-leds.
I don't know why i get the tx signal back to rx pin, because i have cut the
receiverline in the rcx (IR-Receiver rx pin)
as shown http://www.convict.lu/Jeunes/RCXCam/RCXCam_Journal.htm
in the main program i do now:
cputs("if--") ; sleep(1);
//! disable IR carrier frequency. // carrier_shutdown();
//extern inline void carrier_shutdown(void)
T1_CR =0;
T1_CSR =0;
// --------------- does not work ----------------------------
// and set the port6<7> pin LOW. Now the upper PNP
//transistor isn't conducting anymore.
// Port Bit Description Notes
// 6 7 Infrared carrier (TMO1) 26µs square wave
cputs("pt67") ; sleep(1);
cputw(PORT6); sleep(2);
cputs("cler") ; sleep(1);
bit_clear(&PORT6,7); sleep(1);
cputw(PORT6); sleep(1);
any suggest?
Bernhard
|
|
| |
Dear Claude
In lugnet.robotics.rcx.legos, Claude Baumann wrote:
> In lugnet.robotics.rcx.legos, Bernhard Powolny wrote:
> > http://www-date.uni-paderborn.de/pub/people/dasas/Beh03.pdf
>
> I can't find it anymore neither.
A: Thank you for finding the PDF.
> > Then i have done as it is discriped in
> > http://www.convict.lu/Jeunes/RCXCam/RCXCam_Journal.htm
> > but i dont understand realy why we should do that?
> >
> > 1) To correctly use the H8 TX line with the CMUCam2 module, the driving RCX
> > software MUST shut down the 38kHz carrier
> >
> > like :
> >
> > void infrared_off() {
> > //! disable IR carrier frequency. // carrier_shutdown();
> > //extern inline void carrier_shutdown(void)
> > T1_CR =0;
> > T1_CSR =0;
> > }
>
> The carrier should be quiet in any case, because it disturbs the TX signal.
>
> > and
> > 2)set the port6<7> pin LOW. Now the upper PNP transistor isn't conducting
> > anymore.
> >
> > FOR WHAT reason...
>
> We tried this,but it didn't work. Why, because the transistor will drain some
> current, if the emitter has positive voltage and the base goes low. If the
> carrier is off, and by accident you set long range, then you have the chance to
> repeat what I did: kill a couple of infrared LEDs. Don't forget that they are
> driven at high current, but under the condition of a 50% duty cycle that is
> guaranteed by the carrier. If you shut down the timer, then the pin is high or
> low - the timer stops and you don't know the actual port6<7> state -
>
> If you have short range, the LEDs will rapidly heat also and only burn after a
> while. So, if your IR-TX doesn't work anymore... check you LEDs.
A: I will check ( measure the Voltage on the IF LEDS) should be approx. 9V
betweem LED and Transistor if everything is off.
> > But how managed the people from to http://www.convict.lu/Jeunes/RCXCam/RCXCam_Journal.htm
> > do it ????
>
> With the CMUCam2 everything works fine, even at 19600 as I said.
> > .
A: Now i had success . It works.
> >
> > more snap from the http://www.convict.lu/Jeunes/RCXCam/RCXCam_Journal.htm
> > It is important to add a 100k pull-up resistor to the TX line !!! Otherwise the
> > TX voltage will drop down to 0.45V it
>
> Pulling up the TX line IS necessary-at least with the CMUCam2, because the RX of
> this device is not pulled up.
I have allready done it.
>
> No idea, why it should not work. We have run our the CMUCam2 for hours at many
> occasions. We rebuilt the whole thing with another RCX, that we sent to Tufts
> Univ. They successfully played with the stuff.
A:Ok Now it works
best regards
Bernhard
|
|
| |
Dear Matthew
> * So if I understand these posts correctly, 4800 baud now works with the IR
> connection and not just with the hardware hack?
A: Now it works with 4800 baud via bluetoothconnection .
There was a couple of Problems.
1) At first i tried with the USB Tower but i coult only swith to 4800 bauds but
there is no possibilty to change parity.
2) With the serial Tower i could change ti 4800 baud an no parity but i used on
the laptop a USB to Serial converter. Maybe this is the problem. I'm not sure.
3) a)Now a load the "normal 2400 baud + paritiy" brickos 0.9.0 Software with the
USB Tower down to the RCX.
b) Download the SW witch switch the baudrate 4800 doen to the RCX.
c) Start the SW on the RCX and witch send and receive messages and i had succes
with the Serial Bluetooth.
YES it works now.
> *A couple posts from Dick Swan in the earlier thread noted the differences
> in "IR transceiver" chips between RCX 1.0 and 2.0--will the software updates
> work @ 4800 baud with a 1.0 RCX, or does this need to be tested?
A: The only difference bwtween 1.0 and 1.5 to 2.0 RCX is the IR receiver chip on
the RCX
RXC1.0 use 38hkz carrier and the RCX 1.5 2.0 use 76.khz carrier witch gives a
better solution for 4800 khz but you can't change parity on the Infrared TOWER
SW on the PC..
> * In your final implementation, does the Bluetooth module communicate with
> the RCX via IR ( as seems to be described in • A: Yes
>
http://www.tik.ee.ethz.ch/~beutel/projects/sada/2002ss_erni_reichmuth_presentation.pdf
)
> , or did you connect the Bluetooth module via the hacked serial port?
A: I connect the Bluetooth module via hacked serial port ( oh my dear you need
good eyes, a tiny solerding iron and a quiet room to do the hardware hack, dont
allow that your wife or kids comes in). But now i have done the hardware change
to my two RCX's 1.5 and 2.0.
> * Are the changes to lnphost available as a patch?
A: Yes it's till now more experimental, but it works.
writen in visual C 2005
best regards
Bernhard
|
|
| |
In lugnet.robotics.rcx.legos, Bernhard Powolny wrote:
> http://www-date.uni-paderborn.de/pub/people/dasas/Beh03.pdf
I can't find it anymore neither.
> Then i have done as it is discriped in
> http://www.convict.lu/Jeunes/RCXCam/RCXCam_Journal.htm
> but i dont understand realy why we should do that?
>
> 1) To correctly use the H8 TX line with the CMUCam2 module, the driving RCX
> software MUST shut down the 38kHz carrier
>
> like :
>
> void infrared_off() {
> //! disable IR carrier frequency. // carrier_shutdown();
> //extern inline void carrier_shutdown(void)
> T1_CR =0;
> T1_CSR =0;
> }
The carrier should be quiet in any case, because it disturbs the TX signal.
> and
> 2)set the port6<7> pin LOW. Now the upper PNP transistor isn't conducting
> anymore.
>
> FOR WHAT reason...
We tried this,but it didn't work. Why, because the transistor will drain some
current, if the emitter has positive voltage and the base goes low. If the
carrier is off, and by accident you set long range, then you have the chance to
repeat what I did: kill a couple of infrared LEDs. Don't forget that they are
driven at high current, but under the condition of a 50% duty cycle that is
guaranteed by the carrier. If you shut down the timer, then the pin is high or
low - the timer stops and you don't know the actual port6<7> state -
If you have short range, the LEDs will rapidly heat also and only burn after a
while. So, if your IR-TX doesn't work anymore... check you LEDs.
> But how managed the people from to http://www.convict.lu/Jeunes/RCXCam/RCXCam_Journal.htm
> do it ????
With the CMUCam2 everything works fine, even at 19600 as I said.
> .
>
> more snap from the http://www.convict.lu/Jeunes/RCXCam/RCXCam_Journal.htm
> It is important to add a 100k pull-up resistor to the TX line !!! Otherwise the
> TX voltage will drop down to 0.45V it
Pulling up the TX line IS necessary-at least with the CMUCam2, because the RX of
this device is not pulled up.
No idea, why it should not work. We have run our the CMUCam2 for hours at many
occasions. We rebuilt the whole thing with another RCX, that we sent to Tufts
Univ. They successfully played with the stuff.
|
|
| |
Glad to hear it is working--thank you for the update. If I may ask, I have
a few questions--
* So if I understand these posts correctly, 4800 baud now works with the IR
connection and not just with the hardware hack?
*A couple posts from Dick Swan in the earlier thread noted the differences
in "IR transceiver" chips between RCX 1.0 and 2.0--will the software updates
work @ 4800 baud with a 1.0 RCX, or does this need to be tested?
* In your final implementation, does the Bluetooth module communicate with
the RCX via IR ( as seems to be described in
http://www.tik.ee.ethz.ch/~beutel/projects/sada/2002ss_erni_reichmuth_presentation.pdf )
, or did you connect the Bluetooth module via the hacked serial port?
* Are the changes to lnphost available as a patch?
Thank you,
Matthew
P.S. I was able to find one of the "dead link" documents at archive.org -
http://web.archive.org/web/20051207031919/http://www-date.uni-paderborn.de/pub/people/dasas/Beh03.pdf .
Like a couple of the other documents listed in these threads, it is in
German.
|
|
| |
Hi
I have implemented the stuff
// and set the port6<7> pin LOW. Now the upper PNP transistor isn't conducting
anymore.
Now TX and RX works
Here are the program
#include <lnp.h>
#include <conio.h>
#include <string.h>
#include <lnp-logical.h>
#include <dkey.h>
#include <dsound.h>
#include <sys/lnp-logical.h>
#include <sys/lnp.h>
#include <sys/h8.h>
#include <dkey.h>
#define MY_PORT 2
#define DEST_HOST 0x8
#define DEST_PORT 0x7
#define DEST_ADDR ( DEST_HOST << 4 | DEST_PORT ) // rcx0
#define SENDBUFF 25
unsigned char buf[SENDBUFF];
unsigned char len = 3;
unsigned char receive_buffer[5];
static const note_t rx[] = {
{ PITCH_C5, 1 } , { PITCH_D5, 1 } ,{ PITCH_E5, 1 } ,{ PITCH_END, 0 }
};
wakeup_t prgmKeyCheck(wakeup_t data)
{
return dkey == KEY_PRGM;
}
/*
void packet_handler_add(const unsigned char* data,unsigned char length, unsigned
char src)
{
// ++rx_count;
}
*/
void baud2400() {
unsigned short lnp_byte_time = MSECS_TO_TICKS(5); //!< 2400
baud
unsigned short lnp_byte_timeout = (3*lnp_byte_time/2); //!< timeout waiting for a byte
unsigned short lnp_byte_safe_temp = (4*lnp_byte_time); //!< delay before transmitting a b yte
unsigned short lnp_wait_txok_temp = (2*lnp_byte_timeout); //!< delay after good transmit
unsigned short lnp_wait_coll_temp = (4*lnp_byte_timeout); //!< delay after collision
lnp_logical_baud_rate = B2400;
lnp_logical_parity = SMR_P_ODD;
lnp_byte_safe = lnp_byte_safe_temp;
lnp_wait_txok = lnp_wait_txok_temp;
lnp_wait_coll = lnp_wait_coll_temp;
}
void baud4800() {
unsigned short lnp_byte_time = MSECS_TO_TICKS(3); //!< 4800 baud
unsigned short lnp_byte_timeout = (3*lnp_byte_time/2); //!< timeout waiting for a byte
unsigned short lnp_byte_safe_temp = (4*lnp_byte_time); //!< delay before transmitting a b yte
unsigned short lnp_wait_txok_temp = (2*lnp_byte_timeout); //!< delay after good transmit
unsigned short lnp_wait_coll_temp = (4*lnp_byte_timeout); //!< delay after collision
lnp_logical_baud_rate = B4800;
lnp_logical_parity = SMR_P_NONE;
lnp_byte_safe = lnp_byte_safe_temp;
lnp_wait_txok = lnp_wait_txok_temp;
lnp_wait_coll = lnp_wait_coll_temp;
}
void infrared_on() {
//! enable IR carrier frequency.
//extern inline void carrier_init(void) { }
T1_CR =0x9;
T1_CSR =0x13;
T1_CORA=0x1a;
}
// doesnt work well with usb tower
void infrared_on76khz() {
//! enable IR carrier frequency.
//extern inline void carrier_init(void) { }
T1_CR =0x9;
T1_CSR =0x13;
// change it to76 KHz setting T1_CORA to 0x0D instead of 0x1A.
T1_CORA=0x0D;
}
void infrared_off() {
//! disable IR carrier frequency. // carrier_shutdown();
//extern inline void carrier_shutdown(void)
T1_CR =0;
T1_CSR =0;
}
void packet_handler_integrity(const unsigned char* data,unsigned char length)
{
dsound_system(DSOUND_BEEP);//DSOUND_SYS_MAX
// cputs(data);
}
void SendInt(int i)
{
int result,i;
for (i=0; i<SENDBUFF; i++ ){
buf[i] = 'U';
}
buf[0] = 'A';
buf[1] = 'B';
buf[2] = 'C';
// result = lnp_addressing_write( buf, sizeof(buf), DEST_ADDR, MY_PORT);
result = lnp_logical_write( buf, sizeof(buf));
// result = lnp_integrity_write(data,len);
// msleep(500);
// result = lnp_integrity_write( buf, sizeof(buf));
}
int main ( int argc, char **argv )
{
int result,i;
int c=48;
cputs("down") ; sleep(1);
//! Shutdown the logical layer (IR port)
lnp_logical_shutdown(); sleep(1);
// change Baudrate to 4800
cputs("4800") ; sleep(1);
baud4800(); sleep(1);
cputs("init") ; sleep(1);
lnp_init(); sleep(1);
//! Initialize the logical layer (IR port)
lnp_logical_init(); sleep(1);
// infrared carrier off
// To correctly use the H8 TX line with the CMUCam2 module,
// the driving RCX software MUST shut down the 38kHz carrier
cputs("if--") ; sleep(1);
infrared_off(); sleep(1);
// and set the port6<7> pin LOW. Now the upper PNP transistor isn't
conducting anymore.
cputs("pt67") ; sleep(1);
cputw(PORT6); sleep(2);
cputs("cler") ; sleep(1);
bit_clear(&PORT6,7); sleep(1);
cputw(PORT6); sleep(1);
cputs("baud") ; sleep(2);
lcd_int(lnp_logical_baud_rate); sleep(2);
// lnp_addressing_set_handler_add(MY_PORT, packet_handler_add);
lnp_integrity_set_handler( packet_handler_integrity);
//lnp_logical_range (0 );
cputs("baud") ; sleep(1);
lcd_int(lnp_logical_baud_rate); sleep(1);
cputs("run") ; sleep(2);
while( 1 ) {
if( prgmKeyCheck( 0 ) ){
dsound_system(DSOUND_BEEP);//DSOUND_SYS_MAX
baud2400(); sleep(1);
bit_set(&PORT6,7); sleep(1);
infrared_on(); sleep(1);
break;
}
SendInt( c );
lcd_int(c-48); msleep(500);
c++;
if (c >= 48+10 ) c =48;
cputs("baud") ; sleep(1);
lcd_int(lnp_logical_baud_rate); sleep(1);
}
// infrared_off(); cputs("if--") ; sleep(3);
// infrared_on(); cputs("if38") ; sleep(3);
cputs ( "done" );
sleep(2); // show done for 2 sec then clear display...
lcd_clear();
return 0;
}
by the way. I have written a DLL for the Infrared Tower based on the C program
called. lnphost
by
Bernhard
|
|
| |
Hi
As allready described in a other thread i have build a bluetoothconnection
between pc and the RCX.
There is one thing that the serial bluetooth is only available to tx/rx with a
minimum from 4800 baud.
At first i compiled brickos 0.9.0 with
#define CONF_LNP_FAST //!< enable 4800 bps LNP in boot/config.h and
util/dll-src
Downlad of brickos.srec was successfull but i had allmost no success to download
the programs with 4800 baud.
Maybe it is the usb to serial coverter for the serial Tower.
The usb tower has no option for that in standart dll. ( Only with c++ pn Windows
but there is no feature to define the
parity bit)
So i changed the kernel and write a program to switch from the rcx from 2400 to
4800 baud.
This was sucessfull.
brickos:
include\lnp\sys\lnp-locigal.h
extern unsigned short lnp_logical_baud_rate;
extern unsigned short lnp_logical_parity;
extern unsigned short lnp_byte_safe;
extern unsigned short lnp_wait_txok;
extern unsigned short lnp_wait_coll;
kernel\lnp-locigal.c
unsigned short lnp_logical_baud_rate=LNP_LOGICAL_BAUD_RATE; // ok
unsigned short lnp_logical_parity =LNP_LOGICAL_PARITY;
unsigned short lnp_byte_safe = LNP_BYTE_SAFE;
unsigned short lnp_wait_txok = LNP_WAIT_TXOK;
unsigned short lnp_wait_coll = LNP_WAIT_COLL;
change:
S_MR =lnp_logical_parity;
S_BRR=lnp_logical_baud_rate;
and so on for safe txok and coll
rcx program:
#include <lnp.h>
#include <lnp-logical.h>
#include <sys/lnp-logical.h>
#include <sys/lnp.h>
#include <sys/h8.h>
void baud2400() {
unsigned short lnp_byte_time = MSECS_TO_TICKS(5); //!< 2400
baud
unsigned short lnp_byte_timeout = (3*lnp_byte_time/2); //!< timeout waiting for a byte
unsigned short lnp_byte_safe_temp = (4*lnp_byte_time); //!< delay before transmitting a b yte
unsigned short lnp_wait_txok_temp = (2*lnp_byte_timeout); //!< delay after good transmit
unsigned short lnp_wait_coll_temp = (4*lnp_byte_timeout); //!< delay after collision
lnp_logical_baud_rate = B2400;
lnp_logical_parity = SMR_P_ODD;
lnp_byte_safe = lnp_byte_safe_temp;
lnp_wait_txok = lnp_wait_txok_temp;
lnp_wait_coll = lnp_wait_coll_temp;
}
void baud4800() {
unsigned short lnp_byte_time = MSECS_TO_TICKS(3); //!< 4800 baud
unsigned short lnp_byte_timeout = (3*lnp_byte_time/2); //!< timeout waiting for a byte
unsigned short lnp_byte_safe_temp = (4*lnp_byte_time); //!< delay before transmitting a b yte
unsigned short lnp_wait_txok_temp = (2*lnp_byte_timeout); //!< delay after good transmit
unsigned short lnp_wait_coll_temp = (4*lnp_byte_timeout); //!< delay after collision
lnp_logical_baud_rate = B4800;
lnp_logical_parity = SMR_P_NONE;
lnp_byte_safe = lnp_byte_safe_temp;
lnp_wait_txok = lnp_wait_txok_temp;
lnp_wait_coll = lnp_wait_coll_temp;
}
I have done also the Hardware hack from
http://www.convict.lu/Jeunes/RCXCam/RCXCam_Journal.htm
I search for the orignal hack but the link is dead
http://www-date.uni-paderborn.de/pub/people/dasas/Beh03.pdf
Then i have done as it is discriped in
http://www.convict.lu/Jeunes/RCXCam/RCXCam_Journal.htm
but i dont understand realy why we should do that?
1) To correctly use the H8 TX line with the CMUCam2 module, the driving RCX
software MUST shut down the 38kHz carrier
like :
void infrared_off() {
//! disable IR carrier frequency. // carrier_shutdown();
//extern inline void carrier_shutdown(void)
T1_CR =0;
T1_CSR =0;
}
and
2)set the port6<7> pin LOW. Now the upper PNP transistor isn't conducting
anymore.
FOR WHAT reason i should do that. Maybe because the TX pin of the hitachi can
only drive only 1 TTL Load and a 30pf
load?? it is descriped in the HW Manual for the Hitachi CPU on page 104.
I try to do that without clear the bit 7 on port 6. and with infrared on.
I can receive data in the RCX from the pc via usb bluetooth serial connection
(4800 Baud) as described above
but
transmit data from RCX to Bluetooth module and further to the pc i got only
carbage.
I checked the TX Pin on the RCX with an osziloscope and it looks like the port
is a very sensible to an additional
LOAD. Also on the TX pin there is a carrier of 38Khz (level between 1 Volt means
the voltage is switching something
between 3 till 4 Volt ) .. Interesting..
Example:
If i want to load a program on the RCX and i don not disconnect the TX port to
the RX Port of the Bluetoothmodule, its
allmost impossible do do an download from the Infrared Tower to the RCX.
(I think TX signal breaks down for the resistance or capacative Load). I use the
same curcuit as desribed on the
page http://www.convict.lu/Jeunes/RCXCam/RCXCam_Journal.htm
But how managed the people from to http://www.convict.lu/Jeunes/RCXCam/RCXCam_Journal.htm
do it ????
.
more snap from the http://www.convict.lu/Jeunes/RCXCam/RCXCam_Journal.htm
It is important to add a 100k pull-up resistor to the TX line !!! Otherwise the
TX voltage will drop down to 0.45V it
won't be possible to set up a correct connection. (We do this on the CMUCam2
connector, since a 5V pin exists.)
I have done this hardware .
Maybe I missed something . Has somebody allready has expirience in general about
the RCX hack for RX/TX ?
best regards
Bernhard
|
|
| |
> by Bernhard
I have found the thread,
its in http://news.lugnet.com/robotics/rcx/?n=1825&t=i&v=a
There is a also a 2 thread in
http://www.line.to/mac/MindStorms/JoyBricx/index-e.html
concernig the usb tower dll.
and a c program called
joybricxsrc.zip
I looked short in the header files
LEGOUSBTowerioctl.h
and there is a posibility to set the
speed
#define LT_CAPS_SPEED_BPS_300 LT_SPEED_BPS_300
#define LT_CAPS_SPEED_BPS_600 LT_SPEED_BPS_600
#define LT_CAPS_SPEED_BPS_1200 LT_SPEED_BPS_1200
#define LT_CAPS_SPEED_BPS_2400 LT_SPEED_BPS_2400
#define LT_CAPS_SPEED_BPS_4800 LT_SPEED_BPS_4800
#define LT_CAPS_SPEED_BPS_9600 LT_SPEED_BPS_9600
#define LT_CAPS_SPEED_BPS_19200 LT_SPEED_BPS_19200
#define LT_CAPS_SPEED_BPS_38400 LT_SPEED_BPS_38400
I will see what i can do.
|
|
| |
.Sorry for the delay
Now i am in italy , triest. so i just do a short look in the messages.
Thanks for the answers.
In meantime i recogmised too that there is no serial baud rate change in the dll
for the usb.
I think i have something at home what i have downloaded in the past from a
japanese webside called like joybrick. I dont remember now exactlly the name and
the features, but. there are a lot of sw adjustments for the usbtower dll like
carrier frequency and so on..
However i can use the old serial tower, but usally i use the notebook and that
new one has only usb devices . Ok however there is a possibility to use the usb
to serial adapter ( if it is 100% compatible)
Ok in short i am back next week on monday so i will take a look at usb tower dll
driver.
by Bernhard
|
|
| |
Somewhere in the bowels of the header files within the RCX SDK is a list of
"IODEVICE control commands" which does include description of messages
required to change baud rate on the USB tower. I am assuming you're not
using the LEGO Windows DLL which has an easier interface to use.
It's quite a while since I "played" with this code. But I did have 4800
working fine with USB tower as long as you had the complimentary version of
the RCX. Once I started using AC adaptor RCX version almost exclusively, I
pretty much stopped using it.
The other thing you'll find if you using "fast" download mode and avoiding
the "double byte" transmission is that messages with a significant inbalance
of ones or zeroes won't work so well. There's not enough transitions bit
transitions for the serial port hardware to recover / sync to a proper
clock. I "solved" that particular problem by dynamically adjusting the size
of the download packet if it looked like the bits were "unbalanced". The
header bytes (0x55, 0xFF and 0x00) were enough to periodically allow the
clock syncing.
-----Original Message-----
From: news-gateway@lugnet.com [mailto:news-gateway@lugnet.com] On Behalf Of
Jochen Hoenicke
Sent: Wednesday, April 30, 2008 7:51 AM
To: lugnet.robotics.rcx.legos@lugnet.com
Subject: Re: brickos 090 problem no program download with CONF_LNP_FAST
<<snip>>
I just checked the source code. There is no speed setting for usb
tower in the code. If you look into firmdl3 you also find that fast
mode is disabled for USB, because it doesn't work. I think the USB
tower sends at 2400 baud and there is no known way to change it.
Remember that 4800 baud mode was never used by the official LEGO
firmware or download programs.
I have no idea how you can change baud rate (is this even possible?)
or carrier frequency on the USB tower. AFAIK the transmit carrier
frequency on the RCX is set by carrier_init in lnp-logical.c to 38
KHz. If I understand Dick Swan's post right, one should change it to
76 KHz for RCX 2.0. I think it should be possible by setting T1_CORA
to 0x0D instead of 0x1A.
Best regards,
Jochen
--
Jochen Hoenicke, http://hoenicke.ath.cx/rcx/
|
|
| |
Hello Bernhard,
>
> 4) using now the serial tower
>
> download a program with dll 2400 to rcx using the brickOS.srec 2400
> sucess
> download a program with dll 4800 to rcx using the brickOS.srec 2400
> no sucess
>
> download a program with dll 2400 to rcx using the brickOS.srec 4800
> no sucess
> download a program with dll 4800 to rcx using the brickOS.srec 4800
> no sucess
>
> interesting because i thing there must be a option to change the usb tower to
> 4800 baud but how ?
I just checked the source code. There is no speed setting for usb
tower in the code. If you look into firmdl3 you also find that fast
mode is disabled for USB, because it doesn't work. I think the USB
tower sends at 2400 baud and there is no known way to change it.
Remember that 4800 baud mode was never used by the official LEGO
firmware or download programs.
I have no idea how you can change baud rate (is this even possible?)
or carrier frequency on the USB tower. AFAIK the transmit carrier
frequency on the RCX is set by carrier_init in lnp-logical.c to 38
KHz. If I understand Dick Swan's post right, one should change it to
76 KHz for RCX 2.0. I think it should be possible by setting T1_CORA
to 0x0D instead of 0x1A.
Best regards,
Jochen
--
Jochen Hoenicke, http://hoenicke.ath.cx/rcx/
|
|
| |
You should scan for some old posts by either John Barnes or Philo concerning
the different "IR transceiver" chips used between RCX 1.0 and 2.0 and
between serial vs USB towers. As I recall:
Serial tower can only transmit 38 KHz carrier. It's IR receiver is optimized
for 38 KHz.
USB tower can be set to either use 38 or 76 KHz transmission. Depending on
the application you use, the setting for this may not be exposed in an
interface. The IR receiver chip is optimized for 76 KHz carrier.
RCX 1.0 (i.e. the one with AC adaptor jack) uses same 38 KHz receiver as
serial tower. RCX 2.0 uses the same one as in the USB tower.
Due to harmonics, a IR receiver for one of the two carriers will generally
receive the other carrier frequency.
For best operation, you want to use a matched set where the transmitted
carrier frequency is the same as the IR receiver chip.
For completeness, I've tried to also use 9600 baud transmission. It simply
didn't work. The USB tower does not allow specification of this baud rate so
you have to use the serial tower. Unfortunately, it's fixed at a 38 KHz
carrier frequency which is not high enough for reliable transmission at 9600
as receiver chips need to get at least six carrier "cycles" per bit
transmitted.
|
|
| |
> Hello Jochen
> Solutions:
>
> 1)Try the old serial tower.
Now i have success !
!) i made to directorys
brickos-0.9.0_orig
with //#ifdef CONF_LNP_FAST
in /boot/config.h
and
util/dll-src/config.h
and
brickos-0.9.0_pat48
with #ifdef CONF_LNP_FAST
in /boot/config.h
and
util/dll-src/config.h
2) compile all
3) download the 2 brickOS.srec file to 2 rcx's
4) using now the serial tower
download a program with dll 2400 to rcx using the brickOS.srec 2400
sucess
download a program with dll 4800 to rcx using the brickOS.srec 2400
no sucess
download a program with dll 2400 to rcx using the brickOS.srec 4800
no sucess
download a program with dll 4800 to rcx using the brickOS.srec 4800
no sucess
interesting because i thing there must be a option to change the usb tower to
4800 baud but how ?
> best regard
> Bernhard
|
|
| |
Hello Jochen
At first i was astonished, that somebody is answering
so fast, because in the last 2 years there is not much conversation here.
> You're trying this still with standard hardware and standard dll-src,
I am not completly shure about your question concerning standart HW. I use the
USB Tower and the RCX2.0 for this tests because for the 76 Khz IR-modulation at
the tower and the ir receiver in the rcx.
I use standart sw 090 version.
I activate the CONF_LNP_FAST option in boot/config.h
...
// networking services
//
#define CONF_LNP //!< link networking protocol
#define CONF_LNP_FAST //!< enable 4800 bps LNP
// Can override with compile-time option
#if !defined(CONF_LNP_HOSTADDR)
#define CONF_LNP_HOSTADDR 0 //!< LNP host address
#endif
....
This change the baudrate, parity and bytetimes in include\lnp\sys\lnp-logical.h
....
#ifdef CONF_LNP_FAST
#define LNP_LOGICAL_BAUD_RATE B4800 //!< baud rate
#define LNP_LOGICAL_PARITY SMR_P_NONE //!< parity
#define LNP_BYTE_TIME MSECS_TO_TICKS(3) //!< time to transmit a byte
#else
.....
Intersting is, that for the dll program loader there exists a more or less
eaquel config.h file. Interesting is, that i never have heard something about
that config file on the internet.
util\dll-src\config.h
Here i have made for testing after i hade no sucess for download the program the
same changes.
....
// networking services
//
#define CONF_LNP //!< link networking protocol
//#define CONF_LNP_VIS //!< display LNP activity
#define CONF_LNP_FAST //!< enable 4800 bps LNP
#define CONF_LNP_HOSTADDR 0x8 //!< LNP host address
#define CONF_LNP_HOSTMASK 0xf0 //!< LNP host mask
....
> right? Otherwise, check that you use the right baud-rate and parity
> settings (4800, no parity bit, 1 start, 1 stop bit).
>
> In my experience the IR-communication doesn't work that well,
> especially in 4800 baud mode. It is mainly the PC that does not
> understand the RCX correctly. Try running dll-src with "-v" to get
> more information. Sometimes the PC receives part of the reply but
> there are some broken or missing bytes so the reply is just ignored.
Now i made the tests.
1) download the changed (4800) kernel to the rcx
2) Send a simple hello program to the rcx and get this :
/brickos-0.9.0_pat48/A_test send_hello_usb.sh
Hary Mahesan - LEGO USB IR Tower Mode
opening tty...
KeepAlive Init...
KeepAliveSend: keeping the IR tower alive...
LNP Initialized...
loader hostaddr=0x00 hostmask=0xf0 portmask=0x00
#time 3913531404 try 0: ack:0
try 1: ack:0
try 2: ack:0
try 3: ack:0
try 4: ack:0
error setting IR mode to far
But now i made a crazy try.
1) load down the original kernel (2400) to the rcx.
and tried to send once again the program with the change in
util\dll-src\config.h == set 4800 baud
and
/brickos-0.9.0_pat48/A_test send_hello_usb.sh
Hary Mahesan - LEGO USB IR Tower Mode
opening tty...
KeepAlive Init...
KeepAliveSend: keeping the IR tower alive...
LNP Initialized...
loader hostaddr=0x00 hostmask=0xf0 portmask=0x00
#time 23948733 f1 03 80 00 00 73
deletef1 03 80 00 00 73
create f1 0a 80 00 00 01 be 40 be 7e be 7e f1
data
#time 228000 f1 03 80 00 00 73
SUCCESS
-----------------------------------------------------
Now i made a filediff from
original
C:\cygwin\brickos-0.9.0_pat48\util\dll.exe RENAMED to dll2400.exe
compiled with the config.h option (2400)
//#define CONF_LNP_FAST //!< enable 4800 bps LNP
and the the second compilation option (4800) of dll with
#define CONF_LNP_FAST //!< enable 4800 bps LNP
dll.exe RENAMED to dll4800.exe
There is a difference in the files. I used the Ultraedit for that check.
So i am not shure what it is.
Solutions:
1)Try the old serial tower.
2) Use the hard way : Take a 38 khz IR receiver and check the data with a
osciloscope.
3) try to change the kernel that i can change baudrate/ paritiy in some timings
at runtime of the rcx.
Hard way stop the taskmanagment , change serial parameters and start once again
the whole LNP stuff.
But however there is guarantie that it works.
Maybe there are other option and i am free for all sugestions.
best regard
Bernhard
|
|
| |
Hello Powolny,
>
> I build allready a bluetooth connection between the pc and the rcx . The
> bluetooth module (BTM-222) supports the spp serial protocoll only
for 4800 or
> higher baudrates. But it is cheap in comparsion to other ones.
Costs about 14
> Euros.
sounds interesting...
> Now i tried to compile brickos 090 with the
>
> #define CONF_LNP_FAST //!< enable 4800 bps LNP
>
> option in
> boot/config.h
> [...]
> util/dll-src/config.h
>
> and recompile the whole stuff
>
> but no success too. Same error with download the program with dll
You're trying this still with standard hardware and standard dll-src,
right? Otherwise, check that you use the right baud-rate and parity
settings (4800, no parity bit, 1 start, 1 stop bit).
In my experience the IR-communication doesn't work that well,
especially in 4800 baud mode. It is mainly the PC that does not
understand the RCX correctly. Try running dll-src with "-v" to get
more information. Sometimes the PC receives part of the reply but
there are some broken or missing bytes so the reply is just ignored.
I think LNP_FAST mode is not tested very often. There may also be a
stupid bug in brickOS code that prevents communication.
Regards,
Jochen Hoenicke
--
Jochen Hoenicke, http://hoenicke.ath.cx/rcx/
|
|
| |
Hi
I build allready a bluetooth connection between the pc and the rcx . The
bluetooth module (BTM-222) supports the spp serial protocoll only for 4800 or
higher baudrates. But it is cheap in comparsion to other ones. Costs about 14
Euros.
Look here if you are interested:
http://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=364530&highlight=
The connection between the bt module and the rcx is based on the homemade serial
tower curcuit from
http://www.tik.ee.ethz.ch/~beutel/projects/sada/2002ss_erni_reichmuth_presentation.pdf
Now i tried to compile brickos 090 with the
#define CONF_LNP_FAST //!< enable 4800 bps LNP
option in
boot/config.h
under cygwin/XP and download the brickOS.srec with the lego usb tower and
BricxCC to the rcx.
If i want to download a program via BricxCC or in cygwin using the dll downlaod
i have no success.
I get the usual message: error deleting program .
Then i tried to change the dll for programdownload.
in util/dll-src/config.h
i do the same like in boot/config.h
marked out the 2 slashes //#define CONF_LNP_FAST
#define CONF_LNP_FAST //!< enable 4800 bps LNP
and recompile the whole stuff
but no success too. Same error with download the program with dll
Now i changed the config.h
in /boot
and
util/dll-src/config.h
back to the original configuration ( //#define CONF_LNP_FAST )
and recompiled once again.
Downlaod brickOS.srec
and
download a program .
Success as it was before the change.
Does anybody knows a reason for that problem that i canot download a program with the CONF_LNP_FAST option ?
Bernhard
|
|
| |
> Any suggestion for me to bring the RCX kit back to live?
Just buy a USB to Serial adaptor and use your Serial Tower if you can't find a
USB Tower for sale anywhere. They're not very expensive and work fine. Many
new desktop PC's done have serial ports these days.
Dom
|
|
| |
In lugnet.robotics.rcx.legos, Chun Sing Kwok wrote:
> Guys,
>
> Just retrieved my (dusted) RCX kit & a few spybots, when I move things
> around, unfortunately, my notebook does not have serial port any more.
> Moreover, the CD does not support XP either.
If your IR tower still functions, and it's just a matter of not having a serial
port, the simplest solution would be to just buy an adapter that will allow you
to hook up a serial device to a USB port. I don't know if Radio Shack will
deliver to you, but here's a link that'll give you some ideas for what you'd
need to buy (ignore the stuff that's farther down the page, as everything that
you'd be looking for is at the top of the list):
http://www.radioshack.com/search/index.jsp?kwCatId=&kw=usb%20serial%20adapter&origkw=usb%20serial%20adapter&sr=1
As for the XP issue, that's probably just something you're going to have to
cheat. XP will complain about software that doesn't have the right
authentication, but that doesn't mean it won't _run_ the software. Just that it
doesn't think you should trust it. Supposedly you can also tell XP to run a
program as if your system had an older generation of Windows installed, but I've
heard mixed results on that, and I've never actually tried it myself (it still
won't get around any complaints about lack of authentication certificates,
though).
|
|
| |
Guys,
Just retrieved my (dusted) RCX kit & a few spybots, when I move things
around, unfortunately, my notebook does not have serial port any more.
Moreover, the CD does not support XP either.
Do you aware if any online shop will sell RCX USB IR-Tower to Asia? I am
living in HK, but all overseas online shop I aware of didn't sell things to
here.
I ringed Lego HK, but they will not take customer orders (don't know what
they do here??)
Found one located in HK, but ... too late .... USB IR Tower already out of
stock.
Any suggestion for me to bring the RCX kit back to live? Can I
|
|
| |
> At 11:13 AM 7/16/07, Timothy Su wrote:
> > I tried my own skill on writing a program for the included lego test pad (RIS
> > 2.0), and I discovered something weird. The following code does set the
> > conditions right, but the following code doesn't set the conditions right if I
> > comment out the 'cputs("");'. Any idea why?
It looks to me like the c compiler optimized the assignment to the
variable away, since there is no external method call
(shutdown_requested() is just a macro).
> >
> > int offonpad =0;
You should make this
volatile int offonpad = 0;
> > while(!shutdown_requested()) {
> > if(LIGHT(LIGHTSENS) < 40) {
> > offonpad = 1;
> > }
> > else {
> > offonpad = 0;
> > }
> > //cputs("");
> > }
You should also put an msleep(10) or at least a yield() somewhere
inside the loop; otherwise it uses up its full time-slice without
letting any other thread react to the change of the variable. You can
tweak the sleep time to balance between reaction time and cpu usage.
Regards,
Jochen
--
Jochen Hoenicke,
Email: hoenicke@informatik.uni-freiburg.de
|
|
| |
I use BrickOS (LegOS) but I'm not expert in the inner workings.
The code you have here appears fine to me. So, it may be a bug in
BrickOS, or a problem elsewhere in your code.
I will say I've ran into some interesting things when using
tasks. Sometimes, you have to include a wait, to suspend the current
task, and allow others to execute. The cputs may include something like that.
So, the problem may be a bug in BrickOS, but the solution may be in
how you start & switch your tasks.
Steve
At 11:13 AM 7/16/07, Timothy Su wrote:
> I tried my own skill on writing a program for the included lego test pad (RIS
> 2.0), and I discovered something weird. The following code does set the
> conditions right, but the following code doesn't set the conditions right if I
> comment out the 'cputs("");'. Any idea why?
>
> int offonpad =0;
>
> int check_off_pad(int argc, char *argv[]) {
> while(!shutdown_requested()) {
> if(LIGHT(LIGHTSENS) < 40) {
> offonpad = 1;
> }
> else {
> offonpad = 0;
> }
> cputs("");
> }
> return 0;
> }
>
> What doesn't work is (it fails to set the varible, if i initialize offonpad as
> 1, its always one. If i initialize offonpad as 0, it is always zero.):
>
> int check_off_pad(int argc, char *argv[]) {
> while(!shutdown_requested()) {
> if(LIGHT(LIGHTSENS) < 40) {
> offonpad = 1;
> }
> else {
> offonpad = 0;
> }
> //cputs("");
> }
> return 0;
> }
|
|
| |
I tried my own skill on writing a program for the included lego test pad (RIS
2.0), and I discovered something weird. The following code does set the
conditions right, but the following code doesn't set the conditions right if I
comment out the 'cputs("");'. Any idea why?
int offonpad =0;
int check_off_pad(int argc, char *argv[]) {
while(!shutdown_requested()) {
if(LIGHT(LIGHTSENS) < 40) {
offonpad = 1;
}
else {
offonpad = 0;
}
cputs("");
}
return 0;
}
What doesn't work is (it fails to set the varible, if i initialize offonpad as
1, its always one. If i initialize offonpad as 0, it is always zero.):
int check_off_pad(int argc, char *argv[]) {
while(!shutdown_requested()) {
if(LIGHT(LIGHTSENS) < 40) {
offonpad = 1;
}
else {
offonpad = 0;
}
//cputs("");
}
return 0;
}
|
|
| |
> > It sounds like the code is testing for pressing the run button, but not
> > pressing the power button.
>
> I'm using what appears to be called BrickOS 0.9.0. It was installed using
> John
> Hansen's simplified installation from his BricxCC sourceforge site.
Yes, that should be the latest version.
> I was under the impression that on later versions of BrickOS, like what I
> am
> using, the firmware handles the Run and Power buttons. My code does use
> the
> View and Prgm buttons but I do no special handling of the other two
> buttons
> other then monitoring shutdown_requested and exiting and killing all tasks
> when
> that is encountered.
That is correct. You shouldn't need to do anything else.
At one point, I made some changes to the firmware so the program could also
access the run button. But, normally all that is handled in the firmware.
We'll see if we can figure it out at Brickworld.
See you in a few days...
Steve
|
|
| |
In lugnet.robotics.rcx.legos, Steve Hassenplug wrote:
> > I have a big and somewhat complicated BrickOS program that I believe is
> > reasonably well behaved. All my loops monitor shutdown_requested and I
> > have
> > tested stopping the program with the Run button while the program is in
> > various
> > states and it always seems to shutdown perfectly. My problem is if I
> > shutdown
> > with the Off button. In that case the firmware crashes and I have to pull
> > the
> > battery out to reset the RCX and then re-download the firmware.
> >
> > I believe the same thing happens if I leave the program running and the
> > RCX does
> > an auto-shutoff though I don't have recent experience with this. How do
> > you set
> > the auto-shutoff to either a very long time or disable it completely?
>
> Gus,
>
> It sounds like the code is testing for pressing the run button, but not
> pressing the power button.
>
> I would think testing for shutdown would be good enough, but who knows...
> :) What version of BrickOS are you using?
>
> I'd be glad to take a look at it, if you want.
>
> Steve
I'm using what appears to be called BrickOS 0.9.0. It was installed using John
Hansen's simplified installation from his BricxCC sourceforge site.
I was under the impression that on later versions of BrickOS, like what I am
using, the firmware handles the Run and Power buttons. My code does use the
View and Prgm buttons but I do no special handling of the other two buttons
other then monitoring shutdown_requested and exiting and killing all tasks when
that is encountered.
Hitting the Run button while my program is running, does causes
shutdown_requested to return true and my program does exit cleanly. Hitting the
On/Off button while the program is running does appear to turn off the RCX but
when I turn it back on it appears at first to be okay but when I run the program
things go haywire and then I have to reset the RCX by removing a battery.
Powering off with the On/Off button while the program is not running does not
seem to cause any ill effects.
This is part of my Line Maze program but it is not critical, it just would have
been nice to have had it resolved before going to BrickWorld. If I accidentally
forget to stop the program before hitting Off or if I let the auto-off do its
thing, then I know I will need to re-download the firmware and my program. I
will show you in Chicago and maybe you can help figure out a solution when we
meet.
Gus
|
|
| |
> I have a big and somewhat complicated BrickOS program that I believe is
> reasonably well behaved. All my loops monitor shutdown_requested and I
> have
> tested stopping the program with the Run button while the program is in
> various
> states and it always seems to shutdown perfectly. My problem is if I
> shutdown
> with the Off button. In that case the firmware crashes and I have to pull
> the
> battery out to reset the RCX and then re-download the firmware.
>
> I believe the same thing happens if I leave the program running and the
> RCX does
> an auto-shutoff though I don't have recent experience with this. How do
> you set
> the auto-shutoff to either a very long time or disable it completely?
Gus,
It sounds like the code is testing for pressing the run button, but not
pressing the power button.
I would think testing for shutdown would be good enough, but who knows...
:) What version of BrickOS are you using?
I'd be glad to take a look at it, if you want.
Steve
|
|
| |
I have a big and somewhat complicated BrickOS program that I believe is
reasonably well behaved. All my loops monitor shutdown_requested and I have
tested stopping the program with the Run button while the program is in various
states and it always seems to shutdown perfectly. My problem is if I shutdown
with the Off button. In that case the firmware crashes and I have to pull the
battery out to reset the RCX and then re-download the firmware.
I believe the same thing happens if I leave the program running and the RCX does
an auto-shutoff though I don't have recent experience with this. How do you set
the auto-shutoff to either a very long time or disable it completely?
Any insight on this would be much appreciated.
Thank you.
Gus
|
|
| |
In lugnet.robotics.rcx.legos, Dominic Clifton wrote:
> I've been trying to build a cross compiler and brick-os on my machine for a
> day now and well, what can I say except that all the how-to's and
> instructions for building brick-os seem to be either wrong, bad or out of
> date. (e.g. they talk about very old versions of gcc and binutils and refer
> to brickos as legOS still!)
>
> I think I've sucessfully managed to build a cross compiler and brick os, but
> man was it painful trying to figure out what I needed to do it! (I think I
> owe google some money for all the searching I had to do! :D) I'll test it
> on my rcx soon but as there were no errors during the build
> (eventually) i think it should be ok.
>
> I will update the howto and will update the cygwin shell script and provide
> information regarding some patches that are required to enable it to be
> compiled using gcc > 3.2 and binutils 2.16 but how do:
>
> a) we get these patches (created by debian users) integrated into brick-os
> itself.
> b) I get an updated howto onto the brickos site.
>
> Personally I think the brickos site on sourceforge should have a wiki where
> these instructions should live so that they can be updated as needed by
> anyone who has the time.
>
> Who can setup a wiki there? Anyone got some time to go though some of the
> info on the site and update it?
>
> btw, see my comments on here for more info about the patches:
>
> http://marc.abramowitz.info/archives/2006/01/07/building-brickos-tools-on-mac-os-x/#comment-70727
Hi Dom,
As far as I know, all the sourceforge web pages are held in the CVS repository,
as are the sources. Only people with developer permission on the project have
commit access to CVS - you have to contact the project admins to request that
permission. Once you have commit access you can commit changes using the
instructions here: http://sourceforge.net/cvs/?group_id=58151
It isn't a very active project - not much has been updated in the last 2 years.
HTH
ROSCO
|
|
| |
I've been trying to build a cross compiler and brick-os on my machine for a
day now and well, what can I say except that all the how-to's and
instructions for building brick-os seem to be either wrong, bad or out of
date. (e.g. they talk about very old versions of gcc and binutils and refer
to brickos as legOS still!)
I think I've sucessfully managed to build a cross compiler and brick os, but
man was it painful trying to figure out what I needed to do it! (I think I
owe google some money for all the searching I had to do! :D) I'll test it
on my rcx soon but as there were no errors during the build
(eventually) i think it should be ok.
I will update the howto and will update the cygwin shell script and provide
information regarding some patches that are required to enable it to be
compiled using gcc > 3.2 and binutils 2.16 but how do:
a) we get these patches (created by debian users) integrated into brick-os
itself.
b) I get an updated howto onto the brickos site.
Personally I think the brickos site on sourceforge should have a wiki where
these instructions should live so that they can be updated as needed by
anyone who has the time.
Who can setup a wiki there? Anyone got some time to go though some of the
info on the site and update it?
btw, see my comments on here for more info about the patches:
http://marc.abramowitz.info/archives/2006/01/07/building-brickos-tools-on-mac-os-x/#comment-70727
- Dom
|
|
| |
hi,
(1. PROBLEM) :o)
i am trying to send something from my rcx to my pc(serial tower) via
lnp. with my rcx program running i started lnpdump to see if anything
arrives at my pc, but nothing seems to arrive. with my pc-side program i
also cant receive anything. but when i start lnpdump -a or lnpdump -r
(shows raw data without interpretation) i see the sent data arriving
correctly at the pc. why is this? i tried brickos 0.2.4 0.2.5 0.2.6
without any change.. :(
the relevant lines are:
on the rcx:
#define HOST_3 3
...
int receiver = ((HOST_3 << 4) | PORT_A);
result = lnp_addressing_write(samples, 128,receiver,1);
on the pc:
...
if (lnp_init(0,0,0x30,0,0)){
printf("killing");
exit(1);
}
lnp_addressing_set_handler(1,data);
...
...
void data(const unsigned char *data,unsigned char length,unsigned char rc)
{
printf("recieving data\n");
memcpy(&(image[lines*128]),data,128);
count++;
}
...any ideas?
(2. PROBLEM)
because the 0.2.x brickos series didnt work i added stable sources to my
apt file and downloaded brickos 0.9.0, an egcs-2.91.60 crosscompiler and
the binutils-h8300 via apt-get. As described in the docs i copied the
Makefile from the demo dir. but when i try to "make" any program the
following errors occur:
> claut@phobos:~/demo$ make myscan.lx
> /usr/h8300-hitachi-hms/bin/h8300-hitachi-hms-gcc -O2 -fno-builtin
-fomit-frame-pointer -Wall -I/usr/include/brickos
-I/usr/include/brickos/lnp -I. -I/usr/include -I/usr/include/brickos -c
myscan.c -o myscan.o
> /usr/include/brickos/dsensor.h:118: warning: this is the location of
the previous definition
> /tmp/cc614n9t.s: Assembler messages:
> /tmp/cc614n9t.s:1: Error: no such instruction: `gcc For the Hitachi
H8/300'
> /tmp/cc614n9t.s:2: Error: no such instruction: `by Hitachi America
Ltd and Cygnus Support'
> /tmp/cc614n9t.s:3: Error: no such instruction: `release F-1' `release
F-1'> /tmp/cc614n9t.s:4: Error: junk at end of line, first unrecognized
character is `-'
> /tmp/cc614n9t.s:12: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:13: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:14: Error: no such instruction: `jsr @_motor_a_dir'
> /tmp/cc614n9t.s:15: Error: no such instruction: `rts'
> /tmp/cc614n9t.s:19: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:20: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:21: Error: no such instruction: `jsr @_motor_c_dir'
> /tmp/cc614n9t.s:22: Error: no such instruction: `rts'
> /tmp/cc614n9t.s:26: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:27: Error: no such instruction: `jsr @_motor_a_dir'
> /tmp/cc614n9t.s:28: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:29: Error: no such instruction: `jsr @_msleep'
> /tmp/cc614n9t.s:30: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:31: Error: no such instruction: `jsr @_motor_a_dir'
> /tmp/cc614n9t.s:32: Error: no such instruction: `rts'
> /tmp/cc614n9t.s:36: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:37: Error: no such instruction: `jsr @_motor_c_dir'
> /tmp/cc614n9t.s:38: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:39: Error: no such instruction: `jsr @_msleep'
> /tmp/cc614n9t.s:40: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:41: Error: no such instruction: `jsr @_motor_c_dir'
> /tmp/cc614n9t.s:42: Error: no such instruction: `rts'
> /tmp/cc614n9t.s:49: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:50: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:51: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:52: Error: no such instruction: `jsr @_motor_c_set'
> /tmp/cc614n9t.s:53: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:54: Error: no such instruction: `jsr @_msleep'
> /tmp/cc614n9t.s:55: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:56: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:57: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:58: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:59: Error: no such instruction: `bls .L63'
> /tmp/cc614n9t.s:60: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:62: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:63: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:64: Error: no such instruction: `bgt .L65'
> /tmp/cc614n9t.s:65: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:66: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:68: Error: no such instruction: `shlr r0h'
> /tmp/cc614n9t.s:69: Error: no such instruction: `rotxr r0l'
> /tmp/cc614n9t.s:70: Error: suffix or operands invalid for `add'
> /tmp/cc614n9t.s:71: Error: no such instruction: `bne .Llt1'
> /tmp/cc614n9t.s:72: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:73: Error: no such instruction: `jsr @___udivhi3'
> /tmp/cc614n9t.s:74: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:75: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:76: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:77: Error: suffix or operands invalid for `add'
> /tmp/cc614n9t.s:78: Error: suffix or operands invalid for `add'
> /tmp/cc614n9t.s:80: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:81: Error: no such instruction: `jsr @_msleep'
> /tmp/cc614n9t.s:82: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:83: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:84: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:85: Error: no such instruction: `bhi .L64'
> /tmp/cc614n9t.s:87: Error: no such instruction: `jsr @_motor_c_stop'
> /tmp/cc614n9t.s:88: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:89: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:90: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:91: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:92: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:93: Error: no such instruction: `jsr
@_lnp_addressing_write'
> /tmp/cc614n9t.s:94: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:95: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:96: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:97: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:98: Error: no such instruction: `jsr
@_lnp_addressing_write'
> /tmp/cc614n9t.s:99: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:100: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:101: Error: no such instruction: `jsr @_motor_c_set'
> /tmp/cc614n9t.s:102: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:103: Error: no such instruction: `jsr @_msleep'
> /tmp/cc614n9t.s:104: Error: suffix or operands invalid for `add'
> /tmp/cc614n9t.s:105: Error: suffix or operands invalid for `add'
> /tmp/cc614n9t.s:106: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:108: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:109: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:110: Error: no such instruction: `bhi .L69'
> /tmp/cc614n9t.s:111: Error: no such instruction: `jsr @_motor_c_stop'
> /tmp/cc614n9t.s:115: Error: no such instruction: `rts'
> /tmp/cc614n9t.s:119: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:120: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:121: Error: no such instruction: `jsr @_motor_a_set'
> /tmp/cc614n9t.s:122: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:123: Error: no such instruction: `jsr @_msleep'
> /tmp/cc614n9t.s:124: Error: no such instruction: `jsr @_motor_a_stop'
> /tmp/cc614n9t.s:125: Error: no such instruction: `rts'
> /tmp/cc614n9t.s:130: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:132: Error: no such instruction: `bset '
> /tmp/cc614n9t.s:135: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:137: Error: no such instruction: `jsr @_scanline'
> /tmp/cc614n9t.s:138: Error: no such instruction: `jsr @_linefeed'
> /tmp/cc614n9t.s:139: Error: suffix or operands invalid for `sub'
> /tmp/cc614n9t.s:140: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:141: Error: no such instruction: `bne .L81'
> /tmp/cc614n9t.s:142: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:144: Error: no such instruction: `bclr '
> /tmp/cc614n9t.s:147: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:149: Error: no such instruction: `bclr '
> /tmp/cc614n9t.s:152: Error: invalid character '.' in mnemonic
> /tmp/cc614n9t.s:154: Error: no such instruction: `rts'
> make: *** [myscan.o] Fehler 1
i am using debian etch with a 2.6 kernel and i allready tried many
reinstalls but it didnt work.
please help me, this is really drivin me nuts...
|
|
| |
Hi everyone, I'm doing my thesis using Brickos and LNP on Debian, with a RCX 2.0
and an IR tower USB, LNP because I need to have a constant communication between
the pc and several RCXs.
I'm using brickos lnpd_0.9.0-1 stable, lnpd_0.9.0-1_i386.deb on a debian system
with kernel
kernel-image-2.6.8-3-386_2.6.8-16sarge5_i386.deb. Everything works fine,
downloading programs to RCX, compiling programs ... but when I try to use the
lnpd on the pc side I get the following errors:
1. In the log file (lnpd.log):
0:Info > created lock file /var/lock/LCK..legousbtower0
0:Fatal > /dev/usb/legousbtower0 is not a tty
2. In the command lines:
debian:~/diego/pcrcx/pc# export RCXTTY=/dev/usb/legousbtower0
debian:~/diego/pcrcx/pc# ./lnpd
Usage: /etc/init.d/lnpd {start|stop|restart|force-reload}
debian:~/diego/pcrcx/pc# ./lnpd start
lnpd: Starting daemon with options=[--fast RCXTTY=/dev/usb/legousbtower0 --log=/var/log/lnpd.log ]
Starting BrickOS LNP Daemon: lnpd.
debian:~/diego/pcrcx/pc# ./pc
lnp_init: Connection refused
debian:~/diego/pcrcx/pc# ./lnpd stop
I know that the problem comes from the relation RCXTTY=/dev/usb/legousbtower0
with Lnpd in file lnpd.conf but I don't know what to do for slove this problem.
the lnpd.conf is this:
# Configurable command-line options for lnpd(8)
#
# NOTE: this is a POSIX shell fragment
#
# Logging options
#
#OPT_LOG="-l" # log to syslog
#OPT_LOG="--log=/var/log/lnpd.log" # log to specified file
#OPT_LOG="" # to disable logging
OPT_LOG="--log=/var/log/lnpd.log" # log to specified file
#
# Communication speed options
#
#OPT_FAST="--fast"
OPT_FAST=""
#
# Logging Detail [see lnpd(8)]
#
#OPT_DEBUG="-vavil"
OPT_DEBUG=""
#
# The serial device to which the IR Tower is attached
#OPT_TTY="--tty=/dev/ttyS0"
OPT_TTY="RCXTTY=/dev/usb/legousbtower0"
#OPT_TTY="--tty=/dev/ttyS1"
Anyone who can help with this problem with LNPD, I 'll be very thankful.
Diego
|
|
| |
Michael Obenland wrote:
> I think we all want to get (or have it already) a NXT brick. BrickOS was
> not changed in the last year, as I remember. But it is a great way to do
> real programming and I wish to have someting like a nxtOS. :)
Santa thinks I haven't played enough with my RCX since I got
it, so he won't give me a NXT just yet. ;-)
> > and if I should volunteer to get the code to a state where
> > it compiles wih gcc 4.x without warnings.
>
> That sounds great for me. I use my good old RCX and brickOS, actually
> with a gcc < 4.x toolchain. It works, but if it could work better...
Aside from some signedness warnings and a missing function for
converting unsigned to float, brickOS compiles nicely with gcc HEAD.
Patch: http://carl.troein.com/brickos/ct_signedness.diff
And I should test with some slightly older version of gcc too.
//Carl
--
Carl Troein - carl@thep.lu.se
http://www.thep.lu.se/~carl/
|
|
| |
> Carl,
>
> Welcome! If you have the time and the interest we welcome your
> spending time on this.
>
> As you can tell there has not been much activity here in a while... ;-(
Still it is nice to see some activity :-)
BTW: I've adopted Stephen's Debian packages, so there are new ones for those of
you who are on Debian.
Is there anything one could do to help?
Best,
Michael
|
|
| |
Hi Carl,
I think we all want to get (or have it already) a NXT brick. BrickOS was
not changed in the last year, as I remember. But it is a great way to do
real programming and I wish to have someting like a nxtOS. :)
> and if I should volunteer to get the code to a state where
> it compiles wih gcc 4.x without warnings.
That sounds great for me. I use my good old RCX and brickOS, actually
with a gcc < 4.x toolchain. It works, but if it could work better...
Regards,
Michael
|
|
| |
Carl,
Welcome! If you have the time and the interest we welcome your
spending time on this.
As you can tell there has not been much activity here in a while... ;-(
In lugnet.robotics.rcx.legos, Carl Troein wrote:
> So I wonder what the development status is at the
> moment, and if I should volunteer to get the code to a state where
> it compiles wih gcc 4.x without warnings.
Regards,
Stephen
--
|
|
| |
Hey folks.
I played around a bit with brickOS a couple of years ago but never
got around to do anything serious. And now I thought I'd look into
it again, if only for the joy of low-level coding.
So I noticed, like others before me, that brickOS straight from
CVS won't compile (with any recent version of gcc) without Jochen's
opcode patch. So I wonder what the development status is at the
moment, and if I should volunteer to get the code to a state where
it compiles wih gcc 4.x without warnings.
//Carl
--
Carl Troein - carl@thep.lu.se
http://www.thep.lu.se/~carl/
|
|
| |
Hoodia 920+ -- The newest and most exciting fat loss product available - As seen on Oprah!
http://www.trimnor.com/d/
Real testimonials:
"I was originally amazed that the first two pills I took of Hoodia 920+, almost immediately took my cravings away.
Now 4 weeks later, 3 belt holes later,
I have become an advocate for this awesomely powerful, natural supplement!"
Lusia R., Boston
"I tried Hoodia 920+ after visiting your website, and I lost a few pounds without doing anything else.
I was so amazed I decided to start exercising and getting outside more and I even starting eating better.
Now I don't even look like the same man. Friends I haven't seen for more than a year don't even recognize me.
The change is that dramatic! Thank you …. Hoodia 920+ really works!"
Mike Brown, Chicago
Read more testimonals here!
http://www.trimnor.com/d/
Remove you e-mail
http://www.trimnor.com/d/u.php
--
MIME ATTACHMENTS DISCARDED:
1. Content-Type: text/html
Content-Transfer-Encoding: 7bit
Content-Length: 1239
|
|
| |
Hi,
lnpd is a very old program and has several problems, it does not support the
protocol used by brickOS, lacks support for the USB tower and may lose packets
as soon as they get too large (>8 bytes or so). Collision detection does not
work as long as the serial port FIFO is enabled.
Sure, it might be possible to repair most issues, but I have decided to start a
new infrared library from scratch that should have more features and less
problems.
<http://lnphost.sourceforge.net/>
Greetings,
Stephan
|
|
| |
In lugnet.robotics.rcx.robolab, Elizabeth Mabrey wrote:
> Since the NXT does not have IR capability, it will not be communicate with
> the RCX brick.
The NXT has a new sensor control bus. That allows many ways to interact almost
anything you want.
From Hear-say i have heared that HiTechnics is building an NXT - IR converter in
the size of a NXT sensor..
Daniel Wittenaar
Brickbash Robotics
|
|
| |
> I succeeded in writing, compiling and uploading c
> code.
> When I tried to convert the SAME program in c++
> (changing extension from .c to .cpp) and eventually
The h8300 gcc compiler is really buggy across different versions of
gcc/binutils. Using the wrong version of binutils/gcc with each other always
causes extremely strange problems on my RCX. Usually it will allow me to send
the firmware, but sending a lx program crashes everything.
Personally I use the following versions:
gcc 3.4.4
binutils 2.16.1
That has always solved weird brickos problems for me.
To get brickos to compile in gcc3+ you will need the gcc33 patch from:
http://hoenicke.ath.cx/rcx/brickOS.html
----
Matthew Ruschmann
http://matthew.ruschmann.net
|
|
| |
In lugnet.robotics.rcx.legos, Daniele Benedettelli wrote:
> :Hi.
> I'm currently working on a thesis using Brickos 0.9.0.
>
> I succeeded in writing, compiling and uploading c
> code.
> When I tried to convert the SAME program in c++
> (changing extension from .c to .cpp) and eventually
> including a library such as <c++/MotorPair.H>, it
> compiles and uploads BUT RCX dies after an instant, no
> button works, no response to remote, no sound, and I
> had to remove batteries to reload ROM firmware!
Danny,
I've not used C++, but I have seen problems like this. For me, it happened when
the firmware in my brick didn't match the firmware I compiled the program to
use. However, it doesn't sound like that's the problem your having.
I'd suggest commenting out all the C++ code, and see if you still get the
problem.
Actually, my guess is that the c++ library has not been updated to work with the
latest version of BrickOS. I think a couple years ago the motor control stuff
was moved in memory, and I don't recall anyone saying anything about updating
the c++ code.
If you really want to use c++, you may need to look into the motor.h and
motorpair.h files, and figure out what's going on. However, give the lack of
reply to this post, you may have to figure it out yourself. :(
I hope you come up with something
Steve
|
|
| |
:Hi.
I'm currently working on a thesis using Brickos 0.9.0.
I succeeded in writing, compiling and uploading c
code.
When I tried to convert the SAME program in c++
(changing extension from .c to .cpp) and eventually
including a library such as <c++/MotorPair.H>, it
compiles and uploads BUT RCX dies after an instant, no
button works, no response to remote, no sound, and I
had to remove batteries to reload ROM firmware!
I think this problem is related to thread management.
I attach the sources:
- Test1.c is the C code
- Test2.cpp is the equivalent C++ code.
Thank you so much.
Danny
**************************************************************************
Test1.c
**************************************************************************
#include <conio.h>
#include <unistd.h>
#include <tm.h>
#include <lnp/lnp.h>
#include <dmotor.h>
int MotorSpeed=255;
int Spin();
int CheckMessage();
/* Robot spins */
int Spin() { //spin thread
while (!shutdown_requested())
{
motor_a_dir(rev);
motor_c_dir(fwd);
motor_a_speed(MotorSpeed);
motor_c_speed(MotorSpeed);
lcd_number(MotorSpeed,unsign,e0);
msleep(1);
}
return 0;
}
/* Remote control of motor velocity */
int CheckMessage() { //remote control thread
while (!shutdown_requested())
{
if (get_msg()==3) if(MotorSpeed+5<=MAX_SPEED)MotorSpeed+=5;
if (get_msg()==1) if(MotorSpeed-5>=MIN_SPEED)MotorSpeed-=5;
if (get_msg()==2) MotorSpeed=125;
}
return 0;
}
int main(int c, char **v)
{
execi(CheckMessage, 0, 0, PRIO_LOWEST, DEFAULT_STACK_SIZE);
execi(Spin, 0, 0, PRIO_LOWEST, DEFAULT_STACK_SIZE);
while(!shutdown_requested()) msleep(100);
return 0;
}
********************************************************************
Test2.cpp
********************************************************************
#include <conio.h>
#include <unistd.h>
#include <tm.h>
#include <lnp/lnp.h>
#include <dmotor.h>
#include <c++/MotorPair.H>
int CheckMessage(int, char**);
int Spin(int, char**);
int MotorSpeed=125;
MotorPair m(Motor::A, Motor::C);
/* Robot spins */
int Spin(int c, char *v[]) { //spin thread
while (!shutdown_requested())
{
m.right(MotorSpeed);
lcd_number(MotorSpeed,unsign,e0);
msleep(1);
}
return 0;
}
/* Remote control of motor velocity */
int CheckMessage(int c, char *v[]) { //remote control thread
while (!shutdown_requested())
{
if (get_msg()==3) if(MotorSpeed+10<=MAX_SPEED)MotorSpeed+=10;
if (get_msg()==1) if(MotorSpeed-10>=MIN_SPEED)MotorSpeed-=10;
if (get_msg()==2) MotorSpeed=125;
}
return 0;
}
int main(int c, char *v[])
{
execi(CheckMessage, 0, 0, PRIO_LOWEST, DEFAULT_STACK_SIZE);
execi(Spin, 0, 0, PRIO_LOWEST, DEFAULT_STACK_SIZE);
while(!shutdown_requested()) msleep(100);
return 0;
}
|
|
| |
In lugnet.robotics.rcx.legos, Jonathan Wilson wrote:
> > No amount of lubrication is going to help. In due course the motor will become
> > permanently stuck and useless. Such is the natural history.
> Is this triggered by time or by usage? (i.e. will a motor that is run more
> wear out faster?)
Both. Likely due to bad design and/or manufacture.
Someone at TLC is supposed to be looking into it. But I do not know what is the
outcome.
C S Soh
|
|
| |
> No amount of lubrication is going to help. In due course the motor will become
> permanently stuck and useless. Such is the natural history.
Is this triggered by time or by usage? (i.e. will a motor that is run more
wear out faster?)
|
|
| |
In lugnet.robotics.rcx.legos, Marc Abramowitz wrote:
> My robot is having a hard time getting around and I think that it's because the
> motors seem to be sticking. Even on my linoleum floor, my little tank robot
> often gets stuck and goes in slow circles, because one motor gets stuck. Once I
> nudge it or pick the robot up, the motor kicks in again but only for a little
> while and then gets stuck again a few seconds later.
>
> I am thinking that the motors need lubrication. Is this a good idea and if so,
> what type of lubrication to use? I have WD-40 and Tri-Flow, a teflon-based
> lubricant that is used for bikes, skates, etc.
>
> Would either of these work and not damage the motor?
You may want to check if your motors are the new type 9V geared motor (#43362).
If so, please be aware it is prone to failure, the first sign being sticking. Pl
see my previous post on this ailment:
http://news.lugnet.com/robotics/?n=24484&t=i&v=a
No amount of lubrication is going to help. In due course the motor will become
permanently stuck and useless. Such is the natural history.
C S Soh
|
|
| |
My robot is having a hard time getting around and I think that it's because the
motors seem to be sticking. Even on my linoleum floor, my little tank robot
often gets stuck and goes in slow circles, because one motor gets stuck. Once I
nudge it or pick the robot up, the motor kicks in again but only for a little
while and then gets stuck again a few seconds later.
I am thinking that the motors need lubrication. Is this a good idea and if so,
what type of lubrication to use? I have WD-40 and Tri-Flow, a teflon-based
lubricant that is used for bikes, skates, etc.
Would either of these work and not damage the motor?
|
|
| |
In lugnet.robotics.rcx.legos, Pierluigi Rolando wrote:
> Hi,
> I'm new here. My name is Pierluigi and I am a student at the Turin
> Polytechnic (http://www.polito.it,
> http://en.wikipedia.org/wiki/Politecnico_di_Torino ).
> I've used BrickOS with LNPd for a summer project, and I've recently
> bought the Robotics Invention System 2.0, that comes with a USB IR
> Tower.
>
> This tower works pretty well with BrickOS (I can download the firmware
> and test programs), but AFAIK is not supported at all by LNPd (there's
> even a related item in the TODO list).
>
> In order to improve the situation I've been hacking all the day and now
> I think I might have a LNPd version that at least lets you download
> programs with lnpdllx, at slow speed. It worked with every example
> program distributed with BrickOS but rover.lx, and I'm still looking
> into the matter.
>
> If anybody is interested please reply to this message; I'm more than
> willing to share my findings and my source files. I've used BrickOS and
> LNPd version 0.9.0 and the h8300 toolchain that come with Ubuntu 5.10
> 'Breezy Badger'.
>
> I know that the netiquette requires to lurk for a bit on a list before
> posting, so I sincerely apologize if this isn't news. It might be that
> there is already extensive support for the LNPd + USB tower, but I
> couldn't find any piece of information about it.
>
> HTH,
> Pierluigi Rolando
I've never used LNPd, but since it's old enough to have "legOS" as its first
letter, then it must support the serial IR tower. If no one else has info for
you, you might consider buying one. Pitsco sells it new for $31.00:
http://www.legoeducation.com/store/detail.aspx?ID=390
You can get them new or used on BrickLink, too, for under $10:
http://www.bricklink.com/search.asp?q=serial
|
|
| |
In lugnet.robotics.rcx.legos, Marc Abramowitz wrote:
> I also could take a stab at modifying the "dll" program to support USB on the
> Mac.
As I said to Marc in a private email (I have trouble posting to lugnet, not
being a member and all), I hacked "dll" so that it works on Mac OS X 10.4 with
the USB tower, using the USB code from lejos.
http://www.cse.unsw.edu.au/~peteg/blog/hacking/mindstorms/
Hope that helps.
cheers
peter
|
|
| |
In lugnet.robotics.rcx.legos, Brian Davis wrote:
> In lugnet.robotics.rcx.legos, Marc Abramowitz wrote:
>
> > I hope that this doc is helpful to somebody out there.
>
> Thank you! It will be. Intallation is one reason I've never moved into
> BrickOS (despite some people urging me to) on the Mac.
Perhaps one of the brickOS folks wants to work with me to turn this into a HOWTO
that can go on the brickOS site?
I also could take a stab at modifying the "dll" program to support USB on the
Mac.
If any folks from brickOS are interested, email me.
-Marc
|
|
| |
Hi,
I'm new here. My name is Pierluigi and I am a student at the Turin
Polytechnic (http://www.polito.it,
http://en.wikipedia.org/wiki/Politecnico_di_Torino ).
I've used BrickOS with LNPd for a summer project, and I've recently
bought the Robotics Invention System 2.0, that comes with a USB IR
Tower.
This tower works pretty well with BrickOS (I can download the firmware
and test programs), but AFAIK is not supported at all by LNPd (there's
even a related item in the TODO list).
In order to improve the situation I've been hacking all the day and now
I think I might have a LNPd version that at least lets you download
programs with lnpdllx, at slow speed. It worked with every example
program distributed with BrickOS but rover.lx, and I'm still looking
into the matter.
If anybody is interested please reply to this message; I'm more than
willing to share my findings and my source files. I've used BrickOS and
LNPd version 0.9.0 and the h8300 toolchain that come with Ubuntu 5.10
'Breezy Badger'.
I know that the netiquette requires to lurk for a bit on a list before
posting, so I sincerely apologize if this isn't news. It might be that
there is already extensive support for the LNPd + USB tower, but I
couldn't find any piece of information about it.
HTH,
Pierluigi Rolando
|
|
| |
Since the NXT does not have IR capability, it will not be communicate with
the RCX brick. If there is no such plan from LEGO to build in the new NXT
such capability, I am afraid they are going to put RCX brick in an obsolete
track!? O, no!
----------------------------------------------------------------------------
--------
Best Regards,
Elizabeth Mabrey
--
MIME ATTACHMENTS DISCARDED:
1. Content-Type: text/html;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Content-Length: 1729
|
|
| |
In lugnet.robotics.rcx.legos, Marc Abramowitz wrote:
> I hope that this doc is helpful to somebody out there.
Thank you! It will be. Intallation is one reason I've never moved into
BrickOS (despite some people urging me to) on the Mac.
--
Brian Davis
|
|
| |
Hi all,
I just finished compiling and installing a cross-compiler and brickOS to my RCX
from my PowerBook with Mac OS X Tiger 10.4.3 and a USB IR tower. Here's a blog
posting about my experience:
http://marc.abramowitz.info/archives/2006/01/07/building-brickos-tools-on-mac-os-x/
Note that I was able to install brickOS to my RCX (using lejosfirmdl), but I
haven't yet figured out any way of downloading .lx files to it, since "dll"
seems to not have Mac USB support. There is some room to improve brickOS a bit
to make it easier to use on a Mac and I'd volunteer a bit of time to work on it.
I hope that this doc is helpful to somebody out there.
-Marc
|
|
| |
Hi,
It appears to be straight-forward to control the WowWee robots from RCX and
generate their IR commands by controlling the TxD output pin of the RCX's
processor.
More info, small webcam video, and simple example source:
http://www.robotika.sk/projects/robsapien/petnrcx.php
This opens up for a lot of fun - and Robert even promised to integrate this into
his RoboSapien Dance Machine, so if you own RCX, and one of the WowWees, stay
tuned for more fun!
Pavel.
|
|
| |
from the lego press release...
...The heart of the new system is the NXT brick, an autonomous 32-bit LEGO
microprocessor that can be programmed using a PC, or for the first time in
the retail offering, a Mac. After building their robots, users create a
program within easy-to-use yet feature-rich software, powered by LabVIEW
from National Instruments. ...
(hmmm... will it be something similar to the Robolab interface??? )
...Downloading programs to an invention is easy. Users with
BluetoothR-enabled computer hardware can transfer their programs to the NXT
wirelessly,...
LEGO MINDSTORMS NXT highlights include:
* 32-bit processor
* All-new NXT intelligent brick
* 3 interactive servo motors feature inbuilt rotation sensors to align
speed for precise control
* New ultrasonic sensor makes robots "see" by responding to movement
* New sound sensor enables robots to react to sound commands,
including sound pattern and tone recognition
* Improved light sensor detects different colors and light intensity
* Improved touch sensor reacts to touch or release and allows robots
to feel
* 519 hand-selected, stylized elements from the LEGO TECHNICR building
system ensure robot creations will be sturdy and durable while also looking
authentic
* Opportunities for physical programming of robots and interaction
with robots during programming
* 18 building challenges with clear, step-by-step instructions help
acclimate users to the new system to create robots ranging from humanoids
and machinery to animals and vehicles
* *****Digital wire interface allows for third-party developments*****
* Information, inspiration, news, community programs and more at
<http://www.mindstorms.com> www.mindstorms.com
***Too exciting! Does it mean I can write a third-party software to
interface with my bluetooth cell phone now!? I am so excited...If this is
true... I can see great and more challenging addition to our robotics club
in the future....
----------------------------------------------------------------------------
--------
Best Regards,
Elizabeth Mabrey Storming Robots,LLC
Director, M.S.C.S. Technology Learning
Center
3322 Rt. 22 West, Bldg 4, Ste 402 www.storming-robots.com
<http://www.storming-robots.com/>
Branchburg, NJ 08876 Partner of LEGO MINDSTORMS
Ph: (908) 595-1010 Robotics Community
Fax: (908) 891-2026
--
MIME ATTACHMENTS DISCARDED:
1. Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Length: 6730
|
|
| |
Approved: emabrey@storming-robots.com
from the lego press release...
...The heart of the new system is the NXT brick, an autonomous 32-bit LEGO
microprocessor that can be programmed using a PC, or for the first time in
the retail offering, a Mac. After building their robots, users create a
program within easy-to-use yet feature-rich software, powered by LabVIEW
from National Instruments. ...
(hmmm... will it be something similar to the Robolab interface??? )
...Downloading programs to an invention is easy. Users with
BluetoothR-enabled computer hardware can transfer their programs to the NXT
wirelessly,...
LEGO MINDSTORMS NXT highlights include:
* 32-bit processor
* All-new NXT intelligent brick
* 3 interactive servo motors feature inbuilt rotation sensors to align
speed for precise control
* New ultrasonic sensor makes robots "see" by responding to movement
* New sound sensor enables robots to react to sound commands,
including sound pattern and tone recognition
* Improved light sensor detects different colors and light intensity
* Improved touch sensor reacts to touch or release and allows robots
to feel
* 519 hand-selected, stylized elements from the LEGO TECHNICR building
system ensure robot creations will be sturdy and durable while also looking
authentic
* Opportunities for physical programming of robots and interaction
with robots during programming
* 18 building challenges with clear, step-by-step instructions help
acclimate users to the new system to create robots ranging from humanoids
and machinery to animals and vehicles
* *****Digital wire interface allows for third-party developments*****
* Information, inspiration, news, community programs and more at
www.mindstorms.com <http://www.mindstorms.com>
***Too exciting! Does it mean I can write a third-party software to
interface with my bluetooth cell phone now!? I am so excited...If this is
true... I can see great and more challenging addition to our robotics club
in the future....
----------------------------------------------------------------------------
--------
Best Regards,
Elizabeth Mabrey Storming Robots,LLC
Director, M.S.C.S. Technology Learning
Center
3322 Rt. 22 West, Bldg 4, Ste 402 www.storming-robots.com
<http://www.storming-robots.com/>
Branchburg, NJ 08876 Partner of LEGO MINDSTORMS
Ph: (908) 595-1010 Robotics Community
Fax: (908) 891-2026
|
|
| |
Hi everyone,
Wonder if anyone knows much about the NXT. Exciting addition, but I am
concerned with the software compatibility with the future Robolab 3.0. From
what I understand, beta Robolab 3.0 only is underway for Mac platform. How
about the windows platform? I signed up for the "Potential LEGO MINDSTORMS
NXT PIONEER" program. It will be great and fun to be able to contribute a
bit for this upcoming set.
Any reading material about this NXT will be greatly appreciated!
----------------------------------------------------------------------------
--------
Best Regards,
Elizabeth Mabrey
--
MIME ATTACHMENTS DISCARDED:
1. Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Length: 2344
|
|
| |
In lugnet.robotics.rcx.legos, Kyle Husmann wrote:
> Hi,
> I have been trying to get brickos to compile on my linux machine. I followed
> the instructions here:
> http://did.mat.uni-bayreuth.de/~matthias/veranstaltungen/ws2004/mindstorms/doc/brickos-howto.html
>
> I used binutils version 2.16.1, and gcc version 4.0.2.
>
> The cross compile seemed to work. However, when I try to compile brickos, I get
> the following error. Should I try a earlier version of binutils? What is the
> recomended gcc and binutils versions? Thanks for any help.
>
> PS: What is the official/proper way to build the cross compiler? If I use the
> regular "make install" with the /usr prefix, will it overwrite and files
> belonging to the native gcc already installed? I would like to know, because I
> am thinking of making a gcc-h8300-hms, binutils-h8300-hms, and brickos package
> for arch linux.
>
> /usr/local/H8300/bin/h8300-hms-as expandsf.s -o expandsf.o
> expandsf.s: Assembler messages:
> expandsf.s:121: Warning: mismatch between opcode size and operand size
> /usr/local/H8300/bin/h8300-hms-as joinsf.s -o joinsf.o
> joinsf.s: Assembler messages:
> joinsf.s:200: Warning: mismatch between opcode size and operand size
> /usr/local/H8300/bin/h8300-hms-as addsf3.s -o addsf3.o
> addsf3.s: Assembler messages:
> addsf3.s:187: Warning: mismatch between opcode size and operand size
> /usr/local/H8300/bin/h8300-hms-as negsf2.s -o negsf2.o
> /usr/local/H8300/bin/h8300-hms-as mulsf3.s -o mulsf3.o
> /usr/local/H8300/bin/h8300-hms-as divsf3.s -o divsf3.o
> /usr/local/H8300/bin/h8300-hms-as floatsisf.s -o floatsisf.o
> floatsisf.s: Assembler messages:
> floatsisf.s:138: Warning: mismatch between opcode size and operand size
> /usr/local/H8300/bin/h8300-hms-as cmpsf2.s -o cmpsf2.o
> /usr/local/H8300/bin/h8300-hms-as fixsfsi.s -o fixsfsi.o
> fixsfsi.s: Assembler messages:
> fixsfsi.s:195: Error: invalid operands
> make[2]: *** [fixsfsi.o] Error 1
> make[2]: Leaving directory `/usr/local/src/brickos-0.2.6.10.6/lib/float'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/usr/local/src/brickos-0.2.6.10.6/lib'
> make: *** [all] Error 2
Hi again,
I've got it working now, thanks to help from Jochen Hoenicke and Peter Gammie.
I've posted my notes on the process here, if anyone is interested:
http://home.comcast.net/~kyle-violin/linux/brickos/howto.html
However, now I've got a new problem... Everything was working great for about a
day, but now whenever I try to download firmware, I get a no response from rcx
error even though it is on, and the firmware has been reset. I think my serial
ir tower is broken :(
Thanks,
-Kyle
|
|
| |
On Thu, December 29, 2005 2:23 pm, Daniel Carvalho wrote:
>
> didn't find the c code in the url you mentioned. You used the same
> technique in the train, as in the legway?
Yes, I used the same code for controlling Legway as the Great Ball Contraption
train. That's what I posted here:
http://news.lugnet.com/robotics/rcx/legos/?n=3957
Steve
|
|
| |
>
>
> As Brian said, it's not the motors, it's the RCX. You can run Technic motors off a
> train controller, and you can vary the speed. But you need to do a bit more if
> you're using the RCX.
>
> We used that scheme when we controlled a train with an RCX.
>
> http://www.teamhassenplug.org/GBC/Train/
>
> There are plenty of ways to do what you want, this is just one of them. And, it is
> exactly the same as what you want.
>
> Steve
didn't find the c code in the url you mentioned. You used the same
technique in the train, as in the legway?
daniel
|
|
| |
Brian B. Alano wrote:
> I do think Steve is on the right track here. The train regulator varies the
> voltage, but the RCX output can't. So you are left with managing (nominally) 9v
> pulses. But there is another solution. You could add a DCC decoder to your train
> motor, and then use either LDCC or BrickOS with LDCC support to control your
> train. This way your RCX sends digital commands to the train and the DCC decoder
> takes care of speed and acceleration. Most DCC decoders have highly tunable
> performance parameters to get just the kind of control you are seeking.
thanks for the suggestion, Brian
I want to make some experimences with LDCC some day. But not in this
project.
daniel
|
|
| |
On Thu, December 29, 2005 11:33 am, Daniel Carvalho wrote:
> Steve Hassenplug wrote:
> > On Tue, December 27, 2005 4:49 pm, Daniel Carvalho wrote:
> > > I have a moc where i use the RCX to control a train with a lego train
> > > motor. • ...
> > One problem you'll run into with most software is that it switches between power
> > and
> > float to adjust the motor levels. It works much better to switch between power
> > and
> > brake. • ...
> > Using most software, the train will continue to speed up, even with the power set
> > low. (I've done this before, and it doesn't work well) • ...
> I think the problem is not exactly the same.
>
> The lego technic motors run always at the same speed so you need to use
> that kind of schema for speed control in robots. The train motors are
> different, they have a speed proportional to the output level (like the
> old technic motor).
As Brian said, it's not the motors, it's the RCX. You can run Technic motors off a
train controller, and you can vary the speed. But you need to do a bit more if
you're using the RCX.
We used that scheme when we controlled a train with an RCX.
http://www.teamhassenplug.org/GBC/Train/
There are plenty of ways to do what you want, this is just one of them. And, it is
exactly the same as what you want.
Steve
|
|
| |
I do think Steve is on the right track here. The train regulator varies the
voltage, but the RCX output can't. So you are left with managing (nominally) 9v
pulses. But there is another solution. You could add a DCC decoder to your train
motor, and then use either LDCC or BrickOS with LDCC support to control your
train. This way your RCX sends digital commands to the train and the DCC decoder
takes care of speed and acceleration. Most DCC decoders have highly tunable
performance parameters to get just the kind of control you are seeking.
That's the upside. The downside:
* Your top power output will be reduced (due to voltage drops in the DCC
decoder, I believe).
* You can still use your train in "analog" or normal mode, but the lowest
voltages won't work (because you must supply at least enough voltage to run the
DCC decoder's electronics first).
* Your track must be very clean to avoid dropouts in the signal.
* The LDCC firmware doesn't support scripting or programming. If you use
BrickOS, you may have to compile the LDCC support in yourself. LejOS is probably
too slow to permit an LDCC port in Java, you'd have to do it using native code.
Search LDCC on Lugnet for details.
Kind regards,
Brian A.
Daniel Carvalho wrote:
> >
> > hi Steve,
> >
> > I think the problem is not exactly the same.
In lugnet.robotics.rcx.legos, Daniel Carvalho wrote:
> hi Steve,
>
> I think the problem is not exactly the same.
>
> The lego technic motors run always at the same speed so you need to use
> that kind of schema for speed control in robots. The train motors are
> different, they have a speed proportional to the output level (like the
> old technic motor).
>
|
|
| |
Steve Hassenplug wrote:
> On Tue, December 27, 2005 4:49 pm, Daniel Carvalho wrote:
>
> > A couple of years ago, i used brickOS. Then, i changed to Lejos...
> >
> > I have a moc where i use the RCX to control a train with a lego train
> > motor. It is difficult to control the train with LejOS, because it only
> > has 8 output levels. Two solve the problem, i need to implement loops
> > that alternate two levels. But the result is not so smooth as i want. It
> > is the same thing with NQC and the official lego programming system.
> >
> > I've heard that BrickOS is different, because it doesn't use the
> > standard lego routines for output control. Do you thing i can get more
> > precise control of the train, with BrickOS?
> >
> > thanks
> >
> > daniel
>
>
>
>
> Daniel,
>
> One problem you'll run into with most software is that it switches between power and
> float to adjust the motor levels. It works much better to switch between power and
> brake.
>
> Using most software, the train will continue to speed up, even with the power set
> low. (I've done this before, and it doesn't work well)
>
> I used a scheme for my Legway robot, and it seemed to work very well. It stitches
> the power level ever 1ms, and has 8 forward "settings", and 8 backward settings.
> It's very simple, and works very well. Just set the variable MotorA, B or C to the
> speed you want the motor to go (a number between 0 and 16).
>
> Does this make sense?
hi Steve,
I think the problem is not exactly the same.
The lego technic motors run always at the same speed so you need to use
that kind of schema for speed control in robots. The train motors are
different, they have a speed proportional to the output level (like the
old technic motor).
But my problem is that i cannot control my train with the 8 power levels
Lejos has. If i have an loaded train, it won't move with power less than
4. When i change to 5, it will start to move. With 6, it will move fast
and 7 the same.
So, i need to use loops. I tried with brake and without brake. But the
result is not so smooth has when using the "Lego Train Speed Regulator"
(http://guide.lugnet.com/set/4548).
Since BrickOS has 256 power levels, maybe it is better. With that
precision, i think i can control the speed without using loops.
[Note: I think that, internaly, the BrickOS also use loops to set the
output level, but maybe they are more accurate.]
Anyone can try to connect an loaded train to rcx, and see if it can be
controlled??? For instance, use a program that sets the output vary
slowly from 0 to 255 and see if the train has a continuos aceleration.
I cannot try this because i still don't have BrickOS installed in my
computer. The last time i tried to install, it was very difficult. I had
to upgrade many packages.
daniel
|
|
| |
On Tue, December 27, 2005 4:49 pm, Daniel Carvalho wrote:
> A couple of years ago, i used brickOS. Then, i changed to Lejos...
>
> I have a moc where i use the RCX to control a train with a lego train
> motor. It is difficult to control the train with LejOS, because it only
> has 8 output levels. Two solve the problem, i need to implement loops
> that alternate two levels. But the result is not so smooth as i want. It
> is the same thing with NQC and the official lego programming system.
>
> I've heard that BrickOS is different, because it doesn't use the
> standard lego routines for output control. Do you thing i can get more
> precise control of the train, with BrickOS?
>
> thanks
>
> daniel
Daniel,
One problem you'll run into with most software is that it switches between power and
float to adjust the motor levels. It works much better to switch between power and
brake.
Using most software, the train will continue to speed up, even with the power set
low. (I've done this before, and it doesn't work well)
I used a scheme for my Legway robot, and it seemed to work very well. It stitches
the power level ever 1ms, and has 8 forward "settings", and 8 backward settings.
It's very simple, and works very well. Just set the variable MotorA, B or C to the
speed you want the motor to go (a number between 0 and 16).
Does this make sense?
---
int MotorSpeedArray[4] = {1,3,2,0};
// motor speed 0-7 = forward, 0 = fast, 7 = slow
// motor speed 8 = stop
// motor speed 9-16 = reverse, 9 = slow, 16 = full reverse
int MotorRunningValue;
[main loop]
{
...
MotorRunningValue = ((sys_time) & 7);
motor_a_dir(MotorA + MotorRunningValue) >> 3]);
motor_b_dir(MotorB + MotorRunningValue) >> 3]);
motor_c_dir(MotorC + MotorRunningValue) >> 3]);
}
---
Steve
|
|
| |
A couple of years ago, i used brickOS. Then, i changed to Lejos...
I have a moc where i use the RCX to control a train with a lego train
motor. It is difficult to control the train with LejOS, because it only
has 8 output levels. Two solve the problem, i need to implement loops
that alternate two levels. But the result is not so smooth as i want. It
is the same thing with NQC and the official lego programming system.
I've heard that BrickOS is different, because it doesn't use the
standard lego routines for output control. Do you thing i can get more
precise control of the train, with BrickOS?
thanks
daniel
|
|
| |
Hi,
I have been trying to get brickos to compile on my linux machine. I followed
the instructions here:
http://did.mat.uni-bayreuth.de/~matthias/veranstaltungen/ws2004/mindstorms/doc/brickos-howto.html
I used binutils version 2.16.1, and gcc version 4.0.2.
The cross compile seemed to work. However, when I try to compile brickos, I get
the following error. Should I try a earlier version of binutils? What is the
recomended gcc and binutils versions? Thanks for any help.
PS: What is the official/proper way to build the cross compiler? If I use the
regular "make install" with the /usr prefix, will it overwrite and files
belonging to the native gcc already installed? I would like to know, because I
am thinking of making a gcc-h8300-hms, binutils-h8300-hms, and brickos package
for arch linux.
/usr/local/H8300/bin/h8300-hms-as expandsf.s -o expandsf.o
expandsf.s: Assembler messages:
expandsf.s:121: Warning: mismatch between opcode size and operand size
/usr/local/H8300/bin/h8300-hms-as joinsf.s -o joinsf.o
joinsf.s: Assembler messages:
joinsf.s:200: Warning: mismatch between opcode size and operand size
/usr/local/H8300/bin/h8300-hms-as addsf3.s -o addsf3.o
addsf3.s: Assembler messages:
addsf3.s:187: Warning: mismatch between opcode size and operand size
/usr/local/H8300/bin/h8300-hms-as negsf2.s -o negsf2.o
/usr/local/H8300/bin/h8300-hms-as mulsf3.s -o mulsf3.o
/usr/local/H8300/bin/h8300-hms-as divsf3.s -o divsf3.o
/usr/local/H8300/bin/h8300-hms-as floatsisf.s -o floatsisf.o
floatsisf.s: Assembler messages:
floatsisf.s:138: Warning: mismatch between opcode size and operand size
/usr/local/H8300/bin/h8300-hms-as cmpsf2.s -o cmpsf2.o
/usr/local/H8300/bin/h8300-hms-as fixsfsi.s -o fixsfsi.o
fixsfsi.s: Assembler messages:
fixsfsi.s:195: Error: invalid operands
make[2]: *** [fixsfsi.o] Error 1
make[2]: Leaving directory `/usr/local/src/brickos-0.2.6.10.6/lib/float'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/local/src/brickos-0.2.6.10.6/lib'
make: *** [all] Error 2
|
|
| |
In lugnet.robotics.rcx.robolab, Elizabeth Mabrey wrote:
> Yes, I indeed have an attachment which will act like blockage,
> but not a full one though.
I'd agree that a physical block is the easiest, although there is a software
solution. The RCX can not recieve a command while it's transmitting - so if you
saturate the transmitter with things to do, it will not be able to "look" for
any incoming opcodes. The easiest way I know to do this is to send out blocks of
serial data - just sending the same block again & again in a tight loop will do
it. I discovered this accidently while testing something else (and the RCX
stopped responding to the remote, requiring me to chase it across the room as it
attacked innocent passerbys). The downside is battery life - adding one task to
transmit continuously won't slow things down a lot, but it will chew up battery
life. The upside is the RCX can be selectively "blind" to commands, and if it
needs to communicate with the outside IR world in can shut off such IR
"jamming".
--
Brian Davis
|
|
| |
Yes, I indeed have an attachment which will act like blockage, but not a
full one though. Sounds like this is the fastest and easiest to do. I
fully understand the opcodes concept, as I myself wrote compile code before.
However, these kids age only from 10 to 14. Well, needless, I won't even
attempt to do that.
That's very interesting. Thank you very much.
----------------------------------------------------------------------------
--------
Best Regards,
Elizabeth Mabrey
> -----Original Message-----
> From: news-gateway@lugnet.com
> [mailto:news-gateway@lugnet.com] On Behalf Of Steve Hassenplug
> Sent: Monday, December 05, 2005 9:47 AM
> To: lugnet.robotics.rcx.robolab@lugnet.com;
> lugnet.robotics.rcx.legos@lugnet.com
> Subject: Re: avoid messaging
>
> On Mon, December 5, 2005 8:58 am, Elizabeth Mabrey wrote:
> > Hi
> >
> > In order to avoid unwanted interruption, such as remote • shutdown, from
> > other RCX during execution time, I wonder if the only thing can be
> > done to safe-guard my RCX will be having an independent task
> > dedicated to receive message (mail). This, of course, • might be quite time consuming to the RCX.
> > I wonder if there is anyone out there using the same • hacking method
> > and observe any negative impact to the actual working task. • Or, the
> > negative impact may be negligible. Or, perhaps there is better and
> > smarter way to do this.
>
>
> If you have an event waiting for a message, I doubt it will
> have much impact on the speed of the rest of the program.
>
> However, this will not catch the messages you're looking for.
> You can't use the "mail" function to receive op-code, such
> as power off.
>
> A real quick intro to op-codes: (I don't have all the exact
> numbers, so this may not be 100% correct, and this is really
> not that quick...)
>
> When you send an op-code to the standard firmware, it should
> be of the format:
> 0x55,0xff,0x00,
> [command],[command_complement],
> [optional_argument],[optional_argument_complement],
> [check-sum],[check-sum_complement]
>
> The first three numbers (the header) tell the RCX the
> following message is something it should listen to (an op-code)
>
> The next two are the command, and the complement of the
> command. The command is a number, usually written in hex,
> like 0x60 or as a decimal, like 96. The complement is FF (or
> 255 dec) minus the command. The RCX uses this value to make
> sure the data is valid.
>
> After the command, there may be arguments, and their complements.
>
> Finally, is the check-sum (sum of command and arguments) and
> the complement of that sum.
>
> Clear as mud? :)
>
> So, if you send a message (mail) value of "3", the complete
> message that's sent via IR would be something like:
> 0x55, 0xff, 0x00, (header)
> 0xf7 (command to send message), 0x08 (complement),
> 0x03 (message to send), 0xfc (complement),
> 0xfa (checksum), 0x05 (complement)
>
> If you want to send a power off command:
> 0x55, 0xff, 0x00, (header)
> 0x60 (command to power off), 0x9f (complement),
> 0x60 (checksum), 0x9f (complement)
>
> The robolab mailbox will only receive the 'f7' command, which
> tells it to store the argument in the mailbox.
>
> With BrickOS, you can change the message handler, so your
> program can receive all messages (op-codes). But it's not as
> clear and easy as using Robolab.
>
>
> You should build a wall in front of your IR window. :)
>
> Steve
>
|
|
| |
On Mon, December 5, 2005 8:58 am, Elizabeth Mabrey wrote:
> Hi
>
> In order to avoid unwanted interruption, such as remote shutdown, from other
> RCX during execution time, I wonder if the only thing can be done to
> safe-guard my RCX will be having an independent task dedicated to receive
> message (mail). This, of course, might be quite time consuming to the RCX.
> I wonder if there is anyone out there using the same hacking method and
> observe any negative impact to the actual working task. Or, the negative
> impact may be negligible. Or, perhaps there is better and smarter way to do
> this.
If you have an event waiting for a message, I doubt it will have much impact on the
speed of the rest of the program.
However, this will not catch the messages you're looking for. You can't use the
"mail" function to receive op-code, such as power off.
A real quick intro to op-codes: (I don't have all the exact numbers, so this may not
be 100% correct, and this is really not that quick...)
When you send an op-code to the standard firmware, it should be of the format:
0x55,0xff,0x00,
[command],[command_complement],
[optional_argument],[optional_argument_complement],
[check-sum],[check-sum_complement]
The first three numbers (the header) tell the RCX the following message is something
it should listen to (an op-code)
The next two are the command, and the complement of the command. The command is a
number, usually written in hex, like 0x60 or as a decimal, like 96. The complement
is FF (or 255 dec) minus the command. The RCX uses this value to make sure the data
is valid.
After the command, there may be arguments, and their complements.
Finally, is the check-sum (sum of command and arguments) and the complement of that
sum.
Clear as mud? :)
So, if you send a message (mail) value of "3", the complete message that's sent via
IR would be something like:
0x55, 0xff, 0x00, (header)
0xf7 (command to send message), 0x08 (complement),
0x03 (message to send), 0xfc (complement),
0xfa (checksum), 0x05 (complement)
If you want to send a power off command:
0x55, 0xff, 0x00, (header)
0x60 (command to power off), 0x9f (complement),
0x60 (checksum), 0x9f (complement)
The robolab mailbox will only receive the 'f7' command, which tells it to store the
argument in the mailbox.
With BrickOS, you can change the message handler, so your program can receive all
messages (op-codes). But it's not as clear and easy as using Robolab.
You should build a wall in front of your IR window. :)
Steve
|
|
| |
Hi
In order to avoid unwanted interruption, such as remote shutdown, from other
RCX during execution time, I wonder if the only thing can be done to
safe-guard my RCX will be having an independent task dedicated to receive
message (mail). This, of course, might be quite time consuming to the RCX.
I wonder if there is anyone out there using the same hacking method and
observe any negative impact to the actual working task. Or, the negative
impact may be negligible. Or, perhaps there is better and smarter way to do
this.
Thanks for your input in advance!
----------------------------------------------------------------------------
--------
Best Regards,
Elizabeth Mabrey
--
MIME ATTACHMENTS DISCARDED:
1. Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Length: 2241
|
|
| |
Most of you are aware of the speed of the robot often causes parity in
distance via the feedback of rotation sensors because of inertia. In our
experiment, even with a robot with moderate speed. The parity seems to
often occur right at the beginning of the execution, i.e. when the robot
just starts to move. We use a rather thick tire for traction in order to
make the rotation feedback more consistent. However, this does not eliminate
the inertia problem. I wonder if there is any clever tip out in the wonder
lego galaxy.
I am planning to turn down the power level way down to 2 at the startup, and
then slowly increase back to the power level 5. I thought this method was
simply ahack, or am I way off base?
----------------------------------------------------------------------------
--------
Best Regards,
Elizabeth Mabrey
--
MIME ATTACHMENTS DISCARDED:
1. Content-Type: text/html;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Content-Length: 2089
|
|
| |
My club children, age 11 to 14, just started to make a writer... This is
different from what is in the Ferrari's book. The one we are attempting to
build is to load the pen into the center of the construction. RCX is
sitting on a mobile chassis. That means the RCX will be moving as it writes.
We try to use rack and pinion to do the lifting and lowering. The
difficulty is to keep the center of rotation close to a single point as
possible. Suggestion on reading ?
About programming it, we were talking about making each letter as a subvi.
Each letter vi itself has 5 subroutines. We are planning to create one
icon for each letter program so that the main program which is supposed to
write, e.g. , robot, will simply call on all the sub-vi letter programs
namely letterR.vi letterO.vi, letterB.vi, etc. However, I suspect I
cannot have more than 3 letters within one program, as it will load 15
subroutines already. Is that assumption correct?
----------------------------------------------------------------------------
--------
Best Regards,
Elizabeth Mabrey
--
MIME ATTACHMENTS DISCARDED:
1. Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Length: 2484
|
|
|
