Espruino on P8 smartwatch - ST7789 display driver in Inline C

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.

Interesting Pinetime effort https://forum.pine64.org/showthread.php?­tid=14623

Maybe Bangle can do it including sound via piezo speaker?

The video is already converted here https://github.com/TT-392/pinetime-bad-a­pple/tree/master/src/bad_apple

Also nice trick with SPI DMA there, the whole initial rectangle setup commands/data sequence of ST7789 is sent as single DMA transfer with just carefully timed DC pin toggling (via timer and PPI) while the DMA transfer runs https://github.com/TT-392/pinetime-bad-a­pple/blob/master/src/drivers/pinetime_di­splay_driver/display_fast.c#L123
That could be used in current LCD_SPI_UNBUF driver to speed up small rectangles.

Nice, I like the style of Set, easy to handle, even for lefties.

Wow, that speed is impressive. I didn't think that was even really possible on 52832 with SPI. I guess they can run 12 bit, but even so...

The timer + PPI for DC is really neat - I bet that would speed up things a lot!

Or another way to sound via the hardware just like MT17 bangle with ATS300X, based nrf52, can play music without smartphone

1 Attachment