Hallo, ich mache gerade meine ersten Erprobungen mit dem ATMEGA128 und dem AVR. Ich wollte einfach mal eine LED ein paar Sekunden ein und ein paar sekunden aus schalten. Man sagte mir das ich es am simpelsten zum ausprobieren mit einem "for" Befehl machen kann. ---> gesagt, getan Das ganze ohne Fehler compiliert. Nur was mich stutzig macht, ist dass ich folgende Meldung bekomme: Program: 222 bytes (0.2% Full) (.text + .data + .bootloader) Data: 0 bytes (0.0% Full) (.data + .bss + .noinit) Nachdem ich das Programm mal auf den Controller gespielt habe, funktionierte es natürlich nicht. Dann habe ich mal in der *.lss Datei geschaut, und dort wurde der C-Code auch nicht compiliert. Woran kann das liegen?? Muss unter "Data" nicht auch ein paar bytes angezeigt werden?? Gruß Kay
CODE POSTEN!!! WIE SOLL MAN SONST WAS DAZU SAGEN??? Data sind Deine Variablen. Das Programm tun Compiler/Linker in das Segment "Text". WIE ÄUSSERT SICH DEIN FEHLER??? GEHT NICHT GEHT NICHT. DAS IST KEINE BESCHREIBUNG.
Ich wär mal dafür, dass im Forum eine Software eingebaut wird, die Beiträge mit entsprechender Beschreibung und ohne Code nicht akzeptiert...
Oder vielleicht Tags. Verschiedene Kategorien. Eine Kategorie z.B. ("Anfängerfrage" | "Schülerhausaufgabe" | "Stundentenhausaufgabe" | ...). Vielleicht sogar auch eine freie Tageingabe. Dann könnte man noch irgendwo eine Tagcloud anzeigen, um Sachen zu finden. Man könnte auch Moderatorentags einführen, die von den Moderatoren vergeben werden und in einer eigenen Tagcloud und/oder neben der Beitragsliste auf der Homepage angezeigt werden. Mich würde auch mal interessieren, woher die Leute kommen. Vielleicht sind es nur zwei oder drei Lehrer in ganz DE, die ihre Arbeit nicht richtig machen und immer wieder die Schüler hierherschicken; und das, ohne ihnen die Benutzung des Forums richtig zu erklären.
>Muss unter "Data" nicht auch ein paar bytes >angezeigt werden?? Nein. Data zeigt den Speicherverbrauch der globalen und statischen Variablen. Wenn dein Programm davon keine enthält, ist data eben Null. >Dann habe ich mal in der *.lss Datei geschaut, und dort wurde der C-Code >auch nicht compiliert. Wenn Compiler und linker fehlerfrei durchlaufen, ist das nicht möglich. Das Problem dürfte insgesamt darin liegen, daß dein Programm und/oder die Hardware nicht fehlerfrei sind (was beim allerersten mal auch gar nicht schlimm ist). Daher, wie schon geschrieben, alles zeigen. Oliver
So, dies habe ich als Code geschrieben. #include <avr/io.h> int main (void) { int lauf=0; PORTC=0x20; DDRC |= _BV(DDC5); while(1) { PORTC=0x20; for(lauf=0;lauf<1000;lauf++); PORTC=0x00; for(lauf=0;lauf<1000;lauf++); } }
Kay --- schrieb: > So, dies habe ich als Code geschrieben. > ... Naja, fast. Für eine Warteschleife ist for(...) nicht günstig, da der Compiler erkennt, dass da gar nichts passiert und das Ding wegoptimiert. Besser ist, die Datei <util/delay.h> per #include einzubauen und dann _delay_ms(xy) zu verwenden. xy ist dabei eine Konstante, die die Wartezeit in Millisekunden angibt. Beispielsweise _delay_ms(1000); für eine Sekunde. Wenn du das dann kompilierst und in den Controller flashst, sollte es auch funktionieren. Funktionstüchtige Hardware mal vorausgesetzt. EDIT: Die Wartefunktionen aus <util/delay.h> funktionieren aber nur richtig, wenn sie mit Optimierung (Compiler-Option -O1, -O2, -O3 oder -Os) übersetzt werden. Ausserdem benötigen sie das Makro F_CPU. Letzteres kannst du im gcc-Plugin von WinAVR in den Eigenschaften einstellen. Ansonsten halt Compileroption -DF_CPU=1000000 für 1MHz.
Das bedeutet dann also, dass Dein Port doch geblinkt hat. Allerdings sehr schnell. Mit einem Oszilloskop hätte man ein Rechtecksignal gesehen. Mit einem Analogmultimeter die halbe Versorgungsspannung. Mit einer LED-Prüfspitze halbe Helligkeit im Vergleich zu VCC.
for zum Warten geht aber auch, wenn die Zählvariable volatile ist. Trotzdem ist delay besser, da man hier genau sagen kann, wie lang man warten will. Wobei so wie das Programm ist (wegoptimiertes for), müsste die LED zumindest leicht glimmen; ist ja im Prinzip ne PWM mit 50:50.
Das Programm sollte, wie bereits gesagt, sich zumindest an der LED bemerkbar machen. Deine Aussage, dass im *.lls File nichts drinnen ist, ist nicht ganz koscher. Das deutet auf irgendein Problem hin. Was auch sein könnte: Das beim Flashen irgendetwas schief gelaufen ist. Wieviele LEDS hast du zur Verfügung und kannst du die auch an einem anderen Port anhängen?
hmm, kannst du das mit dem f_cpu etwas näher erläutern? Wo muss ich das einstellen??
1 | #define F_CPU 1000000 // 1 Mhz
|
2 | |
3 | #include <avr/io.h> |
4 | #include <util/delay.h> |
5 | |
6 | int main (void) |
7 | {
|
8 | PORTC = 0x20; |
9 | DDRC = 0x20; |
10 | |
11 | while(1) |
12 | {
|
13 | PORTC = 0x20; |
14 | _delay_ms( 1000 ); |
15 | PORTC = 0x00; |
16 | _delay_ms( 1000 ); |
17 | }
|
18 | }
|
Für die 1000000 setzt du dein tatsächliche Taktfrequenz in Hertz ein.
@Karl heinz: Wobei dabei noch anzumerken wäre, dass diese Definition dann am Anfang jeder Datei stehen muss, die Funktionen aus der <util/delay.h> verwendet. Daher halte ich es für sinnvoller, das Makefile, bzw. die Projektoptionen entsprechend anzupassen, damit der Compiler das Makro immer mitbekommt. @Kay: Sag' doch mal, auf welcher Plattform (Windows, Linux, Mac) und mit welcher Toolchain (WinAVR mit AVR-Studio, sonstige IDE, Kommandozeile) du dein Programm erstellst und kompilierst.
Philipp Burch schrieb: > @Karl heinz: > > Wobei dabei noch anzumerken wäre, dass diese Definition dann am Anfang > jeder Datei stehen muss, die Funktionen aus der <util/delay.h> > verwendet. Daher halte ich es für sinnvoller, das Makefile, bzw. die > Projektoptionen entsprechend anzupassen, damit der Compiler das Makro > immer mitbekommt. Schon klar. Ich hielt es nur in diesem Fall für einfacher einen kompletten Code zu haben, der nicht von irgendwelchen Einstellungen (ausser der Optimierung) in der Entwicklungsumgebung abhängt. Wenn die Optimierung nicht richtig eingestellt ist, ist es auch nicht weiter schlimm, stimmen die Zeiten nicht, aber blinken sollte es trotzdem. Erst mal alle möglichen Fehlerquellen ausschliessen. > @Kay: > > Sag' doch mal, auf welcher Plattform (Windows, Linux, Mac) und mit > welcher Toolchain (WinAVR mit AVR-Studio, sonstige IDE, Kommandozeile) > du dein Programm erstellst und kompilierst. Ja, da würd ich mal ansetzen. Worauf ich auch die ganze Zeit hinwill: Mal am PORTB 8 Led rann, und dann statisch das Muster 0xAA draufgeben. Dann müsste abwechselnd eine LED leuchten und eine nicht leuchten, egal wie die LED angeschlossen sind. Je simpler das Testprogramm, umso besser.
Danke Karl Heinz!!! Das hat funktioniert, auch wenn ich nicht weiss wieso. Mit dem Befehl F_CPU, kann ich damit dem Controller eine geschwindigkeit vorgeben obwohl ein 16MHz-Quarz eingebaut ist? Oder was macht dieser Befehl?
> @Kay: > > Sag' doch mal, auf welcher Plattform (Windows, Linux, Mac) und mit > welcher Toolchain (WinAVR mit AVR-Studio, sonstige IDE, Kommandozeile) > du dein Programm erstellst und kompilierst. Also, ich mache das ganze mit Windows XP und AVR-Studio Das mit den LED ist kein Problem, ich habe mir ein Steckboard gekauft. da kann ich rumspielen wie ich will. Als Controller nutze ich den ATmega 128 von Alvidi.de mit dem passenden USB-ISP Programmer
Kay --- schrieb: > Mit dem Befehl F_CPU, kann ich damit dem Controller eine geschwindigkeit > vorgeben obwohl ein 16MHz-Quarz eingebaut ist? Nein. Du teilst damit dem C-Code mit, auf welcher Geschwindigkeit dein Prozessor tatsächlich arbeitet. Das ist also einfach nur eine Information an den Code. > Oder was macht dieser > Befehl? Er definiert das Makro F_CPU In den _delay_xx Funktionen wird dieses Makro benutzt um daraus zu errechnen, wie oft eine Warteschleife durchlaufen muss um die gewünschte Zeit zu erhalten. Diese Anzahl ist klarerweise davon abhängig, wielange gewartet werden soll und wie schnell ein Durchlauf durch die Warteschleife abgearbeitet wird. Wie lang gewartet werden soll, teilst du hier _delay_ms( 1000 ); mit. Und wie schnell dein Prozessor ist, legtst du mit #define F_CPU xxxxxxxxx fest. Anstatt das hier im Code zu machen, gibt es auch noch die Möglichkeit im AVR-Studio in den Projekt Einstellungen eine entsprechende Angabe zu machen. Aber im Grunde läuft auch das auf genau das gleiche hinaus. Für Details zu 'Makro' empfehle ich ein C-Buch. Das wirst du sowieso brauchen, also am besten sofort besorgen.
kann ich diesen befehl auch dafür nutzen, um eine Weiterschaltung zu realisieren?? Im klartext. ich möchte das der Controller auf gewisse Signale wartet, z.B. auf das schalten von Reedkontackten. Dann soll er ein Magnetventil ansteuern, dieses wiederum gibt mir Luft für einen Stellzylinder frei. Nun muss ich WARTEN bis der Stellzylinder eine Klappe bewegt hat. Wenn er damit Fertig ist, wird es wieder Über Reedkontackte dem Controoller gemeldet und er kann den nächsten Schritt durchführen. Quasi eine ablaufsteuerung.
Sowas habe ich vor einiger Zeit mal zusammengeschustert. Musste Schnell gehen, also nicht auf die Beschreibungen achten. Die Timerfunktion hat einen Bug. Die musst du wohl mal überdenken. Das Programm ist eine Ablaufsteuerung. Es wartet das ein "Schlitten" einen Endanschlag berührt. Danach wird ein Kontakt "High", damit wird ein Magnetventil ausgelöst. Ein Druckluftzylinder fährt runter, wenn er unten ist (wird mit einen Reedkontakt gemerkt) wartet das Programm die Haltezeit und schaltet dann das Magnetvetil wieder ab. Ich vermute das Programm ist für einen Anfänger etwas undurchsichtig. zum Lernen von C empfehle ich http://openbook.galileocomputing.de/c_von_a_bis_z/ Wenn es dir gefällt kauf das Buch. Die Autoren und der Verlag wollen ja bezahlt werden.
Andreas W. schrieb: > zum Lernen von C empfehle ich > http://openbook.galileocomputing.de/c_von_a_bis_z/ Danke für den Tip.
Du weißt, das Buch ist nur zum reinlesen. Wenn es dir gefällt, kaufe es. in gedruckter Form ließt es sich auch besser. hast du mal in mein Programm geschaut? passt es mit den was du machen möchtest? Es ist aber für ein ATMega88 geschrieben mit interner Taktfrequenz. Die genaue Zeit war mir nicht so wichtig.Ob nun 1ms oder 2ms ist in den Geschwindigkeiten der Mechanik egal.
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.