To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcx.legosOpen lugnet.robotics.rcx.legos in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / legOS / Search Results: Mac BrickOS
 Results 181 – 200 of about 790.
Search took 0.00 CPU seconds. 

Messages:  Full | Brief | Compact
Sort:  Prefer Newer | Prefer Older | Best Match

  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)
 

brickos
(score: 1.291)

  Re: Communication between RCX's with BrickOS
 
...Problem Solved #include <lnp/lnp-logical.h> lnp_logical_range(1); I set the IR transmission range to far and everything works fine. It seems the issue was that the RCX's are not facing eachother and depend on bouncing mesages off a wall. I'm (...) (22 years ago, 3-Jan-03, to lugnet.robotics.rcx.legos)
 

brickos
(score: 1.291)

  Re: How do i make a program to run on brickos
 
(...) If you are running brickOS on a Windows machine then you should definitely consider using BricxCC to write your brickOS programs. John Hansen (22 years ago, 27-Jan-03, to lugnet.robotics.rcx.legos)
 

brickos
(score: 1.291)

  Float and int
 
Does anyone know what the maximum and minimum size of integer which can be stored is? Likewise, what is the floating point accuracy of BrickOS for variables of type "float" and "double" (is there such thing in BrickOS?) ? Both of these questions (...) (22 years ago, 29-Dec-02, to lugnet.robotics.rcx.legos)
 

brickos
(score: 1.291)

  RCXTTY-Variable Problem, calling ./firmdl3 ../boot/brickOS.srec
 
Hello, Dear NewsGroup ---...--- My Problem is: When I tri to download the BrickOS firmware to the Brick using ./firmdl3 ../boot/brickOS.srec after setting "RCXTTY=USB" with "export ...". (I have the USB-Tower) I get the following error: "USB: No (...) (22 years ago, 25-Jan-03, to lugnet.robotics.rcx.legos)
 

brickos
(score: 1.290)

  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)
 

brickos
(score: 1.290)

  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)
 

brickos
(score: 1.290)

  makedepend variable in Makefiles
 
While attempting to build brickOS under DJGPP I noticed a few discrepancies across the makefiles using the variable makedepend. Under the directories boot, demo, demo/c++ for the .depend rule it uses the variable $(MAKEDEPEND) while the makefiles in (...) (22 years ago, 2-Jan-03, to lugnet.robotics.rcx.legos)
 

brickos
(score: 1.290)

  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)
 

brickos
(score: 1.290)

  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)
 

brickos
(score: 1.290)

  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)
 

brickos
(score: 1.290)

  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)
 

brickos
(score: 1.290)

  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)
 

brickos
(score: 1.290)

  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)
 

brickos
(score: 1.290)

  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)
 

brickos
(score: 1.290)

  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)
 

brickos
(score: 1.290)

  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)
 

brickos
(score: 1.290)

  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)
 

brickos
(score: 1.290)

  RE: Float and int
 
(...) I'm doing a seminar at BricksWest on fixed point notation and simple algorithms for square root, trig, etc for BrickOS and pbForth users. The focus will be on the mechanics of the algorithms, the actual code implementation will be a "exercise (...) (22 years ago, 30-Dec-02, to lugnet.robotics.rcx.legos)
 

brickos
(score: 1.290)

  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)
 

brickos
(score: 1.290)

More:  Next Page >>


©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR