Add support for ST7735 and ST7789 display boards

[paul-1]

My first ST7735 board came damaged, and the replacement was taking forever so I bought one of these

https://www.waveshare.com/product/displays/lcd-oled/lcd-oled-3/2inch-lcd-module.htm

This pull request add support for both boards through the settings file. I don't yet have a ST7735 board to test....but should work the same. Perhaps you can test.

One thing I noticed while running the tests. The facelet color space is BGR, which meant the display showed the wrong color. So I converted the values to RGB before showing on the screen. Not sure if this is something related to my display, or something that was never quite right.

This is a 320x240 resolution display. Obviously a few more pixels to display, so I added options to change the SPI speed too. below are the settings I'm using with this display

"disp_type": "st7789", "disp_width": "320", "disp_height": "240", "disp_offsetL": "0", "disp_offsetT": "0", "disp_rotation": "180", "disp_color_invert": "true", "disp_spi_freq": "50000000"

I can post a pcb cover model that fits this screen (Once I get done fitting it)

[AndreaFavero71]

Hi Paul, I appreciate your support for making the code more reliable, while I'm not much inclined about changes for specific cases or personalizations. Target for this project is to keep the lowest possible complexity for the Makers, to encourage people to give it a try. By including the personalizations in the main stream, it will be even more difficult for me to keep up the instructions update.

Anyway, along time ago, I made a folder to collect these type of situations: https://github.com/AndreaFavero71/cubotino/tree/main/personalizations; I believe the ST7789 display and related files could be saved there, by also adding the necessary instructions.

Colors are correctly displayed on ST7735, with the current code. Just a thoght ... some of the display's specific parameters (like SPI, rotation, colors invertion, others?) could be conditionally set at display's init, according to the selected display.

[paul-1]

I completely understand your point around personalization, This PR was meant to make the code more flexible, to make it easier for users to adapt. I.E editing a settings file, vs changing python code. Python is a lot like the snake that it is named after :)

When I found this project, the first thing I did was to look through the Bill of Materials.

• Servos - easy to find
• LED for lighting. This thing was really hard to find, and may be a show stopper for some.
• Display - Again, finding the specific design you had in the BOM was almost impossible to find.

Setting rotation, color inversion and color maps could be done hard coded based on screen type, but are we only dealing with 2 discreet screens, or are there many variations based on how the controller was implemented on the PCB.

• Rotation, putting the screen in upside-down would be a common personalization, so making this a setting would make it easier.
• Inversion, It quite possibly is ST7735=False, ST7789=True.
• Color mapping, I'm really confused here, how creating a PIL Image with RGB, can correctly display a BGR color space without conversion. I'll have a ST7735 screen in a few weeks that I can see if this ends up being the case where ST7735 works, but ST7789 requires conversion.

Let me do a little more investigation to see if we can simplify the settings based on screen type. But I'll understand if you don't want to put this in the code base.

[AndreaFavero71]

Hi Paul, I do fully recognize your good intentions, no doubts on that. Flexibility is not necessarily good for non-skilled people, and it requires more guidance via instructions. Perhaps, I should ask Maker to list the used shops for the parts, this might help. Of course, in case, or when, parts won't be available then the BOM and code will require changes.

Wrt the display code, the conditional I was thinking of is something like:

inverted_col_displays = (display_A, display_B, display_C))
if display in inverted_col_display:
    BGR = BGR[2]+BGR[1]+BGR[0]

A similar approach could be used for the SPI and other parameters. Perjhaps not efficient, but should do the job.

[paul-1]

My ST7735 made it through customs quickly and got here a week early. Anyway, the mystery of the color inversion is solved. My display did show colors correctly too.

While both displays are using 565RGB colors. The ST7735 driver is defaulting to BGR colors. We are currently using version .0.0.4 of the ST7735 driver. Commit https://github.com/pimoroni/st7735-python/commit/99e44092de728f9928a219639fb3b35d8df64da8 which after the .0.0.4 release, adds a switch to be able to set BGR vs RGB colors, but keeps the default to BGR. If I set the ST7735 driver to init the screen as RGB, then the color appearance is the same as the ST7789.

The ST7789 python driver does not have the ability to switch to BGR. The screen does have the ability. This code excerpt is from the linux drm display driver. Perhaps I should make a PR to pimoroni to enable that MAD control.

#define ST77XX_MADCTL_MY  0x80
#define ST77XX_MADCTL_MX  0x40
#define ST77XX_MADCTL_MV  0x20
#define ST77XX_MADCTL_ML  0x10
#define ST77XX_MADCTL_BGR 0x08
#define ST77XX_MADCTL_RGB 0x00

Sorry for the tangent. And back to your proposal. It is probably likely that the displays are all pretty similar, and we can create a parameter table in the python code to set the values accordingly. We could just keep the settings.txt to have the ability to select a display type, then most everything is automatic. I do think we should keep rotation in the settings, since someone may need to put the screen in upside down. But rather making it an angle setting, we can just make a upside-down setting.

