Raspi en 7 inch AMOLED display via MIPI aansluiten- haalbaar of onbegonnen?

Hoi,

De "eerste de beste" op alibaba heeft een amoled. Of dat ook "oled" is zoals jij wilt hebben weet ik niet.

https://www.alibaba.com/product-detail/Hksebo-7-AMOLED-Display-FHD-108…

Omdat "oled" een substring van amoled is gok ik van wel.

Dit is 2x goedkoper dan wat jij op aliexpress op het oog had.

De lol van via alibaba kopen is dat je meestal direct met een fabrikant praat. En die MOET een datasheet hebben. De kwaliteit kan "slecht" zijn maar er is in ieder geval iets.

Dat ligt anders op aliexpress aangezien je dan te maken hebt met kleine doorverkopers die items inkopen bij de fabrikanten of op de "grote markt" in shenzhen, en dan zonder kennis van zaken proberen door te verkopen.

Loop een keer langs bij m'n nieuwe kantoor. !

Hoi,

AMOLED of een andere variant zou ook prima zijn maar ik ben bang dat dit toch een LCD is ipv OLED. Een paar indicaties:

• Onder het kopje AM OLED lcd display list,if you didn't find the size you need,please inquiry us.
  Staat een tabel en in de kolom Display Mode staat IPS. Er is nog een tweede tabel waar wel expliciet OLED staat maar die zijn niet groter dan 3.12" en hebben een SPI en/of I2C aansluiting en zijn grotendeels monochroom
• The sizes of TFT LCD modules we are offering are:
  1.44", 1.77", 2.0", 2.2", 2.4", 2.8", 3.0", 3.2", 3.5", 4.3", 5.0", 7.0", 8",9.7" and 10.1"and other sizes for industrial or special area.
• Als je de video afspeelt staat daarin o.a.
  - 1200*1920 LCD Display with Capacitive
  - Manufactured by ND this TFT display
  - 4.3 inch lcd display for you... this lcd is full HD
  - With LED backlighing and ratio of 900 to 1
• Het display ziet er mat uit in de video, OLEDs zijn bijna altijd spiegelend
• De prijs lijkt typisch voor een LCD, niet voor een OLED voorzover ik heb kunnen vinden

Ik heb een keer iets gekocht bij Alibaba ipv AliExpress, ging op zich prima maar was wel wat minder gestroomlijnd dan bij Ali maar dat is niet zo gek (consument vs b2b). Was op zich wel voor herhaling vatbaar, zolang de minimum afname niet in de weg zit.

Loop een keer langs bij m'n nieuwe kantoor. !

Ga ik zeker doen!

Ik weet niet of je er iets aan hebt, maar lang geleden heeft Mike's Electric Stuff een video serie gemaakt over het aansturen van een iPod Nano scherm via MIPI:
https://www.electricstuff.co.uk/nanohack.html
https://www.youtube.com/watch?v=7TedIzmguP0

Dat was best interessant om te bekijken maar ik mag toch hopen dat ik niet hoef te reverse-engineeren om dit scherm aan te sturen, dat is geen optie. Ik hoopte eigenlijk dat er een DSI driver is voor de Raspi (bijvoorbeeld die van de officieel ondersteunde schermen) die je dusdanig kunt configureren met parameters van de fabrikant dat je beeld krijgt.

Maar misschien is zo'n driver er niet. Ik geloof dat de officieel ondersteunde schermen 2 MIPI lanes gebruiken en het OLED scherm uit mijn oorspronkelijke post gebruikt er 4. Kan me goed voorstellen dat de bestaande drivers niet zo flexibel zijn dat je dat met een parameter kunt instellen.

Wanneer het scherm echt zwart moet zijn wanneer het systeem niet actief is kun je bij een TFT-LCD ook de backlight uit zetten misschien?

Als uitzetten van de backlight al mogelijk is (dat kan bijvoorbeeld niet met een gewoon LCD scherm met HDMI aansluiting voorzover ik weet, dan moet je het scherm echt even helemaal uitzetten) dan nog denk ik dat dat niet het gewenste effect gaat geven voor mijn toepassing. Ik denk dat je dan namelijk nog steeds het rechthoekige kader gaat zien als er wel beeld is en dat zou het effect onderuit halen. Dus het niet zo dat het scherm alleen helemaal zwart moet zijn als er geen beeld is.

