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.
Hallo Da kommt garantiert vorher eine Fehlermeldung, das lcd_ini() fehlt. Gruß JJ
Beim compilieren kommt keine Fehlermeldung. Wie kann ich die lcd_ini() implementieren?
gib uns mehr infos. Schaltplan, 4 bit betrieb oder 8 bit die pins die am avr verwendet werden. kannst du die komplette software angeben usw
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
Hey Markus dein Make sah aber einen ATMEGE16 mit 16MHz vor!!! wo kommt jetzt der atmeg48 und die 8MHz her????
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
ich komme nicht mehr mit! :-( Der 48er hat kein JTAG, nur zur INFO. WIE sieht dein Projekt jetzt aus? Bitte Komplett.
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?
.. schrieb: > schnell mal Zwischenruf das HEX-File wird ja erstellt! Es ist nur das Warning was Markus jetzt beunruhigt hat.
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.
schreibs halt richtig als
1 | int main( void ) |
2 | {
|
3 | ....
|
In dem Fall ist die Warnung ok und leicht zu beheben. Sie hat allerdings in diesem Fall auch keine Auswirkungen auf die Funktionsfähigkeit.
:
Bearbeitet durch User
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 | void lcd_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?
:
Bearbeitet durch User
Karl H. schrieb: > In deinem Header File gibt es noch eine Funktion namens >
1 | > void lcd_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.
Ganz ehrlich. Schmeiss den Code weg und hol dir die Fleury Lib. Wenn ich sowas schon sehe
1 | void lcd_write (uint8_t data, uint8_t rs) |
2 | {
|
3 | uint8_t dataBits ; |
4 | |
5 | if (rs) // write data (RS=1, RW=0) |
6 | dataBits=0x10; // RS liegt an Pin 4 = B 0001 0000 = H 10 |
7 | else // write instruction (RS=0, RW=0) |
8 | dataBits=0; |
9 | |
10 | PORTC = dataBits | (data>>4); // output high nibble first, zzgl. Zustand für RS-Leitung |
11 | lcd_flash_e (); |
geht mir die Galle hoch. Wer so programmiert, sollte nicht veröffentlichen.
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.
Karl H. schrieb: > Ganz ehrlich. > Schmeiss den Code weg und hol dir die Fleury Lib. Wo bekomme ich die her?
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"
:
Bearbeitet durch User
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
Wie sieht eigentlich die Schaltung aus. Am Mega48 ist der Port C ja der ADC Port. Ist AVcc angeschlossen?
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 !"
sorry dumme frage, war ja der Include. Hatte es nicht gesehen. Steht leider nicht da warum, oder?
Und was spricht "avr-gcc -v"? Bei reichlich altem Gerät ist die Antwort auf Fragen gern mal: nimm was zeitgemäßes.
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)
Karl H. schrieb: > Hier eine Version, die ich seit vielen Jahren verwende. in lcd.h die Konfiguration der Pins nicht vergessen.
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!
Ok, vielen herzlichen Dank. Ich werde heute Abend den Code von Karl Heinz ausprobieren. :-)
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.
:
Bearbeitet durch User
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.