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!

[FA]

Well, I don't think the case is really complicated knowing the capability of PPI and easyDMA, which I don't have full knowledge yet. Again, the only thing needed is storing in RAM. Reading is always the same in terms of bytes, we are storing all in one array. The timer handler just does this, nothing else. At some point, we want the radio to work for let's say 100 msec. This means 10 TWI reads. We don't want to miss these reads due to radio being active.

[endnode]

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...

[FA]

Still for the case of PPI vs easyDMA I'm not getting my answer, and about the example I made: when I say 100msec we need the radio it means no other interrupts can be handled. The reason: timing of reading from TWI is important, so any delay cause by the radio is not acceptable. So, which method will make it possible to not miss the 10 samples in this example and still be able to transmit? To make it clear: whenever the timer interrupts for 10msec, we HAVE TO service it ASAP, no matter if the radio is active or not.

[endnode]

You are not getting better answer then "yes it could work" because 1) you won't get it until you code quick demo and try it and 2) your requirements aren't precise enough (e.g. to code that demo) anyway. Luckily you know what exactly you want so it should be easy to get there with PPI and TWI (with EasyDMA) examples from SDK. I suppose you need to have some tolerance/threshold on that 10ms timer and based on that you can assess resulting demo. Just to be clear: with Nordic stack once there is some scheduled radio event it will get always priority and delays all application SW processing. In case you wouldn't be able to achieve your goal with PPI and "cached" TWI transaction handled autonomously by EasyDMA then you would only need custom stack (very very costly) or some "cache and forward" auxilary MCU (this is easy and even relatively cheap).

Cheers Jan

[MartinBL]

Hi

There are some new MPU examples here. The examples are showing:

• How to set up EasyDMA with the SDK drivers or simply using the nRF52 registers. The examples only use one buffer though, but using two buffers should just be a matter of defining two buffers, A and B, and then switch between them whenever you want. This should enable you to transfer old data while at the same reading new data.
• How to send accelerometer data over BLE using a simple service.
• How to use MPU data ready interrupts. With this example you can set up the MPU to sample every 10 ms and generate an interrupt when data is ready. Then you don't need a timer on the nRF52, just some GPIO to sense the interrupt.
• How to use MPU free fall interrupts.

Tested on:

• MPU9255
• MPU9150
• nRF51 DK (PCA10028)
• nRF52 DK (PCA10040)
• SDK 11.0.0
• SoftDevice S132 V2.0.0 and S130 V2.0.0.

However no guarantees or warranties are provided.

Older SDKs and Softdevices will not be supported. If you want to use other SDKs you will have to do the porting yourself.