[Bericht gewijzigd door Delphium op woensdag 28 januari 2026 21:20:05 (14%)]

Op woensdag 28 januari 2026 20:15:44 schreef Delphium:
Maar misschien is zo'n driver er niet. Ik geloof dat de officieel ondersteunde schermen 2 MIPI lanes gebruiken en het OLED scherm uit mijn oorspronkelijke post gebruikt er 4. Kan me goed voorstellen dat de bestaande drivers niet zo flexibel zijn dat je dat met een parameter kunt instellen.

Dat lijkt me geen software issue, maar een hardware issue. De processoren hebben een beperkt (en met de generatie groeiend aantal CSI/MIPI pins. Maar sinds de eerste RPI ligt de connector vast, volgens mij met twee MIPI lanes. Dus RPI heeft voor het eigen 7 inch scherm dus moeten schipperen om een 2-lane scherm te vinden. Nu weet ik niet of je met "minder pixels per sec" toch 2 lanes zal kunnen gebruiken op een 4-lane scherm.

Dat is wel redelijk gebruikelijk. De fabrikant brengt een nieuw scherm uit en wil dat die compatible is met de oude....

REW schreef aan Gemini:
On SPI connected displays (usually smaller) I have to send a whole initialization sequence. Is DSI similar, or is DSI just an XxY datastream of the right timing, pixel-depth and size?

Gemini antwoordde:
That is exactly where the complexity lies. The short answer is: It is both.

DSI (Display Serial Interface) is significantly more complex than SPI because it operates in two distinct modes to handle both configuration and high-speed video.

1. The Two Faces of DSI
When a Pi starts up, it communicates with a DSI display using two different protocols over the same physical wires:

LP (Low Power) Mode / DCS: This is very similar to SPI. It uses the Display Command Set (DCS) to send an initialization sequence. This tells the display controller how to wake up, what the internal voltage levels should be, and how to map colors.

HS (High Speed) Mode: Once initialized, the bus switches to a high-speed differential clock. This is the "datastream" you mentioned: a continuous flow of pixel data timed perfectly with horizontal and vertical sync pulses.

Er schijnen drivers (DeviceTreeBlobs) te zijn voor diverse chips. Welke chip heeft dat ding?

Volgens wat ik gelezen heb heeft de Raspi 5 heeft een andere MIPI connector (22 pins met een kleinere pitch) dan alle voorgangers (15 pins) en ondersteunt als eerste 4 MIPI lanes ipv slechts 2. Dus volgens mij zou dit scherm wel met een Raspi 5 te gebruiken zijn en mogelijk niet met eerdere versie ivm max aantal lanes (tenzij misschien met lage refresh). Ik neem aan dat een Raspi 5 zonodig ook met 2 lanes kan werken ipv 4 dus vandaar dat ik denk dat het een software/driver kwestie is voor dat model Raspi.

1.2.1 Display color: 1.07 billion colors (RGB x 10bits)
1.2.2 Frame rate: Support max 165HZ
1.2.2 Display format: 7" FHD(1080RGBx1920)
1.2.3 Pixel Configuration: V-style4
1.2.4 Interface: MIPI 4 lanes
1.2.5 Driver IC: SH8804B
1.2.6 Touch IC: FT3519T
1.2.7 Touch screen?On-Cell

Driver IC is dus SH8804B, die lijkt niet zo standaard te zijn als sommige andere IC's. Verder lijken de andere bovenstaande zaken zoals de 'V-style4' pixel configuration mij ook belangrijk om in een eventuele driver te kunnen configureren, als dat niet overeenkomt zul je vermoedelijk naar een zwart scherm staren.

De termen Device Tree's en Device Tree overlay's was ik al tegengekomen (zonder precies te weten wat dat inhoud) maar DeviceTree blobs zijn nieuw. Als ik het goed begrijp zou het daarmee mogelijk moeten zijn om precies bovenstaand soort hardware parameters te coderen zodat de Raspi er iets mee kan. Zou natuurlijk ideaal zijn als de fabrikant zelf zo'n Device Tree Blob aanbied voor dat scherm icm een Raspi 5 maar dat vind ik niet terug op hun website of in de datasheet.

Heb voor de grap eens aan Google gevraagd wat die er over 'weet'. Hele korte samenvatting van wat daar uit komt:

Connecting an SH8804B 4-lane MIPI OLED to a Raspberry Pi 5 requires a custom
Device Tree Overlay (.dtbo). Unlike older Raspberry Pi models where you might use a dt-blob.bin, the Pi 5 uses the VC4 DRM/KMS driver architecture, meaning the display must be defined as a panel node in the device tree.

Hij komt ook met een .dst bestand en vraagt vervolgens om timing parameters Vertical Back Porch (VBP) en Horizontal Back Porch (HBP) om dat .dst bestand aan te passen maar die zie ik nergens in de datasheet, ook niet onder een andere naam. De enige timingparameters die ik daar vind zijn voor de power-on en power-off sequence.

Die on/off sequence kan ook nog wel eens lastig worden als ik Google AI mag geloven:

The SH8804B often requires an initialization command sequence (e.g., 0x11 for Sleep Out, 0x29 for Display On) sent via DCS. Since the standard Pi panel-simple driver doesn't support these commands via Device Tree alone, you may need to use a Generic DSI Panel Driver or write a small custom kernel module if the display remains blank.

Misschien moet ik maar aan die fabrikant vragen of die een kant-en-klaar .dst bestand heeft voor een Raspi 5. Of anders op zijn minst de timing parameters die daar kennelijk in moeten staan volgens Google:

    compatible = "brcm,bcm2712";

    fragment@0 {
        target = <&dsi1>; /* Pi 5 Port 1; use dsi0 for Port 0 */
        __overlay__ {
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;

            panel@0 {
                compatible = "sh8804b,panel"; 
                reg = <0>;
                reset-gpios = <&gpio 24 1>; /* Adjust to your reset pin */
                dsi,lanes = <4>;
                dsi,format = <0>; /* 0 = RGB888. 10-bit support may require a specific driver bridge */

                display-timings {
                    native-mode = <&timing0>;
                    timing0: timing0 {
                        /* Standard 60Hz example: approx 135MHz clock */
                        clock-frequency = <135000000>; 
                        hactive = <1080>;
                        vactive = <1920>;
                        hfront-porch = <...>; /* From Datasheet */
                        hback-porch = <...>;  /* From Datasheet */
                        hsync-len = <...>;    /* From Datasheet */
                        vfront-porch = <...>; /* From Datasheet */
                        vback-porch = <...>;  /* From Datasheet */
                        vsync-len = <...>;    /* From Datasheet */
                    };
                };
            };
        };
    };
};

