Atmega 32 mit 16 mhz quarz zu schnell ?

[bluePumpkin]

Hallo liebe comunitie


Folgendes Problem hat sich mir beim programmieren eines Atmega 32 in den Weg gestellt:

Den Instruktionen des Beitrags "robotikeinstieg leicht gemacht" folgend, habe ich die Schaltung aufgebaut (ausser des rs 232). Diese funktionierte auch prima. (in diesem Sinne danke für diesen grossartigen Einstiegsartikel).

Als ich aber die Fuse bits (Ponyprog) einstellte, musste ich festsellen, dass die blinkfrequenz des LED's doppelt so schnell ist wie sie sollte.
als Taktgeber habe ich einen 16 mhz quarz mit 2* 22 pf kondensatoren verwendet, wie die schaltung dies auch vorsieht.
Den Code habe ich in C geschrieben und das Brennen mit Ponyprog ausgeführt.
zudem habe ich einfach 2 mal delay(5000) programmiert (LED ein/aus). Das ganze dauerte dann aber nur 5 s wo es meiner Meinung nach doch 10 dauern sollte.

Dadurch stimmt natürlich auch die Servo programmierung nicht mehr, welche ich ebenfalls nur copy paste aus dem Servo beitrag zu Testzwecken eingefügt habe.

Ach ja die fuses sind:
CKSEL 3..0 : 1111
SUT 1..0 : 01
BOD : 0
Und die Inversität des Ponyprog habe ich beachtet!

Die Frage:
Liege ich einfach falsch und der Takt stimmt doch und wenn ja, wie kann ich das ohne oszilloskop überprüfen?
wenn nein, woran kann das liegen?

vielen dank im voraus für die Antwort

[Thomas$]

schick mal code weil du bei delay ja im programm ja die taktrate mal angeben musst
doppelt so schnell wie 16mhz glaub ich nicht so gut lassen die dinger sich nicht übertakten (wäre aber schön )
ich vermute das die taktrate im programm mit 8mhz mal flasch angegeben wurde

[bluePumpkin]

Danke für die Antwort hier ist der code dazu ... wie gesagt nur so zum mal testen, ich bin mich erst am einarbeiten
:)



// Testprogramm: Blinken und servo
//
#ifndef MCU // Welcher AVR genutzt wird, wird i.A. im Makefile definiert
#define MCU atmega32
#endif

#ifndef F_CPU // kann auch im Makefile definiert sein
#define F_CPU 16000000UL // Takt als LONG definieren, da zu groß für Integer
#endif

#include <avr/io.h> // Namen der IO Register
#include <util/delay.h> // Funktionen zum warten
// Achtung, damit delay richtig funktioniert muß mit Optimierung compiliert werden

int main(void)
{
DDRC = _BV(0); // Nur PC0 als output, _BV(0) = (1<<0) = 1
PORTC = 254; // Pullups auf allen anderen Pins
DDRA = 0xff; // (3)
PORTA = 0x08; // (4)

while (1)
{
PORTC &= 255-_BV(0); // 0 auf Bit 0 Ausgeben, Rest so lassen
_delay_ms(1000); // 100 ms Warten
PORTC |= _BV(0); // 1 auf Bit 0 Ausgeben, Rest so lassen
_delay_ms(1000);
}
}


Edit:

Also ... das ist jetzt nur der Code für die LED's, wobei auch hier meiner meinung nach für 1 Zyklus 2 s gebraucht werden sollten. In meiner Schaltung hat dieser Zyklus ( LED an/aus) aber nur 1 Sekunde.

Was mir jetzt erst auffällt ist, dass da noch steht, dass mit optimierung Compiliert werden soll .... was damit genau gemeint ist, weiss ich zwar nicht, könnte aber vielleicht einen Einfluss haben?
wobei doppelte Taktrate dann schon etwas extrem wäre.
wie gesagt ich habe das auch noch mit delay(5000) ausprobier, wobei das resultat dann einfach 2.5 s war.

[uwegw]

Ist F_CPU vielleicht schon im makefile definiert?

[bluePumpkin]

Vorerst mal vielen Dank für die Antwort.

Nun zum Problem :
Das war tatsächlich der Fall, dass im Makefile F_CPU mit 8 mhz definiert war.
Allerdings blieb das Problem bestehen, als ich F_CPU im Makefile mit 16 mhz definierte und auch als ich die Definition ganz aus dem Makefile löschte.

gibt es noch andere Möglichkeiten den cpu takt zu überprüfen?

ich hätte diese uc sehr gerne richtig am laufen bevor ich noch weitere Experimente anstelle

[bluePumpkin]

Ich glaube, ich habe jetzt den Fehler gefunden. _Delay_ms() ist in meiner avr_libc fehlerhaft. Ich habe das Blinken nun mit einem Timer abgehandelt und so stimmt die Blinkfrequenz nun.

Ich habe auch einen BugFix als "reinen code" für das Problem gefunden. leider weiss ich aber nicht wie ich diesen in avr_libc einbinden könnte. Falls jemand weiss, wie das geht, wäre ich sehr erfreut, wenn er mir das erklären könnte