Modified version of the official mbed lib providing a RTOS enabled i2c-driver based on the official i2c-C-api.

Dependencies:   mbed-rtos mbed-src

mbed-RtosI2cDriver

This version is obsolete!

Please use this one:
http://mbed.org/users/humlet/code/I2cRtosDriver/

Overview

  • Based on RTOS
    • No busy wait waste of CPU cycles
    • ... but still some waste of CPU cycles by context switches
  • Spends minimal time in interrupt context
  • Supports I2C Master and Slave mode
  • Interface compatible to official I2C lib
  • Supports LPC1768 and LPC11U24.
    • Performs fine on the LPC1768, see measurements below
    • OK it works for the LPC11U24, but the performance data doesn't look that promising.
  • Reuses the official I2C implementation
    • Implemented with a few tiny but rather intrusive add-ons to the official I2C C-API
    • Updates of the official I2C lib can be easily merged into this library. Merges should be rather trivial.
    • Requires a rebuild of the mbed library (builds within a few seconds)
    • Official I2C interface not usable in parallel
  • The test and example programs works quite well and the results look promising. But this is by no means a thoroughly regression tested library. There might be some surprises.

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.
  • The declaration has to be done in thread context, i.e. in a thread function or in main. A global declaration does not work.
  • Don't use the original I2C interface classes. They don't work anymore.
  • 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 test/example implementations in I2CDriverTest01.h and I2CDriverTest02.h

Design

Basic Idea

Each time the official I2C implementation has requested the I2C controller to perform an action, it enters a central busy wait loop (i2c_wait_SI(...) in i2c_api.c) and simply polls the I2C controller until it reports that it has completed the request. By running the I2C API on a RTOS thread and replacing the busy wait loop by an RTOS signal wait, the wasted CPU time can be made available for other threads ... apart from interrupt latency and task switching overhead.

"Hack" of the I2C-API

Unfortunately this busy wait loop is located down in the i2C-C-API in the platform dependent mbed-NXP lib. Because I was too lazy to clone the whole interface and wanted to be able to easily merge updates of the official implementation to the driver, I decided to simply tweak the official implementation. The changes are rather small. Instead of entering a busy wait loop, the function i2c_wait_SI(...) now enables the I2C interrupt and waits for a RTOS semaphore. This semaphore is given by a tiny ISR. The ISR just releases the semaphore and then immediately disables the i2c interrupt. The disabling is necessary because, before the interrupt is cleared, the I2C controller HW expects new requests, which have not been applied yet. The first implementation utilized RTOS signals, but measurements revealed, that semaphores are slightly faster.
A second busy wait loop in the i2c_stop function has not been touched. It is not entered that frequently and does only take 10µs at 100kHz bus speed. At 400kHz even less time is consumed. Thus there wouldn't be any benefit if one triggers the whole interrupt task wait/switch sequence for that short period of time.
BTW: Since the last re-base to the latest version of the mbed-NXP lib (rev 10 by emilmont) the change set of i2c_api.c looks awful. The diff tool reports 900 changed lines, which is nonsense. This seems to be a bug of the diff tool. In fact there are only three additional blocks of code compared to the original revision, one at the top defining two additional local static functions, one in the i2c_wait_SI(..) function replacing the busy wait and one at the bottom behind the i2c_slave_receive(...) function.

Driver interface

The I2CDriver class is the central component of this I2C interface

  • On creation it registers the ISR and starts the high priority driver thread that runs the I2C accesses (if not already running).
  • Communication between the calling user thread and the high priority driver thread is realized by a simple static transfer struct and RTOS signals.
    • All requests are blocking.
    • I did not see much added value for implementing a more complex non-blocking buffered access using the RTOS mail or queue feature.
  • I2CDriver provides "fat" API for I2C master and slave access
    • It supports on the fly changes from master to slave mode and vice versa.
    • It ensures mutual exclusive access to the I2C HW. This is realized by a static RTOS mutex for each I2C channel that is taken by the calling thread on each call of an interface 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. In fact the user thread inherits the high priority of the driver thread during I2C access. The user thread does not do very much in the function call, it sends request to the driver thread and then waits for the driver thread to complete the request. The priority inheritance ensures that the I2C device is freed as fast as possible and prevents dead locks.
    • The interface can be locked for other threads, in order to run a sequence of commands without interruption
    • All interface functions are blocking, i.e. they return when the requested I2C transaction is completed.
    • Multiple I2CDriver instances are allowed

