• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

Detected Micro does not match the selected Micro ATtiny13

T

testosteron

Geocacher
Hallo!

Bin grade ziemlich genickt und hoffe ihr könnt mir helfen:

Ich wollte den LED-only analog blinker nachbauen, und mit dem "RL mit Teachin der Blinksequenz-dyn Schwelle - LEDonly Version mit AD-Wandlung - für ATtiny13V" (Version 1.12 03.11.2010) bespielen.

Ich habe das Programm geladen, die Option "Optimize code" aktiviert und dann den Attiny mit der HEX und der EPP Datei bespeilt.
Hat auch geklappt.
Danach habe ich die FUSE bits genau so eingestellt wie auf der Seite (http://reaktivlicht.pbworks.com/w/page/32119730/RL%20mit%20Teachin%20der%20Blinksequenz-dyn%20Schwelle%20-%20LEDonly%20Version%20mit%20AD-Wandlung%20-%20für%20ATtiny13V) zu sehen ist.

Angeschlossen an die Schaltung: LED leuchtet dauerhaft.
Versucht ein anderes Programm auf den Attny zu flashen: Erhalte die Fehlermeldung aus dem Betreff.

Naja, da ich dachte dass ich irgendwas falsch gemacht habe, alles noch mal: Selber fehler beim nächsten Attiny...
So langsam gehen mir die Attinys aus.

Wie bekomme ich sie ins Leben zurück?

Gruß

testoseron
 
S

stonewood

Geowizard
testosteron schrieb:
Ich habe das Programm geladen, die Option "Optimize code" aktiviert und dann den Attiny mit der HEX und der EPP Datei bespeilt.
Hat auch geklappt.
Danach habe ich die FUSE bits genau so eingestellt wie auf der Seite (http://reaktivlicht.pbworks.com/w/page/32119730/RL%20mit%20Teachin%20der%20Blinksequenz-dyn%20Schwelle%20-%20LEDonly%20Version%20mit%20AD-Wandlung%20-%20für%20ATtiny13V) zu sehen ist.

Angeschlossen an die Schaltung: LED leuchtet dauerhaft.
Versucht ein anderes Programm auf den Attny zu flashen: Erhalte die Fehlermeldung aus dem Betreff.
Zum Vergrößern anklicken....
Welchen Programmer verwendest Du? Wenn es der parallelport-Adapter ist: Wie steht $crystal? (bzw. wie steht das unter Programmer -> chip features)?

Der Parallelport-Programmer stellt anhand von $crystal die Geschwindigkeit beim Programmieren runter, damit der Tiny noch antworten kann. $crystal ändern, neu kompilieren und schon programmiert er langsamer/schneller.

Kannst Du die Fuses noch auslesen?
 
cum-d

cum-d

Geocacher
hm... muss man die Fusebits nicht VOR dem Senden des Codes einstellen?

Bin auch erst recht frisch auf dem Gebiet, aber ich mache das immer so und hatte bisher noch nie Probleme bei den Attiny-Schaltungen (außer dem dämlichen Fehler, die LED verkehrt herum eingebaut zu haben :motz: ). Ich habe den Eigenbau-Parallal-Port-Adapter.
 
Kappler

Kappler

Geowizard
Das es immer wieder zu Problemen wegens des "Runterfusens" der Taktfrequenz gibt:
Hat schon mal jemand in der Praxis ausprobiert, ob das überhaupt nötig ist?

In der "Laborpraxis" gab es ja schon Versuche mit dem Ergebnis, dass ein Tiny in Werkseinstellung einen geringeren Stromverbrauch hat als ein mit extrem langsamem Takt betriebener, sofern alle Wartezeiten über Watchdog-Zyklen abgedeckt werden.
Meine entsprechend eingestellten Reaktivlichter hängen erst ein gutes Jahr im Wald, aber tun mit 2 AAAA-Zellen (aus 9V-Block) noch gut ihren Dienst.

Falls sich das bestätigt wäre es bestimmt eine sinnvolle Sache, das Kochbuch und die Wiki-Seiten dahingehend zu ändern, dass die ganze Runterfuserei rausfällt. Damit dürfte bestimmt die Hälfte der "Hilfe, mein Tiny..." Threads hinfällig werden und man könnte sich auf die wirklich wichtigen Probleme konzentrieren.
 
S

stonewood

Geowizard
Kappler schrieb:
Das es immer wieder zu Problemen wegens des "Runterfusens" der Taktfrequenz gibt:
Hat schon mal jemand in der Praxis ausprobiert, ob das überhaupt nötig ist?
Zum Vergrößern anklicken....
thomas_st hatte das doch glaub ich mal nachgemessen. Bisher hab ich das aber nicht übernommen und fuse noch fleißig runter.

Stichhaltigste Begründung dafür: Der A/D wandler braucht ja eine gewisse Anzahl Zyklen um seine Werte zu erzeugen. Die dauern mit 128 Khz schlicht länger als z.b. bei 1 Mhz. Und in der Zeit schläft der Tiny dann nicht.
 
OP
T

testosteron

Geocacher
stonewood schrieb:
Programmer verwendest Du?
Zum Vergrößern anklicken....
Ich verwende den mySmartUSB light von myAVR.

stonewood schrieb:
Kannst Du die Fuses noch auslesen?
Zum Vergrößern anklicken....
Nein, gar nichts mehr. Habe es schon in allen möglichen Programmen versucht.

Kappler schrieb:
Das es immer wieder zu Problemen wegens des "Runterfusens" der Taktfrequenz gibt:
Hat schon mal jemand in der Praxis ausprobiert, ob das überhaupt nötig ist?
Zum Vergrößern anklicken....
Auch ich habe es versucht:
Erst das Programm drauf und getestet was passiert: LED leuchtet dauerhaft. Danach dann die Fuse Bits so gesetzt wie es eigentlich soll.

Hoffe ihr könnt mir weiterhelfen.

Grüße!
 
T

*Trinity*

Geocacher
Hallo...

Hatte die gleiche Fehlermeldung.
Mein Brenner ist ein USBASP

Was immer gern übersehen wird:
Lt. Datasheet darf die Brenngeschwindigkeit max 1/4 des Taktes betragen !!!

Soll heissen: Wenn ich den ATTiny auf 128kHz "runterfuse", darf die Brenngschwindigkeit max 32kHz betragen.

Hab das ganze dann in Bascom auf 32Khz geändert, seither gibt es keine Probleme mehr ;-)

Dirk
 
OP
T

testosteron

Geocacher
Hallo!

Danke für eure Mühe!
Pin 1 habe ich, zumindest nicht wissentlich auf RSTDISBL gefused
Die SCK Frequenz steht bei 7200Hz. Müsste doch eigentlich auch passen.

Ich verstehe mittlerweile nur noch Bahnhof, zumal ich mit dem ATTiny 2313 nie solche Probleme hatte.

Gruß!
 
T

thomas_st

Geowizard
Kappler schrieb:
Das es immer wieder zu Problemen wegens des "Runterfusens" der Taktfrequenz gibt:
Hat schon mal jemand in der Praxis ausprobiert, ob das überhaupt nötig ist?
Zum Vergrößern anklicken....
Wie stonewood schon ganz richtig schrieb, habe ich/wir (ich war nicht alleine) das mal mit einem normalen (1) Reaktivlicht nachgemessen - dabei gab es kaum Abweichungen des Stromverbrauchs von der Taktfrequenz; sogar ein kleines (!!) Minimum bei ~ 1MHz, was den Werkseinstellungen entspricht.
Ich gebe mich aber keiner Illusion hin: solange im K o c h buch (2) noch die 128kHz beschrieben werden, wird es dabei für die Mehrheit bleiben.

Viele Grüße,
Thomas(_st)
________________
(1) normal heißt: Zwischen den Messzyklen wird das RL in den Schlafmodus versetzt.
(2) das "Kochbuch" nervt
 
OP
T

testosteron

Geocacher
Hallo!
thomas_st schrieb:
Wie stonewood schon ganz richtig schrieb, habe ich/wir (ich war nicht alleine) das mal mit einem normalen (1) Reaktivlicht nachgemessen - dabei gab es kaum Abweichungen des Stromverbrauchs von der Taktfrequenz; sogar ein kleines (!!) Minimum bei ~ 1MHz, was den Werkseinstellungen entspricht.
Ich gebe mich aber keiner Illusion hin: solange im K o c h buch (2) noch die 128kHz beschrieben werden, wird es dabei für die Mehrheit bleiben.
Zum Vergrößern anklicken....

Soll ich also einfach den Code drauf schreiben und keine FUSE Einstellungen vor nehmen?

Grüße!
 
Kappler

Kappler

Geowizard
testosteron schrieb:
...Soll ich also einfach den Code drauf schreiben und keine FUSE Einstellungen vor nehmen?...
Zum Vergrößern anklicken....
Genau - Voraussetzung ist allerdings, dass du eine Codeversion verwendest die keinerlei

- wait
- waitms
- waitus

Befehle verwendet. Sonst steigt der Stromverbrauch wieder drastisch an.

thomas_st schrieb:
...Ich gebe mich aber keiner Illusion hin: solange im K o c h buch (2) noch die 128kHz beschrieben werden, wird es dabei für die Mehrheit bleiben.
Zum Vergrößern anklicken....
Wer ist denn für Änderungen im K o c h buch verantwortlich? Sollte man denjenigen nicht mal auf diese Erkenntnisse aufmerksam machen?

PS: Jetzt weiß ich auch, was du mit Backbuch meinst... :D
 
OP
T

testosteron

Geocacher
Hallo!

OK, danke für Deine Antwort. Dann werde ich mal diesen Code: http://reaktivlicht.pbworks.com/w/page/3714542/Reaktivlicht%20mit%20Teachin%20der%20Blinksequenz%20-%20LEDonly%20Version%20mit%20AD-Wandlung%20-%20für%20ATtiny13V verwenden, und NUR die Option "Optimize code" Code verwenden.

Kappler schrieb:
Wer ist denn für Änderungen im K o c h buch verantwortlich? Sollte man denjenigen nicht mal auf diese Erkenntnisse aufmerksam machen?
Zum Vergrößern anklicken....
Ja, bitte! Ich finde das ganze hier soooo sehr verwirrend. Ich musste bei "Reaktives Licht mit Atmel AVR" bis Seite 149 lesen um feststellen zu dürfen das die Version die davor beschrieben wurde veraltet ist, und der Hinweis aus dem ersten Post mit dem Backbuch überholt ist.
Auch die beiden Backbücher sind ja wohl überholt. Die Schaltungen darin sind ja nicht mehr aktuell.

Grüße!
 
Kappler

Kappler

Geowizard
Du solltest nur auch daran denken, die Taktfrequenz im Code richtig anzugeben:

statt: $crystal = 128000
jetzt: $crystal = 1200000

verwenden.
Sonst gibt es Probleme mit dem AD-Wandler und eventuell auch mit den EEPROM-Routinen.

Edit: Taktfrequenz von 1MHz auf 1,2MHz geändert - Tiny13 ist halt doch speziell...
 
OP
T

testosteron

Geocacher
Kappler schrieb:
Du solltest nur auch daran denken, die Taktfrequenz im Code richtig anzugeben:
statt: $crystal = 128000
jetzt: $crystal = 1000000
Zum Vergrößern anklicken....

DANKE!
OK, einen ATTiny 13V habe ich ja noch :)
Also versuche ich es nun erneut. Ich passe im Quellcode (siehe Link von eben) den Taktwert ($crystal) an, stelle auf "Optimize code" und schiebe das ganze auf den ATTiny.

OK? Oder habe ich noch einen Denkfehler? Möchte nicht den letzten auch noch verlieren.

Achso: Hat vielleicht jemand im Raum Gießen - Dillenburg so einen High Voltage Programmer um die anderen vier wiederzubeleben?

Grüße!
 
T

thomas_st

Geowizard
Kappler schrieb:
Wer ist denn für Änderungen im K o c h buch verantwortlich? Sollte man denjenigen nicht mal auf diese Erkenntnisse aufmerksam machen?
Zum Vergrößern anklicken....
Müßte Ralf sein - vor Zeiten hat er hier mitgelesen ...

Kappler schrieb:
PS: Jetzt weiß ich auch, was du mit Backbuch meinst... :D
Zum Vergrößern anklicken....
wenn ich zumindest erkennen könnte, warum man aus einem K o c h buch ein backbuch machen muss... Software (auch Forensoftware) sollte nicht versuchen für die Nutzer zu "denken".

Kappler schrieb:
Du solltest nur auch daran denken, die Taktfrequenz im Code richtig anzugeben:

statt: $crystal = 128000
jetzt: $crystal = 1000000

verwenden.
Zum Vergrößern anklicken....
Ist noch etwas komplizierter - Dank bitte in Richtung Atmel. Für die meisten µC stimmt obiges, nicht aber für den Tiny 13 - aus irgend einem Grund hat Atmel entschieden, das dieser mit einem 9,6MHz Takt läuft - geteilt durch 8 ergibt das 1,2MHz. Also beim Tiny 13 bitte:
$crystal = 1200000

