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.
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
@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?
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