Bilder mit c++ und atmega 328 anzeigen

Ich möchte ein Programm erstellen, das Farbbilder (eventuell auch Videos mit Ton) auf einem kleinen Farb-LCD-Bildschirm anzeigt. Ich möchte einen Atmega 328-Chip mit einer SD-Karte verwenden, um die Bilder zu speichern. Jede Hilfe, die mich in die richtige Richtung weisen würde, wäre sehr dankbar.

Sie müssen uns mitteilen, mit welchem ​​Teil Sie Probleme haben. Hast du ein LCD ausgewählt? Haben Sie herausgefunden, wie man eine SD-Karte verwendet? Diese Frage ist viel zu weit gefasst, um hier gut zu passen. Die Fragen sollten sich im Allgemeinen auf ein bestimmtes Elektronikdesignproblem beziehen.
Ich stimme zu – diese Art von Posts, die mich in die richtige Richtung weisen, sind normalerweise absurd vage und häufig unmöglich oder unvernünftig. Gibt es eine Möglichkeit, das gleiche Maß an allgemeiner Wut über diese Fragen aufzubringen wie über Einkaufsfragen?

Antworten (2)

Ohne weitere Details ist es unmöglich, eine spezifische Antwort zu geben, also hier ein paar allgemeine Dinge:

Wenn Sie Farbvideos anzeigen möchten (z. B. ~24 Bilder oder mehr pro Sekunde), benötigen Sie etwas mehr Rechenleistung, als die meisten 8-Bit-uCs bieten können.

Angenommen, Sie haben ein kleines 240 x 320 Farb-TFT-Display mit bis zu 18-Bit-Farbe. 18-Bit-Farbe ergibt 2^18 = 262144 mögliche Farben.

Sie benötigen mindestens einen Bildschirm RAM für den Anzeigespeicher.
Um einen ganzen Bildschirm anzuzeigen, werden 240 x 320 x 18 = 1382400 Bits (1,38 Mbit oder 172,8 KByte) RAM benötigt.
Wenn Sie eine Bildrate von sagen wir 25 Bildern pro Sekunde haben, dann haben Sie einen Datendurchsatz von 1,38 Mbit x 25 = 34,56 Mbit oder 4,32 MB pro Sekunde.

Natürlich müssen Sie nicht die vollen 18-Bit-Farbinformationen verwenden, sodass Sie beispielsweise auf 240 x 320 x 8 = 614400 Bit pro Frame mit 256 Farben (~ 15,3 Mbit für 25 fps) herunterkommen können.

Für Schwarzweiß braucht man nur 1 Bit pro Pixel, also bekommt man 240 x 320 x 1 = 76800 Bit oder 9,6 KB pro Frame. Der Durchsatz bei 25 fps wäre 240 x 320 x 25 = 240 KB pro Sekunde.

Wenn Sie also nicht nur statische (oder sich langsam ändernde) Bilder wünschen, würde ich empfehlen, sich einen 32-Bit-uC wie einen PIC32 oder eine Art ARM anzusehen. Die Display-Controller-ICs, die die Displays ansteuern (dh das Ding, mit dem Ihr uC spricht), haben normalerweise mindestens einen Frames Speicher, manchmal mehr, sodass Sie mit begrenztem RAM arbeiten können, wenn Sie die Dinge ein wenig mischen, aber im Allgemeinen sind Sie die Idee Nehmen Sie Ihre Änderungen im uC-RAM vor und aktualisieren Sie dann den gesamten Bildschirm auf einmal mit Ihrer angegebenen Bildrate.

Microchip hat ein paar TFT-Entwicklungsboards und einen Grafikstapel, um bei der Entwicklung zu helfen, obwohl ich nicht weniger als die High-End-PIC32s zum Ansteuern wählen würde.
Abhängig von Ihren Auflösungs-/Farb-/Soundanforderungen ist ein leistungsfähigerer ARM möglicherweise besser, sie reichen von Geschwindigkeiten von 40 MHz bis zu GHz, also eine große Auswahl - die Entwicklungsmöglichkeiten sind im Allgemeinen jedoch nicht ganz so budgetfreundlich.
Ein ausgezeichneter Chip ist der STM32F4, sehen Sie sich das STM32F4 Discovery Board an, es hat alles, was Sie brauchen, um es für 10 £ zu verwenden (ja, wirklich). Dafür erhalten Sie einen 168-MHz-uC mit 1 MB Flash, 192 KB RAM und mehr Peripheriegeräten, als Sie sich vorstellen können. Außerdem sind auf der Platine ein MEMS-Beschleunigungsmesser und ein Mikrofon, ein Codec und eine Kopfhörerbuchse sowie ein STLINK2-Programmierer (der zum Programmieren anderer ST-Chips verwendet werden kann) enthalten.

Auf der anderen Seite ist die Entwicklung nicht so freundlich wie zB Microchip oder Atmel - sie bieten keine IDE und die Dokumentation lässt zu wünschen übrig.

Zufälliges Video von STM32F1 beim Abspielen von QVGA

Ich bin mir etwas unsicher über die Farbtiefe und die Anzahl der Bits - möglicherweise liegt ein Fehler in der Anzahl der Farben vor, und ich denke, es könnte gut sein, RGB- und BW-Bilder nur aus Gründen der Klarheit zu trennen. Wie auch immer +1 :)
@clabacchio - Ich habe fälschlicherweise 2 ^ 28 eingegeben, ich habe es auf 2 ^ 18 korrigiert, was es hätte sein sollen. Außerdem wurden einige Berechnungen für das Schwarzweißbild hinzugefügt.
Gesehen :) Aber mit 18 Bit Tiefe meinst du 18 Graustufen oder 6x3? Ich interessiere mich nicht so sehr für Bildkomprimierung und Anzeigesteuerung, aber vielleicht könnte Farbzuordnung hilfreich sein?
Mit 18-Bit-Tiefe meine ich RGB 6-6-6 für 262.000 Farben. Also ja 6x3. Andere Optionen wären Dinge wie RGB 5-6-5, RGB 4-4-4 usw. Sie können eine Farb-LUT verwenden, um aus verschiedenen Formaten zu konvertieren, die Anzeigetreiber-ICs haben normalerweise eine eingebaute.

Klingt für mich so, als sollten Sie zunächst ernsthaft darüber nachdenken, Ihre Anwendung auf einem Arduino zu entwickeln, da sie auf dem ATMega328 basiert.

Es gibt eine Reihe von Bibliotheken und Tutorials zum Ansteuern von Grafik-LCDs. In ähnlicher Weise enthalten die Arduino-Kernbibliotheken SD-Kartentreiber . Und sobald Sie dazu bereit sind, gibt es auch Shields und Treiber zum Generieren von Audio .

Sobald Sie mit Arduino und Shields Prototypen erstellt haben, können Sie die kompilierten Artefakte (z. B. Hex- / Elf-Dateien) aus dem Arduino-Build abrufen und in Ihrem eigenen integrierten Design verwenden.

Unter der Decke ist die Arduino-Software nur C++, das mit avr-libc / avr-gcc erstellt wurde.

Könnten Sie mir zeigen, wie ich das ohne Arduino machen kann? Ich habe bereits einen Programmierer und einen Chip und ein Steckbrett.
@Cjueden Sie können die Arduino IDE verwenden, um Ihre Software zu entwickeln, und dann Ihren ATMega328 wie gewohnt (z. B. mit einem ISP-Programmierer) mit der von der avr-gcc-Toolchain generierten Intel-HEX-Datei ansprechen ... oder alternativ einfach C++ verwenden Quellcode aus den jeweiligen Bibliotheken zur Einbindung in Ihr eigenes Projekt.
Bilder mit c++ und atmega 328 anzeigen
AntwortenHierDatenschutz-Bestimmungen1y, 0v