Subject:
|
Re: RCX Replacement Firmware
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 11 Nov 2004 10:04:00 GMT
|
Viewed:
|
1219 times
|
| |
|
|
"John Barnes" <barnes@sensors.com> wrote in message
news:I6uDu9.MqE@lugnet.com...
> > snip<<
>
> This may be the answer for people that need the speed but don't have
> the time,
> patience and understanding to get BrickOS up and running.
>
> Will there be a collaboration between yourself and John H. to sort out
> NQC
> support of the new features?
I hope this proves to be the case.
> Will there be some kind of user level "configuration" control which
> allows the
> user to set the maximum number of concurrent processes which will be
> started and
> thus the resource reservation necessary for it? I assume if a program
> can be
> started in an environment in which the answer is "1", then all kinds
> of indexing
> to the process context can vanish. I think I could really take
> advantage of a
> single thread running at max. speed!
There's user configuration control, but not over "concurrent processes".
The best way to think of it is that the opcode interpreter is a single
process which may share time among up to 10 tasks. It's very efficient
in its scheduling and sharing among those tasks and smart enough not to
give time to tasks that are not ready to run (as in waiting for timer to
expire, waiting for event). I think the interpreter gets 70-80% of the
total CPU time.
The other "processes" are sensor, motor, LCD, battery, IR and keypad
handlers. Most of their work is done at interrupt level. Except for the
LCD they all are very small. LCD is a bit of a time hog (it takes 2+
milliseconds to run and gets scheduled every N x 100 msec) so it can be
totally disabled.
Pretty comprehensive user control is available over system parameters.
Here's a selection of most of the #defines for NQC that enable this.
#define rcxParm1MsecTimer 22
#define rcxParmSystem 24
#define kSystemMotorTransition 6
#define kSystemOpcodesPerTimeslice 5
#define kSystemSensorRefreshRate 7
#define kSystemLCDRefreshRate 9
#define kSystemNoPowerDownOnACAdaptor 10
#define kSystemFloatDuringInactiveMotorPWM 14
#define kSystemSerialLinkStatus 4
#define Timer1(n) @((rcxParm1MsecTimer<<16) + (n))
#define nOpcodesPerTimeslice
@((rcxParmSystem<<16)+kSystemOpcodesPerTimeslice)
#define nMotorTransitionDelay
@((rcxParmSystem<<16)+kSystemMotorTransition)
#define nSensorRefresh
@((rcxParmSystem<<16)+kSystemSensorRefresh)
#define nLCDRefreshRate
@((rcxParmSystem<<16)+kSystemLCDRefreshRate)
#define bNoPowerDownOnAC
@((rcxParmSystem<<16)+kSystemNoPowerDownOnACAdaptor)
#define kSystemFloatDuringInactiveMotorPWM
@((rcxParmSystem<<16)+kSystemFloatDuringInactiveMotorPWM)
#define bSystemSerialLinkStatus
@((rcxParmSystem<<16)+kSystemSerialLinkStatus)
'Timer1' gives timer access at 1 millisecond resolution
'nOpcodesPerTimeslice' defines size of CPU time slices for the 10 task
'nMotorTransitionDelay' defines brake period delay when flipping motor
direction
'nSensorRefresh' defines frequency of sensor scans
'nLCDRefreshRate' defines frequency of LCD updates
'bNoPowerDownOnAC' is self-explanatory bool for 1.0 RCXs
'bFloatDuringInactiveMotorPWM' float or brake on inactive PWM
'bSystemSerialLinkStatus' allows checking if whether IR link is inactive
>
> What changes if any are made to the sensor power/acquisition timing
> cycles? This
> may affect the behaviour of some 3rd party sensors.
Sensor scanning is programmable. Default is 3 milliseconds which
provides full compatibility (hopefully) with standard firmware. Scanning
can be reconfigured with 'nSensorRefresh' variable described above in 1
millisecond steps from 1 to 255. Zero is a special case indicating 0.5
millisecond scanning. "group" A/D scanning is used (i.e. all four at
once and not one at a time; same as in standard firmware.
> Same question as regards the motor PWM frequency and timing.
Motor handling is designed to be compatible with standard firmware. I
did play around with using 0.5 instead of 1 millisecond PWM update but
didn't find it useful.
Motor power levels have been increased to 128 levels. However, power
levels can be accessed in the 0..7 or 0..127 range transparently and all
refer back to a single level. Similar to how timers can be accessed in
units of 1, 10, 100 milliseconds but all refer to the same timer.
I did change inactive PWM to provide option to use brake instead of
float. This was a trick I saw in Legway's implementation and thought it
might be useful. But I've done minimal experimentation on it.
Transition delay when flipping direction is programmable and
disableable. On standard firmware, it's fixed at 100 milliseconds.
> Again, fanatastic work. Please let us know when you are ready for the
> world at
> large to take this new beast for a test drive.
>
> JB
|
|
Message has 1 Reply:
 | | Re: RCX Replacement Firmware
|
| Will there be a collaboration to sort out the mesh with NQC? This is simply great stark news and very exciting stuff, and we do pass along a 'congrats'! Nonetheless, we urge (and will contribute whatever we can) towards the move to use NQC, as or (...) (20 years ago, 11-Nov-04, to lugnet.robotics)
|
Message is in Reply To:
| | Re: RCX Replacement Firmware
|
| (...) This sounds fantastic! This may be the answer for people that need the speed but don't have the time, patience and understanding to get BrickOS up and running. Will there be a collaboration between yourself and John H. to sort out NQC support (...) (20 years ago, 8-Nov-04, to lugnet.robotics)
|
13 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
