Atmega168A Prescaler ändern und neu flashen

[wedemännchen]

Hey Leute,

ich bin noch relativ neu bei den Microcontrollern. Nun habe ich ein Beispielprojekt aus einem Buch (make: AVR programming)
probieren wollen aber das führt zu Problemen. Vorweg, ich nutze einen Atmega168A und als Oberfläche nutze ich Atmel Studio 7, als Kommandozeilentool AVRdude, als
ISP Programmer einen chinesischen USBasp.
In dem Beispiel im Buch wird der Prescaler von den standartmäßigen 1 MHz auf die volle Power gesetzt (8 MHz).

Das passiert über

#include <avr/power.h>
clock_prescale_set(clock_div_1);

nun ist die einmalige Ausführung des Programms anscheinend kein Problem. Sobald ich jedoch etwas neues flashen will, ist es nicht mehr möglich und ich bekomme

avrdude.exe: Device signature = 0x000102
avrdude.exe: Expected signature for ATMEGA168 is 1E 94 06
Double check chip, or use -F to override this check

Dies passiert, sobald ich den Chip schneller als 1 MHz takte möchte. Wenn ich den Chip langsamer takten möchte, sprich einen clock_div > 8 nutze, ist ein weiteres flashen
des Chips anscheinend Glückssache. Mal klappt es und mal nicht.

Kann es sein, dass die CPU des Chips irgendwie mit dem ISP-Programmer oder so abgestimmt sein muss, damit man flashen kann? Und wie löse ich dieses Problem?

Vielen Dank schonmal,
Mike

[oberallgeier]

Hallo Mike,
willkommen im Forum.


.. Wenn ich den Chip langsamer takten möchte, sprich einen clock_div > 8 nutze ..Der Controller läuft nur mit CKDIV8 auf [Ein] oder [AUS], sprich Fuse CKDIV8 ist gesetzt oder gelöscht. Egal ob Du es programmtechnisch machst oder direkt über das Setzen der Fuses - anders geht es nicht mit dem CKDIV8. Du kannst aber verschiedene Prescaler am Chip setzen, die - z.B. für Timer - den Controllertakt für diese Chipsektion niedriger setzen.

