Hallo bin blutiger Anfänger, Als Board benutze ich ein Eval. Board von Pollin. Nun habe ich ein kleines Testprg. geschrieben für einen Atmega8. Eine LED soll jeweils 0.5Sekunden an sein, danach wechselt es zur andern LED. Nun beträgt die Delay Zeit aber ca. 3Sekunden. woran kann das liegen? Beim Makefile habe ich Otimierung stufe 3 eingestellt. Danke #define KEY_ONE PD5 #define KEY_TWO PD6 #define ONE_ON PORTD |= (1 << PD5); #define ONE_OFF PORTD &=~(1 << PD5); #define TWO_ON PORTD |= (1 << PD6); #define TWO_OFF PORTD &=~(1 << PD6); #include <avr/io.h> #include <util/delay.h> int main() { // Port Ausgänge DDRD = (1 << KEY_ONE) | (1 << KEY_TWO); while(1) { TWO_ON; _delay_ms(500); //500ms warten... TWO_OFF; ONE_ON; _delay_ms(500); //500ms warten... ONE_OFF; } }
Oder Fuses nicht/falsch gesetzt, oder F_CPU falsch definiert, oder -O3 macht Mist - meines Wissens stimmen die _delay-Dinger nur bei-Os. Letzteres weiß ich jetzt aber nicht, ohne nachzusehen.
Am Anfang hatte ich die F_CPU nur im Makefile, nun aber auch im main.c, ohne Änderung. Werde mal Fuses oder Opt S versuchen. Danke Pascal
Pascal schrieb: > Am Anfang hatte ich die F_CPU nur im Makefile, nun aber auch im main.c, > ohne Änderung. > Werde mal Fuses oder Opt S versuchen. Du kannst dein F_CPU haben wo immer du willst. Solange die dort gemachte Angabe nicht mit der Taktfrequenz übereinstimmt, mit der der µC tatsächlich läuft, wird _delay_ms nicht stimmen. F_CPU ust eine Information für den Compiler. Aber der µC läuft deswegen nicht schneller oder langsamer sondern immer noch mit der am µC eingestellten (entweder interner Takt oder Quarz oder ...) Taktfrequenz
Guck Dir auch mal die Beschreibung von _delay_ms.
1 | The maximal possible delay is 262.14 ms / F_CPU in MHz. |
500ms gehen also nur mit um die 500kHz Takt.
Florian Micro schrieb: > Guck Dir auch mal die Beschreibung von _delay_ms. Da steht in halbwegs aktuellen Versionen (seit min. 1 Jahr) auch folgendes: When the user request delay which exceed the maximum possible one, _delay_ms() provides a decreased resolution functionality. In this mode _delay_ms() will work with a resolution of 1/10 ms, providing delays up to 6.5535 seconds (independent from CPU frequency). The user will not be informed about decreased resolution.
schöner ist da sowieso soetwas (und genauer auch da delay fktn nur eine bergrenzte zeit hat): #define ui16 unsigned short void ms_delay(ui16 millisekunden) { for(; millisekunden > 0; millisekunden--) { _delay_ms(1); } } das ist auf die dauer genauer. aber ich kenne dein problem, nutze dezeit einen attiny2313, fcpu ist gesetzt, fuses sind auf externen quarz gestellt (8mhz) und die funktion läuft ca 1000 mal schneller als sie soll (also rein von der optischen "analyse") mit dem oszi werde ich mal alles messen sobald ich eines habe um der sache auf den grund zu gehen...
Micha S. schrieb: > das ist auf die dauer genauer. Nimm _delay_ms. Das implementiert auch nur diese For-Schleife. (Ok, als "while" mit 10-Fach höherer Auflösung, whatever) Und wenns genau werden soll, muss eh der Timer ran. Typedefs/defines wie "ui16" sind übrigens seit über 10 Jahren "out". Schau dir mal den "stdint.h"-Header an, den jeder C-Compiler, der nicht im letzten Jahrtausend stehen geblieben ist, mitliefert. Micha S. schrieb: > läuft ca 1000 mal schneller als sie soll Hört sich nach wegoptimierter Schleife an...
>Typedefs/defines wie "ui16" sind übrigens seit über 10 Jahren "out".
Müsste das nicht eh "umgekehrt" sein? (typedef unsigned short ui16)
out? sorry aber das ist mir ziemlich egal was in und was out ist... ist gewöhnungssache, beim arbeiten schaffen wir so daheim auch, sag ja nicht das es jemand übenehmen muss :) wegoptimierte schleife? hm ja wäre möglich, muss ich mal probieren (opt level ist 0s), muss ich mal probieren... wenn die _delay_ms() mit 1000 aber auch so schnell läuft dann wirds wohl woanders liegen. die delay funktioen sind eh nur für "anfänger" da sie während der verz den prozessor blockieren, also nicht grad das gelbe vom ei... aber wems so reicht warum nicht? wenn ich nur ne led blinken lassen würde würd ich die ebenfalls benutzen!
Mitleser schrieb: >>Typedefs/defines wie "ui16" sind übrigens seit über 10 Jahren "out". > Müsste das nicht eh "umgekehrt" sein? (typedef unsigned short ui16) bei typedef ja bei #define nein!
Micha S. schrieb: > Mitleser schrieb: >>>Typedefs/defines wie "ui16" sind übrigens seit über 10 Jahren "out". >> Müsste das nicht eh "umgekehrt" sein? (typedef unsigned short ui16) > > bei typedef ja bei #define nein! Arghh, verguckt. Bei #define ist das natürlich richtig.
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.