Hallo. Ich möchte euch meine Lösung vorstellen, mit der es möglich ist mit einem Atmega32 BMPs (Bitmaps) von einer SD / MMC Karte zu lesen, und diese auf einem S65 LCD Display auszugeben. Es sind ein paar Funktionen aus der lib "MMC" und "FAT" in die lib "S65" einflossen, was Geschwindigkeitsvorteile gezeigt hat. Die S65 lib stammt von "Christian Kranz" und wurde um das anzeigen von bmp erweitert. Es handelt sich nur um unkomprimierte bilder, das ich mehr wert auf Geschwindigkeit lege, als auf speicher. (SD Speicher ist nicht sonderlich teuer, Rechen power dagegen schon) Es können Bilder mit 16 bit und 8 bit Farbtiefe angezeigt werden. Die Bilder habe ich mithilfe GIMP erstellt, sicher ist das aber auch mit Photoshop möglich. Mit Pain hatte ich meine Probleme, was die 16 bit angingen. In der Zip Datei ist ebenfalls ein Schaltplan enthalten. :-) Anbei noch ein Video: **folgt** viel spaß beim testen...
Hallo, bevor ich jetzt meine eher bescheidenen C-Kenntnisse bemühe: welche Vorteile hat Deine Lösung gegenüber dieser: Beitrag "Digitaler Bilderrahmen mit mega8 S65 Display und SD-Karte" Ist wirklich nur eine Frage, habe den anderen Bilderrahmen gebaut und hatte zuerst ein paar Probleme mit dem Format der SD-/MMC-Karten. Gruß aus Berlin Michael
ich denke der größte unterschied sollte sein, das ich mit dem Hardware SPI arbeite, und somit ein Bildwechsel deutlich schneller als "3s" von statten geht. Desweiteren scheint mir so, als wäre es bei " M. Bode" nur möglich BMPs mit 24bit zu laden. Das bedeutet, das die Bilder irgendwo wieder runtergerechnet werden müssen. Meine lib kann 8 und 16 bit anzeigen, und sendet diese optimiert ans Display.
Hallo, kannst du den Schaltplan auch als jpeg hochladen? danke und mfg jtag
Anbei der Schaltplan als jpg. Und noch das versprochene Video. http://www.youtube.com/watch?v=U1Lo6-4snbM
Hallo, macht das das Display lange mit, Du bläst das Teil mit 5V Pegeln an, die schon ein Stück über der Vcc des Displays liegen. Die SD Karte auch. Wenns funktioniert, dann ist es schön zu wissen. Ich könnte mir aber gut vorstellen, dass Ableitströme über interne Schutzdioden fließen. Warum den AVR nicht gleich mit 3V betreiben und dann schauen, was für einen Takt er noch schafft. Dann wäre eine Versorgung mit einem LiPo Akku möglich, die Hintergrundbeleuchtung dann mit einem freien PWM Kanal via StepUp wie es Cristian macht. Die Induktivität kann auch kleiner ausfallen 220µH reichen. Den Code schau ich mir noch an, sieht aber sehr vielversprechend aus. Super Projekt. Grüße Lothar
> Meine lib kann 8 und 16 bit anzeigen, und sendet diese optimiert ans > Display. Was für eine optimierung nutzt du? Dithering? Bin auch zu faul mir den code an zu schauen. Ich hab das Display an nem ARM, vielleicht komm ich irgendwann dazu ne jpeg lib ein zu binden...
@Lothar Lehmann: Keine Panik. der 7805 versorg nur den JTAG. (Was aber auch keine Pflicht ist) Ursprünglich sollte die gesamte Schaltung mit 5V laufen, bis ist mich im laufe der Entwicklung, dazu entschieden habe alles auf 3,3V zu portieren, um diverse Pegelwandler zu sparen. Der Atmega32 läuft alse auf verbotenen 3,3V bei 16 MHz !!! Die 3,3V werden mit dem LM317 erzeugt. @ Lupin: Ich nutze Dithering nicht bewusst. Ich weiß nicht, was mir GIMP erzeugt, wenn ich aus einem 24 bit Bild ein 16 Bit Bild erzeuge. Optimiert habe ich es insofern, das ich lediglich Bilder lade mit einer Farbtiefe, die das Display unterstütz. (im moment nur 16 bit und 8 bit. wenig noch nicht) außerdem sind die Libs für FAT und LCD etwas mehr verschmolzen. Es sind in der LCD lib direkt angepasste Funktionen aus der FAT lib zu finden, um etwas mehr Geschwindigkeit zu erreichen. An was für einem ARM versuchst du es denn? Das steht bei mir auch noch auf der toDo liste mit einem AT91sam7. Aufgrund der geringeren Datenmenge bei einem 8 bit tiefen bild, wird das Bild schneller dargestellt.
Ja, 3,3V sieht schon besser aus. Du zeigst nur fest definierte Bilder an. Ich habe mich mit FAT nur rudimentär beschäftigt. Ginge nicht ein Findfirst... Findnext oder so ähnlich um alle auf der Karte zu findenden Files anzuzeigen. Wenn ein Fehler auftritt, keine neue Datei mehr da, dann wieder von vorn anfangen. Ansonsten muss ich bei jeder neuen Bilderserie neu compilieren.
@Lothar Lehmann: Sicher ginge das, war aber bei meiner Anwendung nicht gewollt. Ich möchte lediglich eine Lösung vorstellen, mit der sich ein paar Bilder darstellen lassen. So können gezielt vordefinierte Bilder geladen werden.
ja hab mein display auch an einen at91sam7s256. Denke mal jpeg ist im grunde kein problem damit. Man muss nur eine lib finden die sich gut für den arm eignet.
Hi, ich versuche grad verzweifelt ein BMP von einer MMC karte mit deinem code auf einem L2F50xxx auszugeben, die bib von Christian Kranz für das L2F50xxx funktioniert auch soweit, inzwischen hab ich es geschafft die initalisierungs routine in deinen code zu übertragen, mein problem ist wohl dass wenn ich das display deselecte um von der mmc zu lesen es wohl nicht mehr auf weitere commandos reagiert.... kann das sein ? Hat jemand was ähnliches schon gemacht ?
@ Andreas H.: prüf mal, ob du nicht ausversehen eine Leitung vertauscht hast (CS oder RS, oder so) Ich habe das LS020 am laufen, und keine probleme damit. Sollte also mit dem L2F auch laufen. Wenn möglich, schau mit dem Oszi ob die Signale am Display auch richtig anliegen. Gruß Gunni
Danke für die Antwort, ich habe das problem inzwischen gelöst das L2F50xxx mag es nicht wenn man während der "Pixelfüllung" am RS was ändert
1 | fat_read_file (Clustervar,Buffer,b); |
2 | CLR(LCD_CS); //select Display |
3 | CLR(LCD_RS); //clear RS line |
nach entfernem des "clear RS line" gings danke trozdem
@Gutmar H. Ich bin gerade dabei eine multi Grafik Bibliothek für AVR und ARM µC´s zu schreiben und wollte fragen, ob ich deinen Code verwenden darf. Ich dachte daran, das ich den gesamten Code später unter die GPL stelle. Ich fände das echt super, wenn du mir das erlauben würdest, und es würde warscheinlich auch vielen helfen. Viele Grüße
hallo Christian. Natürlich darfst du den Code verwenden. Der Code basiert größtenteils auf anderen Bibliotheken. Nur die Funktionen zur BMP darstellungen stammen von mir. viel Erfolg damit. halt mich mal auf dem Laufenden, was die ARM geschichte angeht.
Guntmar H. schrieb: > halt mich mal auf dem Laufenden, was die ARM geschichte angeht. Mach ich gerne. Viele Grüße
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.