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.
LPC17681byte/ms4byte/ms6byte/ms1byte/ms6byte/ms12byte/ms25byte/ms
SRF08@ 100kHz@ 100kHz@ 100kHz@ 400kHz@ 400kHz@ 400kHz@ 400kHz
rtos/ISRDC[%]91.791.090.593.391.990.386.8
t[µs]421714910141314518961
busy waitDC[%]57.127.78.185.868.748.23.8
t[µs]415710907128299503949
LPC17681byte/ms4byte/ms7byte/ms1byte/ms6byte/ms12byte/ms36byte/ms
MPU6050@ 100kHz@ 100kHz@ 100kHz@ 400kHz@ 400kHz@ 400kHz@ 400kHz
rtos/ISRDC[%]91.590.789.393.091.690.084.2
t[µs]415687959133254398977
busy waitDC[%]57.730.53.386.574.359.71.2
t[µs]408681953121243392974
LPC11U241byte/ms6byte/ms1byte/ms6byte/ms23byte/ms
SRF08@ 100kHz@ 100kHz@ 400kHz@ 400kHz@ 400kHz
rtos/ISRDC[%]79.277.581.178.771.4
t[µs]474975199374978
busy waitDC[%]51.82.480.5633.3
t[µs]442937156332928
LPC11U241byte/ms6byte/ms1byte/ms6byte/ms32byte/ms
MPU6050@ 100kHz@ 100kHz@ 400kHz@ 400kHz@ 400kHz
rtos/ISRDC[%]79.176.881.078.667.1
t[µs]466922188316985
busy waitDC[%]52.87.281.769.87.4
t[µs]433893143268895
Revision:
13:530968937ccb
Parent:
9:65aae53a34de
Child:
14:352609d395c1
--- a/I2CDriver.h	Fri May 10 07:34:24 2013 +0000
+++ b/I2CDriver.h	Fri May 10 20:38:35 2013 +0000
@@ -5,7 +5,6 @@
 
 #include "I2C.h"
 
-#include "Thread.h"
 #include "Mutex.h"
 
 namespace mbed
@@ -115,7 +114,7 @@
      *  general call address.
      */
     void addressSlave(int address) {
-        m_slaveAdr=address;
+        m_slaveAdr=(address & 0xff) | 1;
     }
 
     /** Checks to see if this I2C Slave has been addressed.
@@ -137,6 +136,7 @@
      *  @returns
      *       0 on success,
      *   non-0 otherwise
+     * ... no! instead it returns number of bytes read minus one ... weird, guess its a bug in the official lib
      */
     int readSlave(char *data, int length);
 
@@ -154,7 +154,7 @@
      *
      *  @returns
      *       0 on success,
-     *   non-0 otherwise
+     *   non-0 otherwise 
      */
     int writeSlave(const char *data, int length);
 
@@ -175,8 +175,10 @@
     ///Creates a stop condition on the I2C bus
     void stopSlave(void);
 
-    ///Creates a stop condition on the I2C bus
-    void stopMaster(void);
+    /// Creates a stop condition on the I2C bus
+    /// If unsccessful because someone on the bus holds the scl line down it returns "false" after 23µs 
+    /// In normal operation the stop shouldn't take longer than 12µs @ 100kHz and 3-4µs @ 400kHz. 
+    bool stopMaster(void);
 
     /// Wait until the i2c driver becomes available.
     ///
@@ -189,52 +191,30 @@
     void unlock();
 
 protected:
-    // commands sent from user to drive thread
-    enum Command {
-        START,
-        STOP,
-        READ_MST,
-        READ_MST_REG,
-        READ_SLV,
-        READ_BYTE,
-        WRITE_MST,
-        WRITE_SLV,
-        WRITE_BYTE,
-        RECEIVE
+    void config();
+    void lockNconfig() {
+        lock();
+        config();
+    }
+
+    // structure that holds I2C channels status
+    struct Channel {
+        rtos::Mutex mutex;
+        i2c_t i2c;
+        int freq;
+        int slaveAdr;
+        bool modeSlave;
     };
 
-    // data transfer struct for communication between user and driver thread
-    struct Transfer {
-        Command cmd;
-        int ret;
-        int freq;
-        int adr;
-        char* dta;
-        const char* wdta;
-        int len;
-        int ack;
-        bool rep;
-        uint8_t reg;
-        bool slv;
-        uint32_t tmout;
-        osThreadId caller;
-    };
+    // curren i2c configuration of this driver interface
+    int m_freq;
+    int m_slaveAdr;
+    bool m_modeSlave;
 
-    // structure that holds handles/locks for accessing the I2C channels
-    struct Channel {
-        osThreadId driver;
-        rtos::Mutex  mutex;
-        volatile Transfer transfer;
-    };
-
-    // current frequency setting
-    int m_freq;
-    // current slave address setting
-    int m_slaveAdr;
-    // prio of current caller thread
+    // id and prio of current caller thread
+    osThreadId m_callerID;
     osPriority m_callerPrio;
-    // ID of current caller thread
-    osThreadId m_callerID;
+    
 
     // i2c driver prio
     static const osPriority c_drvPrio = osPriorityRealtime;
@@ -245,14 +225,9 @@
     // static storage for the I2C channel access objects
     static Channel* s_channels[2];
 
-    // i2c channel object of this driver interface, in fact just pointer
+    // i2c channel object of this driver interface, in fact just a pointer
     /// to one of the entries in s_channels
     Channel* m_channel;
-
-    // the driver thread function
-    static void threadFun(void const *args);
-
-    int sendNwait();
 };
 }
 #endif