nRF52 TWI easyDMA feature

RE: nRF52 TWI easyDMA feature

MartinBL — Fri, 11 Mar 2016 10:40:39 GMT

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.

RE: nRF52 TWI easyDMA feature

endnode — Mon, 07 Mar 2016 05:54:58 GMT

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

RE: nRF52 TWI easyDMA feature

FA — Mon, 07 Mar 2016 03:51:20 GMT

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.

RE: nRF52 TWI easyDMA feature

endnode — Fri, 04 Mar 2016 22:08:08 GMT

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

RE: nRF52 TWI easyDMA feature

FA — Fri, 04 Mar 2016 20:58:32 GMT

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.

RE: nRF52 TWI easyDMA feature

endnode — Fri, 04 Mar 2016 20:27:40 GMT

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.

RE: nRF52 TWI easyDMA feature

endnode — Fri, 04 Mar 2016 20:24:34 GMT

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.

RE: nRF52 TWI easyDMA feature

FA — Fri, 04 Mar 2016 19:44:37 GMT

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.

RE: nRF52 TWI easyDMA feature

endnode — Fri, 04 Mar 2016 09:15:05 GMT

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

RE: nRF52 TWI easyDMA feature

FA — Thu, 03 Mar 2016 04:51:05 GMT

Can someone please comment on this topic?!