I would suggest you to use the mutex or even a semaphore to deal with the concurrent access to the driver. It seems to be the simple way in my point of view.

Indeed I guess the first "workaround" you suggest could be added to the driver. It would be better than return always an EIO.

Best regards,
Rodrigo Peixoto

On Tue, 30 Oct 2018 at 12:47 <aurelien.vouaillat@...> wrote:

Hi,

I'm currently using the i2c_nrfx_twi driver to process i2c transfers with some peripherals.
I have several slave units on the same i2c bus and use multi-threading to deal with all of them.

I have to face the problem that at least two threads have to use the i2c bus at the same time.
Unfortunately the i2c_nrfx_twi_transfer() function doesn't handle this issue and only returns
-EIO  even if the real problem comes from the busy state of the i2c bus:

nrfx_err_t res = nrfx_twi_xfer(&get_dev_config(dev)->twi,
                           &cur_xfer,
                           (msgs[i].flags & I2C_MSG_STOP) ?
                           0 : NRFX_TWI_FLAG_TX_NO_STOP);


        if (res != NRFX_SUCCESS) {
            LOG_ERR("Error nrfx_twi_xfer with %d", res);
            return -EIO;
        }

Easy workarounds was to :

1- Add another if case :
if (res != NRFX_ERROR_BUSY)
and return a -EBUSY

OR

2- Protect the function with a mutex and leaving the kernel handle this using the priority of each threads

I don't know if there are better/cleaner solution than these two ones but i would really appreciate some help

Thanks
Aurelien

--

Rodrigo Peixoto
Co-founder and Technical guru

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex

.