Viele Grüße,
Thomas(_st)
 
Kappler

Kappler

Geowizard
Upps - stimmt... :eek:ps:
Da hab ich in letzter Zeit wohl zu viel mit den "großen" Atmels rumgebastelt...

mal schauen, ob ich meinen obigen Post noch ändern kann, um Verwirrung zu vermeiden...
 
OP
T

testosteron

Geocacher
Für mich war es noch früh genug :D

Sonst muss ich aber nichts anpassen, oder?
Hatte mir es nicht so schwer vorgestellt. Hab aus einem anderen Forum schon mal einen 3x3x3 LED Cube nachgebaut. Der brauchte einen ATTiny2313. Das war irgendwie einfacher :roll:
 
Kappler

Kappler

Geowizard
Eigentlich ist es ganz einfach, wenn man mal die Hintergründe kennt.
Passiert wäre übrigens auch bei $crystal = 1000000 nichts, schlimmstenfalls hätte das Programm nicht funktioniert.
Aber solange man die Finger von den Fuses lässt, kann man immer das Programm korrigieren und neu schreiben. Ausser, man bekommt den Tiny auf andere Weise zum Abrauchen... :D
 
OP
T

testosteron

Geocacher
Hallo!

OK; habe nun mal den Quellcode angepasst (also $crystal = 1200000) und das ganze an meine Schaltung angeschlossen:
Die LED geht an, bleibt für ca. 30 Sekunden an, geht aus und geht nach einiger Zeit wieder an. :hilfe:
Wenn ich an den Cube zurück denke, würde ich sagen der Takt ist zu langsam.

Was nun?

Gruß!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben