app_twi Vs. nrf_drv_twi - What's the difference and why would you choose one over the other?

[Sensors]

I've been trying to get my head around the TWI on the nRF51822 today, using the "twi_sensor_pca10028" example to begin with.

Firstly, I still don't quite understand how that works in non-blocking mode, so some explanation of that would be greatly appreciated. (Generally I find quite a lot of the example code to be unintuitive and difficult to follow, having some detailed functional description to go along with the example would be very helpful)

Having become frustrated at this example code I opted to check out the other example: "twi_master_using_app_twi_pca10028". In looking through this I realised the TWI is handled in a completely different manner. Why do two implementations of the same driver exist? Is there a benefit using one over the other?

[Vidar Berg]

There is additional documentation for all the libraries and drivers in the SDK documentation in case you haven't seen it already (TWI driver and TWI library) which should give a more functional description of the various components.

Firstly, I still don't quite understand how that works in non-blocking mode, so some explanation of that would be greatly appreciated. (Generally I find quite a lot of the example code to be unintuitive and difficult to follow, having some detailed functional description to go along with the example would be very helpful)

The drivers and libraries provides a high level of abstraction so you can use the the peripheral with a few simple API calls in your application with the intention of making it easier to implement. However, the complexity of the drivers/libraries themselves can be quite high considering that they have to be made generic in order to cover "all" use cases (e.g, support both blocking and non-blocking mode, callbacks,etc).

In non blocking mode the call to for instance nrf_drv_twi_tx() will schedule the operation and return immediately. Once completed the driver will send a callback (twi_handler in sensor example) to the application to notify it of the NRF_DRV_TWI_TX_DONE event. In blocking mode (event handler not set) the function will not return before the transaction has completed.

Having become frustrated at this example code I opted to check out the other example: "twi_master_using_app_twi_pca10028". In looking through this I realised the TWI is handled in a completely different manner. Why do two implementations of the same driver exist? Is there a benefit using one over the other?

app_twi is a library used on top of on top of the twi driver, and works as a transaction manager. I.e., schedule one or more successive read and write transactions with a slave. This library is not needed if your prefer to use the driver directly.

[Sensors]

Thanks for that clarification.

I just have another couple questions... With a TWI obviously there could be many sensors, so how would I go about modifying the event handler to deal with receiving data that may not always be from the same source? i.e. might not call the same function to process it, the data may be a different length, etc. Is this something that's easier to do with app_twi? And which twi HAL/driver would be best to use when it comes to also using a BLE soft device?