 | | Re: Sensor Sampling; Progress?
|
|
I have been following this thread with great interest for two reasons. One day, someone will be persuaded to provide me with direct help and assistance in getting BrickOS running on my laptop - perhaps at BW or BF. I have built quite a few prototype (...) (22 years ago, 18-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Sensor Sampling; Progress?
|
|
Joe, Great job on taking the bull by the horns! The following are my suggestions on a system configuration. Please note that the term "divider" is being used here to indicate the function should only be performed every Nth interrupt. OCRA interrupt (...) (22 years ago, 18-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Sensor Sampling; Progress?
|
|
So far, I have reconfigured a copy of BrickOS in the following way: 1) Adjusted the clock_handler to improve the accuracy of the sys_time variable. Now running at very close (if not right on) 1 msec per tick. 2) Allowed the FRC (Free-Running (...) (22 years ago, 18-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: DISTRIBUTED/PARALLEL CLUSTER for legOS through n*RCX
|
|
Nick, What you propose it's another way, and of course, should work, but we might have to create another software layer over the current operating system of the RCX (of course, legOS), and we would loose 1 sensor per RCX. What I was trying to (...) (22 years ago, 17-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: DISTRIBUTED/PARALLEL CLUSTER for legOS through n*RCX
|
|
(...) An interesting idea. Presumably a light sensor alone would suffice, as it could be switched between active/passive mode to turn the LED on/off. You couldn't get high bandwidth, but there wouldn't be interference. Also, this would take multiple (...) (22 years ago, 17-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: brickOS with BricxCC
|
|
(...) Well, I guess I am one of the two :) Its nice to know I am on the cutting edge of things. Actually I am probably one of the few BrickOS users that is too dumb or impatient to deal with cygwin or unix. (...) Seems fine to me. I think all we (...) (22 years ago, 17-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | MIDI conversion
|
|
I have added a feature to BricxCC to convert MIDI files to NQC, MindScript, LASM, brickOS C, and brickOS Pascal code. It seems to work quite well with the first three languages (i.e., the sound generated by the RCX closely resembles the MIDI file (...) (22 years ago, 16-Jan-03, to lugnet.robotics.rcx.legos, lugnet.robotics.rcx.nqc)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
(...) I forgot to mention... This is *almost* the same as moving some of the subsystem code into a seperate high priority task. For example, LCD refresh code is executed in the 1ms timer ISR. It really doesn't need to be in the ISR. It can do it's (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
(...) 250msec? Not blocked entirely, but delayed. That's what I meant by "stutter". I've measured the general interrupt handler to take anywhere from 70-150us. So, the higher the sample rate the more significant the disruption. Anything faster than (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | RE: Interesting BrickOS Timing Results
|
|
(...) I have been following this thread in my peripheral vision for a while now. All of the talk is very interesting and appears to be leading to a general question about how and why the drivers are the way they are.... As a point of interest, some (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos, lugnet.robotics.rcx.pbforth)
|
| |
| | 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)
|
