Forum: Projekte & Code [STM32/HAL] Treiber für ST7735 160 x 80 TFT


von Harry L. (mysth)


Angehängte Dateien:

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.

: Bearbeitet durch User
von NichtWichtig (Gast)


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.

von Harry L. (mysth)


Lesenswert?

NichtWichtig schrieb:
> Framebuffer für 16er Font paßt locker noch ins RAM

Ein Font hat nichts mit einem Framebuffer zu tun.

von NichtWichtig (Gast)


Lesenswert?

Harry L. schrieb:
> NichtWichtig schrieb:
>> Framebuffer für 16er Font paßt locker noch ins RAM
>
> Ein Font hat nichts mit einem Framebuffer zu tun.

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.

von Harry L. (mysth)


Lesenswert?

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...

von NichtWichtig (Gast)


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.

von W.S. (Gast)


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.

von Johannes S. (Gast)


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.

von .. (Gast)


Lesenswert?

W.S. hat wieder kein Durchblick?

von eingast (Gast)


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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.