 | | 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)
|