If you like this direction, I can update this PR with a new proposal.

[AndreaFavero71]

Hi Paul, my suggestion is to let this topic sinking until your robot will be up and running with both the displays. I believe this will let you checking for all the details: Does it fit inside the structure (i looks like it's slightly longer), the 3D file for the cover, the display mechanical support, the driver installation, etc. Other display's related aspects, could be the font sizing "automation", according to the display resolution.... just a thought.

[paul-1]

Sounds good. I'll be in touch later.

[AndreaFavero71]

Hi Paul, I forgot to mention that I'll soon release a little update, that also involve the display (further than other files).

[paul-1]

No worries, I'm pretty decent with git and managing changes.

[paul-1]

I just finished my 2nd robot, one with a ST7735 and one with a ST7789. I have a few upgrades to the prints. Cover for the camera electronics, with a nice Cubot Logo. Light Shield for the cube, it helps with overhead lighting. Printed on a Bambu X1-Carbon, so I used the multi color printing capabilities. The red is a translucent red, and it lets the LED light show through. The gray one I moved the USB-C Power connector to the base. Pardon the messy desk.

The 7789 is a much nicer display. Black is noticeably blacker, and the viewing angle is better. I have the code almost finished up, just need to clean up a few things.

[AndreaFavero71]

Hi Paul, impressice job done :-)

[paul-1]

Let me know what you think of the approach.

[AndreaFavero71]

Hi Paul, I visually checked the code, and I can follow the approach, and it looks fine. Can you confirm a couple of aspects (I still have to by that display ...): 1) If the driver installed via setup.sh (pip3 install st7789==0.0.4) works fine with your changes? 2) If the the test1_display shows three rectangles with the external one approaching (at?) display limit?

I'm now going to run a test on the st7735 display I have.

Edit1: I have done a few tests with the st7735 display and it works well. The code looks pretty clean, and the settings aren't changed much: Thank you for your contribution! I'm going to edit now the instructions, to cover this proposal. Once you'll confirm the two points above, I'll merge your pull request.

Edit2: What about the PCB_cover file matching the https://www.waveshare.com/product/displays/lcd-oled/lcd-oled-3/2inch-lcd-module.htm display?

Edit3: Sorry, other questions: By looking to the display pinout, it seems having a different order. How have you matched it? Adapted the Connections_board?

[paul-1]

1. Yes,I'm using a RaspiOS Bullseye (Fully updated) install on a Pi Zero 2, and used your install script to install the required dependencies. No modifications to drivers, just the changes in this commit.

2. Yes I see 3 rectangles. With the increased resolution, its hard to count pixels, but its real close to the edge. The only thing I see is the Fonts may be slightly oversized. Mainly on the Cube display the large font showing the cube side.

3. The displays I used in testing is both waveshare lcd's. https://www.waveshare.com/product/displays/lcd-oled/lcd-oled-3/1.8inch-lcd-module.htm and https://www.waveshare.com/product/displays/lcd-oled/lcd-oled-3/2inch-lcd-module.htm both have the same pinout, but they include a cable that connects to the display and has dupont female connectors on the other end. The display is set forward in the PCB cover to give plenty of room to connect the cable. it would be easy to connect to the boards you have in the PDF. I can supply Covers models for both of these displays in the USBC variant.

4. Yes, I also had a pCB printed, based on the standard schematic. And used JST connectors.

[AndreaFavero71]

I'd suggesting you add a "waveshare_displays" folder into https://github.com/AndreaFavero71/cubotino/tree/main/personalizations, and add the PCB_cover files and some pictures of how the wiring looks like and how the display is fixed. This could be part of the same Pull request I'll link that folder/info in the instructions.

[paul-1]

I'll work on that this weekend.

[AndreaFavero71]

Hi Paul, I was just checking if your robots are working well or if my support is needed (I doubt :-)). If all well, I would be grateful if you would publish your I MADE IT on Instructables page (https://www.instructables.com/CUBOTino-Autonomous-Small-3D-Printed-Rubiks-Cube-R/, acccout needed). Differently, may I add above picture to the CUBOTino family?

[paul-1]

Doing well. I was experimenting with different cubes. Some definitely work better than others. Facelet detection for all cubes seems to work best with boarderless settings, even on my cubes with boarders. I have a feeling that it's the v2 camera differences. White balance seems off, but changing white balance settings seem to not have any affect.

Feel free to use images that I posted, I'll try to find the time to do something on instructables.

[AndreaFavero71]

Thank you Paul. A way to speed up the color picking is to reduce the fcs_delay parameter, from default 3 to about 0.5: This only gives one chance to the edges detection algorithm, and afterward the facets colors will be taken on fix coordinates. The fix coordinates are anyhow automatically saved each time a cube is correctly detected via the edges detection. For what concerns the robustness on color detection, there still is room for improvement: I'll sooner or later port one of learnings from Cubotino_Pocket project.