optimales Bildformat für Microcontroller + TFT

Stefan · 2013-08-12T14:34:40+00:00

Hallo, wir haben ein STM32 System mit 800x480 TFT Display auf Basis eines SSD1963 entwickelt und versuchen jetzt, Bilder auf dem Display darzustellen. Die Bilder kommen von einer SD-Karte mit FAT32. Grundsätzlich funktioniert das schon, ist aber zu langsam. Hauptproblem ist wohl der Zugriff auf die SD-Karte. Da ist sicherlich noch einiges zu optimieren, z.B. Hardware-SPI. Momentan verwenden wir Software-SPI. Die Bilder sind momentan als 16 Bit BMP (565) gespeichert. Ich kenne von früher her *.PCX. Das könnte einiges bringen und ist einfach in der Auswertung. Also weniger Bytes über SPI einlesen, dafür etwas mehr rechnen und insgesamt schneller das Bild aufbauen. Welche anderen Bildformate sind für eine solche Anwendung geeignet, bzw. was wäre das beste Bildformat für den Zweck? Wichtige Randbedingungen sind: Wenig RAM, z.B. 1 Zeile á 480 unsigned short zeilenweiser Bildaufbau Das komplette Bild kann nicht im Ram gespeichert werden. Gruß Stefan

Aug 12, 2013 25 Replies

Rate this thread:

Stefan vor 12 Jahren

Daran hab ich durchaus schon gedacht. Sprengt eventuell aber den Kostenrahmen und funktioniert auch nur vernünftig mit einem 2. Display.

Ist bekannt. Bisher haben wir bei SPI genutzt, um den ADU des Touch-Screens auszulesen und keine hohen Geschwindigkeitsanforderungen gehabt. Und bei der SD-Karte hatten wir zunächst auch erstmal andere Probleme, als die Geschwindigkeit.

Momentan benötigen wir ca. 8 Sekunden.

Für das Display benötigen wir deutlich unter einer Sekunde.

Ich denke mal, wir werden die Bildgröße verkleinern. Wie schon beschrieben, oben und unten Teile abschneiden, Texte oder feste Grafiken z.B. Logos ausgeben. Hintergrund in einer festen Farbe.

Gruß

Stefan

Vote

Uwe Hercksen vor 12 Jahren

Stefan schrieb:

Hallo,

Lauflängenkodierung ist aber für solche Bilder gerade besonders schlecht geeignet. Bei einem Logo könnte das noch gutgehen, beim Früstücksbuffet mit Verläufen, Texturen und kleinen Details eher schlecht. Das Hotelzimmer mit grosser weißer Wand konnte gutgehen, mit kleingemusterter Tapete dagegen nicht.

Bye

Vote

Uwe Hercksen vor 12 Jahren

Stefan schrieb:

Hallo,

eine ganz simpel programmierte Lauflängencodierung kann in ungünstigen Fällen auch die Datei bis auf das doppelte vergrössern wenn man 16 Bit für die Lauflänge nimmt und 16 Bit für die Bildpunktdaten. Oder auf das

1,5 fache bei 8 Bit für die Lauflänge. Man sollte sie also nur auf Bilddateien anwenden die sich damit ordentlich reduzieren lassen oder man muss die Daten vorbearbeiten, Rauschen entfernen und gleitende Farbverläufe in genügend wenige Stufen umwandeln.

Bye

Vote

Frank Buss vor 12 Jahren

Na dann wäre die Lösung doch, einfach die Geschwindigkeit zur SD-Card zu erhöhen, sollte ja Faktor 10 drin sein. Falls du den Hardware-SPI Anschluss für den ADU des Touch-Screens verwendest, müsstest du das dann allerdings umlegen, wenn da nur ein SPI-Modul drauf ist, denn den kannst du wahrscheinlich per Bitbanging abfragen.

Frank Buss, http://www.frank-buss.de electronics and more: http://www.youtube.com/user/frankbuss

Vote

Hartmut Kraus vor 12 Jahren

Man kann auch im Zeitalter hochgezüchteter Verbrennungsmotoren eine neue mikrorechnergesteuerte Dampfmaschine erfinden.

Vote

Wolfgang Draxinger vor 12 Jahren

Wieso SPI? Die STM32 haben ein echtes SDIO-Interface. Und damit bekommt man auch größere Datenmengen schnell von der SD-Karte. Ich kann hier damit beim Einschalten des Geräts eine schöne Animation abspielen, bis der Rest der Hardware "wach" ist.

Natürlich sollte man das Display auch mit dem schnellen parallelen Interface ansteuern. 8080-Mode am STM32 FSMC und eine der höherbittigen Adressleitungen als CMD/DATA.

Gruß

Wolfgang

Vote

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required