Hi Community, bin "relativ neu" in der µC Entwicklung mit AVR. Ich wollte ganz einfach eine led blinken lassen, wie im tutorial beschrieben. Ich hab jetzt ehrlich bestimmt 50 Varianten durch. Doch immer das selbe resultat: LED leuchtet permanent. Ich hab auch die max. delay time berücksichtigt. Bitte um hilfe, ich vermute das der Quelltext soweit richtig ist und vielleicht nur meine winavr Einstellung falsch ?!?! Als Warning gibt er komischerweise nur manchmal aus : warning "Compiler optimizations disabled; functions from <util/delay.h> won't work as designed" Atmega8515L Mein Quelltext: #include "avr/io.h" #ifndef F_CPU #define F_CPU 1000000UL #endif #include "util/delay.h" int main(void) { uint8_t i=0; DDRA = 0b00000001; PORTA= 0b00000001; while(1) { PORTA ^= (1 << PA0); for(i=0;i<100;i++) { _delay_ms(10); } } return 0; }
Du musst im Makefile oder im AVRStudio das Optimierungslevel einstellen. Es ist defaultmäßig -O0, also keine Optimierung. Sinnvoll ist es meist, -Os einzustellen (Codegrößenoptimierung). Ohne Optimierung funktionieren die _delay-Funktionen nicht.
Hi, danke für die schnelle Antwort. Hab ich jetzt eingestellt. Hat aber immer noch nicht die Wirkung gebracht. Ich hab da meine Frequenz eingestellt 1000000 Hz und das Model Atmega8515. Hab das Stk500 und wenn ich den µC progge setze ich auf intern 1 MHz (default) Ist das vielleicht doppelt gemoppelt wegen dem Quelltext #ifndef F_CPU #define F_CPU 1000000UL #endif Danke groetjes Henni
Henni wrote: > Ist das vielleicht doppelt gemoppelt wegen dem Quelltext > > #ifndef F_CPU > #define F_CPU 1000000UL > #endif Ja und? Dafür ist schließlich das #ifndef...#endif da. Die Angabe im Code greift nur dann, wenn im Makefile nichts angegeben ist.
Habe einen STK500 aus dem Schrank genommen (da steckt ein ATmega8515
von Haus aus drin), deinen Code compiliert, geflasht -- geht. Mir
kommt es so vor, als würde er zu schnell blinken, hab's aber auch
nicht nachgemessen oder andwerweitig analysiert.
> warning "Compiler optimizations disabled; functions from <util/delay.h> won't
work as designed"
Ja, wenn du _delay_ms() nehmen willst, solltest du die Optimierung
einschalten, sonst wird alles viel zu langsam gehen.
Hier das Hexfile, ist ja ziemlich klein.
1 | :1000000010C029C028C027C026C025C024C023C0D6 |
2 | :1000100022C021C020C01FC01EC01DC01CC01BC0EC |
3 | :100020001AC011241FBECFE5D2E0DEBFCDBF10E065 |
4 | :10003000A0E6B0E0EAE7F0E002C005900D92A0363D |
5 | :10004000B107D9F710E0A0E6B0E001C01D92A036DC |
6 | :10005000B107E1F701C0D4CF81E08ABB8BBB31E0AF |
7 | :10006000E4ECF9E08BB383278BBB20E0CF01019751 |
8 | :0A007000F1F72F5F2436D1F7F5CF2A |
9 | :00000001FF |
Der disassemblierte Code sieht eigentlich OK aus:
1 | 00000058 <main>: |
2 | 58: 81 e0 ldi r24, 0x01 ; 1 |
3 | 5a: 8a bb out 0x1a, r24 ; 26 |
4 | 5c: 8b bb out 0x1b, r24 ; 27 |
5 | 5e: 31 e0 ldi r19, 0x01 ; 1 |
6 | 60: e4 ec ldi r30, 0xC4 ; 196 |
7 | 62: f9 e0 ldi r31, 0x09 ; 9 |
8 | 64: 8b b3 in r24, 0x1b ; 27 |
9 | 66: 83 27 eor r24, r19 |
10 | 68: 8b bb out 0x1b, r24 ; 27 |
11 | 6a: 20 e0 ldi r18, 0x00 ; 0 |
12 | 6c: cf 01 movw r24, r30 |
13 | 6e: 01 97 sbiw r24, 0x01 ; 1 |
14 | 70: f1 f7 brne .-4 ; 0x6e <main+0x16> |
15 | 72: 2f 5f subi r18, 0xFF ; 255 |
16 | 74: 24 36 cpi r18, 0x64 ; 100 |
17 | 76: d1 f7 brne .-12 ; 0x6c <main+0x14> |
18 | 78: f5 cf rjmp .-22 ; 0x64 <main+0xc> |
In Adresse 0x60/0x62 wird rr30 mit 0x9c4 = 2500 geladen. Das ist dann der Schleifenzähler für die innere Schleife (0x6e/0x70), die wird also 4 * 2500 = 10000 Mal durchlaufen. Darum gewickelt ist die x100 äußere Schleife. Wenn das Teil also schneller blinkt, müssen die Fuses irgendwie anders stehen...
Hmmm ja, dann ist ein fragezeichen weniger bei mir. Das Problem ist immer noch das selbe das die LED konstant 5 V bekommt. Alle anderen ports sind low, auch nachgemessen. Wo liegt mein Fehle, bzw. mögliche Fehlerquellen??? Danke groetjes Henni
Hi Jörg das ist ja richtig nett von dir das du so einen aufwand machst, danke. Mein Problem ist aber das meine LED augenscheinlich immer an ist und auch immer 5V am ausgang hat. Also muss ich die Fuses überprüfen??? Henni
Kannst du das Programm aus dem µC zurücklesen? Vermutung: Beim Brennen des Programms in den µC ist was schief gelaufen. Probier mal einen anderen Pin als PA0. Geht PA0 dann auf 0V und der von dir gewählte auf 5V?
den Atmega auslesen geht, datei im Anhang. Ich versuch ma nen anderen PIN, müsste eigentlich aber egal sein. Also auf 0 Volt geht bei mir nichts. Kann aber auch sein das mein Multimeter zu träge ist und das nicht so schnell mitbekommt. Aber die LED ist augenscheinlich immer an und ich will ja ca. ne Sekunde pause haben. groetjes Henni
Henni wrote: > den Atmega auslesen geht, datei im Anhang. > Ich versuch ma nen anderen PIN, müsste eigentlich aber egal sein. > > Also auf 0 Volt geht bei mir nichts. Kann aber auch sein das mein > Multimeter zu träge ist und das nicht so schnell mitbekommt. Aber die > LED ist augenscheinlich immer an und ich will ja ca. ne Sekunde pause > haben. Wenn du die Vermutung hast, dass die LED in Wirklichkeit ganz schnell blinkt, kannst du das leicht abtesten. Schalte einfach daneben eine LED auf Dauer-EIN. Eine blinkende LED ist deutlich dunkler.
Mein Hexfile ist auch deutlich anders als das von Jörg Wunsch. Ich versuch das mit der zweiten led mal. Henni
Henni wrote: > Ich versuch ma nen anderen PIN, müsste eigentlich aber egal sein. Das ist richtig. Aber eigentlich muesste dein Programm auch funktionieren :-) Alles schon dagewesen: Das erste Programm schaltet lediglich die LED ein. Reingebrannt, geht. LED leuchtet Das nächste Programm entsteht aus dem ersten, indem die LED zum Blinken gebracht wird. Nur aus irgendeinem Grund schafft es das Programm nicht bis in den µC (Compilerfehler, Brennfehler, was weiss ich). Auf jeden Fall führt der µC immer noch Programm 1 aus, während der Programmierer denkt das Programm 2 läuft. Der genervte Programmierer steht dann mit einem µC da, der partout nicht blinkt, obwohl das Programm das eigentlich vorschreibt. Wie gesagt: Alles schon mal dagewesen.
Sorry ich habs, danke an alle ! Ich bin davon ausgegangen wenn ich das compiliere und built mache, anschließend eine übertragung zum stk500 veranlasse, das er auch das file nimmt. Aber es ist so das ich das INput HEX-File Verzeichnis seperat/manuell wechseln muss, lol. man o man . Da stand noch mein altes projektverzeichnis drinne. Danke für die mühen, trotzdem hätte ich es ohne euch nicht geschafft. So wußte ich das es nämlich nicht am code lag. Danke und weiterhin viel spass groetjes Henni
Vielen Dank, an alle, die Henni geholfen haben. Ich bin als Anfänger soeben exakt in die gleiche Falle gelaufen. Sehr gute Unterstützung. TL
...Der disassemblierte Code sieht eigentlich OK aus:..... mit welchem disassembler hast du den sourcecode erstellt?
roboter wrote:
> mit welchem disassembler hast du den sourcecode erstellt?
avr-objdump -d
wie kann ich die ausgabe festhalten? das fenster verschwindet gleich wieder. und gibt es ein help-aufruf für dieses programm? mfg
Standard-Ausgabeumlenkung: > dateiname Es gibt eine ausführliche Hilfe dafür im "info"-Format. Ich nehme an, du hast das als Teil von WinAVR, da müsstest du irgendwo eine Möglichkeit haben, "tkinfo" aufzurufen. objdump ist Teil von den binutils. Ich kenne mich aber mit Windows und WinAVR nicht aus.
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.