[ESP32] New dev board

Discussion and questions about boards that can run MicroPython but don't have a dedicated forum.
Target audience: Everyone interested in running MicroPython on other hardware.
User avatar
mattyt
Posts: 239
Joined: Mon Jan 23, 2017 6:39 am

Re: [ESP32] New dev board

Post by mattyt » Mon Sep 10, 2018 11:19 am

OutoftheBOTS_ wrote:
Sun Sep 09, 2018 8:45 pm
I do note on 1 of your previous posts you were talking about a GUI and this definitely 1 area that the extra psRAM makes so much more possible.
Yes, I have a goal to create a UI toolkit but the obvious design calls for a full-screen framebuf (we can use less memory-intense designs but they have compromises). On a 320x240 display with 565RGB that's ~75KB. After MicroPython boots on a standard ESP32 (no PSRAM) there is only ~103KB free so that leaves little for implementation. We can probably strip a few things out at boot but driving a display like that will clearly be much more comfortable with PSRAM.

Now, as it turns out, for this application, I'm looking at using an M5Stack anyway. Just because I want a small ESP32 board doesn't mean I have to use it in every project! ;)

Unless of course we can somehow fit in PSRAM...

User avatar
pythoncoder
Posts: 3538
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Frame buffers

Post by pythoncoder » Mon Sep 10, 2018 6:14 pm

If you plan on a 75K frame buffer you also might need to consider the time it takes to transfer the contents to the display. Most larger displays have an onboard frame buffer and built-in graphics primitives. In which case you have to choose between using it or duplicating the frame buffer on the host and zapping the whole thing across when you want to refresh the display.

For small displays having the framebuf on the host makes for a very simple driver by inheriting the primitives in the underlying framebuf instance, an example being here. I find it amazing that such a trivial driver can support graphics primitives and text display in arbitrary fonts (via my CWriter class).

With the frame buffer on the host you get simplicity with high RAM use and slower speed. Using the one on the display provides performance at the cost of driver complexity. As the frame buffer gets larger, hosting it looks increasingly unappealing.
Peter Hinch

OutoftheBOTS_
Posts: 640
Joined: Mon Nov 20, 2017 10:18 am

Re: [ESP32] New dev board

Post by OutoftheBOTS_ » Mon Sep 10, 2018 9:02 pm

mattyt wrote:
Mon Sep 10, 2018 11:19 am
OutoftheBOTS_ wrote:
Sun Sep 09, 2018 8:45 pm
I do note on 1 of your previous posts you were talking about a GUI and this definitely 1 area that the extra psRAM makes so much more possible.
Yes, I have a goal to create a UI toolkit but the obvious design calls for a full-screen framebuf (we can use less memory-intense designs but they have compromises). On a 320x240 display with 565RGB that's ~75KB. After MicroPython boots on a standard ESP32 (no PSRAM) there is only ~103KB free so that leaves little for implementation. We can probably strip a few things out at boot but driving a display like that will clearly be much more comfortable with PSRAM.

Now, as it turns out, for this application, I'm looking at using an M5Stack anyway. Just because I want a small ESP32 board doesn't mean I have to use it in every project! ;)

Unless of course we can somehow fit in PSRAM...
Just for you info here is 8mb psRAM for $0.80US https://www.electrodragon.com/product/2 ... 4-iot-ram/ and you can see the size and as far as I am aware it uses the same pins as the external flash so it doesn't use up any more pins.

As I said before it isn't many projects that u need the extra psRAM for but at the price to have it there for when needed is hard to knock back.

loboris
Posts: 317
Joined: Fri Oct 02, 2015 6:19 pm

Re: [ESP32] New dev board

Post by loboris » Mon Sep 10, 2018 9:36 pm

It may be difficult (if not impossible without modifing esp-idf sources) to connect external SPIRAM to ESP32-PICO-D4 even it there is enough room on the board.
It uses GPIOs 16&17 for internal Flash and those pins are used by esp-idf to drive the external SPIRAM.

User avatar
mattyt
Posts: 239
Joined: Mon Jan 23, 2017 6:39 am

Re: Frame buffers

Post by mattyt » Tue Sep 11, 2018 12:18 am

pythoncoder wrote:
Mon Sep 10, 2018 6:14 pm
If you plan on a 75K frame buffer you also might need to consider the time it takes to transfer the contents to the display.
Let's explore this because I'm counting on two things:

