Task variables are currently overlaid with
the global variables as shown in the accompanying table. Note: it would be an easy
change to use unique address spaces if this has an advantage.The following is a description of the addition capabilities of the enhanced firmware over the standard Lego supplied firmware
End user program control of all options.
Replacement firmware is up to 100 times faster than the Lego
supplied firmware. Lego firmware typically takes 3.2 milliseconds per opcode.
In enhanced firmware (100X version), a no-op (opcode 0x10) opcode takes less
than 10 microseconds to execute! New firmware interprets 16-bit add or subtract
opcodes in under 30 microseconds. 16-bit conditional branch opcodes take 50 –
80 microseconds. Real-life measurements taken from live firmware. Time for
opcode execution includes all operating system overhead (scheduler, sensor
handling, LCD updates, interrupts, etc).
Typical performance appears to be 20,000 – 35,000 interpreter opcodes executed per second; these are actual measurements from a variety of sample programs. Standard Lego firmware does just over 300.
The performance improvements come from:
32-bit and floating opcodes are much slower. Floating point opcodes typically take 200+ microseconds each. This is because the H8 CPU is only an 8/16 bit CPU; arithmetic operations on ‘floats’ and ‘longs’ are done by software subroutines.
The objective was to provide backwards compatibility with standard Lego firmware. This has been substantially achieved. See separate section providing more details.
Standard Lego firmware supports 32 global variables and 16 variables per task. Replacement firmware expands support to 256 global variables.
Task variables are overlaid on the global variables 32 to 191.
New opcodes and intrinsic variables have been added to the firmware to support the expanded variable address space.
New opcodes and intrinsic variables have been added to firmware to support 32-bit long integers. Each long integer occupies the space of two consecutive 16-bit integers.
New opcodes and intrinsic variables have been added to firmware to support 32-bit float variables. Each long integer occupies the space of two consecutive 16-bit integers.
New firmware implements a single high-resolution (32-bit) clock variable with a one-millisecond period. Four Lego firmware compatible timers are then implemented using this clock variable.
New opcodes and intrinsic variables are implemented to provide full access to these timers. This includes variables that provide 1, 10 and 100-millisecond resolution; and new wait1Msec opcode to perform program waits using one millisecond resolution.
The Lego rotation counters are wonderful sensors. Internally they have a fan blade interrupting two optical transmitter/receiver pairs. This provides 16 counts per revolution; there are four states for the optical T/R as each of the four fan blades rotates through them. However the sensor frequently provide spurious readings as each fan blade transitions under a optical T/R. Depending on rotation speed, error rates range from 0.05% (very fast speed) to over 60% (very slow).
New firmware provides a powerful software state machine to (hopefully) provide perfect rotation counter support. The state machine filters and eliminates transient readings.
Standard Lego firmware scans rotation sensor every three milliseconds leading to a theoretical maximum speed of 333 counts per second. However, the asymmetrical nature of the fan blade – the gap is different size from the blade – reduces the maximum speed to about 220 counts. RobotC supports maximum speed of ~1,300 counts per second; six times the capacity of the standard Lego firmware.
New firmware allows customization of the sensor scan rate through a new intrinsic variable. A one-byte value holds the number of milliseconds in the scan interval. A value of zero indicates a 0.5 millisecond scan rate. Of course, as the scan rate is reduced, less CPU time is available for user programs; at 0.5 millisecond rate, the byte code interpreter is about twice as slow as the ‘standard’ 3 millisecond rate.
Firmware resets the scan rate to 3 milliseconds on RCX power up.
New firmware has been designed for tight integration with a new IDE providing powerful debugging capabilities from the PC. New opcodes and capabilities have been implemented for debugging support including:
Current programming environments do not support these new capabilities. A new IDE is required and one has been written that is currently in Alpha testing.
New firmware allows infrared messaging to be optionally configured to operate over four times faster than the standard Lego supplied firmware. This has value in two applications: [1] faster IR communication in multi-RCX applications and [2] faster communication between RCX and PC development environments.
On RCX power up, the messaging is always reset to the “standard” 2,400-baud values.
The new IDE currently in Alpha testing takes full advantage of the enhanced IR messaging. Features include:
Note: The Lego remote control only operates at the slow 2,400-baud speed. It is incompatible with the optional ability to configure RCX to operate at faster IR rates.
Three new enhancements to the motor control.
Standard Lego firmware provides eight levels of motor power levels. New firmware provides support for 128 levels of control. New opcodes and intrinsic variables are provided to provide full access to this expanded range. User programs can use either format at the power level is internally stored in the 128 level format and conversion to 8 level is provided when accessing this format.
Standard Lego firmware provides a 100-millisecond delay when changing powered motor direction to “prevent wear and tear on the motor gears”. The implementation appears to have a few software errors, as it doesn’t appear to always work. New firmware provides a clean implementation. The actual delay period is customizable from 0 to 255 milliseconds; a new intrinsic variable provides control over the interval.
There is a complicated relationship between power level and motor speed related to the actual load on the motor. It is not a linear relationship! Normally, the PWM (Pulse Wave Modulation) algorithm used to control motor provides periods of ‘power’ and ‘float’ to the motor; at higher power levels, there are more frequent ‘power’ intervals. A technique borrowed from Steve Hassenplug’s Legway is to replace the ‘float’ periods with ‘brake’. This provides a more linear relationship power level and speed; however, the motors become very noisy (grinding gears?). New firmware provides a new intrinsic variable for use of ‘brake’ for users who want to explore this functionality and perhaps wear out their motors faster.
New firmware implements a stack for each task. The stack is used to store subroutine return addresses and (future) local procedure variables and parameters. This functionality enables nested subroutine calls.
A new intrinsic variable allows customization of the size of task stack. The task stack is allocated when a task is first run. The stack remains allocated until the task is deleted.
It would be a relatively easy extension in the future to provide storage for procedure variables on the task. This would eliminate restrictions on running out of variables.
Standard Lego firmware supports only one level of subroutine call. New firmware supports nested subroutine calls. The number of nested subroutines is limited by the size of the allocated task stack; four bytes are used for each call. Default task size is four bytes.
New firmware includes a new intrinsic variable to store function return values. Usage of this feature will require changes to existing programming environments.
RobotC firmware provides expanded sound features.
New firmware provides several new intrinsic variables to tune the performance of the operating system. These include parameters like:
Enhanced firmware provides support for over 25 different exceptions. When an exception occurs, the byte code interpreter is suspended and a special display is posted to the RCX LCD.
Optionally the RCX can be configured to generate an autonomous exception report message that can be received by a PC-based IDE. When the new IDE is in debug mode it is continuously scanning for these exception messages and will pop up a window display the exception details.
Some of the different exceptions include:
Standard firmware only supports 8-bit message. The enhanced firmware has opcodes to support both 8-bit and 16-bit messages. 16-bit messages are useful in multi-RCX applications where 8-bit messages have inadequate bandwidth.
Standard Lego firmware supports eight subroutines for each of the five program slots. The lack of nested subroutines, return values and procedure parameters make it cumbersome to use more than eight slots with standard firmware. The RobotC overcomes these limitations facilitating extensive use of more subroutines as good programming practice.
RobotC firmware operates in two modes: [1] compatibility with standard firmware and [2] making all 40 subroutines available to a single program slot.
Enhanced firmware implements existing opcodes for backwards compatibility. Over 100 new opcodes have been implemented to provide enhanced functionality and improved performance. These opcodes provide the functionality described in the preceding text (256 variables, ‘long’ variables, ‘float’ variables, debugging support, expanded messaging, etc).
The best real time performance (100X and above) comes from compilers that support the use of the new real time optimized opcodes; using these opcodes probably contributes an additional 30% performance factor.
The enhanced firmware is believed to be compatible with existing NQC compiler. Existing NQC programs should run on the new firmware without change. They should take full advantage of the increased real time performance.
The new header file NewFirmware.nqh provides additional #defines to enable the incremental functionality of the enhanced firmware. The header file contains new intrinsic variables and opcode function definitions.. The file is well commented and a quick read will give a basic understanding of this functionality and how to use it.
There are a few issues that arise when trying to use these new variables in a NQC program
Seamless support by NQC (or other development systems and compiler) to the enhanced features will require.
One benefit of the enhanced firmware is more variables to a total of 256 global variables. The existing firmware has 32 global variables and 16 local variables for each of the ten tasks.
Task variables are currently overlaid with
the global variables as shown in the accompanying table. Note: it would be an easy
change to use unique address spaces if this has an advantage.
Memory variables in Lego’s firmware are accessed with a single address in the range 0-47. 0-31 is for global variables and 32-47 corresponds to task variables 0-15 for the currently running task. Local variables can only be accessed during execution of a task.
Interpreter variables are defined within the interpreter with a three byte “address”. The first byte is the type of variable (global/task variable = 0, sensor = 1, constant = 2 and so on); the remaining two bytes are the index/address within that type of variable. A new type (37) was defined to represent global variables.
Many opcodes use only one or two bytes to address a variable. One byte is used to implicitly reference a global/task variable; two bytes are used when the index/address byte is only a single byte. In particular, the arithmetic opcodes (+=. -=, *=, /=, …) always assume destination is a global/task variable. There is no way within existing opcodes to access the expanded range of global variables.
Eight arithmetic opcodes were defined in the enhanced firmware to support the expanded global variable range. The destination parameter of these opcodes is a global variable (0-255) rather than the combined global/task var (0-470. These opcodes have identical format and parameters as existing arithmetic opcodes to simplify conversion of programming systems.