Hi folks. I am contemplating making a project around the Blackberry Q5 “replacement hardware” available on AliExpress/elsewhere. These have a 720x720 MIPI DSI display+synaptics touchscreen, amongst other parts. Here is the Blackberry spec for the display: https://www.panoxdisplay.com/uploadfile/datasheet/LT031MDZ4000.pdf
I have seen a post from @TechToys about interfacing with a DSI screen using an ESP32 (Bigger 2-Lane-MIPI displays - #3 by techtoys). I guess that the approach of using the SSD2805 is still valid (are there better ways these days?), but I also saw that the ESP32-C5 is supposed to have MIPI-DSI support like the P4.
Has anyone used the -P4’s DSI hardware? Does it seem like the -C5 will function similarly? How would you try to do this?
to my knowledge the C5 does not have DSI built in. There is a way to kind of hack it to make it work but quite a but is involved and I do not believe that the C5 is able to do it to it’s full speed because of only having a single core and DSI not being supported by the hardware.
Why not get a P4? They are available from some vendors…
I personally have bought that one from that company, it’s legit…
a display that has a 720 x 720 resolution is also no problem if the connection to the display is an I8080 display. Add that to an ESP32-S3 with a couple MB of flash and SPIRAM and you are good to go. You are going to need to use ioexpanders to handle the keyboard…
Just to let you know there are also Blackberries blackberry like devices that are already made. They use a C series ESP32 to handle the keyboard input.
Now I know that is not a Q5 but it gives some insight into what is being done and how it is being done. I believe using the C5 as the central processor is not the best way to go about it. Using a C series to handle the keyboard is a good way to do it because it is cheaper to do that then it is to add IO expanders to do the job. The S3 is pretty inexpensive and it comes with quite a bit of processing power. I8080 is either 8 lanes or 16 lanes to the display. if you can get 16 lanes that would offer you optimal performance but even with 8 lanes you are talking a fairly decent speed. you can the lanes at 80mhz so the theoretical speed is 80,000,000 bytes per second.
While DSI is fast yes the displays typically do not have internal GRAM so the entire displays data has to be sent to the display over and over again at that high rate of speed. where as with I8080 you only send the areas that have been updated to the display because the display IC takes care of updating the panel from it’s internal GRAM.
What that means is the performance gain from DSI also gets used up because of having to write the entire displays worth of data which means there is a slot of copying buffer data and that eats up processor time.
DSI also adds a lot of complexity to the circuit because of the differential pair which makes it exceedingly sensitive to EMI. The board has to be designed a very specific way to keep the ECM as low as possible near those lanes. Distance is yet another things and all of the lanes needing to be the same length can pose some challenges as well.
Just to let you know that DSI is something that is built into the hardware of the ESP32-P4 and that ability is not built into the hardware of the C5. It’s not something that is software based because it wouldn’t be fast enough to be really worth doing.
Hi Kevin. Thanks for the response. I’m not sure why I thought that the C5 had DSI support. I suspect I found a programming API datasheet that had a single mention of it, and extrapolated.
It definitely does sound like the P4 is a better option, possibly with a C3 or similar companion chip for any Wifi needs. The idea is actually to pair it with a LoRa radio to make a Meshtastic node, so maybe the WiFi companion chip won’t be necessary at all.
The P4 should also have enough GPIO’s to handle the keyboard too. Seems like my real problem is getting hold of bare chips. I guess this project will have to wait a bit, until the P4 is more readily available. Oh, and also locating samples of the Hirose connectors for the display and touch screen, that doesn’t involve buying a reel of 8000!
I am telling ya you can do everything you want using an S3 and a 16 lane I8080 display. You will be much happier with how it runs because of not having to deal with copying of the display buffer data and the large amount of resources used for the 2 frame buffers and also the time it takes to transmit the buffer data. I know DSI is fast but the constant interrupts that happen every 64K bytes so it can create a new DMA transaction to send the next block of data really hurts things.
As an example. This is theoretical using just math and things will actually be running slower.
With the display you want to use being 720 x 720 in size and I am going to say it will be 24 bit color. That works out to 1,555,200 bytes of data for each frame that gets sent… every 64k bytes an interrupt takes place to create a new transaction. that’s 25 interrupts per frame. Now lets say you get getting 1ghz of speed. That ends up working out to 4,018 interrupts per second. That is going to consume almost an entire core. The interrupts take time because the state of the core needs to be saved and then the code loaded into the core to create the transaction, then the core has to reload the saved state to start running again. All of that adds up really fast especially if there are some 4000+ interrupts happening per second. Even at 400mhz speed on the core it is still going to make a large impact. You will have to pass the buffer data between 2 tasks running on different cores. It’s going to get pretty complicated code wise in order to do that. I have several thousand lines dedicated to doing this very same thing for RGB displays for the S3 in order to have the frame rate high enough where it is actually usable. This applies even more if the display is rotated because the rotation is done in software not hardware.
I understand that there are easier ways to do this
I just happen to already have the Q5 shell, with touch screen and display included, so would like to use it if possible. All in, it cost $25 for screen, touch sensor, keyboard, case, speaker, antennas (not usable, of course!) which is about half of what I have seen just the screen being sold for.
For a messaging device, I certainly don’t need high frame rates, or 24-bit colour. Even 8-bit would be plenty, and I was considering halving the resolution in each dimension to 360x360 to reduce the required framebuffer size (although turning that into DMA-able bytes might be more trouble than it is worth!). Let’s say a 512kB framebuffer, then. 10fps would be plenty, in my estimation. A P4 should be able to manage that with little difficulty, I would think, unless the desired framerate doesn’t correlate to the requirements of the display to be refreshed at a minimum rate?
Anyway, this is kind of a back-burner project, it seems, since the P4 is not readily available as bare chips on the open market, and I still need to source the Hirose connectors, without which I am dead in the water.
You would get way more than 10FPS running at full resolution at 24 bit color. somewhere around 60FPS is what you would get.
Just make sure the P4 you get has 8MB of octal SPIRAM and you will have more then enough for the 2 full frame buffers to be able to utilize the DMA transfers.
I was doing a little bit of reading on the P4 and as it turns out it has a 2D graphics accelerator built into it called dave2d which I believe that LVGL has a rendering driver for that. That will speed things up quite a bit. Another thing is the DSI driver in the ESP-IDF will allow you to pass smaller partial buffers to LVGL and it handles the copying of the partial buffers to the full buffers using the accelerator which will greatly boost performance as well. You can set it up so LVGL runs on one core and the display driver runs on the other core.
I have to check and see if the SPIRAM is able to be overclocked. I would imagine it is. In order to do that you have to make sure you get the MCU that has at least 8MB of octal SPIRAM and 16mb of octal flash.
