• State Verified Answer
  • Replies 10 replies
  • Subscribers 62 subscribers
  • Views 11298 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 112192
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52 TWI easyDMA feature

FA

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!

  • 0

    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

  • 0 in reply to endnode

    Can PPI access the RAM without CPU interruption too? What do you mean by management in the app?

    To be more clear, let's say we are sampling data and storing in RAM, meanwhile anytime our radio might start working and accessing another part of the RAM. We want these two tasks do not interrupt each other at all. So, after setting the timer, timer must not interrupt radio (or actually radio must not delay the timer) and TWI reading should not interrupt any tasks. Right now I'm more into seeing even if this is possible or not for potential switch to nRF52. If PPI in nRF51 can do the job, then it would be much better.

  • 0 in reply to endnode

    PPI means that you can pre-program to launch some task upon some (HW) event. In your case you would hook timer compare to start task of the TWI. However this won't help you if you want to do any kind of data pre or post processing (e.g. if you want change I2C TX data, if you want to do something with Rx data etc.) So this will solve your case only if you simply repeat the same static transaction (Tx and Rx length known in advance) and then you will process the data before they will be replaced during next transaction (assuming you run timer indefinitely with clearing during compare or something like that).

    From other side if you are running classic BLE radio stack then you will be safe because you will always have reasonable time slot for processing at app level (so if you really insist on very precise timing of I2C "polling" then try it with PPI and the rest in SW interrupt.

  • 0 in reply to endnode

    Btw. this is exactly that kind of use case which cannot be solved on paper. Simply get nRF51 or nRF52 DK and do simple PoC. It will take probably 1-2 weeks but if your product needs this strange feature then it's time and money well spent.

Related