nrf52832 nanosecond delay for E-Ink display

[InvalidException]

Hi all

I have issues with E-INK display for signals I need 100ns and 500ns delays but in nrf delay is only nrf_delay_us()

What is easiest way to get nano delays with nrf52832??? I have searched forum but no luck(as nobody needs such crucial timing)

Please help :)

[ta2]

I don't have a copy of an SDK handy at the moment, but a quick web search on nrf_delay_us() suggests that it is implemented as a sequence of NOP instructions. The references I found looked like some loop control overhead and 12 NOPs per microsecond.

If you hunt up the source for nrf_delay_us() in your copy of the SDK, then make a couple of copies of that function, you ought to be able to create something near nrf_delay_100ns() and nrf_delay_500ns() by removing some number of the NOPs.

You may need to dig out a scope or a logic analyzer to help you determine the right number of NOPs and/or the effect of removing/not removing the loop control code.

Cheers!

--- ta2

[Nguyen Hoan Hoang]

There is something available here part of the EHAL library. There is a link to Github in the blog. Use the dev branch. It is not yet available in the master branch. Look for idelay.h in EHAL/ARM/include. Contains both usDelay & nsDelay. nsDelay is not nsec precision. It depends a lot on CPU speed. On nRF52, it's about 100sec precision, on nRF51 it's about 300 ns precision.

[AmbystomaLabs]

nSec precision gets discussed regularly on this blog. Assuming your app is the only thing running on the nRF then you can probably implement with NOPs as discussed above. But since you are likely trying to utilize the wireless communications capabilities of the nRF then you will find this difficult to execute with NOPs and ISRs. The reason is the softdevice for the radio has precise timing needs and largely takes control of the microprocessor when it needs. So unless you timeslot the SD (look in this blog for app timer and timeslotting) the latency for your ISR could be anywhere from microseconds to upwards of a millisecond. I haven't personally used the timeslot approach, but basically the idea is to force some known downtime for the SD such that your application can take control of the processor.

Another approach to your problem is writing the data to the e-Ink from a register driven by ppi/gpiote. In this way the data writing is driven by hardware and not software and you can get timing as precise as 1/16 usec..

A third approach would be to look at talking to the e-Ink using spi, or i2c. Nordic has likely taken the time to make sure the drivers for these communications methods work well with the SD.

Finally, since the communications with the E-Ink is just filling up a frame buffer. The timing is likely the minimum time for them to latch the data. You should investigate if that is just the minimum and then you can always run long if your communications get interrupted by the SD. So a couple of well placed NOPs could solve the problem.

Please post back your final solution. It could prove useful to others.