This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52 TWI easyDMA feature

Hi,

I want to know that if the TWI easyDMA in nRF52 can help in achieving this task:

  • we want to read from TWI each 10msec based on a timer interrupt and write the values in an array, e.g., A

  • meanwhile we want to transfer an array, e.g., B. Assume we can choose between non-connectable advertising or being in a connection.

Is this possible? Normally we should wait for the reading to finish, and then transmit in the 10msec window. Can DMA help in eliminating this sequence?

Thanks!

Parents
  • Hi,

    I guess it's not EasyDMA (alone) but rather PPI (see the description here). It should be possible to launch TWI transfer upon Timer end event (all that purely in HW without need to wake or interrupt CPU) but still you will probably need some management in your app. I did similar with PWM and SPI just by using NRF drivers from SDK 10/11 (they use EasyDMA and I've used two rotating 128-byte buffers to keep the PWM continuous, you are limited to 255B for single transfer on SPI and TWI anyway). It worked with interrupts at 1ms range, so 10ms shouldn't be a problem.

    Cheers Jan

  • Of course you need to use PPI for precise timing only if you want to be 100% safe against postponed interrupts due to radio activity (because BLE stack will always have priority and can postpone actual processing by several ms - extreme case when you have connection events with up to 6 packets). If you are fine with going few ms here and there then you can handle it with existing drivers without big problems (because 10ms is lot of time and you will definitely get some slot there to process incoming data and be ready for next TWI transfer). So the fact that you are going to use radio for "only 100 ms" is pretty much irrelevant (at least for Nordic BLE stack) because what matters are actual intervals and "free slots" for application processing...

Reply
  • Of course you need to use PPI for precise timing only if you want to be 100% safe against postponed interrupts due to radio activity (because BLE stack will always have priority and can postpone actual processing by several ms - extreme case when you have connection events with up to 6 packets). If you are fine with going few ms here and there then you can handle it with existing drivers without big problems (because 10ms is lot of time and you will definitely get some slot there to process incoming data and be ready for next TWI transfer). So the fact that you are going to use radio for "only 100 ms" is pretty much irrelevant (at least for Nordic BLE stack) because what matters are actual intervals and "free slots" for application processing...

Children
No Data
Related