1) Fast SPI transmission rate. The ESP32 is capable of 80MHz SPI rates though I'm not sure if we can achieve that in MicroPython today. If my back-of-the-envelope math is right at 80MHz a complete frame ought to take less than 10ms (100fps!). It's more complex of course - the ILI9341 I intend to use seems to only be rated to <7MHz but this seems to be a gross underrating as it appears it's common to drive this much higher (20MHz is typical, 40+ possible). Even so, let's say a full frame takes 150-200ms (5-10fps); that's still usable for my purposes.

2) Partial updates. I intend to use a 'dirty row' flag in the driver so only changed rows are transmitted. The ILI9341 supports partial updates, as do many display drivers in this class. This is especially useful for small images that require fast updates - like button icons where responsiveness is important. It's also attractive that I can implement the driver without partial updates and build it in if/when it becomes necessary.

Does that check-out? Are any of my assumptions incorrect or misplaced?
pythoncoder wrote:
Mon Sep 10, 2018 6:14 pm
Most larger displays have an onboard frame buffer and built-in graphics primitives. In which case you have to choose between using it or duplicating the frame buffer on the host and zapping the whole thing across when you want to refresh the display.
I've found that when the display primitives are on the hardware you lose flexibility (eg, font selection) and you become tightly bound to the hardware. I'd like to avoid it if at all possible...
pythoncoder wrote:
Mon Sep 10, 2018 6:14 pm
For small displays having the framebuf on the host makes for a very simple driver by inheriting the primitives in the underlying framebuf instance, an example being here. I find it amazing that such a trivial driver can support graphics primitives and text display in arbitrary fonts (via my CWriter class).

With the frame buffer on the host you get simplicity with high RAM use and slower speed. Using the one on the display provides performance at the cost of driver complexity. As the frame buffer gets larger, hosting it looks increasingly unappealing.
I've actually found almost the opposite - using small displays and using display driver hardware primitives means you can get good responsiveness with low-powered microcontroller hardware. As the display increases in size the limitations of the display driver hardware become more obvious and the UI looks...janky. You need more RAM and more powerful micros but the result can look better rendering into a framebuffer...

In any case, the ILI9341 I'm planning on using doesn't offer much in the way of graphics primitives. :) So I'm going to try making this work with a framebuffer!

User avatar
mattyt
Posts: 239
Joined: Mon Jan 23, 2017 6:39 am

Re: [ESP32] New dev board

Post by mattyt » Tue Sep 11, 2018 12:38 am

OutoftheBOTS_ wrote:
Mon Sep 10, 2018 9:02 pm
Just for you info here is 8mb psRAM for $0.80US https://www.electrodragon.com/product/2 ... 4-iot-ram/ and you can see the size and as far as I am aware it uses the same pins as the external flash so it doesn't use up any more pins.

As I said before it isn't many projects that u need the extra psRAM for but at the price to have it there for when needed is hard to knock back.
Yes, it's small, cheap and sometimes extremely convenient. Don't get me wrong, I would really like to have it. :)
loboris wrote:
Mon Sep 10, 2018 9:36 pm
It may be difficult (if not impossible without modifing esp-idf sources) to connect external SPIRAM to ESP32-PICO-D4 even it there is enough room on the board.
It uses GPIOs 16&17 for internal Flash and those pins are used by esp-idf to drive the external SPIRAM.
You're right, currently PSRAM on the PICO D4 is not supported. But some users have managed to get it working anyway.

I'll try to find out what Espressif are planning with this...

User avatar
deshipu
Posts: 1347
Joined: Thu May 28, 2015 5:54 pm

Re: Frame buffers

Post by deshipu » Tue Sep 11, 2018 1:10 am

mattyt wrote:
Tue Sep 11, 2018 12:18 am
1) Fast SPI transmission rate. The ESP32 is capable of 80MHz SPI rates though I'm not sure if we can achieve that in MicroPython today. If my back-of-the-envelope math is right at 80MHz a complete frame ought to take less than 10ms (100fps!). It's more complex of course - the ILI9341 I intend to use seems to only be rated to <7MHz but this seems to be a gross underrating as it appears it's common to drive this much higher (20MHz is typical, 40+ possible). Even so, let's say a full frame takes 150-200ms (5-10fps); that's still usable for my purposes.

2) Partial updates. I intend to use a 'dirty row' flag in the driver so only changed rows are transmitted. The ILI9341 supports partial updates, as do many display drivers in this class. This is especially useful for small images that require fast updates - like button icons where responsiveness is important. It's also attractive that I can implement the driver without partial updates and build it in if/when it becomes necessary.

Does that check-out? Are any of my assumptions incorrect or misplaced?
While both ESP8266 and ESP32 are indeed capable of doing 80MHz SPI transmissions, the display is not. Sure, you can exceed the specification, and if you are lucky, the particular device you own might work for you. That doesn't say that any new ones you buy will work as well, if you plan to make more than one device. They also may stop working when the temperature changes, or the power fluctuates, or the phase of the moon changes. There is really no telling once you move outside of the specs.

