Hallo! Habe einen mega32 und GCC als Compiler. Jetzt habe ich folgendes Problem: Wenn ich die Datei im Anhang compiliere, gibt es keine Probleme. Auch beim simulieren mit AVR Studio wird der PortB ausgegeben. Nur wenn ich das Programm auf den Controller schiebe, sehe ich keine Reaktion am PortB. Wenn ich allerdings eine der 2 for-Schleifen auskommentiere, läuft das Programm auch auf dem Controller. Was kann das sein?
Das angehangene Programm gibt 0xAA am PORTB aus, die Funktionen rufst du garnicht auf.
Ja nur ein paar Zeilen weiter unten soll es ja 0b10101010 ausgeben. Das passiert nur leider nie. Zumindest nur in der Simulation, obwohl ich die Funktionen ja garnicht aufrufe.
Also 0cAA wird bei mir nicht ausgegeben. Der Port bleibt auf 0xFF. Wenn ich die beiden Funktionen auskommentiere, dann läuft es. Lasse ich sie drin, dann läuft es nicht, obwohl ich die Funktionen garniocht aufrufe.
1.) verschiebe beide Funktionen HINTER das main() vermutlich funktioniert das ganze dann auch mit den Funktionen. 2.) Dein Prozessor startet IMMER an einer bestimmten Stelle im Flash, dort sollte (normalerweise) ein Sprung zu main() sein in deinem Falle vermute ich das dein Programm ab dieser Stelle drinsteht (meist ab adresse 0) Da solltest du die Dokumenattion zum Prozessor lesen Gruss
Nope, das wird nichts bringen. Dominik, mit welchen Kommandos baust du denn diese Teile?
"void funktion1(); void funktion2();" welche funktion soll dieser unsinn am anfang haben, obwohl die schleifen schon vor der main stehen. nimm sie raus und dein programm läuft. so etwas macht man , wenn diese schleifen hinter der main stehen oder später eingebunden werden. mfg pebisoft
Das waren jetzt nur Beispielfunktionen. Machen absolut keinen Sinn. Aber ich versuch es mal sie hinter die main zu schreiben. Dachte nur, dass der Compiler so schlau ist und einen Sprungauf den Anfang der main einfügt. Besten Dank erstmal.
räusper Der startup Code sorgt dafür, daß Dein Prozessor ordentlich initialisiert wird und außerdem ein Sprung nach 'main' durchgeführt wird. >"void funktion1(); >void funktion2();" >welche funktion soll dieser unsinn am anfang haben Dieser "Unsinn" sind zwei Funktionsprototypen, die so aber nicht ganz korrekt sind (C99). void funktion1(void); void funktion2(void); Wären korrekte Funktionsprototypen. Dominik: vielleicht beantwortest Du ja mal Jörgs Frage!?
Hallo Leute, also mal im Ernst : Warum sollten Deklarationen vor main() den Programmablauf in irgendeiner Art und Weise beeinflussen ?! Das ist absoluter Unsinn. Deklarationen vor main() sind unabdingabr, wenn man die Funktionen in main() verwenden will. Wo man die Definition dann hinpinselt ist dem Compiler im Prinzip auch egal (vielleicht nicht gerade innerhalb anderer Funktionen, aber ansonsten kann man die Funktionsdefinitionen vor oder nach main oder in anderen Dateien vornehmen - das will dann aber der Linker wissen, sonst hat er ein Problem (äußert sich dann in "undefined symbol"-Fehlern beim Linken. Der Compiler hat weitherin mit dem Einsprung ins Programm eher wenig zu tun. Das ist auch Aufgabe des Linkers. Der Compiler hat nämlich keinen blassen Schimmer, wo die Funktion main() genau im Festspeicher des Mikrocontrollers liegt. Der Linker weiß das (schließlich legt er es ja fest). Deshalb erledigt solche Sachen der Linker. Und der bekommt vom Compiler die festzulegenden Symbole mitgeteilt. Also nicht die Pferde scheu machen und lieber auf Experten, wie Jörg Wunsch horchen, wenn's um den GCC geht. IMHO hier DIE Adresse für kompetente Antworten auf Fragen zu Interna beim GCC. Ansonsten hilft auch ein gutes Buch zum Thema weiter (ja ich konsultiere auch hin und wieder eines, wenn ich was vergessen habe). Schließlich ist der Compiler und Linker keine "magische Kiste", welche den Programmtext in einen Ablauf pressen, der dem Leser logisch vorkommt. Man muss eben deren Sprache sprechen, wenn man was von ihnen will ;-). MfG, Daniel.
Ich compiliere das ganze in der Eingabeaufforderung mit nem Makefile und dem Befehl make. Hoffe das trifft jetzt die Frage von Jörg?
Nein, mich interessiert die konkrete Kommandozeile, mit der avr-gcc aufgerufen wird (zum Compilieren und zum Linken, falls es zwei verschiedene sind). Insbesondere interessiert mich, ob beim Linken das korrekte -mmcu=atmega8 drinsteht.
Im makefile steht : # MCU name MCU = atmega32 Zum compilieren nehme ich einfach den Befehl "make" in der Eingabeaufforderung im Verzeichnis, in dem mein Makefile und die .c datei steht. Oder is da schon grundsätzlich was falsch? Weil das bei einfachen Programmen ohne andere Funktionsaufrufe bei mir funktioniert. Sorry wenn ich das net alles sofort verstehe, was gemeint is. Mir is jetzt aufgefallen, dass sobald ich mehrere Funktionen implementiere und dann versuche sie aufzurufen, der Compiler Probleme macht. Er bleibt dann vor oder in den Aufrufen stehen, auch wenn in der Funktion nur eine Variable deklariert wird, also keine Schleifen, in denen er hängenbleiben könnte.
Sorry. Nich der Compiler macht Probleme, sondern der Controller. Er bleibt dann vor doer in dem Aufruf hängen. Beim Compilieren werden keine Fehler angezeigt. Muss ich vielleicht den Stackpointer vorher noch initialisiren, oder ma acht gcc das automatisch? Hab jetzt auch schon mit dem Optimierungsgrad rumprobiert, aber das hat auch keinen Erfolg gebracht.
Wie machst du das, dass er diese Zeile compiliert? test = 0b10101010; Mein GCC kann das nicht.
Hi das ist ein Patch für den GCC von Jörg. Der bringt ihm binäre Konstanten bei. Leider wird der nicht in die offiziellen GCC sourcen aufgenommen. Wäre nett sowas generell über einen Kommandozeilenschalter einschalten zu können. Matthias
Nun ja, ich habe es nocht nicht wirklich ernsthaft probiert, ihn offiziell einzureichen. Zuerst muss ich ihn dafür mal auf den GCC 4.x portieren, laut Marek hat sich da bisschen was an der Dateistruktur geändert. Ich werde das mit mittlerer Priorität mal angehen, danach kann ich einen offiziellen Request for Enhancement einreichen damit. Es gibt eigentlich keinen Grund für einen Kommandozeilenschalter dafür, da ein Konstrukt wie 0b123 ohnehin nichts sein kann, was derzeit legitim in einem C-Programm gemäß Standard stehen könnte. Damit kann man diese Art Zahlen immer akzeptiere (im Rahmen der eingeschalteten GCC-extensions natürlich, d.h. wenn ich per Schalter Standardkonformität erzwinge, soll er es sehr wohl als Syntaxfehler ablehnen).
OK, ich hab's endlich mal getan: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479 Falls irgendwer einen Kommentar schreiben will...
Moment. Hab da aber keinen besonderen Patch oder sowas eingefügt. hab mir nur ne Version von Gcc irgendwo aus dem Netz gezogen, mit nem Link, den ich hier auf der Seite irgendwo gefunden habe. Merkwürdig, dass der Compiler dann bei mir net meckert. Dominik
Danke, der Patch tut bei 4.01 auch. Der gcc Bugzilla lässt mich nicht für den Bug voten, aber ich hab einen Kommentar geschrieben. Ein bisserl stur ist der Pinski schon, oder?
> Danke, der Patch tut bei 4.01 auch. Ja, zwischen 3.x und 4.x ist nur einiges umsortiert worden, daher musste ich den alten Patch anpassen. libcpp hat jetzt ein eigenes Toplevel-Verzeichnis. > Ein bisserl stur ist der Pinski schon, oder? Naja, im Prinzip hat er ja Recht, sie wollen mit Altlasten eher aufräumen. Ich finde es eben nur nicht sinnvoll, -not-so-pedantic oder so 'nen Kram einzuführen, sondern wenn schon, dann über alle derartigen GCC-Erweiterungen warnen (zumindest mit -Wall).
Kann ich nur zustimmen. BTW: indent müsste aber dann auch gepatcht werden, weil er aus 0b0001111 dann 0 b00001111 macht :-( LG, Fritz "der ohne imdent nicht leben kann" Ganter
> BTW: indent müsste aber dann auch gepatcht werden, weil er aus > 0b0001111 dann 0 b00001111 macht :-( Dafür fühle ich mich aber nicht mehr zuständig. ;-) Naja, ganz persönlich bin ich gar kein großer Freund von binären Konstanten, da in aller Regel symbolische Konstanten (1<<ADEN etc.) die bessere Variante sind, aber gerade Assembler-Umsteiger neigen offenbar zu Zahlenkonstanten.
@Jörg da stimme ich dir voll und ganz zu, aber es gibt fälle (zugegebenermassen sonderfälle), z.B. zeichensatzgeneratoren etc. bei denen es der übersichlichkeit+lesbarkeit+nachvollziehbarkeit dient wenn man mit binären konstanten arbeiten kann. Etwas out of topic: Was immer wieder negativ auffällt sind werte die sich aus formeln ableiten die der präprozessor/compiler berechnen kann, aber als zahlen im sourcecode autauchen. promimentestes beispiel hier sind die baudratenregister wo man immerwieder zB "UBRR=25;" statt "UBRRL=(F_CPU/16/BAUDRATE)-1;" findet. Dann kommen solche codeschnipsel hier ins forum mit der frage warum die verbindung zum PC nicht funktionert :-/ . darunter leidet die portabilität und löesbarkeit des codes. mit der formel muss man nur eine, maximal zwei "einfache" konstanten in einem header/im makefile ändern und das wars, der compiler macht den rest; im andern fall geht das manuelle rechnen von vorne los - vor allen dingen wenn man später nachsehen will welche baudrate den nun eingestellt ist. Das schlechte beispiel findet man übrigens auch hier im tutorial.
> da stimme ich dir voll und ganz zu, aber es gibt fälle > (zugegebenermassen sonderfälle), z.B. zeichensatzgeneratoren > etc. bei denen es der übersichlichkeit + lesbarkeit + > nachvollziehbarkeit dient wenn man mit binären konstanten arbeiten > kann. Es sieht ja auch so aus, als würde der Patch Akzeptanz finden, ich bin schon dabei, die geforderten Testcases noch nachzureichen. Ich halte es schon insgesamt für nicht verkeht, das mit an Board zu haben (auch wenn mein erster Patch sinerzeit eher eine ,,Machbarkeitsstudie'' war) und frage mich gerade, wie man sowas als offizielle Ergänzung zum C-Standard einsortiert bekommen könnte. Da es ja bereits einige Compilerhersteller gibt, die das mit dabei haben, vermute ich mal, dass es im Normungsgremium gar keinen zu großen Widerstand dagegeben gäbe.
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.