Näheres siehe hier unter Fusebits (http://rn-wissen.de/wiki/index.php?title=Avr#Die_Fusebits) - aber besser fährst Du natürlich wenn Du Dir die Dokumentation zum m168 (http://www.atmel.com/Images/Atmel-42733-8-bit-AVR-Microcontroller-ATmega48A-88A-168A_datasheet.pdf) ansiehst - dort z.B. unter 13. System Clock and Clock Options. NUR als ERGÄNZUNG dazu kannst Du natürlich auch mal diesen ABschnitt durcharbeiten. (http://rn-wissen.de/wiki/index.php?title=Avr)

WENN Du den Chip schneller takten möchtest musst Du beim flashen darauf, dass der Takt beim Flashen (keine Ahnung wie das beim AVRdude gemacht wird) immer kleiner als 1/4 des Taktes ist, mit dem >aktuell< der Controller getaktet wird.

[wedemännchen]

Note that any value can be written to the CLKPS bits regardless of the CKDIV8 Fuse setting.

Das steht unter anderem im Datenblatt zum Clock Pescale Register. Ich hatte das nun so gedeutet, dass ich den Prescaler ändern kann, ohne die Fuse löschen zu müssen.
Demnach müsste der Code mit dem von mir verwendeten Macro zum prescalen soweit erstmal ausreichen oder nicht? Habe noch nicht ganz verstanden, wozu genau ich die Fuse brauche,
außer ich wollte den Prescaler permanent auf 8 MHz setzen.


WENN Du den Chip schneller takten möchtest musst Du beim flashen darauf, dass der Takt beim Flashen (keine Ahnung wie das beim AVRdude gemacht wird) immer kleiner als 1/4 des Taktes ist, mit dem >aktuell< der Controller getaktet wird.

Verstehe ich auch nicht so ganz. Meinst du, wenn ich den Chip langsamer getaktet habe als 1 MHz, dann muss ich beim nächsten flashen den "flashtakt" irgendwie runtersetzen? Das werde ich mal probieren,
könnte die Hälfte meiner Prescaler Probleme beheben, aber nicht erklären, woran es nach dem Setzen des Taktes auf 8 MHz hapert.

[oberallgeier]

Note that any value can be written to the CLKPS bits regardless of the CKDIV8 Fuse setting ..GENAU. Aber der prescaler beeinflusst NICHT den Controllertakt - der tickert im fabrikneuen Zustand mit 8 MHz >>aus dem internen Oszillator<< ABER (wieder fabrikneu) ist Fuse CKDIV8 gesetzt, sodass der resultierende CONTOLLERTAKT - egal ob interner Takt oder externer Oszillator/Quarz-oderwasauchimmer - durch acht dividiert wird, fabrikneu daher 1 MHz. Der Prescaler ..:
This can be used with all clock source options, and it will affect the clock
frequency of the CPU and all synchronous peripherals. clkI/O, clkADC, clkCPU, and clkFLASH are
divided by a factor ..

d.h. damit wird NICHT der Prozessortakt reduziert. Damit werden aber die entsprechenden Takteingänge von Timer, ADC etc an die gewünschten Gegebenheiten angepasst (keine Ahnung ob das jetzt verständlich ist - ich hatte seinerzeit ewig gebraucht das zu begreifen).


.. wenn ich den Chip langsamer getaktet habe als 1 MHz, dann muss ich beim nächsten flashen den "flashtakt" irgendwie runtersetzen? ..Genau. Bei 1 MHz (also fabrikneu - oder so eingestellt) muss der Flashtakt kleiner als 250 kHz sein.

Nachtrag:
Unwissen bringt Fehler. Leider kenne ich die Dokumentation zum mega168 (auch zum mega238 und m1284) nicht auswendig, nicht mal den Abschnitt "System Clock Prescaler" bei den von mir schon länger benutzten Typen :-/ . Darin verstehe ich seit eben wirklich so, dass damit offenbar wirklich der >>Prozessortakt<< direkt beeinflusst werden kann. Das wusste ich bisher nicht. Also ist es wohl möglich die von Dir gewünschte Prozessortaktung mit dem CLKPR zu beeinflussen. Das wurde von mir bisher nie benutzt, daher kann ich damit nicht umgehen. sorry.

[wedemännchen]

Habe nun mal auf clock_div_32 gestellt. Das war wohl ein Fehler. Kriege nun die Meldung


avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: error: program enable: target doesn't answer. 1
avrdude.exe: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.

Sobald ich versuche, über die Commandline mit -B250 die Taktrate des USBasp runterzusetzen, kommt


avrdude.exe: set SCK frequency to 4000 Hz
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: error: program enable: target doesn't answer. 1
avrdude.exe: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.

nichts mehr zu machen :confused:

[oberallgeier]

Habe nun mal auf clock_div_32 gestellt. Das war wohl ein Fehler. Kriege nun die Meldung .. nichts mehr zu machen ..Hast Du mal nachgerechnet? WENN Dein Controller (fabrikfrisch) mit 1 MHz tickt und Du den Prescaler auf clk/32 stellt, dann kommen nach Adam Riese 31,25 kHz raus. Mit meinem Flashgerätchen (https://www.pololu.com/product/1300) kann ich zwar bis runter zu 1.21 kHz "programmieren", wenn ich mich richtig erinnere, aber unter 5 kHz oder so nur Fuses umstellen. Flashen geht bei meinem Dingelchen, wenn ich mich richtig erinnere, erst so ab 50 kHz aufwärts. Leider kann ich Dir zu avrdude und Deinem chinesischen USBasp nix raten, da ich über das Protokoll STK500 flashe.


.. könnte .. nicht erklären, woran es nach dem Setzen des Taktes auf 8 MHz hapert.Nur mal so, als Sicherheitsabfrage, hast Du den Controller weiter auf dem internen Takt stehen? Bei Dir sollten die Fuses in diesem Fall z.B. auf /SUT_CKSEL auf Int. RC Osc. 8 MHz; Start-up time ../ oder so ähnlich stehen, also auf INT.ernem RC OSC.illator! Ganz sicher also NICHT auf z.B. /Ext. Crystal Osc. ../ oder ähnlich, da ich vermute, dass Du an Deinem Controller keinen externen Quarz angeschlossen hast (hab ich Recht?).


.. Atmega168A und als Oberfläche nutze ich Atmel Studio 7, ..Kannst Du denn damit irgendwie die Fuses in Deinem Controller auslesen?

[wedemännchen]

Wie sieht es denn aus, wenn ich den Macro "clock_prescale_set(clock_div_32)" nutze? ich hätte nun vermutet, dass der Prescaler nicht auf 1000000/32=31,25 kHz sondern auf
8000000/32=250 kHz gestellt wird, da ich ja auch mit dem dividenden=1 auf 8 MHz komme.

Was die Fuses angeht, ich habe noch nichts an denen rumgespielt, müsste also auf internen Oscillator stehen. CKDIV8 ist gesetzt. Und richtig, ich nutze keinen Quarz, eigentlich sollte zum üben
erstmal die interne clock reichen. Was das Auslesen angeht bin ich mir nicht ganz sicher wie das hier läuft.
http://www.atmel.com/webdoc/atmelstudio/atmelstudio.programmingdialog.fuses.html
Anscheinend kann man direkt fuses angeben, die dann sofort gesetzt werden. Soweit ich das sehe, sollte bei mir dahingehend auch alles im grünen sein.

Ich habe hierfür ja den Atmega168A genutzt. Habe jetzt mal den Atmega168-20PU bestellt. Den hatte ich schonmal genutzt, damals hatte ich keine Probleme mit dem Prescaler.
Habe nur seitdem auch die Software neu aufsetzen müssen. Also vllt liegt der Fehler irgendwo in der Software oder der 168A ist doch etwas anders in Hinsicht auf den Prescaler.