 | | Re: DISTRIBUTED/PARALLEL CLUSTER for legOS through n*RCX
|
|
Hi there, did some worh with rcx/legos/DSM in my thesis which can be found at www.cs.uit.no/~kenne.../Thesis.ps Although i didnt share the memory of each rcx, i installed a dsm server(created at the local university) on a notebook which each rcx (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
Mark Riley wrote: > Actually, if we move the sys_time > handler back to OCRA (instead of the watchdog NMI), > then we could just check if bit 0 of sys_time is zero to > determine if the subsystem handler should be called (plus > this will get (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: DISTRIBUTED/PARALLEL CLUSTER for legOS through n*RCX
|
|
Yes Kekoa it's a bottle neck, as I wrote on the original message, the main idea is to distribute the load, with the MINIMUM amount of network traffic. I think that all the RCX should be connected through fibre optics, in order to implement the (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
Hi Marc, (...) Nice idea, but wouldn't that result in at least one of four cycles beeing blocked by OCRA? or is our system interrupt finished within less than 250msec? (...) Right, that was what I did for my Lepomux patch - works fine. Gunther (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
(...) My thought was that the OCRA interrupt could be used as the general 1ms interrupt and the subsystem handler (which is currently using OCRB) could be called every other time from the OCRA handler by using a flag (toggled every 1ms). Actually, (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: DISTRIBUTED/PARALLEL CLUSTER for legOS through n*RCX
|
|
Last year I built a robot which used multiple RCXs in the way you mention. I was building a sumo wrestling battle bot, and at some point ran out of sensor ports. For my sumo bot I'd built up some small abstraction layers around the sensors and (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: DISTRIBUTED/PARALLEL CLUSTER for legOS through n*RCX
|
|
Just a question about this. Won't the IR airwaves will be a major bottleneck for most parallel applications? -Kekoa (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
OCRA and OCRB are output interrupts for the 16 bit timer. They can be programmed to fire at specific points along the timers run. So, technically, they cannot be used independently of each other. If OCRA resets the timer value back to zero, then (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | DISTRIBUTED/PARALLEL CLUSTER for legOS through n*RCX
|
|
Hi all. I'm taking a course on parallel/distributed operating systems. So this post attempts to find out if someone has thought, or has implemented some kind of distributed application over BrickOS/legOS (from now legOS, for this post). I know (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
(...) Timer B is usually unused but has a lower priority than Timer A. If you do a lot of stuff in the timer A routine, this will block timer B interrupts (especially if timer B generates more interrupts than timer A). The mean thing is that those (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
From the second scope screen capture here : (URL) you can see that the analog settling time is about 10 microseconds for the rotation sensor. Philo www.philohome.com (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
(...) I've found that any interrupt on the RCX has a minimum overhead of 101 to 113 states (or about 7 us). This is the time taken by the CPU to recognize and dispatch the interrupt plus the time the ROM routine takes to dispatch the interrupt to (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
Joe, That's definitely an improvement! So, that would be a 250 Hz sample rate for any given sensor. I just tried a modification similar to yours that did all 4 conversions every OCRA/B interrupt (or 1 KHz sample rate) and got: IDLE: 82 2ROT: 77 (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
I did some "real world" tests with this update. I was Astounded at what a difference it makes. The bot I was testing with is a killough platform; which I had tried for hours previously, to get it to follow a line smoothly. I think BrickOS was giving (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
Mark, I retrieved the latest BrickOS from CVS, made clean and made the cpu test program you listed. I then made two small changes (to see what would happen); first the results, then the changes: IDLE: 89 2ROT: 87 NOAD: 91 (see below) NIRQ: 98 (see (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
(...) The delay was added a long time ago after a bit of discussion on this newsgroup/list. A search through old newsgroup posts will turn up a brief series of three posts with subject "Rom sensor read routine" from Apr/May 1999. The explanation (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Patches on SourceForge? A good/bad way to get changes into brickOS?
|
|
I've just posted (URL) note that there are 4 other patches lingering from as far back as September. Will my patch be looked at because it has been posted there? For info, here is the patch description The last version of binutils that brickOS works (...) (22 years ago, 14-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
This was a terrific analysis. It's not surprizing that current implementation hogs so much CPU time. If all four A/D channels are scanned every 150 us then the A/D interrupt is occuring every 37.5 us since each A/D channel generates its own (...) (22 years ago, 14-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
(...) This would be my favourites. If one builds a fast moving robot, main concern will be how fast the robot reacts to light sensor changes or how small the structures could be that the light sensor will "see". If one builds a thinking robot, for (...) (22 years ago, 14-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
Mark, ANOTHER great find! You are pushing BrickOS to new heights! Ok, so what can we do about this? 1) Provide a constant to set the update frequency at compile time. 2) Provide a variable to set the update frequency at run time. 3) Optimize the (...) (22 years ago, 14-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
Oops, found a little bug. ;-) Forgot to turn off the rotation sensors. Caused a wrong reading if you let the program run through the readings more than once. The rotation sensor section should read like this: // with two rotation sensors enabled (...) (22 years ago, 14-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Interesting BrickOS Timing Results
|
|
Hi All, The recent posts about interfacing an i2c device to an RCX sensor port (in .robotics) got me interested in looking at the kernel code that handles the sensors. So, I did and found myself looking at the ds_handler function. This function is (...) (22 years ago, 14-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | DJGPP Cross Compiler Progress
|
|
I have successfully built an h8300 cross compiler for DJGPP using the newest version of gcc 3.2. I was not successful using gcc 2.95.2, the current used gcc compiler with brickOS, and at the advice of others tried gcc 3.2. Since it is the goal of (...) (22 years ago, 13-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: make seems not to work / djgpp
|
|
(...) You should edit your Makefile. Regards, Michael (22 years ago, 12-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: make seems not to work / djgpp
|
|
(...) I do not have a djgpp directory. Which legos version do you have? First time the make command works, only not, when want start a new project. Reinhard (22 years ago, 12-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: make seems not to work
|
|
(...) Did you add the djgpp directory to your path? I don't remember everything I had to do, but here's a piece from MY autoexec.bat set path=c:\djgpp\bin;c:...til;%path% set djgpp=c:\djgpp\djgpp.env set shell=c:/djgpp/bin/sh.exe Steve (22 years ago, 12-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | make seems not to work
|
|
Hi! I try to compile a new programm (lightseeker.c) with make, but i only get this message (under WinLegos): make.exe: *** No rule to make target `lightseeker.lx', needed by `all'. Stop What is wrong? Reinhard (22 years ago, 12-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | brickRC - A gnome based, LNP using remote control/monitor app for the RCX
|
|
Hi, thanks to this group I got LNP working quite nicely. To get my fingers warm I wrote a little app to remote control the RCX with Linux. It also allows to monitor the input ports. It's quite usefull when you build a model and want to check the (...) (22 years ago, 12-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | brickOS with BricxCC
|
|
So far I have heard from two people who have successfully used brickOS with BricxCC. I'm interested in whether anyone else has tried using BricxCC to edit/compile/download programs to brickOS. Currently BricxCC requires that the cygwin bin directory (...) (22 years ago, 8-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | dll questions
|
|
I'm working on a new release of BricxCC at the moment and I want to better understand the dll utility - specifically the RCX host address and RCX source port options. I think I understand the RCX host address part. Correct me if I'm wrong. Supposing (...) (22 years ago, 8-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: makedepend variable in Makefiles
|
|
Investigating into this further, apparently from the comments in CVS, a change was made to the makefile in legOS\boot (Rev 1.2) and legOS\demo (Rev 1.2) some three years ago. The comment stated "replaced makedepend by MAKEDEPEND". But no similar (...) (22 years ago, 6-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: workaround.patch for h8300-hms-ld crash
|
|
(...) No problem. Stupid lugnet server stripped out the attachments. Here is the patch, both attached and inline. BrickOS maintainers: How about applying (some ideas from) this patch? Max Index: Makefile.user ===...=== RCS file: (...) (22 years ago, 6-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: LNP problem
|
|
(...) This works in deed! Thank you so much Michael! No way I would have found this myself. BB (22 years ago, 5-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: LNP problem
|
|
(...) Ok. This is indeed the result if you run the original LNP package. There are several problems with your sources, too. So try the following to get things done: First, go to the lnpd subdir and edit rcxtty.c. In function tty_init you find a line (...) (22 years ago, 5-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: LNP problem
|
|
(...) Thanks. Too bad it doesn't work, but at least now I know it's not me :) Please let me know if I can be of any help. BB (22 years ago, 5-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: LNP problem
|
|
(...) I know that this won't help, but I tried your program (and the lnptest.c program from the lnp distribution) and got the same errors. No message came through, only frame errors. Will have a closer look at this. Regards, Michael (22 years ago, 5-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: LNP problem
|
|
(...) You are right, that would have probably given me a segfaut if the handler would have ever been called, but it isn't. Even a single, static printf in the handler doesn't work. What worries me are the error messages lnpd reports: (...) (22 years ago, 5-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: LNP problem
|
|
(...) What about ptr = (char *)&temp; Regards Michael (22 years ago, 5-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | LNP problem
|
|
Hi, I'm just getting started using LNP, read the howto and tried to play around with the examples therein. However, somthing goes wrong. I have a little programm on the RCX increasing a counter every second, displaying it's value on the lCD and (...) (22 years ago, 5-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: BrickOS & LinuxUSB & lnpd
|
|
Hi, I would like to get your patches to make the tower and lnpd to w ork. I already have the tower working but I would like to see if did an ything different. So can you please send me your patches? (X) the patch to legotower.c to get the (...) (22 years ago, 4-Jan-03, to lugnet.robotics.rcx.legos)
|
