-
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?
I am not reading back, that bug is only happening when you read back 1 byte. [58] SPIM: An additional byte is clocked out when RXD.MAXCNT = 1
jshSPISendMany uses SoftDevice routines
well, it is not softdevice, those are nordic SDK drivers linked directly to your code. Their code is doing same things as my driver mostly - setting same registers. And from glancing over the code I wouldn't guess it is so bad, in general the compiler does pretty good job when compiling their code. There are some abstractions but mostly the code is optimized away and/or inlined where possible.
softdevice apis are called via software interrupts - SVC calls - that may be indeed slower but it is not the case here, only few parts of hardware are handled like that, see https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.api.v3.0.0/group__nrf__soc__api.html?cp=4_7_3_8_2_7
You are reading a single comment by @fanoush and its replies.
Click here to read the full conversation.
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?