Hi Leute,
ich habe folgendes Problem:
ich habe mir das Buch "AVR - Hardware und Programmierung in C" zugelegt
und bin dabei das Beispielprogramm LCD 20 x 4 auszuprobieren.
Ich compiliere beide C-File (LCD.c & LCD_Tool) und Flash es mit dem
Notepad auf den µC (Atmega48). Aber am LCD kommt kein Text, was
normalerweise sollte.
Jetzt hab ich den µC ans Oszi gehängt und bemerkt das da gar keine
Signale an den Ausgängen rauskommen.
Wie compiliere ich zwei C-Files in ein hex-file?
Oder was könnte sonst das Problem seiIm Makefile hatte ich den richtigen
µC angegeben und auch den Takt.
hier mal eine gefunden Datei 'lcd_tools.c"
http://www.mikrocontroller.net/attachment/49485/lcd_tools.c
wenn deine so ähnlich ist solltest du die Anschlüsse überprüfen.
In dem File ist auch schon rumgeschmiert worden, die Doku passt nicht zu
den genutzten Pins!!!!
Stephan schrieb:> Schaltplan, 4 bit betrieb oder 8 bit> die pins die am avr verwendet werden.> kannst du die komplette software angeben
Ist im 4bit Betrieb.
Pins sind:
D4-7 -> PC0-3
E -> PC5
RS -> PC4
Den ganzen Ordner mit dem Code kann man sich bei Elektor runterladen,
ist dann das LCD 20 x 4 Programm. http://www.elektor.de/avr-buch
Stephan schrieb:> hier mal eine gefunden Datei 'lcd_tools.c">> http://www.mikrocontroller.net/attachment/49485/lcd_tools.c>> wenn deine so ähnlich ist solltest du die Anschlüsse überprüfen.> In dem File ist auch schon rumgeschmiert worden, die Doku passt nicht zu> den genutzten Pins!!!!
Ok, hab mal verglichen, wie es scheint ist dein lcd_tool-File auf PORT D
gelegt und für ein 2 Zeiliges Display?
Ich werde dieses File mal mit einem 2 Zeiligen Display ausprobieren.
Stephan schrieb:> ist das JTAG aktive?> PC2 - PC5 ist von diesem belegt!!!!
Shit, das könnte es sein..
Ich probiere das direkt heute Abend aus, ändere die Ausgänge auf einen
anderen PORT.
Vielen Dank schon mal! :-)
JTAG war es wohl doch nicht.
Beim Compilieren kam diese Warnung:
Compiling: lcd.c
avr-gcc -c -mmcu=atmega48 -I. -gdwarf-2 -DF_CPU=8000000UL -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=lcd.lst -std=gnu99 -MD -MP -MF
.dep/lcd.o.d lcd.c -o lcd.o
lcd.c:17: warning: function declaration isn't a prototype
Stephan schrieb:> Hey Markus dein Make sah aber einen ATMEGE16 mit 16MHz vor!!!> wo kommt jetzt der atmeg48 und die 8MHz her????
Das ist das original makefile, hab das auf meinen controller geändert.
Beim Compilieren kommt nun:
lcd.c:17: warning: function declaration isn't a prototype
Das wäre genau diese Zeile im lcd.c bei der geschweiften Klammer:
int main()
{
lcd_ini();
Ich verstehe nicht weshalb der Compiler da rummotzt. Der Programmaufbau
ist doch inordnung.
So jetzt nochmal genau die die ich auf meinem Controller verwende. Sorry
was ist hiermit:
-Wstrict-prototypes (C and Objective-C only)
Warn if a function is declared or defined without specifying the
argument types. (An old-style function definition is permitted without a
warning if preceded by a declaration that specifies the argument types.)
Markus schrieb:> Beim Compilieren kommt nun:> lcd.c:17: warning: function declaration isn't a prototype>> Das wäre genau diese Zeile im lcd.c bei der geschweiften Klammer:> int main()> {> lcd_ini();
hier ist main als Warning gemeint!!!
Markus schrieb:> Beim Compilieren kommt nun:> lcd.c:17: warning: function declaration isn't a prototype>> Das wäre genau diese Zeile im lcd.c bei der geschweiften Klammer:> int main()> {> lcd_ini();
schnell mal zwischenruf - hab aber nicht alles gelesen!
hast du die lcd.h dabei?
lcd.o auch mit beim linken?
Was ist an dem "main auszusetzen? Ich versteh das nicht.
Also ich komme jetzt nur wegen dieser Warnung nicht weiter.
Das der Atmega48 kein JTAG hat hab ich dann auch festgestellt (Ups..)
durch das "strict-prototypes"
sagst du: das du gerne eine Warnung hättest, wenn es einen
Funktion-Prototyp oder Funktion gibt, die keine Argumente spezifiziert.
Karl H. schrieb:> Sie hat allerdings in diesem Fall auch keine Auswirkungen auf die> Funktionsfähigkeit.
Aber was könnte das noch sein? Ich habe das Display mit nem MSP430G2
laufen lassen und es hat einwandfrei funktioniert. Daran kann es nicht
liegen.
Aber der Code für den Atmega ist als Beispiel-Code zum downloaden und
bei andern LEuten geht der so anscheinend.
Hmm..
In deinem Header File gibt es noch eine Funktion namens
1
voidlcd_port_ini(void);
Nur so ins Blaue geraten: Ich könnte mir vorstellen, dass man die vor
lcd_init() aufrufen muss, damit sie die Portpins auf Ausgang stellt.
Was sagt denn die Doku zu dieser Hypothese?
Karl H. schrieb:> In deinem Header File gibt es noch eine Funktion namens>
1
>voidlcd_port_ini(void);
2
>
>> Nur so ins Blaue geraten: Ich könnte mir vorstellen, dass man die vor> lcd_init() aufrufen muss, damit sie die Portpins auf Ausgang stellt.>> Was sagt denn die Doku zu dieser Hypothese?
Die Dokumentation sagt, dass die "lcd_port_ini()" von der "lcd_ini()"
aufgerufen wird.
Bernd schrieb:> Die Dokumentation sagt, dass die "lcd_port_ini()" von der "lcd_ini()"> aufgerufen wird.
Die "lcd_port_ini()" wird in der "lcd_ini()" aufgerufen.
Markus schrieb:> Karl H. schrieb:>> Ganz ehrlich.>> Schmeiss den Code weg und hol dir die Fleury Lib.>> Wo bekomme ich die her?
Google
"Fleury AVR LCD Lib download"
Markus schrieb:> Jetzt hab ich den µC ans Oszi gehängt und bemerkt das da gar keine> Signale an den Ausgängen rauskommen.
Aber dein Tiny arbeitet grundsätzlich?
Karl H. schrieb:> Markus schrieb:>>> Jetzt hab ich den µC ans Oszi gehängt und bemerkt das da gar keine>> Signale an den Ausgängen rauskommen.>> Aber dein Tiny arbeitet grundsätzlich?
Tschuldigung. Natürlich der Mega48
Karl H. schrieb:> Wie sieht eigentlich die Schaltung aus.> Am Mega48 ist der Port C ja der ADC Port.> Ist AVcc angeschlossen?
Ich habe den µC auf dem Pollin-Board.
Habe die andere Lib ausprobiert (danke für den Tip), aber da wird
rumgemotzt ich hätte eine zu alte Version vom AVR-GCC
In file included from test_lcd.c:14:
lcd.h:49:2: error: #error "This library requires AVR-GCC 4.5 or later,
update to newer AVR-GCC compiler !"
Huch.
Offenbar hat Peter den Code mal etwas überarbeitet.
Hier eine Version, die ich seit vielen Jahren verwende.
Auch wenn ich überzeugt bin, dass der neuere Code auch mit so ziemlich
jedem halbwegs neuerem avr-gcc compilieren wird.
(Was hast du denn für einen gcc? Ich bin jetzt sicher nicht derjenige,
der dauernd neue Versionen installiert. Aber selbst bei meinem hier
schlecht gewartetem Atmel Studio hab ich eine gcc Version 4.8 und Fleury
verlangt mindestens 4.5, deiner muss also noch älter sein)
Stephan schrieb:> sorry dumme frage, war ja der Include.> Hatte es nicht gesehen.>> Steht leider nicht da warum, oder?
Weil Peter explizit die Versionsnummer des Compilers prüft und mit einem
Fehler abbrechen lässt.
Wobei ich codemässig auf die Schnelle nichts erkennen kann, was einen
neuereren Compiler erfordert.
Karl H. schrieb:> Karl H. schrieb:>>> Hier eine Version, die ich seit vielen Jahren verwende.>> in lcd.h die Konfiguration der Pins nicht vergessen.
Und noch einen.
Der Fleury Code will die RW Leitung angeschlossen haben.
Karl H. schrieb:> Wobei ich codemässig auf die Schnelle nichts erkennen kann, was einen> neuereren Compiler erfordert.
das meinte ich. wenn es nur seine Umgebung(der eingesetzter Compiler)
war und kein spezial gcc Befehl von Nöten ist, könnte man den Passus
streichen. Aber dafür kenne ich den Code nicht gut genug!
Karl H. schrieb:> Huch.> Offenbar hat Peter den Code mal etwas überarbeitet.
Hi, also irgendwie will dieser Code auch nicht funktionieren. Der
Compiler bringt ein error wegen der f_cpu.
Mit welchem Compiler arbeitet ihr?
Markus schrieb:> Karl H. schrieb:>> Huch.>> Offenbar hat Peter den Code mal etwas überarbeitet.>> Hi, also irgendwie will dieser Code auch nicht funktionieren. Der> Compiler bringt ein error wegen der f_cpu.
Dann definier ihm ein F_CPU
Das wundert mich ein wenig. Denn eigentlich braucht man praktisch immer
eine Definition für F_CPU, welches die Taktfrequenz darstellt, mit der
der Prozessor läuft.
Eingestellt wird die meistens in den Projekteigenschaften bzw. im
makefile. Man kann ein
1
#define F_CPU 1000000UL // für 1Mhz Taktfrequenz
auch in den Source Code reinmachen, aber eigentlich ist das keine gute
Lösung. Denn dann muss ich als Programmierer sicher stellen, dass gerade
bei mehreren C-Files alle F_CPU Definitionen übereinstimmen. Sonst
gibt es Chaos. Daher ist eine entsprechende Einstellung mittels einer
Compiler Option im makefile (oder in den Projektoptionen bei den
diversen IDEs) die bei weitem bessere Lösung.
> Mit welchem Compiler arbeitet ihr?
Das hat nichts mehr mit dem Compiler zu tun.
Jeder der sein erstes AVR-'Hello World' eine mittels _delay_ms
gesteuerte blinkende LED programmiert, hat das F_CPU bereits schon
mindestens einmal gesehen.
