[STM32/HAL] Treiber für ST7735 160 x 80 TFT

OP #6636931
Lesenswert?

Das ist ein Treiber für die attuell überall anzutreffenden kleinen 0,96" 
ST7735-Displays mit 160 x 80 Pixel und 65k Farben.

Der Treiber ist bewusst einfach gehalten, und verwendet einen 
Framebuffer. (25,6 KB – also nix für einen kleinen F103)

Eigentlich besteht der nur aus einer Initialisierungs-Funktion, dem 
Framebuffer und einer Funktion um den Framebuffer in das Dsplay zu 
übertragen.

Die Übertragung geschieht via DMA, und im Anhang befinden sich 
Screenshots der Cube-Konfiguration.

Es ist kein Fehler, daß der SPI auf 8bit-Mode und der dazugehörige DMA 
im 16bit-Mode konfiguiert ist.
Die Initialisierung benötigt den 8bit-Mode (aber keinen DMA), und danach 
wird auf 16bit umgeschaltert.

Das Framebuffer-Update geschieht dann im 16bit-Mode via DMA.

Bei der Initialisierung muß man -wie üblich- einen Pointer auf das 
HAL-Handle des genutzten SPI übergeben.

Danach reicht es aus, regelmässig ST7735_update() aufzurufen.

Wenn man das zu schnell tut, (während der vorherige Transfer noch nicht 
abgeschlossen ist) gibt die Funktion FALSE zurück, aber blockiert nicht 
– im Normalfall ist das Ergebnis TRUE.
Angehängte Dateien:
Gast #6817934
Lesenswert?

Besten Dank dafür.

Am Wochenende mal mit einem 160x128 am STM32F103 gesteckt.

Framebuffer für 16er Font paßt locker noch ins RAM und mit der 
ST7755_SetFrame(...)Function läßt sich das TFT in 8 Zeilen fix 
beschreiben.

Als Basis für weitere Optimierungen tiptop.
Gast #6819016
Lesenswert?

Harry L. schrieb:
> NichtWichtig schrieb:
>> Ist der Framebuffer kleiner als der Font hoch ist wird es hässlicher zu
>> verarbeiten.
>>
>> Das nur als Hinweis das Deine Aussage nix für einen kleinen F103
>> ausgehebelt werden kann.
>
> Falsch!
> Du verwechselst Framebuffer mit Cache...

Nöö, es gibt kein Cache.

ASCII Text + Font -> Framebuffer -> DMA -> TFT -> lesbarer Text wie 
erwartet.
Gast #6819136
Lesenswert?

Harry L. schrieb:
> Das Framebuffer-Update geschieht dann im 16bit-Mode via DMA.

Ähem... naja den Inhalt des Bildspeichers im RAM braucht man nur dann in 
den Displaycontroller zu transferieren, wenn sich dort auch etwas 
geändert hat - sonst nicht. Man muß das nicht allzu häufig machen. 
Stattdessen kann man in einer Zeichenroutine auch sowas wie ein 
'Geändert'-Flag setzen und den Transfer (in der Grundschleife in main() 
) nur dann machen, wenn dieses Flag gesetzt ist.

W.S.
Gast #6819153
Lesenswert?

NichtWichtig schrieb:
> Ist der Framebuffer kleiner als der Font hoch ist wird es hässlicher zu
> verarbeiten.

sowas erledigt lvgl, da hat man mit dieser Hässlichkeit nix mehr zu tun. 
Der Framebuffer muss nicht den kompletten Inhalt der physikalischen 
Auflösung groß sein, 10 Zeilen reichen da. Allerdings wird auch noch 
Speicher für die Zeichenobjekte benötigt. DMA ist da auch sinnvoll, vor 
allem wenn man Platz für zwei Buffer hat. Dann wird der zweite von der 
CPU gefüllt während der erste vom DMA ins Display geschaufelt wird. Auch 
unter Berücksichtigung das sich erst etwas im entsprechenden Bereich 
geändert haben muss.
Gast #6822624
Lesenswert?

Zusammen mit den Screenshots dürfte ist das sehr hilfreich.
Ein Tipp von mir:
1
void ST7735_Exit_Sleep()
2
{
3
   ST7735_Write_Cmd(ST7735_SLPOUT);
4
}

ist besser als:
1
ST7735_Write_Cmd(ST7735_SLPOUT); //Sleep exit
I.e. verständlicher Code ist besser als unverständlicher Code + 
Kommentare.
Eine weitere Verbesserung wäre es objektorientiert zu arbeiten, dann 
kann man auch mehrere Displays ansteuern.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren