User programming of NXT digital sensors is for advanced users. The average user will not use this capability.
Sensors on the NXT can be either analog or digital sensors.
· For analog sensors, one of the sensor input wires contains an analog value representing the value of the sensor.
· Digital sensors are more intelligent and typically contain a microprocessor. The sensor communicates with the NXT using the I2C serial communications protocol.
Each of the four sensor ports on the NXT can be configured as either a digital or analog sensor.
There are integrated device drivers for the LEGO developed sensors built into the RobotC firmware. If an application program wants to provide its own device drivers for either existing or new 3rd party sensors, it is important to set the sensor type to a “custom user provided device driver” so that there are no conflicts between the built-in device drivers and the user written code. There are four sensor types that are valid for application controlled digital sensors on a NXT. These are:
sensorI2CCustomStd Indicates that user program sensor using standard baud rate communications. Standard communications operates at about 1 byte transferred per millisecond.
sensorI2CCustomStd9V Same as above with the addition that battery voltage (i.e. 9V less the drop through a protection diode) is also provided on pin X for those sensors that want the higher voltage level.
sensorI2CCustomFast Indicates that user program sensor using enhanced baud rate communications. The enhanced baud rate is about five times faster than the standard baud rate. So far, all new 3rd party sensors that have been tested are compatible with the enhanced baud rate; in testing only the LEGO Sonar sensor requires use of the standard baud rate.
sensorI2CCustomFast9V Same as above with the addition that battery voltage (i.e. 9V less the drop through a protection diode) is also provided on pin X for those sensors that want the higher voltage level.
There are several sample programs in the RobotC distribution that illustrate the use of I2C messaging on the NXT with RobotC. There are a few things to remember in I2C messaging.
1. The reply bytes from an I2C “read” message are stored in a circular buffer until read by application program. Before sending an I2C “read” message, it is good practice to clear out any reply bytes that exist in the buffer.
2. I2C messaging can be slow. There are several bytes of protocol overhead on every message. In implementing a device driver, it is better to start up a task that continually sends I2C messages to periodically poll the sensor and stores the results. Within the user application it should simply retrieve the last polled value – i.e. no delay – rather than do an inline I2C read to get the sensor value. RobotC makes this very easy to achieve by allowing user programs to write as well as read the internal “SensorValue” array. The SensorValue” array is used to retrieve the value of a sensor from the internal device drivers.
3. You program should accommodate and recover from the occasional I2C messaging error. Lots of testing has indicated that most sensors experience errors rates of 10-3 to 10-5.
sendI2CMsg(nPort, sendMsg, nReplySize);
Send an I2C message on the specified sensor port.
nI2CBytesReady[]
This array contains the number of bytes available from a I2C read on the specified sensor port.
readI2CReply(nPort, replyBytes, nBytesToRead);
Retrieve the reply bytes from an I2C message
nI2CRetries
The standard firmware tries to send every I2C message three times before giving up and reporting an error. Unfortunately, this many retries can easily mask any faults that can exist. This variable allows changing the number of message retries.
nI2CStatus[]
Currents status of the selected sensor I2C link.