-
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?
jeffmer-
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
-
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
as for lcd_spi_unbuf , it is good when the spi bus is fast enough so that drawing separate pixels is bearable (lines, circles, fonts). that may be true for ESP but IMO not for nrf52. Also the driver is small an yet it has lot of stuff hardcoded - bpp16, ST7789 (the real name should perhaps be lcd_spi_unbuf_st7789_bpp16). It breaks with 12bit mode and for DK08 I even need 6bit (RGB222) mode and 2a/2b/2c commands are different on ST7301 too. If you would remove that too then not sure what would remain - just async generic spi dma writing perhaps.