Druckbare Version
Wenn du einen 16MHz Quarz laut Datenblatt anschaltest passt es so.
Wenn dieser Mega32 dann läuft versorgst du deinen alten M32 mit Spannung und machst eine Verbindung von neu XTAL2 auf alt XTAL1.
Damit hast du einen ext. Takt auf deinem alten M32 und dann kannst du auch bei diesem die Fusebit umstellen, denn kaputt ist er sicher nicht.
So etwas kommt schon mal vor.Zitat:
Zitat von adso
Warum sollte auch ein persönlich bekannter Kollege schlechter sein als wir anonymen AVRholiker? Das ist garnicht spöttisch gemeint. Könnte mir auch so gehen.Zitat:
Zitat von adso
Dumm gelaufen.Zitat:
Zitat von adso
Zitat:
Zitat von oberallgeier am: 27 Nov 2008, 21:26
In diesem Fusebitrechnern steht das mit dem Invertieren etwa so drin. Leider ist das nicht WIRKLICH einfach verständlich dargestellt. Da fallen viele drauf rein.Zitat:
Zitat von McJenso am 01 Dez 2008, um 17:31
Ganz unten auf der RNControl-Seite steht der passende Link dazu.Zitat:
Zitat von adso
Na ja, für weitere Spielereien gibts ja nun den neuen Trick von Hubert.G - übrigens danke Hubert.G dafür, damit hatte ich erst kürzlich zwei Controller gerettet.Zitat:
Zitat von adso
der 16MHz quarz ist sicherlich richtig geschaltet -> RN-Control
Mit meinen wenigen Widerständen, Quartze, … zu Hause ist das so eine Sache mit dem neu Ansteuern. Nach Schaltplan müsste ich ca 10 Pins ansteuern (6, 7, 8, 9, 10, 11, somit 13, 30, 31, 32) ohne Wirkliche Ausstattung spende ich lieber 10 € für einen neuen Atmega. Der alte Atmega werfe ich sicherlich nicht fort und vielleicht ergibt sich einmal etwas.
Gibt es sonst keine Fehler in den Fusebits?
So, habe heute den ATmega bereits bekommen. Natürlich direkt ausgewechselt und versucht zu programmieren.
*grins* ich bekam immer den Fehler, dass Ponyprog den MIC nicht findet. *grins* ... bis ich gemerkt habe, dass das Netzteil nicht eingeschaltet war *grins* ](*,) ](*,)
Naja, jetzt funktionierts. Leider ist das mit den tiefen Tönen wieder da. Ich habe gleich ein Programm geschrieben, das mir über die RS232 Schnittstelle im Sekundentakt was ausgibt. Das klappt auch. (Jede Sekunde, nicht jede 2. Sekunde). Also Zeitlich funktioniert das Ganze. Für mich heisst das, dass auch die Taktfrequenz stimmen müsste.
Dann habe ich die Soundausgabe unter die Lupe genommen. Die Funktion ist ja sound(höhe, länge) und die Ausgabe sieht dann so aus: es ist eine Schleife, die einige Male durchlaufen wird, bis sie die Zahl der Länge erreicht hat. In der Schleife wird der Port aktiviert, x millisekunden gewartet, ausgeschalten und x millisekunden gewartet, bis die Schleife von neuem Startet (x=höhe). daraus ergibt sich eine Frequenz von f=1/(2*Höhe) [kHz]. Beim Beispiel wird u.A. auch Höhe=7 angenommen, was zu einer Frequenz von 71 Hz führt. Es muss also beim Beispielprogramm in C so tief sein. (Nach mir wird f=440Hz für Musikinstrumente zum Stimmen gebraucht, aber nur so als Vergleich.) ](*,) ](*,)Code:for (unsigned char i=0; i<50; i++){
sendUSART("Jetzt");
setportcoff(0);
waitms(150);
setportcon(0);
waitms(850);
}
undCode:sound(6, 270); //Startmelodie
sound(8, 270);
sound(11, 270);
sound(7, 270);
waitms(10);
sound(7, 270);
sound(6, 270);
sound(11, 540);
und ich dachte schon ...Code:void sound(uint8_t hoehe, uint16_t laenge)
{
for(uint16_t i=0; i<laenge*15; i=i+(2*hoehe))
{
setportdon(7);
_delay_ms(hoehe);
setportdoff(7);
_delay_ms(hoehe);
}
}
Hat jemand eine Funktion, bei der man also anstatt einer Maximalen Frequenz (höhe=1 -> Frequenz=500), eine Ausgabe mit sound (frequenz, länge in ms) hat?
Jetzt hab ich also den Fehler, es war nicht die Arbeitsfrequenz des Atmega, sondern ein Denkfehler, dass die Töne standartmässig höher sein müssten.
Gruss und Dank
Hmmm, und wie entsteht der Sekundentakt?Zitat:
Zitat von adso
Aha. Dem waitms traue ich nie. Aber der Test ist für diesen Zweck wohl einigermaßen ok. Wie sehen Deine Fuses aus? Sind die mit dem Vorschlag des fuse calculators abgestimmt?Zitat:
Zitat von adso
Ich habe mir vor Zeiten eine Routine geschrieben, die den Hardwaretimer des aktuellen µC´s benutzt und einen 50 µs-Takt erzeugt (Code für m168 ist hier gezeigt) . Da zähle ich in der ISR z.B. von 1 rauf auf 20 000 - das ist dann genau 1 sec. - - - und zwar nur dann, wenn der zugrundegelegte Takt auch stimmt. Übrigens flackert während meiner Hard+Softwareentwicklung fast immer eine LED (meist auf dem sowieso aufgebauten I2C-Stecker), die im Sekundentakt auf-und-ab-schaltet - solange Interrupt enabled ist. Die lasse ich auch nach dem Reset aber vor dem Erlauben der Interrupts kurz blitzen _ - und hier kommt eine meiner wenigen waitms-Anwendungen. Ein oder zwei Sekunden lang 3/97 waitmsse. Eine sehr praktische Einrichtung, um gelegentlich pannenweise auftretende Interrupts zu entdecken und der Sekundentakt zeigt mir sofort Taktprobleme.
Aber jetzt scheint ja bei Dir alles im Lot zu sein.
Ok, das mit dem Sekundentakt hab ich nochmals angeschaut -> ist wirklich dumm gemacht und hat eine sehr hohe Abweichung.
Das mit dem Calculator habe ich nochmals angeschaut.
In dem Fall kommt es mir so heraus:
[ ] OCDEN
[ ] JTAGEN
[ ] CKOPT
[ ] EESAVE
[X] BOOTSZ1
[X] BOOTSZ0
[ ] BOOTRST
[ ] BODLEVEL
[ ] BODEN
[ ] SUT1
[ ] SUT0
[ ] CKSEL3
[ ] CKSEL2
[ ] CKSEL1
[ ] CKSEL0
(Auswahl:
Ext. Clock, Start-up-time: 6CK +64ms, [CKSEL=0000 SUT=10]
Alle Kreuzlein deaktiviert (da ich offenbar davon nichts brauche,
BodLevel=1, Bootsz=01)
Ist vielleicht eine saudumme Frage, aber ich muss die Häckchen im Ponyprog genauso wie im Fuse Calculator setzten, also nicht invertiert? Und seid ihr mit der Auswahl zufrieden? Jetzt muss es fast einmal stimmen. =P~ Doch meine Frage: Wie erkennt der MIC ob es ein 16MHz oder ein 8MHz Quarz ist?
Gruss und Dank
Euer Adso
Hallo adso,
der waitms-(Sekunden-)Takt ist praktisch, aber eben von der Sorte "quick ´nd dirty".
Deine Fuses sind ja ganz ok - ich nehme an, Du hast da den Bootloader drin? Sonst würde der viele Bootloader-Speicherplatz nicht recht Sinn machen. Ich habe bei meinem selbst geflashten M32 diese Fuses. (Anm.: gerade ausgelesen - extra für Dich - mit PonyProg aus dem m32 in der RNControl mit meinem selbst geschriebenen/compilierten/geflashten Testprogramm).
Die Fuses im PonyProg setzt Du so wie im attachement gezeigt, wenn Du Deine Auswahl "drin" haben willst.
Tja, das ist die Frage. Soweit ich es weiß, erkennt der Quarz das garnicht *gggg* (ist nicht spöttisch gemeint - es ist eben so --- woher weiß Dein Auto, dass in der Stadt nur 50 gefahren werden darf?). Du sagst das dem µC im Quelltext, so nach der Art (hier für meinen m168 mit 20 MHz):Zitat:
... Doch meine Frage: Wie erkennt der MIC ob es ein 16MHz oder ein 8MHz Quarz ist? ...
Eine andere Möglichkeit, den Quarztakt zu definieren ist es auch, den Wert im makefile oder im Compiler reinzuschreiben (mit Beidem habe ich null Erfahrung - ich mache es immer so, wie es oben steht).Code:#define MCU = AVR_ATmega168
#define F_CPU 20000000 // Quarz 20 Mhz-CPU