This is a high level overview of the NXT I/O MAPs (IOMAPs). It’s compiled from information scattered among the recently released Development Kits (DKs). Many third party environments will require that developers have a good knowledge of the IOMAPs to do advanced NXT programming.

There’s 11 separate software “modules” in the NXT firmware. A memory mapped communication scheme is used between modules where each module exposes a block of RAM memory known as its “IOMAP”. The IOMAP becomes the external software interface between one module and its peers. A module is “commanded” (e.g. motor A forward at 50% power) to perform actions by modifying fields within its IOMAP and the results of that command (e.g. current rotation count) is “returned” in other fields.Let’s use a sensor as an example:

1. A user program initially configures a sensor by setting up two fields in the SENSOR IOMAP for the type and mode of the sensor (e.g. set up a sonar sensor with measurement units in cm.). The program should also set a third field that indicates the current sensor value is now invalid. The user program continues execution until its timeslice ends.
2. On its next execution time slice, the sensor module notices that the sensor’s type and mode fields have changed and performs the appropriate steps to initialize the sensor.
3. At some much later timeslice, the sensor has finally stabilized (10 to 20 milliseconds later, much longer for a SONAR sensor). The sensor module clears the “invalid value” flag in the IOMAP and updates the sensor value in its IOMAP but also.
4. During step 2 and 3, the user program has continued to run. When it tries to access this sensor, it should be checking to see if the “invalid data” has been cleared; it might ‘block’ until it is.
5. The sensor module is constantly running to update the IOMAP entry for sensor value with the latest values.

One corrollary is that changes requested by user programs do not happen immediately. User programs must be tolerant of this delay (i.e. check the “invalid data” field).

If you’re programming in the Lego/NI developed NXT-G system, IOMAP complexity is hidden from end user programming. You set a motor speed in a NXT-G block and do not have to understand that updates to several IOMAP fields for the motor are triggered by this one item. However, if you’re using a third party development environment, you may have to deal with all the low level IOMAP access.

RobotC, one of the first third party NXT IDEs, has an interface layer on top of the standard IOMAPs. This interface layer hides the IOMAPs from the end user while still providing access to all the device driver functionality.

IOMAPs are briefly described in several of the NXT Development Kits (DKs) that were released beginning of August 2006.

• The Fantom DK provides interfaces for getting a list of all the modules in the system and for reading and writing individual fields in a module’s IOMAP. You access an individual IOMAP by reading (writing) “offset X for Y bytes”.
• The Execution File Format DK (pg 44 onwards) gives a wealth of detail on the “property” fields for sensors and motors. Property fields look suspiciously like they are really IOMAP fields?
• The PC Direct Message DK describes about a dozen messages used between PC and NXT. Most of these messages look like they may be directly updating the IOMAPs for sounds, sensors, and motors.

Unfortunately the DKs did not provide the detailed internal layout of the IOMAP structures. Hopefully additional DK information will be released that will include this.