Second, while the transmission's clock itself runs at the specified frequency, preparing the transaction and the data will take some time. You say that you plan to send it line-by-line. That means you will have some time gaps between the lines for running the code that checks if the line is dirty and calls the right SPI functions with the right addresses. It also means you will have some overhead from the commands and coordinates that need to be included. Finally, it means that a partially updated frame will be visible (as you are not sending it all in one transaction), which will give you pretty bad tearing effects.

User avatar
mattyt
Posts: 239
Joined: Mon Jan 23, 2017 6:39 am

Re: Frame buffers

Post by mattyt » Tue Sep 11, 2018 2:38 am

deshipu wrote:
Tue Sep 11, 2018 1:10 am
While both ESP8266 and ESP32 are indeed capable of doing 80MHz SPI transmissions, the display is not. Sure, you can exceed the specification, and if you are lucky, the particular device you own might work for you. That doesn't say that any new ones you buy will work as well, if you plan to make more than one device. They also may stop working when the temperature changes, or the power fluctuates, or the phase of the moon changes. There is really no telling once you move outside of the specs.
I don't intend to unless I absolutely have to. I don't think it'll come to that. Even at 6.67MHz (max of the ILI9341) I can achieve ~5fps with full-frame updates. That's plenty fast enough - as long as I can keep up with that throughput when I need fast responsiveness...

I think I can make that feel more responsive with partial updates. Increasing the transmission rate is something I want to keep as a last resort. It's reassuring that a large number of people suggest 20MHz is stable though.
deshipu wrote:
Tue Sep 11, 2018 1:10 am
Second, while the transmission's clock itself runs at the specified frequency, preparing the transaction and the data will take some time. You say that you plan to send it line-by-line. That means you will have some time gaps between the lines for running the code that checks if the line is dirty and calls the right SPI functions with the right addresses. It also means you will have some overhead from the commands and coordinates that need to be included. Finally, it means that a partially updated frame will be visible (as you are not sending it all in one transaction), which will give you pretty bad tearing effects.
No, I won't send it line-by-line; sorry I wasn't particularly clear. The typical way I've implemented partial updates in the past is that you record the top and bottom dirty rows and then periodically send the block between them. There should be no tearing.

You can tweak the 'dirty block' finding algorithm to look for, say, up to 4 strips of rows (which implies a dirty bit per row) but, in my experience, it's not necessary. You just accept that a partial update can devolve into a full frame update if something at the top and bottom of the display changes. Knowing how it works means that you can often design your UI to take advantage of this (render a horizontal, static title at the top. Avoid vertical controls. etc).

Some drivers allow partial region updates where any region within the display memory can be updated. This can have further optimisations (dirty bit per 'widget' is efficient) but is obviously more complicated.

We should probably have discussed this in the other thread... :)

OutoftheBOTS_
Posts: 640
Joined: Mon Nov 20, 2017 10:18 am

Re: [ESP32] New dev board

Post by OutoftheBOTS_ » Tue Sep 11, 2018 2:49 am

the ILI9341 I intend to use seems to only be rated to <7MHz
I have ran a cheap ILI9341 at full speed on a STM32F7 at 54MHz with DMA transfer from RAM buffer to SPI and it ran perfectly.

I was thinking this would test this little cheap Chinese screen but to my surprise it ran fine.

I do know the Ardunio guys are reading the OV7670 camera and outputting the image to a ili9341 at 320x240 and getting 26FPS using a STM32F407 and the limitation was the STM32F407 not the camera or screen.

User avatar
mattyt
Posts: 239
Joined: Mon Jan 23, 2017 6:39 am

Re: [ESP32] New dev board

Post by mattyt » Tue Sep 11, 2018 4:12 am

So I've been working with Seon "Unexpected Maker" on this smallish ESP32 board. Well, Seon has been doing the hard work, I've just made some, err, suggestions along the way. ;)

He released a video about the build this morning so I can share with you the TinyPICO, the name he's given to the board. It's basically as discussed; ESP32 PICO D4, 20 pins, 30x20ish mm^2, LiPo charging onboard.

Be gentle with your feedback! ;) In particular we know that we need to work on the antenna design. The suggestions already made have been useful to guide our efforts for the next revision.

Personally I'd like to make it smaller still, give it mount holes, add PSRAM, an RGB LED, reduce power consumption...and more. But there are tradeoffs; the primary one, of course, is to not turn your board designer into a murderous psychopath by suggesting too many features in an ever reducing space... :D

Post Reply