• 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.

  • 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 my lcd_spi_unbuf driver 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 jshSPISendMany uses SoftDevice routines - including interrupt handling. Your implementation - similar to @atc1441's ATCWatch fastspi module 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?


Avatar for jeffmer @jeffmer started