RGB-Bus to revive a PocketCHIP #558
Replies: 4 comments 15 replies
-
|
I am not sure if this is an issue or you are explaining how to do something. There are some questions that I would be more than happy to answer.. You seem like you are having issues with using the RGB bus with only 8 lanes. Now with that being said. Unless the IC for the display is specifically set up for an 8lane connection you are not going to be able to use only 8 lanes. the RGB bus IC typically doesn't have any way to set things like the number of lanes via software. It is typically done in the hardware where a combination of 2 pins on the IC are what control the number of lanes the IC is using. There are some IC's that are bridge IC's where it will convert an RGB connection to something like an MIPI DSI connection and in some cases those bridge IC's can be setup using software. These IC's types typically make use of a low speed SPI 3wire connection to be able to do that.. If you display has not specifically broken out the pins that allow you to set the bus width being used then you will have to use the number of lanes that the display has broken out, you do not get a choice with it. I lso se from your code that you are manually setting the display buffers. I recommend not doing this especially with the RGB bus. The RGB bus driver is a rather complicated driver that deals with a total of 4 frame buffers. 2 of the buffers are full buffer and they reside in PSRAM and the other 2 are partial buffers and ideally they should be allocated in the internal memory space on the ESP32. With the wahy you are allocating the buffers. you are using more memory than you need to for one, and for 2 you are allocating the buffers into the slower SPIRAM. Doing that will be a HUGE performance hit not only because the memory is slower but also because the SPIBus for the SPIRAM will become a bottleneck doe to the copying of data between a partial and full buffer while also reading from the other full buffer for transmitting at the same time. Let the driver handle the buffers for the best performance, By default the driver sets the buffer size for the partial buffers to be 1/10th of a full frame buffer size. If you do want to tweak the size of the partial buffers you can but I suggest doing it so the buffers are allocated in the internal memory (if it will fit). The only cases where you would want to tweak this setting is if you are updating large areas of the screen and you are doing this very often. If an update is smaller than the buffer size then the smaller size is what gets used and passed to the bus driver. You don't want to set the partial buffers too large where they will not for into internal ram and you also don't want to waste memory either by setting the buffer size to a size that is only used occasionally. If the buffer is too small the update will be broken into multiple pieces and because of how the driver is written the screen will only update once all of the pieces have been rendered. The LDO... As far at the backlight is concerned... The wonderful thing about Python is the ability to "monkey patch" code. This is specifically the reason why the display drivers are written in Python and not in C. This provides you the ability to override the default behavior of things, thing like the backlight... Here is an example of what you would need to do.. import rgb_display
class RGBDisplay(rgb_display.RGBDisplay):
def __init__(
self,
data_bus,
display_width,
display_height,
frame_buffer1=None,
frame_buffer2=None,
reset_pin=None,
reset_state=STATE_HIGH,
power_pin=None,
power_on_state=STATE_HIGH,
backlight_pin=None,
backlight_on_state=STATE_HIGH,
offset_x=0,
offset_y=0,
color_byte_order=BYTE_ORDER_RGB,
color_space=lv.COLOR_FORMAT.RGB888, # NOQA
rgb565_byte_swap=False,
):
super().__init__(
data_bus,
display_width,
display_height,
frame_buffer1,
frame_buffer2,
reset_pin,
reset_state,
power_pin,
power_on_state,
backlight_pin=None,
offset_x=offset_x,
offset_y=offset_y,
color_byte_order=color_byte_order,
color_space=color_space,
rgb565_byte_swap=rgb565_byte_swap
)
# do setup code for backlight how you need it to be done.
# if it is simply adjusting the initialization of the PWM for the
# pin. If you don't need to adjust the init stuff then omit the
# __init__ method
# self._backlight_pin is the Pin instance and if PWM is to be used it is
# the same variable that holds the PWM instance
def set_backlight(self, value):
# if there is something more complicated that needs to be done
# when actually setting the brightness you would do it here.
# You had mentioned "inverting" the backlight. I am guessing
# that this means 0 is fully bright and higher values are dimmer.
This is a simple inversion that you can do here.
value = 100.0 - value
super().set_backlight(value)
def get_backlight(self):
value = super().get_backlight()
return 100.0 - value |
Beta Was this translation helpful? Give feedback.
-
|
I'm afraid I didn't quite got the principle of the RGB-Bus then... Is there a setup, where the pixel data is sent through in two steps, each at the rising edge of PCLK? And the RGB-Driver interprets an 8-bit bus as having to tranfer each pixels' data in two pulses of PCLK before moving on to the next one? That would explain the stretched image and the stripes on the 8-bit picture. Sadly I couldn't decipher the writing on the back of my display. The display model referenced in the board schematic also doesn't seem to expose any of the communication lines. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, before I forget. This is just to put my findings and experiences with this project out there for others to draw from it. The past week was me fighting with search results and scouring tangentially related forum posts for pieces of information. Thank you for your time. |
Beta Was this translation helpful? Give feedback.
-
|
This binding is not the "official" LVGL MicroPython binding. That binding seem to pretty much be a dead stick and is no longer being maintained. The last code change they did broke it and it has not been fixed since. This one is actually far easier to get up and running, most of the stuff is pretty well automated (except the things that need to have su privileges to do. I also have spent the time to write a heap load of drivers for display IC's, Touch IC's, IO Expanders, IMU's and a few other things. It seems pretty stable right now and no bugs are really coming up. I am thinking about doing an official release and provide some pre compiled binaries of the firmware, |
Beta Was this translation helpful? Give feedback.
-
|
Also, I never really dug into the low level stuff on the RGB driver. You could be correct about how it works. I had thought the pclk is for the bit timing to know what the on and off duration is for each bit that is sent. The pclk is what keeps the display and the MCU in sync with regards to the bitrate the data is being sent at, That's how the display knows how long the "on" time is It's based on the pclk, otherwise they would not be able to stay in sync, I could be wrong on that. I would have to go and look at the specification for it.. |
Beta Was this translation helpful? Give feedback.
-
|
as a note... I suggest using the P4 if you have one and if that P4 board is not overloaded with things already being added to it (I hate it when they do that). The P has more usable pins than the S3 and it also has a faster CPU as well as the "SPIRAM" is not running on an SPI bus, it is able to run a lot faster than the SPIRAM on the S3. The LDO pins on the P4 have a very specific purpose as to why they were added. They are supposed to be used with an SDCard reader. High speed SDCard readers operate at a lower voltage and that pin is a necessity to be able to switch between high speed and low speed depending on what kind of SDCard has been inserted. Previous ESP32's have only been able to use low speed cards. The LDO pin are not able to be used for anything other than supplying voltage to something. They are able to handle more current than other GPIO's and they can be used to turn an accessory on and off. They do not need to be used in order to use a display attached to a P4. |
Beta Was this translation helpful? Give feedback.
-
|
The reason why some people will opt for using an S3 over P4 is because the S3 has built in bluetooth/wifi. You are able to piggy back a C series ESP32 to the P4 in order to add those things to the P4. There are some additional pins needed to be able to do this but those pins are recovered because the C series works kind of like a co processor and it extends the P4. This will allow you to connect things like the keyboard to the C series and be able to access the C series pins from the P4 as well as accessing the wifi and bluetooth. |
Beta Was this translation helpful? Give feedback.
-
|
My goal with the project is to create a kind of drop in replacement for the original SBC without having to modify the case at all if possible. Me aiming for the S3 is because the Lilygo Esp32-S3 T7 comes in a footprint that would completely fit between the two rows of headers in the back. So I could create PCBs (first perfboards) to make all the connections without making everything crazy thick. The P4 of course has the advantage of all that IO that is kind of wasted on the Ethernet port and all the rest. Maybe there is one board which could fit. I haven't found it yet. |
Beta Was this translation helpful? Give feedback.
-
|
From what I am reading we should be able to do a 6 lane RGB connection to transmit RGB565 data. However I do not believe the ESP32 is set up to handle this... |
Beta Was this translation helpful? Give feedback.
-
|
it looks like it should work. you will need to specify the 8 pins and set the color depth to RGB565. You can either set the last 8 pins to -1 or simply not supply them. The DE line and PCLK lines must also be attached. |
Beta Was this translation helpful? Give feedback.
-
|
I have changed my mind on the 8-bit bus... After lowering the porch values I'm not seeing any change at all. To keep it simple I will not mess with the rgb driver code (that is absolutely beyond my abilities) and go with the 16 bit bus with some lines going to one pin to not be used. That seems to work fine. I will use more than 8 lines though to have more than 256 colors as that is too limiting. I'm not convinced on the porch thing. On a VGA Monitor the porches are like a frame around the displayed area that were there to allow for the cathode ray to have time to be moved across the screen from one end of a line to the start of the next. In that time the control grid of the electron gun is turned off to not leave streaks on the screen. VGA didn't have DE-line though so the sending device had to ensure nothing was sent in that time. There is a wonderful video by Ben Eater on driving a VGA-Monitor with logic gates. I believe I have dialed in the parameters for the display as good as it gets from the datasheet. The schematic mentions the TST430mini-05dp, but it could also be a compatible model. Though I found that the PCLK works best up to 7.5MHz or the picture is shifted side to side randomly at boot. I've moved on to the keyboard now and managed to have it be polled for key presses. It already does the key-matrix scanning by itself after setting registers 0x1D, E and F to reflect the rows and cols. Now I only need to map the keys. This is how it stands at the moment. It only prints the name of the key and is not very nice: import lvgl as lv
import keypad_framework
import lcd_utils
group = lv.group_create()
group.set_default()
_POCKETCHIP_KEYMAP = [
None,
'+', '1', '2', '3', '4', '5', '6', '7', '8', '9',
'q', 'w', 'e', 'r', 't', 'y', 'u', 'i', 'o', 'p',
'a', 's', 'd', 'f', 'g', 'h', 'j', 'k', 'l', 'Return',
'Tab', 'z', 'x', 'c', 'v', 'b', 'n', 'm', 'Up', 'Down',
'Escape', 'Function', 'Alt', 'Space', 'Control', '/', 'Shift', None, 'Left', 'Right',
'Shift', '0', '-', 'Backspace', ',', None, None, None, None, None
]
class Keyboard(keypad_framework.KeypadDriver):
def __init__(self, device, debug=False): # NOQA
self._device = device
self._debug = debug
self._buffer = bytearray(1)
self._mv = memoryview(self._buffer)
tbuffer = bytearray(1)
tmv = memoryview(tbuffer)
#init scanning
tbuffer[0] = 0b10010000
self._device.write_mem(0x01, tmv)
#init rows
tbuffer[0] = 0b00111111
self._device.write_mem(0x1D, tmv)
#init cols
tbuffer[0] = 0b11111111
self._device.write_mem(0x1E, tmv)
tbuffer[0] = 0b00000011
self._device.write_mem(0x1F, tmv)
super().__init__()
self.set_group(group)
self.enable(1)
def _get_key(self):
#read register if key is pressed
#self._device.read_mem(0x02)
#read from the FIFO register
self._device.read_mem(0x04, buf=self._mv)
key = self._buffer[0]
if key == 0:
return None
elif key > 80:
#key was pressed, not released
if self._debug:
code = key - 128
keyname = self.get_mapping(code)
print('Key Down: ', keyname)
return None
if self._debug:
keyname = self.get_mapping(key)
print('Key Up: ', keyname)
return None
def get_mapping(self, code):
return _POCKETCHIP_KEYMAP[code] |
Beta Was this translation helpful? Give feedback.
-
|
Your keypad code looks good. You need to map the keys to the LVGL keys I believe. I would have to go back and look at the code in the framework to see what it does and how it works, I don't recall off the top of my head how I wrote it. OK so after I really dove into reading about RGB unless the IC is specifically made to operate in a parallel serial mode the number of lanes need to exactly match the color depth. so basically all RGB interfaces are going to be 24 lanes/bits and what is done is the lanes that are supposed to connect to the MCU for the bottom 3 bits for red and blue and the bottom 2 bits for green are probably pulled low. so if you wanted to use only 8 lanes then what you would do is use RGB332 where you would connect the lanes as follows.. r8, r6, r5, g7, g6, g5, b7, b6 You would set LVGL to operate in RGB565 color depth. The remaining pin on the display that are not connected would need to be pulled low so connect those to ground. You cannot leave them in a floating state because they would cause issues with how the color is being displayed. This is not typical to do this for this kind of a bus and there could be something that is not correct in the driver in the ESPIDF that is causing the shift you are seeing when only using the 8 pins which is why you have to sacrifice a pin in order to get it to work. You are correct about the front and back porch timing values. Frankly I am surprised that the driver doesn't do a test to ensure all the pin are unique. You should be able to use anywhere from 3 to 24 pins if you wanted to but the common lane counts that are used is 16, 18 and 24 |
Beta Was this translation helpful? Give feedback.
-
|
On EEVBlog I believe it was somebody warned against tying RGB-LCD pins to ground. Meanwhile somewhere else I came across a schematic where the three or four least significant red lines were all connected to one data line. Leaving the pins floating didn't cause any issues or artifacts. When trying the Stripe Test sketch all the unused pins came through as black. So if anything, the colors will not be as saturated as they could be. For tinkering around this is going to be fine. Once I have figured out all the things to add, will I know how many Pins there will be left for the LCD. My current pick for the core board is the Esp32-P4 Pico Wifi. It has a healthy amount of pins available which are all free to use for anything. It has two test points on the back which are actually strapping Pins and totally unused. They will be sacrificed. I've made progress with keys. Tabbing through the widgets works and text areas can be typed into. For inspiration the TDeck board config was very good. (there is a missing bracket at line 61 in the toml though) Next up will be the key repeat, the shift and function keys. Once the xpt2046 arrive in the mail comes the touchscreen and then I will start designing a PCB for it all. |
Beta Was this translation helpful? Give feedback.
-
|
my suggestion for you is to find a display that uses an I8080 bus. it will be a lot better performant wise. Depending on how much performance you need using an ESP32 P4 and a display with an MIPI DSI bus would yield even better performance. or a P4 with an I8080 would also give good performance. |
Beta Was this translation helpful? Give feedback.
-
|
That's right you have the keyboard on that thing you are dealing with I forgot about that. It's not so easy to simply separate the display from it. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello,
First of all I would like to give a great thank you for making and maintaining this project!
I had a lot of fun putting it onto a CYD to turn it into a Pokemon lookup-tool among other things.
Now I planned to make use of my old PocketCHIP that I had laying around in my closet:
Instead of replacing the original Allwinner based SBC with just any other SBC, I wanted to use an ESP32, which is just more tolerant to losing power.
On hand, I only had the ESP32-P4 Nano by Waveshare and only if I got the display showing something, would I order an ESP32-S3 based board which would fit into the original space in the back of the PocketChip case.
I messed around with it for a week, returning to it day after day with a new approach.
Turns out I used one of those pins of the ESP32-P4 that default to 1.1V logic levels for PCLK.
I thought I was going crazy after only ever getting a white screen after countless rebuilds of lvgl_micropython, a mangled Arduino sketch for Waveshare LCD-Boards (with Esp32-S3) and realizations of not having other suitable board to test it...
8-bit RGB
At this point I got things to show up on the screen:
To make the most of the PocketCHIP hardware, I wanted to use a narrower RGB-Bus to have pins free for other purposes like:
At first I thought I could just omit pins from the bus to make weird colour spaces like RGB343 or RGB333.
But the build would error out and Micropython would just crash at the thought.
So I settle for 8-bit, which is allowed.
But the picture seems to be stretched to double the width with only the left half showing and it is striped.
Could it try to display the complete framebuffer at 16bpp byte by byte?
What would the mapping of this but be? RGB332, RGB242 or something different?
16-bit RGB
When giving all the pins to the bus I get this:
The hardware setup is the same as in the previous image --> I didn't hook up all 16 data lines.
The picture here looks very good and just like the test program.
Code
Here is my Code for both pictures:
Schematic
This is the schematic I stared at for this:
https://github.com/mcilhargey/PocketCHIP-PCB/blob/master/v1_0/PDF/PocketCHIP-v1.0-Schematic.pdf
my Points/Questions
LVGL Colour Spaces
As far as I can find in the LVGL-Docs, there seems to me no native way to make it run in RGB332 or RGB242.
For compatibility I wouldn't mind leaving the RGB565 colour space as is in memory and just not outputting half the bits.
Is there a way to drop the bits when going to the RGB-Bus?
GPIO
I couldn't find a way In micropython to have the data lines not take up any GPIO?
In Arduino you can set the unused bus pins -1 without issue.
LDO
How would I need to write the toml to have LDO4 of the ESP32-P4 run GPIO39 through 48 at 3.3V instead of 1.1?
This is the post where I found the code: https://forum.arduino.cc/t/esp32-p4-dev-kit-difference-between-1-1v-and-3-3v-on-gpios/1405128/12
In the end I will not use the P4 for this but I hope somebody finds this helpful, if anything.
PWM Backlight is inverted
There are ways to set the backlight to active high, active low and PWM. But this would need PWM inverted.
Maybe I will patch that in myself, as this is not any longer an off-the-shelf display-board.
For now...
Thanks again for this project. Here is the back of this madness:
For anybody else with a PocketCHIP:
Beta Was this translation helpful? Give feedback.
All reactions