You are reading a single comment by @fanoush and its replies.
Click here to read the full conversation.
-
I am surprised that the Nordic routines seem to incur such a large overhead.
Oh, if you have the SDK11 build, check if DMA is enabled, most likely it is not turned on by default, try to add
-DSPI0_USE_EASY_DMA=1to board file. See alsotargetlibs/nrf5x_11/nrf52_config/nrf_drv_config.hAs for drivers, the source of spi driver for SDK12 is here https://github.com/espruino/Espruino/blob/master/targetlibs/nrf5x_12/components/drivers_nrf/spi_master/nrf_drv_spi.c , it is very similar in SDK11.
fanoush
Thanks to the clear instructions, I had no problem building the P8 package. I also tested your driver which gives an impressive result of 73ms for the fill rectangle test -
fill_time(). Admittedly, this is 12-bit but it would still be less than 100ms for 16-bit while the best that mylcd_spi_unbufdriver can do is 237ms.I accept your arguments about single pixel operations, however this performance difference is not caused by pixel operations, since both drivers are sending large buffers via EasyDMA. The difference seems to be caused by the fact that you have used a direct implementation of EasyDMA while the Espruino
jshSPISendManyuses SoftDevice routines - including interrupt handling. Your implementation - similar to @atc1441's ATCWatchfastspimodule does not use either the SoftDevice or interrupts. I am surprised that the Nordic routines seem to incur such a large overhead.BTW. Both Espruino and the ATCwatch module have workarounds for the 1 byte EasyDMA transfer bug while your implementation does not - yet it seems to work OK?