Hallo, ich habe gerade versucht nach der Anleitung aus dem AVR-GCC-Tutorial/LCD-Ansteuerung ein HD44780 kompatibles Display mit einem Attiny24 zu betreiben, doch scheint der Speicher zu klein zusein.. Besteht überhaupt ein Chance es doch mit dem µCzum laufen zu bekommen? LG und schon im Vorraus "vielen Dank für die Antworten"
Eigentlich sollte ein Attiny24 locker ausreichen, ich selber nutze hier einen Attiny2313 um ein Display mittels I2C anzusteuern. Da der auch nur 2 kB Flash hat muss der Fehler bei dir woanders liegen.
Code? Schaltplan? Fehlerbeschreibung? Ohne das alles wird das nichts mit der Diagnose.
Hallo, mein Vorschlag ist, verwende eine ausgereifte Routine, z.B. diese Title : HD44780U LCD library Author: Peter Fleury <pfleury@gmx.ch> http://jump.to/fleury File: $Id: lcd.c,v 1.14.2.1 2006/01/29 12:16:41 peter Exp $ Dann kannst Du die Zeit für andere Dinge nutzen. Bei mir läuft diese mit allen LCD Anzeigen, die ich habe, problemlos.
Hallo, zu erst möchte ich mich für den LCD-Display Fehler entschuldigen, war nicht ganz durchdacht ;) @ Oliver J.: Codes und Schaltplan sind im Anbhang. Der Code in lcd-routines.h ist schon auf den von mir verwendeten IO-Port A abgeändert. Der Fehler ist, dass beim Übetragen auf den µC das Programm feststellt, dass zu wenig Speicher vorhanden ist und das Programm nicht übertragen werden kann.. Ich nutze zum Programmieren AVR Studio 5 und einen AVRISPmkII. LG
Hi
>Hier ist er.
Die unbenutzten Datenleitungen haben nichts an GND zu suchen. Der
Displaycontroller hat interne Pull-Up-Widerstände.
MfG Spess
Hallo, grade der intressante Teil lcd-routines.c ist leer. gruß, Bjoern
@ spess53: Danke für den Tipp, aber da das Programm sich noch immer nicht übertragen lässt, hilft es mir noch nicht.. LG
@spess53: Ich habe aber auch in irgendeinem Tutorial gelesen, dass man die unbenutzten Datenleitungen auf GND ziehen soll um das Einfangen von Störsignalen zu verhindern?
Hier hab ich es her: http://www.rn-wissen.de/index.php/LCD-Modul_am_AVR#4-Bit_Ansteuerung_mit_Busy.28I.2FO_Mode.29 Unterhalb des Bildes steht "Unbenutzte Pins des Datenports vom LCD sollten auf GND gelegt werden, da sie ansonsten auf keinen definierten Pegel liegen und Störsignale empfangen."
Helge schrieb: > Der Fehler ist, dass beim Übetragen auf den µC das Programm feststellt, > dass zu wenig Speicher vorhanden ist und das Programm nicht übertragen > werden kann.. So 'n bisschen LCD-Ansteuerung sollte eigentlich überall reinpassen. Deshalb mal ein Tipp ins Blaue: 'Optimierungseinstellung'
HI >Hier hab ich es her: >http://www.rn-wissen.de/index.php/LCD-Modul_am_AVR... >Unterhalb des Bildes steht >"Unbenutzte Pins des Datenports vom LCD sollten auf GND gelegt werden, >da sie ansonsten auf keinen definierten Pegel liegen und Störsignale >empfangen." Man soll nicht jeden Blödsinn glauben, der im Internet zu finden ist. Die Verbindung mit GND erzeugt einen erhöhten Stromverbrauch durch die internen Pull-Ups. Wenn wirklich Störungen auftreten sind externe Pull-Up-Widerstände die richtige Methode. In den meisten Fällen reicht es, die Anschlüsse offen zu lassen. MfG Spess
Der Fehler ist gefunden! Man kann beim AVR Studio für "Build" entweder "Debug", oder "Release" wählen. Das Debug-File ist erheblich größer und da lag dann auch der Fehler. Danke für die Infos und Tipps. LG Helge
Ah, ok, da hatte ich nicht dran gedacht. Beim Debug-Build bindet er noch (wie der Name schon sagt) sämtliche Debug-Symbole ein die beim Debugging hilfreich sein könnten. Allerdings bläht das den Code in aller Regel um ein Mehrfaches auf. Habe hier aktuell auch ein Projekt (nicht auf AVR sondern OMAP3) das mit Debug-Symbolen fast 6 MB groß ist und ohne auf knapp 600 KB schrumpft ^^
Daniel H. schrieb: > Beim Debug-Build bindet er noch > (wie der Name schon sagt) sämtliche Debug-Symbole ein die beim Debugging > hilfreich sein könnten. Nö, das wäre Quatsch, die in den Chip zu laden, der kann damit garnichts anfangen. Dem Debugger reicht völlig, wenn er Zugriff auf die Objekt-Files hat, da steht ja alles drin. Beim Debug-Build wird einfach nur die Optimierung abgeschaltet, da der Debugger sich schwer tut, Registervariablen zu dereferenzieren. Beim AVR hat das zur Folge, daß alles auf 16Bit expandiert wird und jede Variable im SRAM abgelegt werden muß. Auch Umsortierungen unterbleiben (der GCC optimiert zwanghaft auf spätest mögliche Ausführung, egal, was es kostet). Man kann dann zwar debuggen, bloß hat das dann keinerlei Ähnlichkeit mit dem Release-Build, ist also voll für die Katz. Peter
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.