Als ze dat niet kunnen aanleveren inclusief meer info over hoe een on/off sequence te versturen vanuit een Raspi lijkt het me onbegonnen werk. Dan zou je hun HDMI driver board moeten kopen en daar de timing van meten maar dat is zinloos aangezien ik maar een exemplaar nodig heb en juist liever niet voor zo'n driver board wil betalen (plus dat het een beetje klungelige oplossing is).

Linkje naar de conversatie met Google AI (blijft 7 dagen geldig):
https://share.google/aimode/Je4MjQmwixz2VNrLY

Op donderdag 29 januari 2026 13:22:13 schreef Delphium:
Hij komt ook met een .dst bestand en vraagt vervolgens om timing parameters Vertical Back Porch (VBP) en Horizontal Back Porch (HBP) om dat .dst bestand aan te passen maar die zie ik nergens in de

Die backporch timings horen bij de horizontal en vertical timings.

Je hebt een tijdje display data, dan een tijdje niets, dan een sync puls, en dan weer een tijdje niets.

Vroeger had was die periode na de display data nodig om het kanon uit te zetten. De sync en wat er na komt om de beam terug naar links/boven te krijgen, en dan weer "clean" te beginnen met bewegen.

Aangezien dat allemaal niet meer hoeft, zou ik verwachten dat dat soort dingen niet echt meer belangrijk zijn, anders dan dat je waarschijnlijk IETS moet invullen omdat het minofmeer compatible moet zijn met de oude CRT shit. Let op: Niemand implementeert de onderste drie bitjes van de timing registers voor de H timing.

Ik zou verwachten dat iets als 1920+32+32+32 wel zou werken. Ik vermoed dat je die timings dan ook aan de chip moet vertellen zodat ie met de raspberry op 1 lijn zit. Dus die timings moeten gewoon aan beide kanten hetzelfde gezet worden, en hoe je dat naar die chip moet schoffelen... is tricky.

De "Device Tree Source" is een compiler voor die er de binary bestandjes van maakt.

