S210 & twi - timing / speed

RE: S210 & twi - timing / speed

Einar Thorsrud — Wed, 25 Nov 2015 14:00:27 GMT

Yes, referring to Table 18 in S210 SDS, tISR_ANT can be up to 321 μs. This would block execution of code at APP_LOW or MAIN priority for up to that amount of time.

RE: S210 & twi - timing / speed

WolfgangEbersbach — Wed, 25 Nov 2015 13:53:50 GMT

Einar, I have seen this. So, yes, by documentation it may be that the master stretches the clock. But > 100usec ? Anyhow, thanks for the help, I'll close this now as I have other, more urgent things to solve before I come back to this fine tuning issue.

RE: S210 & twi - timing / speed

Einar Thorsrud — Wed, 25 Nov 2015 13:39:40 GMT

Regarding the first quote, I copy-pasted the wrong section. I have updated the answer with what I indented to include. Thanks for noticing.

You are using the hardware peripheral. What I wanted to point out with the quotes is that the CPU has to write and read each byte separately to the TWI peripheral registers, and if the CPU cannot do this in time, the transfer will be delayed.

If you look at the Processor availability section (11.2) of the SoftDevice Specification, you will see that you can expect high priority interrupts some times when using ANT, and the duration of these events are of the order you are seeing (See Table 18 of the S210 Soft Device Spec).

The nRF52 however has a new set of TWI peripherals (TWIM/TWIS) which has DMA. So with the nRF52 should be able to do the transfers consistently without the delay even while doing ANT communication (or processing any other high priority interrupts).

RE: S210 & twi - timing / speed

WolfgangEbersbach — Wed, 25 Nov 2015 12:42:55 GMT

Hi Einar,

thanks for the response. What you refer to is HW related delays, like copying 8 bits from a register to somewhere. Anyhow, I see delays of 70usec between the write transfer and the read transfer. And about 25usec between the first read byte and the 2nd one. And > 100usec between the end of one read transfer and the start of the next write transfer. These numbers are WAY too big to be caused by hardware. I have seen the softdevice document, according to that the TWI is free to be used. Also, interrupt latency additions caused by the soft device are all 1-digit numbers.

Sadly (at least to me) the SDK is extremely scattered into a million files, #defines and macros all over the place so that it is really really hard to understand the example codes.

So, if I use app_twi, does that actually use hardware TWI ? Or is that bit-banged software TWI ?

In any case there is some delays hidden somewhere. Maybe they are required for whatever reason, maybe not. I just try to get the TWI transfers done as quick as possible to save energy. My TWI sensor has quite high power consumption, so any usec more sleep on the sensor side pays off a lot...

According to the NRF51 datasheet there is hardware TWI. On page 58 of the DS you can see that the longest delay required by hardware is 5,2 usec for start / stop conditions. So, there is no hardware reason for 2 or even 3 digit delay times.

I'll put some more time in this as soon as I managed to gain control over the GPIO's in the ant_bpwr_tx example code - which is hard due to the way the board support and app_button stuff is buried everywhere in the example code. I would much more prefer example code that is as minimal as possible. Yes, including having register addresses and such directly in the code instead of hidden behind 15 #include/#ifdef/#macro things.

Regards, Wolfgang.

RE: S210 & twi - timing / speed

Einar Thorsrud — Wed, 25 Nov 2015 10:37:46 GMT

I think you have answered most of your question in your comment. I will try to add some more details.

The TWI transmitter and receiver are single buffered so the CPU has to do some work between every byte. As stated in Section 28.4 of the reference manual for write:

If the CPU is prevented from writing to TXD when the TWI master is ready to clock out a byte, the TWI master will stretch the clock until the CPU has written a byte to the TXD register.

and read:

After receiving a byte, the TWI master will delay sending the ACK/NACK bit by stretching the clock until the CPU has extracted the received byte, that is, by reading the RXD register.

Section 11.2 of the SoftDevice Specification describes the processor availability and latencies for the interrupts/priorities available to the application. This seems to match with the pauses you sometimes see in the TWI transfers.

RE: S210 & twi - timing / speed

WolfgangEbersbach — Tue, 24 Nov 2015 12:32:52 GMT

OK, I put the TWI transfers out of the timer ISR. Now I just set a flag in the ISR and do the TWI transaction within the main loop. This allows for the 100 TWI transactions per second. Every now and then the transaction is paused by 5.something msec. This likely is the s210 processing the ANT stuff. Remains the question why the TWI transaction itself has these delays in it.