I2C Master/Slave Interface Adapters

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 he 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 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 should be negligible.
  • I thought of inheriting from the original interfaces in order to be able to pass the adapters as references of the original I2C/I2CSlave types to I2C access classes or functions. But I have decided against this approach because of the virtual function call overhead.

Performance

The following performance data have been measured with the small test application in I2CDriverTest01.h. In this application 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; read x byte of data). The measurements have been performed with the RTOS wait as used by this driver and with the busy wait approach used by the official mbed I2C implementation. The wait method has been selected by setting #define I2CDRVRTOS in i2c_api.c.

LPC1768
  • SRF08
    • The time for one read cycle is almost the same for both approaches
    • At full load (6byte/100kHz and 25byte@400kHz) the duty cycle of the low priority thread drops almost to zero for the busy wait approach, whereas it stays at 82% / 61% with the RTOS enabled driver.
    • The SRF08 seems to apply some clock stretching.
  • MPU6050 FIFO read:
    • At 100kz results are compatible with the SRF08
    • At 400kHz the MPU performs much better
      • Busy wait: No clock stretching at all is visible on a scope. The clock signal does not show any gaps.
      • RTOS wait: Between each byte a pause of 6µs shows up. These gaps are probably caused by the ISR->driver thread context switch. Thus the RTOS driver needs some more time to complete a read cycle.
      • When using the RTOS driver at full load (30byte/ms@400kHz), still 56% of the CPU time is available for other threads. This is more than 3.3 times the 16.8% observed with he official i2c implementation.
  • => Especially at low bus speeds and/or high data transfer loads the driver is able to free a significant amount of CPU time.
  • Comparison: MODI2C claims to achieve an efficiency resulting in a duty cycle of 75% at 400kHz. Sounds much better. OK, it is expected to be more efficient, because it operates completely in interrupt context (25%) and does not suffer from any RTOS overhead. ... and some of the 75% the user might spend for busy wait checking that the non blocking commands have completed.
LPC17681byte/ms4byte/ms6byte/ms1byte/ms6byte/ms12byte/ms25byte/ms
SRF08@ 100kHz@ 100kHz@ 100kHz@ 400kHz@ 400kHz@ 400kHz@ 400kHz
rtosDC[%]88.184.582.189.583.876.761.4
waitt[µs]438734930160334541996
busyDC[%]54.625.15.483.466.145.30.28
waitt[µs]433733930144317530984
LPC17681byte/ms4byte/ms6byte/ms1byte/ms6byte/ms12byte/ms30byte/ms
MPU6050@ 100kHz@ 100kHz@ 100kHz@ 400kHz@ 400kHz@ 400kHz@ 400kHz
rtosDC[%]81.484.682.389.683.876.956.2
waitt[µs]430712894155298475999
busyDC[%]65.628.410.384.863.159.016.8
waitt[µs]430700880131249389816
LPC11U24
  • Here the results don't look that promising
  • At a bus speed of 100kHz a slightly higher duty cycle can be achieved for the low priority thread
  • At a bus speed of 400kHz the busy wait approach shows better results
  • Keep in mind that the RTOS lib consumes a significant amount of the 11U24's small memory
LPC11U241byte/ms4byte/ms1byte/ms6byte/ms16byte/ms
MPU6050@ 100kHz@ 100kHz@ 400kHz@ 400kHz@ 400kHz
rtosDC[%]36.127.735.424.63.0
waitt[µs]525-569836-880256465-512884-935
busyDC[%]32.610.441.034.621.6
waitt[µs]475-517749-790184303542-589

A second test application (I2CDriverTest01.h) makes the mbed LPC1768 talk to itself. The two I2C channels are directly connected and master/slave mode of the two I2C interfaces are changed on the fly. The communication has been tested to work synchronously and stable at 100kHz and 400kHz.