Misschien moet ik maar aan die fabrikant vragen of die een kant-en-klaar .dst bestand heeft voor een Raspi 5. Of anders op zijn minst de timing parameters die daar kennelijk in moeten staan

Met "je bent op jezelf aangewezen als jehem direct op een pi wil aansluiten" hinten ze sterk naar dat ze hier geen zin in hebben danwel dat ze het geprobeerd hebben en dat het niet gelukt is.

Ik verwacht inderdaad niet al te veel medewerking, maar nu kan ik in ieder geval gerichte vragen stellen ipv 'Hoe sluit ik dit aan op een Raspi'. Als ik daar geen duidelijk antwoord op krijg houdt het wel op met die MIPI interface. Laat nog wel weten wat het resultaat is.

Ik heb ze nog geen mailtje gestuurd maar omdat de datasheet op de Panox Display website die van het scherm zelf is en niet van het driver IC heb ik nog maar eens met Google AI gechat of die ergens te vinden is met dit als resultaat:

>>> Where can I find a datasheet for the SH8804B ic itself

Finding a standalone datasheet for the SH8804B display driver IC can be difficult because it is typically proprietary information shared directly between the manufacturer (SinoWealth) and display module integrators.
...
Are you looking for the pinout for a specific repair, or do you need the initialization codes for a custom controller?

>>> I need timing specifiations for horizontal and vertical back porch

Timing specifications for the SH8804B display driver IC vary depending on the panel's resolution and target refresh rate. For the most common implementation—a 7-inch 1080x1920 (FHD) AMOLED panel at 165Hz (e.g., Panox Display PO070FMTO)—the typical timing parameters are as follows:

Typical Timing Specifications (1080x1920 @ 165Hz)

Horizontal Back Porch (HBP): ~32 to 64 pixels (Commonly set to 48 for stability).
Horizontal Front Porch (HFP): ~32 to 64 pixels.
Vertical Back Porch (VBP): ~12 to 24 lines (Commonly set to 16).
Vertical Front Porch (VFP): ~10 to 20 lines.
Horizontal Sync Width (HSW): ~4 to 10 pixels.
Vertical Sync Width (VSW): ~2 to 4 lines.

Calculating Your Specific Timings

If you are using a different refresh rate (e.g., 60Hz or 120Hz), you may need to adjust these values to maintain a valid Pixel Clock. You can use the general relationship:

Total Horizontal Pixels = H_Active + HFP + HBP + HSW
Total Vertical Lines = V_Active + VFP + VBP + VSW
Pixel Clock = Total Horizontal × Total Vertical × Refresh Rate

Note on Proprietary Data: Because SinoWealth classifies the full SH8804B datasheet as confidential, these values are typically found within the Project Initialization (Init Code) provided by panel manufacturers. If these "typical" values result in image shift or flickering, you may need the specific Initialization Script from your panel supplier to set the internal timing registers via MIPI DSI Display Command Set (DCS).

Fijn dat zo'n fabrikant dat soort specs als vertrouwelijk beschouwd. Maar de exacte tijd van die back porch is dus zoals @rew al zei niet zo heel kritisch. Ik kende alleen de term Horizontal/Vertical Blanking interval uit de CRT tijden en die back porch is daar kennelijk (al van oudsher) een onderdeel van: Horizontal Blanking Interval= Front Porch + the Sync Pulse + Back Porch. Dus misschien dat dit deel nog wel meevalt omdat het display hierin vergevingsgezind is.

De power on/off sequence blijft een beetje mysterieus. In de datasheet van het panel staat een timingdiagram maar het is me niet duidelijk of dat gewoon overeenkomt met de generieke DSI on/off commando's die je kennelijk via mipi_dsi_dcs_write kunt sturen. Een gemiddeld scherm heeft kennelijk vaak een 0x11=ON en 0x29=OFF commando en dat moet dan kennelijk door de driver worden gestuurd via een call als dit:

mipi_dsi_dcs_write(dsi, 0x11, NULL, 0);

Het is me niet duidelijk of je een generieke driver via een .dst device tree overlay file kunt vertellen wat de on/off sequence is die hij moet gebruiken.

Ik zou aanraden om HSW wel een veelvoud van 8 te maken. Dus 8 of 16. 1) het komt niet zo kritisch, 2) ik vermoed nog steeds dat vrijwel niemand de onderste paar bitjes daarvan implementeert.

