Just the other day I was searching a component suppliers’ website looking for sensors to integrate in a prototype IoT device. After scrolling through hundreds of devices, I realized that while sensors offered multiple options for interfacing to them, the IIC bus was by far the most prominent. IIC’s prolific use makes sense given that 127 devices can be addressed on a single bus which contains only four wires (Vcc, Ground, Data and Clock). The only problem with IIC is that writing a driver to read and write data to a slave device is complicated! The communication protocol isn’t simple and relies on ACKs, NAKs and carefully coordinated interrupts to be successful. A highly experienced and skilled developer can still require more than two weeks to implement an IIC driver and that is for master mode only. The Renesas Synergy ™ Platform has a built in IIC framework that we will be exploring in this post.
The IIC Application Framework provides developers with a way to quickly setup master to slave communication. Access to IIC takes place through the SF_I2C application framework but provides two options at the hardware abstraction; R_SCI_SIIC and R_RIIC. R_SCI_SIIC is a dual module that not only supports IIC but can also be used for serial communication. R_RIIC on the other hand is a dedicated IIC module. From the application framework layer, the API is standardized and is identical no matter which module is configured.
The IIC Application Framework provides developers with a simple API set that can be used to open multiple slave devices simultaneously. The API includes options to open, close, read, write and even reset a slave device. The framework tracks how many devices are currently open and even provides a timeout parameter for the read and write operations. I can’t tell you how many times I’ve seen developers write drivers that don’t include a timeout. They just assume that everything will be smooth sailings and bus noise or lock-ups will never occur.
Once the SF_IIC Application Framework has been added to the project, there are several items that require configuration. First, the RXI, TXI, TEI and ERI interrupt priorities need to be set. The IIC driver uses these interrupts to handle the slave communication flow. Next, the module channel needs to be selected. In the example above, the channel is set to the default 0 but the module used in the design would be selected. An initial slave device can also be set but this can also be changed later in the configuration. Developers can select either 7-bit or 10-bit addressing which can come in quite handy for extended address devices. The bus speed has three different options; Standard, Fast-Mode and Fast-Mode Plus. These correspond to 100 kbps, 400 kbps and 1000 kbps.
Finally, and most importantly there is a callback function. The callback is executed when an event such as transfer aborted, transfer completed or receive completed occurs. The callback is a great way for developers to coordinate their application behaviors using a mutex or message queue to communicate the result and any data to the application code.
Since communicating with external devices and sensors is such as important topic, next week we will look at the SPI Application Framework. In the mean-time,
Live long and profit!
Professor_IoT