Committer:
humlet
Date:
Sat Apr 20 09:52:09 2013 +0000
Revision:
4:eafa7efcd771
Parent:
3:967dde37e712
Child:
5:8a418c89e515
running

Who changed what in which revision?

UserRevisionLine numberNew contents of line
humlet 0:13c962fecb13 1 #include "I2CDriver.h"
humlet 3:967dde37e712 2 #include "i2c_api.h"
humlet 0:13c962fecb13 3 #include "error.h"
humlet 0:13c962fecb13 4
humlet 1:90455d5bdd8c 5 using namespace mbed;
humlet 1:90455d5bdd8c 6 using namespace rtos;
humlet 0:13c962fecb13 7
humlet 2:514105beb343 8 #define I2C_ISR_DRV_SIG (1<<7)
humlet 1:90455d5bdd8c 9 #define DRV_USR_SIG (1<<6)
humlet 1:90455d5bdd8c 10
humlet 1:90455d5bdd8c 11 const PinName I2CDriver::c_sdas[] = {p9,p28};
humlet 1:90455d5bdd8c 12 const PinName I2CDriver::c_scls[] = {p10,p27};
humlet 1:90455d5bdd8c 13
humlet 1:90455d5bdd8c 14 I2CDriver::Channel* I2CDriver::s_channels[2] = {0,0};
humlet 0:13c962fecb13 15
humlet 0:13c962fecb13 16
humlet 0:13c962fecb13 17 void I2CDriver::channel_0_ISR()
humlet 0:13c962fecb13 18 {
humlet 2:514105beb343 19 osSignalSet( s_channels[0]->driver, I2C_ISR_DRV_SIG);
humlet 1:90455d5bdd8c 20 NVIC_DisableIRQ(I2C1_IRQn);
humlet 0:13c962fecb13 21 }
humlet 0:13c962fecb13 22
humlet 0:13c962fecb13 23
humlet 0:13c962fecb13 24 void I2CDriver::channel_1_ISR()
humlet 0:13c962fecb13 25 {
humlet 2:514105beb343 26 osSignalSet( s_channels[1]->driver, I2C_ISR_DRV_SIG);
humlet 1:90455d5bdd8c 27 #if defined(TARGET_LPC1768) || defined(TARGET_LPC2368)
humlet 1:90455d5bdd8c 28 NVIC_DisableIRQ(I2C2_IRQn);
humlet 1:90455d5bdd8c 29 #elif defined(TARGET_LPC11U24)
humlet 1:90455d5bdd8c 30 NVIC_DisableIRQ(I2C_IRQn);
humlet 1:90455d5bdd8c 31 #endif
humlet 0:13c962fecb13 32 }
humlet 0:13c962fecb13 33
humlet 0:13c962fecb13 34
humlet 3:967dde37e712 35 I2CDriver::I2CDriver(PinName sda, PinName scl, int hz, int slaveAdr):m_freq(hz),m_slaveAdr(slaveAdr)
humlet 3:967dde37e712 36 {
humlet 3:967dde37e712 37 // check pins and determine i2c channel
humlet 3:967dde37e712 38 int channel=0;
humlet 3:967dde37e712 39 #if defined(TARGET_LPC1768) || defined(TARGET_LPC2368)
humlet 3:967dde37e712 40 if(sda==c_sdas[0] && scl==c_scls[0]) channel=0; // I2C_1
humlet 3:967dde37e712 41 else
humlet 3:967dde37e712 42 #endif
humlet 3:967dde37e712 43 if (sda==c_sdas[1] && scl==c_scls[1]) channel=1; //I2C_2 or I2C
humlet 3:967dde37e712 44 else error("I2CDriver: Invalid I2C pinns selected");
humlet 3:967dde37e712 45
humlet 3:967dde37e712 46 if(s_channels[channel]==0)
humlet 3:967dde37e712 47 new Thread(threadFun,(void *)channel,osPriorityRealtime,512);
humlet 3:967dde37e712 48 m_channel = s_channels[channel];
humlet 3:967dde37e712 49 }
humlet 3:967dde37e712 50
humlet 3:967dde37e712 51
humlet 1:90455d5bdd8c 52 void I2CDriver::threadFun(void const *args)
humlet 0:13c962fecb13 53 {
humlet 0:13c962fecb13 54 int channelIdx = (int)args;
humlet 0:13c962fecb13 55 Channel channel;
humlet 0:13c962fecb13 56 s_channels[channelIdx] = &channel;
humlet 2:514105beb343 57 channel.driver = Thread::gettid();
humlet 0:13c962fecb13 58
humlet 1:90455d5bdd8c 59 #if defined(TARGET_LPC1768) || defined(TARGET_LPC2368)
humlet 0:13c962fecb13 60 if(channelIdx==0)NVIC_SetVector(I2C1_IRQn, (uint32_t)I2CDriver::channel_0_ISR);
humlet 0:13c962fecb13 61 if(channelIdx==1)NVIC_SetVector(I2C2_IRQn, (uint32_t)I2CDriver::channel_1_ISR);
humlet 1:90455d5bdd8c 62 #elif defined(TARGET_LPC11U24)
humlet 1:90455d5bdd8c 63 NVIC_SetVector(I2C_IRQn, (uint32_t)I2CDriver::channel_1_ISR);
humlet 1:90455d5bdd8c 64 #endif
humlet 2:514105beb343 65
humlet 3:967dde37e712 66 int freq = 0;
humlet 3:967dde37e712 67 int adrSlave = 0;
humlet 3:967dde37e712 68 int modeSlave = 0;
humlet 3:967dde37e712 69 i2c_t i2c;
humlet 3:967dde37e712 70 i2c_init(&i2c, c_sdas[channelIdx], c_scls[channelIdx]);
humlet 2:514105beb343 71
humlet 1:90455d5bdd8c 72 volatile Transfer& tr = channel.transfer;
humlet 0:13c962fecb13 73 while(1) {
humlet 1:90455d5bdd8c 74 // wait for requests
humlet 1:90455d5bdd8c 75 osSignalWait(DRV_USR_SIG,osWaitForever);
humlet 3:967dde37e712 76
humlet 1:90455d5bdd8c 77 // check and adapt frequency
humlet 3:967dde37e712 78 if(freq != tr.freq) {
humlet 3:967dde37e712 79 freq = tr.freq;
humlet 3:967dde37e712 80 i2c_frequency(&i2c, tr.freq);
humlet 1:90455d5bdd8c 81 }
humlet 3:967dde37e712 82
humlet 3:967dde37e712 83 // check and adapt slave/master mode
humlet 3:967dde37e712 84 if(modeSlave != tr.slv) {
humlet 3:967dde37e712 85 modeSlave = tr.slv;
humlet 3:967dde37e712 86 i2c_slave_mode(&i2c, tr.slv);
humlet 3:967dde37e712 87 }
humlet 3:967dde37e712 88
humlet 3:967dde37e712 89 // check and adapt slave address
humlet 3:967dde37e712 90 int adr = (tr.adr & 0xFF) | 1;
humlet 3:967dde37e712 91 if(tr.slv && adrSlave != adr) {
humlet 3:967dde37e712 92 adrSlave = adr;
humlet 3:967dde37e712 93 i2c_slave_address(&i2c, 0, adr, 0);
humlet 3:967dde37e712 94 }
humlet 3:967dde37e712 95
humlet 1:90455d5bdd8c 96 // just doit
humlet 1:90455d5bdd8c 97 switch(tr.cmd) {
humlet 0:13c962fecb13 98 case START:
humlet 3:967dde37e712 99 i2c_start(&i2c);
humlet 0:13c962fecb13 100 break;
humlet 0:13c962fecb13 101 case STOP:
humlet 3:967dde37e712 102 i2c_stop(&i2c);
humlet 0:13c962fecb13 103 break;
humlet 3:967dde37e712 104 case READ_MST:
humlet 3:967dde37e712 105 tr.ret = i2c_read(&i2c, tr.adr, tr.dta, tr.len, (tr.rep?0:1));
humlet 1:90455d5bdd8c 106 break;
humlet 3:967dde37e712 107 case READ_MST_REG:
humlet 3:967dde37e712 108 tr.ret = i2c_write(&i2c, tr.adr,(const char*)&(tr.reg), 1, 0);
humlet 1:90455d5bdd8c 109 if(tr.ret)break; // error => bail out
humlet 3:967dde37e712 110 tr.ret = i2c_read(&i2c, tr.adr, tr.dta, tr.len, (tr.rep?0:1));
humlet 3:967dde37e712 111 break;
humlet 3:967dde37e712 112 case READ_SLV:
humlet 3:967dde37e712 113 tr.ret = i2c_slave_read(&i2c, tr.dta, tr.len);
humlet 1:90455d5bdd8c 114 break;
humlet 1:90455d5bdd8c 115 case READ_BYTE:
humlet 3:967dde37e712 116 tr.ret = i2c_byte_read(&i2c, (tr.ack?0:1));
humlet 1:90455d5bdd8c 117 break;
humlet 3:967dde37e712 118 case WRITE_MST:
humlet 3:967dde37e712 119 tr.ret = i2c_write(&i2c, tr.adr, tr.wdta, tr.len, (tr.rep?0:1));
humlet 3:967dde37e712 120 break;
humlet 3:967dde37e712 121 case WRITE_SLV:
humlet 3:967dde37e712 122 tr.ret = i2c_slave_write(&i2c, tr.wdta, tr.len);
humlet 1:90455d5bdd8c 123 break;
humlet 1:90455d5bdd8c 124 case WRITE_BYTE:
humlet 3:967dde37e712 125 tr.ret = i2c_byte_write(&i2c, tr.ack);
humlet 1:90455d5bdd8c 126 break;
humlet 3:967dde37e712 127 case RECEIVE:
humlet 3:967dde37e712 128 tr.ret = i2c_slave_receive_rtos(&i2c, tr.tmout);
humlet 4:eafa7efcd771 129 break;
humlet 1:90455d5bdd8c 130 default:
humlet 4:eafa7efcd771 131 error("call 911\n");
humlet 0:13c962fecb13 132 }
humlet 1:90455d5bdd8c 133 // inform the caller
humlet 1:90455d5bdd8c 134 osSignalSet( channel.transfer.caller, DRV_USR_SIG);
humlet 0:13c962fecb13 135 }
humlet 0:13c962fecb13 136 }
humlet 0:13c962fecb13 137
humlet 3:967dde37e712 138 int I2CDriver::sendNwait()
humlet 0:13c962fecb13 139 {
humlet 3:967dde37e712 140 m_channel->transfer.freq = m_freq;
humlet 1:90455d5bdd8c 141 m_channel->transfer.caller = Thread::gettid();
humlet 1:90455d5bdd8c 142 osSignalSet( m_channel->driver, DRV_USR_SIG);
humlet 0:13c962fecb13 143 osSignalWait(DRV_USR_SIG,osWaitForever);
humlet 1:90455d5bdd8c 144 int ret = m_channel->transfer.ret;
humlet 1:90455d5bdd8c 145 unlock();
humlet 1:90455d5bdd8c 146 return ret;
humlet 0:13c962fecb13 147 }
humlet 0:13c962fecb13 148
humlet 3:967dde37e712 149 int I2CDriver::readMaster(int address, char *data, int length, bool repeated)
humlet 1:90455d5bdd8c 150 {
humlet 1:90455d5bdd8c 151 lock();
humlet 3:967dde37e712 152 m_channel->transfer.cmd = READ_MST;
humlet 3:967dde37e712 153 m_channel->transfer.slv = false;
humlet 1:90455d5bdd8c 154 m_channel->transfer.adr = address;
humlet 1:90455d5bdd8c 155 m_channel->transfer.dta = data;
humlet 1:90455d5bdd8c 156 m_channel->transfer.len = length;
humlet 1:90455d5bdd8c 157 m_channel->transfer.rep = repeated;
humlet 3:967dde37e712 158 return sendNwait();
humlet 1:90455d5bdd8c 159 }
humlet 1:90455d5bdd8c 160
humlet 3:967dde37e712 161 int I2CDriver::readMaster(int address, uint8_t _register, char *data, int length, bool repeated)
humlet 3:967dde37e712 162 {
humlet 3:967dde37e712 163 lock();
humlet 3:967dde37e712 164 m_channel->transfer.cmd = READ_MST_REG;
humlet 3:967dde37e712 165 m_channel->transfer.slv = false;
humlet 3:967dde37e712 166 m_channel->transfer.adr = address;
humlet 3:967dde37e712 167 m_channel->transfer.reg = _register;
humlet 3:967dde37e712 168 m_channel->transfer.dta = data;
humlet 3:967dde37e712 169 m_channel->transfer.len = length;
humlet 3:967dde37e712 170 m_channel->transfer.rep = repeated;
humlet 3:967dde37e712 171 return sendNwait();
humlet 3:967dde37e712 172 }
humlet 3:967dde37e712 173
humlet 3:967dde37e712 174 int I2CDriver::readMaster(int ack)
humlet 1:90455d5bdd8c 175 {
humlet 1:90455d5bdd8c 176 lock();
humlet 1:90455d5bdd8c 177 m_channel->transfer.cmd = READ_BYTE;
humlet 3:967dde37e712 178 m_channel->transfer.slv = false;
humlet 1:90455d5bdd8c 179 m_channel->transfer.ack = ack;
humlet 3:967dde37e712 180 return sendNwait();
humlet 1:90455d5bdd8c 181 }
humlet 1:90455d5bdd8c 182
humlet 3:967dde37e712 183 int I2CDriver::writeMaster(int address, const char *data, int length, bool repeated)
humlet 1:90455d5bdd8c 184 {
humlet 0:13c962fecb13 185 lock();
humlet 3:967dde37e712 186 m_channel->transfer.cmd = WRITE_MST;
humlet 3:967dde37e712 187 m_channel->transfer.slv = false;
humlet 1:90455d5bdd8c 188 m_channel->transfer.adr = address;
humlet 1:90455d5bdd8c 189 m_channel->transfer.wdta = data;
humlet 1:90455d5bdd8c 190 m_channel->transfer.len = length;
humlet 1:90455d5bdd8c 191 m_channel->transfer.rep = repeated;
humlet 3:967dde37e712 192 return sendNwait();
humlet 1:90455d5bdd8c 193 }
humlet 1:90455d5bdd8c 194
humlet 3:967dde37e712 195 int I2CDriver::writeMaster(int data)
humlet 1:90455d5bdd8c 196 {
humlet 1:90455d5bdd8c 197 lock();
humlet 1:90455d5bdd8c 198 m_channel->transfer.cmd = WRITE_BYTE;
humlet 3:967dde37e712 199 m_channel->transfer.slv = false;
humlet 1:90455d5bdd8c 200 m_channel->transfer.ack = data;
humlet 3:967dde37e712 201 return sendNwait();
humlet 0:13c962fecb13 202 }
humlet 1:90455d5bdd8c 203
humlet 3:967dde37e712 204 void I2CDriver::startMaster(void)
humlet 1:90455d5bdd8c 205 {
humlet 1:90455d5bdd8c 206 lock();
humlet 1:90455d5bdd8c 207 m_channel->transfer.cmd = START;
humlet 3:967dde37e712 208 m_channel->transfer.slv = false;
humlet 1:90455d5bdd8c 209 sendNwait();
humlet 3:967dde37e712 210 }
humlet 3:967dde37e712 211
humlet 3:967dde37e712 212 void I2CDriver::stopMaster(void)
humlet 3:967dde37e712 213 {
humlet 3:967dde37e712 214 lock();
humlet 3:967dde37e712 215 m_channel->transfer.cmd = STOP;
humlet 3:967dde37e712 216 m_channel->transfer.slv = false;
humlet 3:967dde37e712 217 sendNwait();
humlet 3:967dde37e712 218 }
humlet 3:967dde37e712 219
humlet 3:967dde37e712 220 void I2CDriver::stopSlave(void)
humlet 3:967dde37e712 221 {
humlet 3:967dde37e712 222 lock();
humlet 3:967dde37e712 223 m_channel->transfer.cmd = STOP;
humlet 3:967dde37e712 224 m_channel->transfer.slv = true;
humlet 3:967dde37e712 225 m_channel->transfer.adr = m_slaveAdr;
humlet 3:967dde37e712 226 sendNwait();
humlet 3:967dde37e712 227 }
humlet 3:967dde37e712 228
humlet 3:967dde37e712 229 int I2CDriver::receiveSlave(uint32_t timeout_ms)
humlet 3:967dde37e712 230 {
humlet 3:967dde37e712 231 lock();
humlet 3:967dde37e712 232 m_channel->transfer.cmd = RECEIVE;
humlet 3:967dde37e712 233 m_channel->transfer.slv = true;
humlet 3:967dde37e712 234 m_channel->transfer.adr = m_slaveAdr;
humlet 3:967dde37e712 235 m_channel->transfer.tmout = timeout_ms;
humlet 3:967dde37e712 236 return sendNwait();
humlet 3:967dde37e712 237 }
humlet 3:967dde37e712 238
humlet 3:967dde37e712 239 int I2CDriver::readSlave(char* data, int length)
humlet 3:967dde37e712 240 {
humlet 3:967dde37e712 241 lock();
humlet 3:967dde37e712 242 m_channel->transfer.cmd = READ_SLV;
humlet 3:967dde37e712 243 m_channel->transfer.slv = true;
humlet 3:967dde37e712 244 m_channel->transfer.adr = m_slaveAdr;
humlet 3:967dde37e712 245 m_channel->transfer.dta = data;
humlet 3:967dde37e712 246 m_channel->transfer.len = length;
humlet 3:967dde37e712 247 return sendNwait();
humlet 3:967dde37e712 248 }
humlet 3:967dde37e712 249
humlet 3:967dde37e712 250 int I2CDriver::readSlave(void)
humlet 3:967dde37e712 251 {
humlet 3:967dde37e712 252 lock();
humlet 3:967dde37e712 253 m_channel->transfer.cmd = READ_BYTE;
humlet 3:967dde37e712 254 m_channel->transfer.slv = true;
humlet 3:967dde37e712 255 m_channel->transfer.adr = m_slaveAdr;
humlet 3:967dde37e712 256 m_channel->transfer.ack = 1;
humlet 3:967dde37e712 257 return sendNwait();
humlet 3:967dde37e712 258 }
humlet 3:967dde37e712 259
humlet 3:967dde37e712 260 int I2CDriver::writeSlave(const char *data, int length)
humlet 3:967dde37e712 261 {
humlet 3:967dde37e712 262 lock();
humlet 3:967dde37e712 263 m_channel->transfer.cmd = WRITE_SLV;
humlet 3:967dde37e712 264 m_channel->transfer.slv = true;
humlet 3:967dde37e712 265 m_channel->transfer.adr = m_slaveAdr;
humlet 3:967dde37e712 266 m_channel->transfer.wdta = data;
humlet 3:967dde37e712 267 m_channel->transfer.len = length;
humlet 3:967dde37e712 268 return sendNwait();
humlet 3:967dde37e712 269 }
humlet 3:967dde37e712 270
humlet 3:967dde37e712 271 int I2CDriver::writeSlave(int data)
humlet 3:967dde37e712 272 {
humlet 3:967dde37e712 273 lock();
humlet 3:967dde37e712 274 m_channel->transfer.cmd = WRITE_BYTE;
humlet 3:967dde37e712 275 m_channel->transfer.slv = true;
humlet 3:967dde37e712 276 m_channel->transfer.adr = m_slaveAdr;
humlet 3:967dde37e712 277 m_channel->transfer.ack = data;
humlet 3:967dde37e712 278 return sendNwait();
humlet 1:90455d5bdd8c 279 }
humlet 1:90455d5bdd8c 280
humlet 1:90455d5bdd8c 281
humlet 3:967dde37e712 282
humlet 3:967dde37e712 283