Ik zou denken dat de datastroom gewoon doorgaat tijdens "niet actieve data", maar misschien stoppen ze dat wel. Mogelijk zie je zoiets op de plaatjes van Mike.

[Bericht gewijzigd door rew op vrijdag 30 januari 2026 14:11:29 (36%)]

Bedoel je met dat laatste het verschil tussen een Video Mode panel vs Command mode panel? Waarbij de eerste een continue datastroom verwacht terwijl de tweede een on-panel framebuffer heeft en je alleen verplicht bent data te sturen als de inhoud wijzigt?

Dat panel van Mike was een (soort) Command mode panel waarbij alleen data werd verzonden bij wijzigingen. Ik gok dat dat vooral gebruikelijk is bij portable devices (zoals die iPod Nano van Mike) met een klein scherm waarbij ze het energieverbruik zo laag mogelijk willen houden.

Heb ze net een mailtje gestuurd en heb de vraag toegevoegd of dit een Video Mode of Command Mode panel is. Nu maar afwachten wat voor reactie ik krijg.

Ik verwacht echt niet dat het een "command mode" panel is.

Ik heb een project met een RP2040 die een 1.3" shermpje aan moet sturen. (eigenlijk is het bijzaak, hij MOET heel wat anders, maar voor de leuk heeft ie ook een klein statusschermpje).

Dan heb je een "lompe" moderne microcontroller met 260kB geheugen.

En een 240x135x16 bit schermpje. Goed: 64k. Dat zou net passen, maar een ATmega328 of een STM32F072 kan dat dus absoluut niet aan. Daar is dus een LCD-controller met iets meer dan 64k aan geheugen voor nodig.

Maar dat ding van jou: Ik verwacht eigenlijk niet dat die chip de 6Mbyte aan RAM heeft om 1 frame op te slaan. (Goed... Op een intel vind je 2000 pins "best een hoop". Dit ding heeft er minimaal 5200! Dat is zowiezo best heftig, dus 6 Mbyte SRAM zou kunnen...)

Tegen de tijd dat je "fullHD" doet, heeft het niet zoveel zin om niet een forse bandbreedte naar de "controller" te hebben. Je wilt een video gewoon realtime kunnen afspelen. Die "50FPS" hoef je op een 240x135 schermpje dus niet te halen: Een idioot die daar een speelfilm op wil gaan kijken.

Heb een keurig en uitgebreid mailtje terug ontvangen van de fabrikant. Volgens de fabrikant zou er een speciaal MIPI->MIPI interface board moeten worden gemaakt wat, opnieuw volgens de fabrikant, een heleboel uitdagingen met zich meebrengt:

1. Benodigde voedingsvoltages zijn niet voorhanden op de Raspi MIPI poort
2. Ontbrekend Reset (RESX) signaal op de Raspi MIPI poort, daar zou een GPIO pin voor moeten worden gebruikt
3. Ontbrekend Tear-Off Effect Signal (TE). Ook daar zou wellicht een GPIO pin voor moeten worden gebruikt.
4. Het is henzelf niet duidelijk of alle signaallijnen compatibel zijn qua voltage (Reset)

En dan heb ik nog helemaal geen reactie gehad over het softwarematige gedeelte. Wat ze op hun website schrijven:

If your Raspberry Pi can support the interface of the display panel, and you know how to program on Raspberry Pi, you can connect to our display.

is kortom veel te optimistisch. Het komt er feitelijk op neer dat het theoretisch mogelijk is maar alleen met een grote inspanning om hardware en software te ontwikkelen.

Ik heb dit display daarm afgeschreven als mogelijk oplossing. In plaats daarvan ga ik denk ik via eBay een Huawei Mate 20x smartphone bestellen uit China, 'new sealed in box' volgens de verkoper.

Deze heeft een 7.2" OLED display en in principe hoeft het ding niet meer te doen dan een filmpje af te spelen, liefst op repeat maar anders maar ik gewoon een heel lang filmpje. Het zou wel leuk zijn om het eventueel interactief te maken maar mocht dat niet kunnen dan is het zo ook goed want ik heb nog meer projecten gepland voor komende Halloween.

Nu maar hopen dat het een echte Huawei is en geen immitatie, maar ik heb het idee dat het gewoon new old stock is die ze daar nog verkopen. Ga in ieder geval betalen met Paypal, dan krijg ik hopelijk mijn geld terug als het een immitatie blijkt te zijn met een LCD scherm ipv OLED.