RP6 ROBOT SYSTEM - 5. Example Programs
Example 6: I²C Bus Interface – Master mode
Directory: <RP6Examples>\RP6_M256_WIFI_EXAMPLES\Example_06_I2CMaster\
File: RP6M256_06_I2CMaster.c
This program shows the use of the I2C bus master mode. The controller on the
main board of the robot must have loaded the I2C slave example program (RP6-
Base_I2CSlave.hex)!
This program shows how to control the microcontroller on the main board in slave
mode. This works only if the I²C bus slave example program from the RP6Base ex-
amples has been loaded into the controller on the main board.
Accessing the I²C bus works almost exactly as for the controller on the main board.
The same functions are used.
All registers of the slave example are read and then transmitted per WLAN – and
only per WLAN, not via the serial interface. A counter status is also displayed via the
LEDs on the main board.
Example 7: I²C Bus Interface – Master mode – react to interrupts
Directory: <RP6Examples>\RP6_M256_WIFI_EXAMPLES\Example_07_I2CMaster\
File: RP6M256_07_I2CMaster.c
This program shows the use of the I2C bus master mode. The controller on the
main board of the robot must have loaded the I2C slave example program (RP6-
Base_I2CSlave.hex)!
Maybe you already noticed the interrupt signals on the XBUS connectors of the RP6?
These can be used to react to sensor or status changes without permanently querying
the slaves via the I²C bus as every bus access costs quite some time.
The ACS on the robot mainboard is a good example. The sensor status changes only
quite
seldom
and it would not be very efficient to keep polling via the bus if something
has changed. As soon as the status of the ACS changes, the slave example program
will set the INT1 signal to high level. As INT1 is connected to one of the inputs of the
MEGA2560 on the RP6 CONTROL M256, the controller can react immediately to this
event and request the detail status of the controller on the main board via the bus.
However we don't use any interrupt routines to react to the event. Instead we poll the
status of the pin once in every cycle of the main loop. As the I²C bus transfers are
also interrupt controlled, a new transmission inside the interrupt routine is not pos-
sible. The task_I2CTWI() function that controls the process of the I²C transfer, must
always be called in the main loop before any transfer happens. Therefore there is no
point in using an interrupt routine. In fact, it would create problems because already
running I²C bus transmissions could be interrupted. So, only the function task_check-
INT() is used to poll the interrupt signal and eventually start a query. As soon as the
status register 0 of the slave is read, the interrupt signal will be reset. The first three
registers of the slave allow to find out what exactly has caused the interrupt.
This is exactly what the example program is doing. The outcome is that the current
status of the ACS is shown via the 4 LEDs, the LCD and the WLAN connection.
- 45 -
