Helmut Schmücker / I2cRtosDriver

RTOS enabled i2c-driver based on the official i2c-C-api.

Dependencies:   mbed-rtos

Fork of mbed-RtosI2cDriver by Helmut Schmücker

I2cRtosDriver

Overview

• Based on RTOS
  • Less busy wait waste of CPU cycles
  • ... but some waste of CPU cycles by context switches
  • Frees up to 80% of CPU resources
• Fixes the bug described in https://mbed.org/forum/bugs-suggestions/topic/4128/
• Spends minimal time in interrupt context
• Supports I2C Master and Slave mode
• Interface compatible to official I2C lib
• Supports LPC1768 and LPC11U24.
• Reuses parts of the official I2C implementation
• The test and example programs work quite well and the results look promising. But this is by no means a thoroughly regression tested library. There might be some surprises left.
• If you want to avoid the RTOS overhead MODI2C might be a better choice.

Usage

• In existing projects simply replace in the I2C interface class declaration the official type by one of the adapters I2CMasterRtos or I2CSlaveRtos described below. The behavior should be the same.
• You can also use the I2CDriver interface directly.
• You can create several instances of I2CMasterRtos, I2CSlaveRtos and I2CDriver. The interface classes are lightweight and work in parallel.
• See also the tests/examples in I2CDriverTest01.h - I2CDriverTest05.h
• The I2CDriver class is the central interface
  • I2CDriver provides a "fat" API for I2C master and slave access
  • It supports on the fly changes between master and slave mode.
  • All requests are blocking. Other threads might do their work while the calling thread waits for the i2c requests to be completed.
  • It ensures mutual exclusive access to the I2C HW.
    • This is realized by a static RTOS mutex for each I2C channel. The mutex is taken by the calling thread on any call of an I2CDriver-function.
    • Thus accesses are prioritized automatically by the priority of the calling user threads.
    • Once having access to the interface the requests are performed with high priority and cannot be interrupted by other threads.
    • Optionally the interface can be locked manually. Useful if one wants to perform a sequence of commands without interruption.

• I2CMasterRtos and I2CSlaveRtos provide an interface compatible to the official mbed I2C interface. Additionally
  • the constructors provide parameters for defining the frequency and the slave address
  • I2CMasterRtos provides a function to read data from a given slave register
  • In contrast to the original interface the I2CSlaveRtos::receive() function is blocking, i.e it returns, when the master sends a request to the listening slave. There is no need to poll the receive status in a loop. Optionally a timeout value can be passed to the function.
  • The stop function provides a timeout mechanism and returns the status. Thus if someone on the bus inhibits the creation of a stop condition by keeping the scl or the sda line low the mbed master won't get freezed.
  • The interface adapters are implemented as object adapters, i.e they hold an I2CDriver-instance, to which they forward the user requests by simple inline functions. The overhead is negligible.

Design

The i2c read and write sequences have been realized in an interrupt service routine. The communicaton between the calling thread and the ISR is realized by a simple static transfer struct and a semaphore ... see i2cRtos_api.c
The start and stop functions still use the busy wait approach. They are not entered that frequently and usually they take less than 12µs at 100kHz bus speed. At 400kHz even less time is consumed. Thus there wouldn't be much benefit if one triggers the whole interrupt/task wait/switch sequence for that short period of time.

Performance

The following performance data have been measured with the small test applications in I2CDriverTest01.h and I2CDriverTest04.h . In these applications a high priority thread, triggered at a rate of 1kHz, reads on each trigger a data packet of given size with given I2C bus speed from a SRF08 ultra sonic ranger or a MPU6050 accelerometer/gyro. At the same time the main thread - running at a lower priority - counts in an endless loop adjacent increments of the mbed's µs-ticker API and calculates a duty cycle from this. These duty cycle measurements are shown in the table below together with the time measured for one read sequence (write address+register; write address and read x byte of data). The measurements have been performed with the ISR/RTOS approach used by this driver and with the busy wait approach used by the official mbed I2C implementation. The i2c implementation can be selected via #define PREFIX in I2CDriver.cpp.

• The time for one read cycle is almost the same for both approaches
• At full load the duty cycle of the low priority thread drops almost to zero for the busy wait approach, whereas with the RTOS/ISR enabled driver it stays at 80%-90% on the LPC1768 and above 65% on the LPC11U24.
• => Especially at low bus speeds and/or high data transfer loads the driver is able to free a significant amount of CPU time.

less smoke, actually it seems to work