Hallo, ich bin neuerdings Linux-Nutzer und möchte in Zukunft Code::Blocks zum Programmieren von AVRs verwenden. Ich glaube, das aufgeblähte Atmel Studio werde ich nicht sehr vermissen. Zum Flashen benutze ich AVR8-Burn-o-mat in Kombination mit AvrDude. Ich verwende LIBC in Version 1.8.0. Hat eine Weile gedauert, bis ich alles installiert hatte, aber jetzt läuft es. Als ersten Test habe ein kleines Blinkprogramm erstellt. Es sollte mittels _delay_ms eine LED mit 1Hz blinken. Leider tut es das nicht. Sobald die eingestellte Zeit ca. 67ms überschreitet, bleibt es bei 67ms. D.h. _delay_ms(50) macht eine Wartezeit von 50ms, _delay_ms(60) macht eine Wartezeit von 60ms, _delay_ms(70) und mehr macht eine Wartezeit von 67ms. Es wird der interne RC-Oszillator mit Teiler 8 verwendet. Ich habe das extra nochmal mittels "Takt nach draußen" (CLKO-Pin) kontrolliert. Der Controller läuft mit 1Mhz. Dies ist auch so als FCPU definiert. Wenn ich absichtlich FCPU auf 2MHz stelle, ist die Wartezeit verdoppelt. Es funktioniert also alles wie es soll. Außer eben diese doofe Begrenzung bei 67ms. Hat jemand eine Idee, was ich noch untersuchen könnte? Ich dachte, solche Anfängerprobleme wie zu schnelle Warteschleifen habe seit Jahren ich hinter mir... Denkste. ;-) Danke Third-Eye
Gast
#3699343
http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html The maximal possible delay is 262.14 ms / F_CPU in MHz. Kaskadieren, wenn Du es brauchst. Oder einen anderen Timer nehmen.
...oder in der Doku auch noch die nächsten Sätze lesen. Oliver
Gast
#3699425
Als Tipp, via Timer ISR:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
Den Satz "The maximal possible delay is 262.14 ms / F_CPU in MHz." habe ich gelesen. Es steht aber weiter auch: "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)." Und so kenne ich die Funktion bisher auch. Ich mache immer gern ein Power-On-Delay mit _delay_ms(1000) am Anfang der Mainschleife. Meine 67ms wären ca. 1/4 von 262ms. Ergibt aber irgendwie auch keinen Sinn. Danke für den Tipp mit dem Timer. Aber ich verwende die Delays wirklich nur für das eben Genannte und derartige primitive Sachen. Ich wollte nur verstehen, warum es nicht funktioniert, wie gedacht. Ich komme immer noch nicht drauf... Ich habe gelesen, dass es einen Bug in der LIBC in Version 1.7 gab, aber ich verwende, wie erwähnt, 1.8.
Third Eye schrieb: > Ich habe gelesen, dass es einen Bug in der LIBC in Version 1.7 gab, aber > ich verwende, wie erwähnt, 1.8. Bist du sicher, dass nicht doch noch irgendwo im Suchpfad eine 1.7er Version liegt? der 1.7.0er Bug würde das "1/4 von 262ms" erklären. Beitrag "Re: _delay_ms() läuft 4 Mal schneller als erwartet"
Wenn ich nachschaue, welche delay.h Codeblocks verwenden will, ist die auf jeden Fall aus dem Verzeichnis mit der 1.8. Ich kann aber nicht ausschließen, dass evtl. irgendwo noch 1.7 rumvagabundiert. Danke. Das muss ich mal untersuchen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.