How to implement two TWI instances

RE: How to implement two TWI instances

GaryD — Wed, 23 Jan 2019 13:59:08 GMT

Torbjorn,

The dual TWI masters works well - I still have under 1 mS distortion during transmission of samples over BLE. The DAC samples involved in the delay are buffered and the waveform "catches up" by sending the samples out faster than every 200 uS. We can live with that for now.

RE: How to implement two TWI instances

ovrebekk — Fri, 11 Jan 2019 08:41:35 GMT

Hi Gary

The best of luck. If you have more questions just let me know 🙂

Best regards
Torbjørn

RE: How to implement two TWI instances

GaryD — Thu, 10 Jan 2019 15:14:52 GMT

Thank you Torbjorn,

I will look into these and should have implemented the dual TWI by early next week and will let you know the result.

If that does not completely solve it, I will try the alternative using PPI that you suggested.

I apologize for the typo on the SDK - I am using SDK 14.2.0

Thanks for your prompt support.

Gary

RE: How to implement two TWI instances

ovrebekk — Thu, 10 Jan 2019 12:52:06 GMT

Hi Gary

The advantage of using two TWI masters is that you can run two transactions in parallel, without the second having to wait for the first to complete.

You still need to run some code from the CPU to start the transaction, but this should be a much quicker procedure than the full transaction.

The TWI master interfaces also have an array list feature, which allow you to fire off multiple write transactions without having to run any code on the MCU side. An event from a timer can be connected to the TWI master over PPI, allowing you to trigger the TWI in the background while the CPU is busy doing something else.
If using two TWI master interfaces is not sufficient to get completely smooth ADC data then this is something you could look into.

Sampling the ADC should not have to impact the TWI communication, as this can also run transparently in the background. Just make sure that any ADC event handler used to process the data is running at a lower IRQ priority (higher priority number).

I don't know where you found the reference to 800K TWI frequency. The hardware in the nRF52832 is ratified to 400K only, and I couldn't find the commented define you mentioned in either SDK v14.2.0 or SDK v15.2.0 (there is no SDK v14.3.0).

Best regards
Torbjørn

RE: How to implement two TWI instances

ovrebekk — Thu, 10 Jan 2019 12:52:06 GMT

Hi Gary

The advantage of using two TWI masters is that you can run two transactions in parallel, without the second having to wait for the first to complete.

You still need to run some code from the CPU to start the transaction, but this should be a much quicker procedure than the full transaction.

Best regards
Torbjørn

RE: How to implement two TWI instances

GaryD — Thu, 10 Jan 2019 02:07:53 GMT

Thanks for the hint on posting code - will try that next time.

RE: How to implement two TWI instances

awneil — Wed, 09 Jan 2019 20:40:08 GMT

Seems to be a popular topic lately:

https://devzone.nordicsemi.com/f/nordic-q-a/42228/two-device-use-twi-transfers-may-be-conflict

https://devzone.nordicsemi.com/f/nordic-q-a/42189/combine-two-different-twi-into-a-single-function/164164#164164

RE: How to implement two TWI instances

awneil — Wed, 09 Jan 2019 20:37:23 GMT

How to properly post source code:

RE: How to implement two TWI instances

GaryD — Wed, 09 Jan 2019 17:12:12 GMT

Thank you for your prompt response Torbjorn,

I will scope out the TWI lines and let you know my findings.

There is an option in the nrf_twi.h file for 800kbps operation that has been commented out - can that be used?

typedef enum
{
NRF_TWI_FREQ_100K = TWI_FREQUENCY_FREQUENCY_K100, ///< 100 kbps.
NRF_TWI_FREQ_250K = TWI_FREQUENCY_FREQUENCY_K250, ///< 250 kbps.
NRF_TWI_FREQ_400K = TWI_FREQUENCY_FREQUENCY_K400, ///< 400 kbps.
//NRF_TWI_FREQ_800K = TWI_FREQUENCY_FREQUENCY_K800 ///< 800 kbps
} nrf_twi_frequency_t;

Also, I used 10k pullups for the SDA/SCL lines and I found your spec calls out for less than 7k - I plan to change it to around 5k. Do I need to beef up the GPIO output to handle a 5k pullup resistors?

There are no reads from the DAC, only writes based on an app timer going off every 200 micro seconds. The IMU is read for six 16 bit samples running on a separate app timer at 20 milliseconds. The IMU only requires 128 clock cycles to transfer the data in from the IMU but one point I will check is to see if the IMU promptly responds to the read request - if not, then the TWI bus may be locked up waiting on the IMU. Do you agree that using a second TWI master can resolve the issue and not impact the other TWI?

I do have four ADCs running on internal clocks for other data collection but that only happens every couple of seconds. Can the "independent" running of ADC collection impact the timing on the TWI channels?

I also have PWM being generated at varying duty cycles (1 to 10 %) at frequencies up to 20 K Hz. Again, the frequency of corruption does not correlate to the PWM generation.

I will check on the using a unique index in the NRF_DRV_TWI_INSTANCE(x) macro - I am not sure how to do that but will let you know if I need additional help to check that.

RE: How to implement two TWI instances

ovrebekk — Wed, 09 Jan 2019 14:24:01 GMT

Hi Gary

Have you tried to scope the TWI lines to see how the TWI transactions are scheduled?

Are you sure that there is enough time to read both the sensors within the same interval?

Is the DAC being read every 200us, or does it buffer multiple samples before you have to read them out?

1. If the problem is bus bandwidth then using 2 TWI's should solve the problem, but it is possible you could also solve it by finding a different way to schedule the TWI access (by making sure you wait for the next DAC transaction before servicing the IMU for instance).

2. Yes, any GPIO on the nRF52832 can be used for TWI.

3. Assuming you initialize the m_imu variable using a unique index in the NRF_DRV_TWI_INSTANCE(x) macro, then it should be correct.

4. Without knowing more about your system I don't want to speculate too much. Is the timer sampling the ADC internal in the ADC, or controlled from the Nordic device?

Best regards
Torbjørn