I2C example with latest drivers

[Jagbir]

Hi,

I am using nRF52840 to communicate with the EEPROM. 24AA32AT-I/MC over I2C interface. The TWI scanner example detects the EEPROM address correctly for me .Now, I want to read/write the EEPROM. 

As you know nrf and other drivers are deprecated in the SDK 16 and its recommended to use nrfx/latest drivers. I just wanted to know that out of the 4 TWI/I2C examples in SDK 16, which is best suited for my application for further development and does not use the legacy drivers. 

Thanks

[Jagbir]

Hi Karl,

Thanks for the reply.

"From the looks of your code, I am not sure that your current twim_evt_handler is the best way to go.."

This event handler attached in my previous post was from nrf_drv_twi.c. Does the twim_evt_handler() really  handle any events? All it seems to do is copy data from one layer to another (nrf_drv_twi_xfer_type_t). Is that correct.

I have a similar question on clock driver nrf_drv_clock.c which is used by twim .I believe this driver is also legacy and should be replaced by nrfx_clock.c .

Thanks.

[Karl Ylvisaker]

Hello,

Jagbir said:

Thanks for the reply.

No problem at all, I am happy to help!

Jagbir said:

"From the looks of your code, I am not sure that your current twim_evt_handler is the best way to go.."

Jagbir said:

This event handler attached in my previous post was from nrf_drv_twi.c. Does the twim_evt_handler() really  handle any events? All it seems to do is copy data from one layer to another (nrf_drv_twi_xfer_type_t). Is that correct.

My mistake, I seem to have misinterpret your code.
You are correct in your analysis of the default twim_evt_handler included in the nrf_drv_twi source code. However, if you look where/when this event handler is used, it is only in the case that you are using a combination of legacy and nrfx twi drivers. So, only in the case that you are using the nrfx_twim module together with the nrf_drv legacy module, then this function will come into play.
The nrf_drv legacy drivers also had a feature for making module instances blocking by providing NULL as the event_handler argument to their _init() calls.
This functionality is no longer supported in the nrfx - but it still 'obfuscates' the nrf_drv source code, making it harder to read.

In essence, if you are using the nrfx_twim driver only, then you do not need to worry about the nrf_drv source code. Furthermore, you should create a twim_evt_handler that you provide during your nrfx_twim_init call, and this function should handle the possible twim events.
In this case, there is no point in including the twim_evt_handler from the nrf_drv_twi source code.
Furthermore, I recommend that you primarily make use of the module functionality as described in the SDK Documentation and API Reference, rather than deducing their utility from the source code - such as in this case, the twim_evt_handler you reference from the nrf_drv_twi source code is not in the API Reference as it is intended for internal use by the driver.
The function itself has little to no utility in an application, as it is included only to maintain compatibility between the modules.

Jagbir said:

I have a similar question on clock driver nrf_drv_clock.c which is used by twim .I believe this driver is also legacy and should be replaced by nrfx_clock.c .

Yes, the nrf_drv_clock is also legacy but unfortunately it is not as straight forward to migrate to nrfx_clock, due to the complexity of its complex dependencies.
Please see the nrfx migration documentation for further information about this.

Please do not hesitate to ask if anything of this should still be unclear - the learning curve in this part of the SDK is sometimes quite steep.

Best regards,
Karl