Bildspeicher auf Microcontroller [geschlossen]

Ich versuche, einen Mikrocontroller für eine sehr einfache Aufgabe zu spezifizieren. Alles, was es tut, ist, beim Hochfahren ein Bild anzuzeigen (das höchstwahrscheinlich schwarzweiß sein wird).

Das Display selbst hat 240*240 und eine Farbtiefe von 12 Bit, was bedeutet, dass es einen Gesamtspeicher von (240*240*12)/(8*1024)=84 KB hätte. Das erscheint mir recht hoch. Sollte ich nicht für den schlimmsten Fall rechnen? Kommen hier bestimmte Komprimierungstechniken ins Spiel?

Ich muss etwas Platz für einen Bootloader usw. freilassen, was meiner Meinung nach auch ziemlich viel Platz einnehmen würde.

Wo auf dem Mikro wird dieses Bild gespeichert, bevor es über SPI an das LCD gesendet wird.

BEARBEITEN:

Im schlimmsten Fall könnte es ein Schwarz-Weiß-Bild ohne Graustufen sein. Was das Problem etwas entschärft.

Aber alles mit Farbe, gibt es Lesematerial, um ungefähr zu sehen, wie viel Speicher ich für mein Display benötige?

Früher dachte ich an Animationen mit mehreren Bildern, aber angesichts meiner Kostenbeschränkungen scheint Speicher eine Prämie zu sein, und daher kommt dies nicht in Frage.

Schließlich ist es im Allgemeinen billiger, ein Mikro der richtigen Größe oder ein wirklich billiges Mikro mit externem Speicher (EEPROM?)

Es gibt wahrscheinlich Komprimierungstechniken, die Sie verwenden könnten, ja, aber Sie müssen auch den Kompromiss der Codegröße berücksichtigen. Die MCU-Preisgestaltung hängt stark von der Flash-Größe ab, mehr noch als von der Kernfähigkeit, daher kann es wirtschaftlicher sein, ein kleines externes Speichergerät zum Speichern des Bildes zu verwenden und es von einer Low-End-MCU übertragen zu lassen. Wenn Sie ernsthaft auf die Produktion abzielen, können Sie beides tun, da MCUs normalerweise mehrere Flash-Größen in einem Footprint bieten und Sie das externe Flash-Gerät immer nicht bestücken können. Machen Sie sich einmal mehr Gedanken darüber, was einfach sein wird - einfacher, das Bild ins Innere zu bekommen.
Wenn Ihr Bild keine Graustufenverpackung als monochrome Bitmap (1 Bit pro Pixel) enthält, wäre es 12-mal kleiner und erfordert wenig Code zum erneuten Erweitern. Das wäre gut für ein generiertes Bild wie ein Logo, aber schlecht für alles Bildliche. Derzeit ist Ihre Frage zu allgemein und unspezifisch, um beantwortet werden zu können.
Bearbeitet, um es hoffentlich genauer zu machen.
Entscheiden Sie sich hinsichtlich der Preisgestaltung für Ihre Menge und kaufen Sie bei dieser Menge MCUs und externe Blitze ein. Wenn Sie eine datenbasierte Animation oder Farbe wünschen, würde ich mir definitiv einen externen SPI-Flash ansehen, aber eine programmgesteuerte Animation kann intern durchgeführt werden. In Bezug auf die Komprimierung können Sie einfach versuchen, Ihr Bild zuerst auf verschiedene Arten auf dem PC zu komprimieren (oder vielleicht auf einem Himbeer-Pi, wenn Sie das Ergebnis tatsächlich auf dem Display sehen möchten), obwohl Sie die Größe des Dekomprimierungscodes für berücksichtigen müssen die aussichtsreichen Kandidaten.
Ich würde mit Off-Chip-Speicher gehen. Es gibt schnelle SPI-basierte FRAM-Chips, die Sie lesen und die Daten an das Display senden können.
@CrossRoads FRAM macht dafür wenig Sinn, es ist weitaus teurer als Standard-SPI-FLASH und nur in relativ kleinen Größen erhältlich. Normalerweise würden Sie das nur verwenden, wenn die Schreib-/Löschbeschränkungen von FLASH ein Problem darstellen, was hier nicht der Fall ist.
Es ist nur eine Option. Ich bin immer für schnelle Schreibgeschwindigkeiten zu haben. Ich denke, 512 KB wären ein bisschen teuer, um beispielsweise 6 verschiedene Bilder mit jeweils 84 KB zu speichern. digikey.com/product-detail/en/cypress-semiconductor-corp/…

