Das OLEDM204 von Electronic Assembly ist ein ganz nettes OLED Display. Ich verwende es für ein größeres Homeautomationprojekt in einem Panel zur Anzeige des Status.

Das Display ist aber sehr "zickig" ist was die Initialisierung angeht. Man muss wirklich alle Kommandos und das Timing genau kontrollieren, weil das Display sonst einfach dunkel bleibt. Hier ist die Beschreibung von EA etwas dürftig.

Nachfolgend die Schritte die man unbedingt beachten muss.

1. SPI Bus LSB First

Normalerweise sind die meisten SPI Bausteine auf MSB First eingestellt, das Display benötigt zwingend LSB First.

2. Das Display muss vor Benutzung ordentlich "geresettet" werden. Resetleitung disoplay pin 12 High->LOW->High , wobei LOW für mindestens 50ms anstehen muss. Ein übliches RC-Glied tuts definitiv nicht - oder man verwendet einen RESET Baustein.

3. Initialisierungssequenz

Auch hier ist die Reihenfolge und die richtige Byteorder essentiell: Beispiel einer Initsequenz

    oled_m204_send_cmdx(hspi,0x2A);    // Set "RE"=1
    oled_m204_send_cmdx(hspi,0x79);    // Set "SD"=1
    oled_m204_send_cmdx(hspi,0x81);    // set contrast command
    oled_m204_send_cmdx(hspi,dim);    // set contrast value
    oled_m204_send_cmdx(hspi,0x78);
    oled_m204_send_cmdx(hspi,0x28);
    oled_m204_send_cmdx(hspi,0x2A);

Jedes Kommando an das Display wird mit 3 Bytes übertragen, wovon das erste Byte wahlweise 1F=CMD oder 5F=DATA bedeutet. Ein 8-bit Kommando wird in jeweils 2 Bytes übertragen.

Jede 3-Byte(!) Sequenz muss  mit chip select High->LOW begonnen werden und am Ende wieder LOW->High beendet werden.

Wichtig ist auch die SPI Polarität: CLK-Phase und CLK Polarität. Auch das hatte mich viele Stunden gekostet.

  /* SPI2 parameter configuration*/
  hspi2.Instance = SPI2;
  hspi2.Init.Mode = SPI_MODE_MASTER;
  hspi2.Init.Direction = SPI_DIRECTION_2LINES;
  hspi2.Init.DataSize = SPI_DATASIZE_8BIT;
  hspi2.Init.CLKPolarity = SPI_POLARITY_HIGH;
  hspi2.Init.CLKPhase = SPI_PHASE_2EDGE;
  hspi2.Init.NSS = SPI_NSS_SOFT;
  hspi2.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_128;
  hspi2.Init.FirstBit = SPI_FIRSTBIT_LSB;
  hspi2.Init.TIMode = SPI_TIMODE_DISABLE;
  hspi2.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
  hspi2.Init.CRCPolynomial = 10;

Hier noch die Pinbelegung am STM32:

Nachfolgend das Zip-File mit den C-Quellen. Es war mein erster Test des STM Cube IDE HAL Layers -

Vorweggenommenes Fazit: Ist doch ganz brauchbar. Man gibt zwar schon recht viel Kontrolle des Programmcodes ab - aber im Prinzip funktionierts ganz gut.

Der Hauptgrund für mich war, das man mit dem CUBE IDE und dem HAL Layer einen viel besseren Überblick über die verwendeten Pins und Subsysteme des jeweiligen Prozessors bekommt die man gerade in Benutzung hat. Insbesondere wenn man alle(!) SPI-, I2C-Busse,UARTS, CAN-Bus und Timer verwendet geht ganz schnell die Übersicht verloren. Das Argument das man mit dem HAL Layer immer bei der STM-Serie bleiben muss ist zwar im Prinzip richtig, aber bei den ARM Core Routinen muss man seinen Code auch immer an den jeweiligen Prozessor und Hersteller anpassen.

Ich habe die Library für das OLED M204 Display im Rahmen eines größeren Projekts erstellt und für diesen Artikel einfach herausgelöst. Man muss daher gegebenenfalls noch die stm32f1xx_it.c core files anpassen.

Nachtrag: Im Zipfile ist jetzt ein komplettes HAL Projectfile was man mit CubeIDE direkt öffnen kann.

Und hier noch die Pin-Belegung wahlweise für SPI1 oder SPI2:

 *      SPI1 Interface:
 *      OLED Display = Function => Olimexino Pin = STM32 Pin:
 *      Pin 12 = RESET => D2  = PA0
 *      Pin  5 = SCLK  => D13 = PA5
 *      Pin  6 = MOSI  => D11 = PA7
 *      Pin  7 = MISO  => D12 = PA6
 *      Pin 19 = CS    => D7  = PA9
 *
 *      SPI2 Interface:
 *      Pin 12 = RESET => D30 = PB11 // D2  = PA0
 *      Pin  5 = SCLK  => D32 = PB13
 *      Pin  6 = MOSI  => D34 = PB15
 *      Pin  7 = MISO  => D33 = PB14
 *      Pin 19 = CS    => D31 = PB12