Espruino on P8 smartwatch - ST7789 display driver in Inline C

Posted on
Page
of 2
Prev
/ 2
  • I think that would be worth investigating as I am not convinced that my current implementation is very robust. I assume the Bangle uses SW SPI as its the same NRF5x jshardware.c implementation. Is there any reason why you do not use HW SPI with DMA?

  • It was just that it felt like I couldn't do anything at the same time as the SPI transaction anyway, plus nRF52 max SPI was 8MHz so there didn't seem much in it - especially with the overhead as it's only generally transferring 16/32 bytes at a time IIRC.

    I'd be interested to see if there was an actual performance improvement though

  • What about battery? I was thinking one of reasons to use software bitbanging was that HW spi takes extra power on top of CPU which is already on? Also display needs DMA, would it make sense to use DMA based SPI for reading from flash too?

  • Having thought about it, I think the current implementation is probably the best you can do as for the reasons below, it is difficult/impossible to use double buffering. In addition, I think enabling and disabling the HW SPI is quite legitimate - it already happens to switch from DMA SPI to normal SPI to read single bytes. For some graphics screens, you have to do something similar to adjust to lower the bus speed for the touch controller if shares the display bus.

    Double Buffering

    My attempt at this - which works well when not using SPI flash - failed with a SPI timeout for - I think - the following reason. The driver starts a DMA operation to flush a buffer full of pixels and then returns to drawImage which accesses SPI flash to read the color palette. This read stops the DMA transfer with no completion interrupt so when it comes to try and flush the next buffer you get the SPI timeout.

    I do not think that there is a general solution- other than synchronous single buffering - to stopping the CPU accessing the SPI flash in the time available during the DMA transfer. I tried blocking the SPI flash read while the DMA is in operation but this causes a sort of deadlock - #drawImage cannot fill the next buffer because it is waiting for a spi flash read which cannot complete because it is waiting for the bus to be released.

    I have persevered with the driver as I would like to run different apps with different graphics requirements - you can see the result in the video below.

    https://youtu.be/cHj_lXSNEv0

    @fanoush - Many thanks for your invaluable help with this - looking forward to softdevice+bootloader upgrade package to move to SDK12 as I need the secure connection to connect my phone.

  • looking forward to softdevice+bootloader upgrade package to move to SDK12

    it is over there, the upgrade was tested by @enaon and seems to be working, use the p8-sdk11-to-sdk12.zip to upgrade to SDK12 and then get one of those prebuild SDK12 zips or build it yourself, I have put SDK12 board files there too

  • Many thanks, I assume, I flash the upgrade zip first and then I can flash normal Espruino builds as in BOARD=P8-SDK12 RELEASE=1 make ?

  • yes, or as in make -j BOARD=P8-SDK12 RELEASE=1 DFU_UPDATE_BUILD=1

  • A small update - I have now got double buffering to work with SPI flash. The solution is to introduce a simple spin lock which blocks any attempt to do a flash read until the DMA transfer has finished. I used the existing macro WAIT_UNTIL for the spin lock so that it can timeout if a DMA interrupt goes missing.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Espruino on P8 smartwatch - ST7789 display driver in Inline C

Posted by Avatar for fanoush @fanoush

Actions