Antworten (2)

Lassen Sie mich voreilig sein und voraussagen, dass Sie tatsächlich versuchen, einen ST7789 zu verwenden? basierten Controller/LCD (da Ebay mit billigen 240*240 LCDs, die auf diesem Controller basieren, überschwemmt ist).

Wenn dies zutrifft, müssen Sie zunächst verstehen, dass der LCD-Controller über einen RAM-Frame-Puffer zum Speichern des Bildes verfügt, sodass Sie möglicherweise nicht so viel RAM / EEProm für die Bildspeicherung bereitstellen müssen, wie Sie vielleicht denken. Die ST7789-Datenblätter sind hier bei Crystalfontz.

  1. Wenn Sie mit Fotos und dergleichen arbeiten, müssen Sie die Bilder in komprimierter oder unkomprimierter Form speichern können. Wenn Sie sie komprimiert speichern, um Speicherplatz zu sparen, benötigen Sie zumindest einen teilweisen Puffer, in den Sie dekomprimieren können, bevor Sie sie an die Anzeige senden. Die Vorkomprimierung mit der Anzeigeauflösung reduziert den erforderlichen Speicherplatz erheblich, aber Sie müssen sowohl die Auflösung als auch die Komprimierung (Bild/Zeile für Zeile) definieren, die Sie verwenden möchten.

  2. Wenn Sie mit Bildern arbeiten, die auf Sprites (für Animationen) oder alphanumerischen Zeichen basieren, benötigen Sie nur Speicherplatz für den Basisinhalt und können auf Ihrem Display neu zeichnen, verschieben und drehen.

  3. Wenn Sie mit Mustern arbeiten, die programmgesteuert erstellt werden, benötigen Sie fast keinen Speicher und nur einen teilweisen Puffer, um auf die Anzeige zu schreiben.

Wenn Ihre MCU mit dem Netzwerk verbunden ist, ist es möglicherweise möglich, nur teilweise unkomprimierte Puffer an die MCU zu senden und diese sofort an das Display zu übertragen. zB ein UDP-Stream --> Puffer --> Anzeige. Dies kann sehr gut für erwachsene IP-Konnektivität bei 100 Mbit / s auf einer anständigen MCU funktionieren.

Wenn Sie die Auswirkungen der verlustbehafteten Komprimierung auf die vorhandenen Bilder anzeigen möchten, können Sie einen Onlinedienst wie OptimiZilla verwenden , um die Auswirkungen auf die Speichergröße anzuzeigen. Beispielsweise kann ein typisches JPEG-Bild mit 240 x 240 Pixeln von 26 KB (typisch für das Internet) auf nur 2,1 KB komprimiert werden und dennoch durchaus brauchbar sein.

Ihr Ansatz ist richtig, wenn Sie möchten, dass es so allgemein wie möglich ist. Wenn Sie nichts über das Bild wissen, das jemand laden möchte, müssen Sie vom schlimmsten Fall ausgehen. Auch die Bildkomprimierung kann Sie nicht retten, da es theoretisch unmöglich ist, jedes Bild zu komprimieren.

Für alles andere muss man Grenzen setzen. Sie können beispielsweise entscheiden, dass Sie mit einem grauen Bild einverstanden sind, in diesem Fall benötigen Sie nur 4 Bit pro Pixel. Sie können entscheiden, nur 16 KB große JPEG-Bilder mit einem festen Satz unterstützter Parameter zuzulassen. JPEG ist nicht so schwer und wurde so konzipiert, dass es von Mikrocontrollern relativ einfach implementiert werden kann. Es gibt gute externe Tools, die Bilder auf eine bestimmte Dateigröße verkleinern können. Entscheiden Sie sich für weniger Komprimierung und Komplexität für ein anderes Format, vielleicht GIF oder PNG. Dies erfordert natürlich mehr Raum für die Dekompression.

Andererseits sind I²C- und SPI-Flash-Speicher billig und klein.