PORTB|=(1<<PB1);// bit im Portregister auf 1 setzen => LED leuchtet
16
_delay_ms(200);// eine halbe Sekunde warten
17
18
PORTB&=~(1<<PB1);// bit im Portregister auf 0 setzen => LED aus
19
_delay_ms(200);// eine halbe Sekunde warten
20
}
21
}
und nach dem erfolgreichen "make" dann geflasht mit:
1
avrdude -p attiny85 -c usbasp -U flash:w:main.hex
Das war dann erfolgreich, jedoch am Ende eine Meldung a la: safemode:
Fuses verändert auf 0, vorher waren die 62, soll das wieder geändert
werden? (j/n)
Da hab ich j getippt und Enter gedrückt, die rote Programmier-LED blieb
an, nach ein paar Sekunden dann ctrl-c gedrückt, hat er abgebrochen.
OK, den Attiny ins Steckboard gepackt und siehe da, die LED blinkt, wie
sie es soll. Soweit so gut, war ich happy :)
Dann hab ich das Programm etwas verändert (Frequenz des LED-Blinkens
erhöht) und neu kompiliert und beim draufladen kam dann nicht
erfolgreich und nur noch:
1
avrdude: error: programm enable: target doesn't answer. 1
2
avrdude: initialization failed, rc=-1
3
Double check connections and try again, or use -F to override
4
this check.
Tja, hab ich einen neuen Attiny genommen - da war es das gleiche, das
erste mal Programmieren geht, dann nicht mehr - er verändert wohl die
Fuses, aber warum macht er das?
Hab dann noch sowas gefunden und probiert:
1
avrdude -p attiny85 -c usbasp -tuF
Da kommt dann:
1
avrdude: error: programm enable: target doesn't answer. 1
2
avrdude: initialization failed, rc=-1
3
avrdude: AVR device initialized and ready to accept instructions
4
avrdude: Device signature = 0x000000 (retrying)
5
avrdude: Device signature = 0x000000 (retrying)
6
avrdude: Device signature = 0x000000
7
avrdude: Yikes! Invalid device signature.
8
avrdude: Expected signature for ATtiny85 is 1E 93 0B
9
avrdude>
Weiß aber nicht, was ich dort eingeben soll.
Ich würde den weiteren Umgang mit uC's gerne mit learning-by-doing
erlernen, dafür muss ich aber wissen, wie ich Programme ausprobieren
kann, ohne die Dinger immer kaputtzuflashen.
Gibt es eine Möglichkeit, die beiden zu retten und falls nicht,
wenigstens eine Möglichkeit, sicherzustellen, dass die Fuses nicht
kaputt gehen?
LG und vielen Dank für etwaige Hilfe!
> Gibt es eine Möglichkeit, die beiden zu retten
Die letzte Rettung ist ein HV Programmer
evtl reicht es den ISP Takt zu senken.
avrdude kennt dazu den -B Parameter
Ältere usbasp haben eine Steckbrücke für LowClock
> sicherzustellen, dass die Fuses nicht> kaputt gehen?
Kaputt gehen die nicht.
10000 Beschreibungen sollten sie aushalten.
Es ist übrigens eine doofe Idee die Fuses einzustellen, wenn man nicht
weiß, was man da tut.
http://www.engbedded.com/fusecalc/> vorher waren die 62
Welches der 3 Fuse Bytes?
Erstmal Danke für die schnelle Antwort.
Auf der verlinkten Seite war ich schon, da wähle ich den Attiny85 aus,
dann sind die default-Werte: -U lfuse:w:0x62:m -U hfuse:w:0xdf:m -U
efuse:w:0xff:m
Aber ich verstehe nicht, wieso die Fuse-Werte sich ändern, wenn ich
meine Hex-Datei hochlade. Und wie ich das unterbinden kann. Oder muss
ich unten ins Programm noch reinschreiben, dass die Fuse-Werte neu
gesetzt werden beim Flash-Vorgang?
Den B-Parameter hab ich auch gesehen, aber ohne Erfolg eingesetzt.
So, z.B.?
Edit: Einen Jumper gibts bei dem Programmer nicht - nur einen 5V-3,3V
Umsteller, der im Moment auf 5V steht.
Edit2: Hab nachgesehen: "avrdude: safemode: lfuse changed! Was 62, and
is now 0"
Rudi A. schrieb:> Aber ich verstehe nicht, wieso die Fuse-Werte sich ändern, wenn ich> meine Hex-Datei hochlade.
Weil da irgendwelche falschen Bits herumgewackelt haben. Das ist
eigentlich auch das, was dieser “safe mode” verhindern soll bzw.
rückgängig machen möchte, aber im dümmsten Fall (wie offenbar bei
dir) kann es in diesem Moment auch zu spät sein. Der “safe mode”
funktioniert normalerweise nur deshalb, weil die geänderten Fuses
nicht während der aktiven ISP-Sitzung (solange /RESET noch low ist)
wirksam gemacht werden, sondern erst danach. Wenn nun aber auch
die /RESET-Leitung selbst wackelig ist, dann isses Pech.
USBasp an sich funktionieren normalerweise so schlecht nicht (habe
ich auch schon getestet), aber „Nummer sicher“ ist halt ein
ordentliches Tool des Herstellers, auch wenn's ein paar Groschen
mehr kostet. Mit denen sind mir solche Dreckeffekte noch nicht
übern Weg gelaufen, während sie mit den vielen Eigenbau-ISPs, wie
sie in der Anfangszeit der AVRs sehr üblich waren, immer mal wieder
passieren (genau deshalb wurde seinerzeit der “safe mode” ja
erfunden).
Ok, aber wieso geht das erste mal programmieren und dann ist das
Programm auch richtig drauf und dann ab dem zweiten Mal geht alles
kaputt?!
Ich hab das hier mehrmals durchgelesen...
Also wenn ich nen neuen Attiny nehme, erstmal die Fuses
setzen/aktualisieren. Dann wird die Frequenz um 8 erhöht von 1MHz auf
die 8MHz die ursprünglich vorgesehen sind?!
Und dann könnte das klappen.
Klingt das logisch?
1
Hallo zusammen,
2
ich hab mit eurer Hilfe das ganze zum funktionieren gebracht. Beim
3
ersten Flashen wird wohl die interne Geschwindigkeit reduziert. Warum
4
auch immer, ich setzt da ja keine Fuses.
5
6
So funktionierts bei mir:
7
8
- neuer ATTiny85, erstmal die Fuses auf L:0xe2 H:0xdf E:0xff
9
damit setze ich den internen Takt von 8MHz auch auf 8MHz, weil ich
10
Divide clock by 8 internally ausschalte, (die 8MHz werden also NICHT
11
durch 8 geteilt)
12
Somit darf der ISP bis zu 2MHz schnell sein.
13
- USBasp macht wohl immer ISP 375kHz. also passt das jetzt
1. Solange Du PB5 nicht aktiviert hattest, sollte das ohne HV-progger zu
bereinigen sein.
Installier Dir mal den AVR Burn-O-Maten, sollte auf'm Mac funzen, da
JAVA.
Ansonsten den Extreme-Burner (WIndoof) in einer Emu Deiner Wahl, z.B.
Virtual Box.
2. Ich habe divers USBASPs vom Chinamann, alle kamen mit einer
speziellen (veralteten?) China-FW, um irgendwelche Uralt-51er zu
supporten.
Du benötigst eigentlich immer zwei (ein Arduino-ISP tut aber auch) damit
Du die aktuelle Fischl drauf packen kannst, ansonsten kommt es mit
aktuellem Dude zu Sync-Problemen.
Hab den Burn-O-Maten mal installiert, dort kommt immer Error writing
Fuses, wenn ich die Fuses writen will. Der arbeitet ja auch nur mitm
avrdude - also quasi das gleiche, als wenn ichs manuell im Terminal
eigebe?!
Ja, die Software ist veraltet, da kommt auch ne Meldung - steht auch bei
den Amazon Rezensionen dabei - jedoch schreiben alle, das die Meldung
nur eine Warnung ist und man trotzdem ganz normal flashen kann.
Du meinst also, ich soll noch so ein Teil kaufen und dann kann ich mit
dem einen den anderen Flashen?
Nachtrag: Ich hab jetzt mal n neuen Attiny aus der Packung genommen und
die Fuses ausgelesen -> sind alle FF gewesen. Hab die dann auf default
gesetzt (FF, DF, 62) und geschrieben, erfolgreich.
Oder sollte ich den lfuse auf E0 setzen, wie der eine Typ das in seinem
Beitrag schrieb?? Damit wird wohl der Takt-Divisor ausgestellt?
Nachtrag2: Die Fuses wurden nicht gesetzt. Er sagt erfolgreich
geschrieben - aber beim Auslesen sind sie wieder alle FF. Hab die dann
mit avrdude manuell nochmal gesetzt und wollte sie mit "-n -v" auslesen,
aber anscheinend ist der Attiny jetzt schon wieder hinüber :(
Rudi A. schrieb:> Nachtrag: Ich hab jetzt mal n neuen Attiny aus der Packung genommen und> die Fuses ausgelesen -> sind alle FF gewesen.
Hochgradig suspekt.
Atmel verschickt die Teile garantiert mit ihren Defaultwerten. Wenn
dein Programmer nichtmal die ordentlich liest, würde ich ihn
zurückschicken und mir was ordentliches kaufen – und nicht noch ein
zweites Mal den gleichen Schrott.
Rudi A. schrieb:> also quasi das gleiche, als wenn ichs manuell im Terminal> eigebe?!
Nicht nur quasi, ist einfach nur ne JAVA-GUI für'n Duden, hat aber auch
ne schöne Übersicht über die einzelnen Fuses..
Fehlermeldung? Ich kenn' die Parameter nicht auswendig, dafür nutze ich
ja die GUI ;)
Es sollte aber eibgentlich funzen, die Fuses zu ändern, natürlich müssen
die Bedingungen beim Schreiben! den aktuell programmierten Fuses
entsprechen!
Zum Ändern der Fuses habe ich bislang aber immer den Extreme Burner
genutzt, von eineigen Khazaama Test-Burns mal abgesehen.
Zum Sync-Fehler bzw. der Warnung, ja, es stimmt, normalerweise klappert
das Schreiben. Wenn aber irgendwann dann mal doch nicht.. Pech jehappt.
Es ist besser, eine aktuelle FW zu flashen, dann sollte auch die
Geschwindigkeitumstellung via softer Ware kein Problem darstellen.
Meinen erstenn ASP hatte ich seinerzeit ebenfalls mit Warning und trara
aufgepeppt, auf dem zu flashenden Teil - also dem nicht aktiven USBASP -
muss dazu ein Jumper gesteckt werden, auf neueren sind da meist zu zwei
benachbarte unbestückte Lötpunkte und gar nur nur Kleckse für 'ne
Lötbrücke.
Und wenn Du mehr Erfahrung hast..der letzte Schrei ist ein ASP mit
Tiny85, zb. GuloProg, Digispark ...
Rudi A. schrieb:> Soll ich sowas mal bestellen?
Warum zum Geier™ nicht endlich mal ein Tool, welches auch vom
Hersteller supportet ist?
https://hbe-shop.de/Art-2407172-ATMEL-ATATMEL-ICE-BASIC-DEBUGGER-ATMEL-ARM-AVR-BASIC-KIT
Damit kannst du die Dinger auch gleich noch debuggen.
Ist dir deine Freizeit wirklich so wenig Wert, dass du noch mehr davon
verplemperst, statt dich endlich deinem eigentlichen Projekt widmen
zu können?
Ok, hab ja schon einen etwas anderen verlinkt, zählt der auch zu
Schrott?
Was ist denn ein Nicht-Schrottiger?
Nachtrag:
Hab den jetzt mal bestellt (20 Euro ist noch ok. Man kann bei Amazon ja
auch Sachen zurückschicken) - man kann wohl mit einer Drahtbrücke einen
Self-Programming-Jumper simulieren und mit dem zweiten Programmer den
ersten umprogrammieren, muss nur drauf achten die Fuses auch hier
richtig zu setzen.
Weiß da jemand zufällige ne gute Anleitung? Und ich nehme dann die
aktuelle Fischl Firmware?
Rudi A. schrieb:> Was ist denn ein Nicht-Schrottiger?
Schrieb ich dir doch schon.
Ich verstehe auch nicht, warum man sowas krampfhaft bei einem
Buchversender kaufen muss. Ach ja klar, weil die Elektronikläden
den Billigstkram nicht erst führen.
Ich mein', so ein USBasp ist schön für einen Schüler, der sich das
alles vom Taschengeld leisten muss und bei dem der Weg das Ziel ist.
Der kann sich den dank Opensource Soft- und Hardware dann auch gleich
selbst aufbauen und lernt was dabei.
Wenn ich sowas aber einfach nur benutzen will, um mich ansonsten
meinem eigentlichen Projekt zu widmen, dann würde ich mir das nicht
antun. Der Debugger spart einem am Ende so viel Zeit beim Projekt,
dass es sich schon deshalb lohnt.
Jörg W. schrieb:> Ist dir deine Freizeit wirklich so wenig Wert, dass du noch mehr davon> verplemperst, statt dich endlich deinem eigentlichen Projekt widmen> zu können?
Naja ich verstehe schon wie Ihr alten Hasen vernünftige Geräte zu Hause
habt und auf die schwört. Aber als Neuanfänger ist es nicht direkt
einsehbar, wieso ein Gerät für 7,99 mit positiven Rezensionen, in den
denen steht, dass das klappt jetzt weniger geeignet ist, als ein
anderes. Zumal ich nach einem kurzen Erfolg jetzt rein mental schon kurz
vor meinem Ziel zu sein scheine.
Das erste mal Programmieren geht ja ohne Probleme.
Rudi A. schrieb:> Aber als Neuanfänger ist es nicht direkt einsehbar, wieso ein Gerät für> 7,99 mit positiven Rezensionen, in den denen steht, dass das klappt> jetzt weniger geeignet ist, als ein anderes.
Wieso?
Das erlebst du doch gerade.
Schreib' doch wenigstens eine negative Rezension, denn wie du siehst,
andere verlassen sich offenbar auf sowas.
Rudi A. schrieb:> aber beim Auslesen sind sie wieder alle FF. Hab die dann> mit avrdude manuell nochmal gesetzt und wollte sie mit "-n -v" auslesen,> aber anscheinend ist der Attiny jetzt schon wieder hinüber :(
Nö.
So ne Driss hatte ich auch mal, da sind die Fuses schlichtweg überhaupt
nicht nicht geschrieben worden und beim Auslesen hats trotz
gegenteiliger Meldung gehapert.
Ein ATTiny85 wird mit 1MHZ intern ausgeliefert und möchte genau so
angesprochen werden.
Eine inzwischen recht stressfreie Methode ist das Flashen mittels
Arduino-IDE 1.6.5.
Dazu muss eine ATTiny-Erweiterung installiert werden, ich nutze die
Damellis Version.
Takt auswählen und flashen hat bislang immer gefunzt, egal was vorher
drauf war.
Hexen kann die aber auch nicht, wenn der Takt auf extern steht, muss er
auch extern angelegt werden.
Rudi A. schrieb:> avrdude -p attiny85 -c usbasp -U flash:w:main.hex>> Das war dann erfolgreich, jedoch am Ende eine Meldung a la: safemode:> Fuses verändert auf 0, vorher waren die 62, soll das wieder geändert> werden? (j/n)
Wieso macht der von sich aus was mit den Fuses? Im Kommando oben steht
dazu nichts drin.
Bislang hab ich ja alles an meinem Mac gemacht, ich hab hab aber auch
einen stationären Win-PC.
Was nehme ich denn für die gleichen Dinge am besten bei Windows. Es gibt
vom Hersteller direkt ein Atmel Studio 7 - das könnte ich mal
installieren.
Und Treiber lad ich von der Fischl-Seite runter.
Dann schließe ich den mal unter Windows an und gucke, ob sich was
ändert.
Rudi A. schrieb:> Es gibt vom Hersteller direkt ein Atmel Studio 7 - das könnte ich mal> installieren.
Hilft dir mit dem USBasp gar nichts.
Aber OK, das mit dem Mac hatte ich verdrängt. Dafür ist das
Atmel-ICE, welches ich dir genannt habe, derzeit (leider) keine
gute Wahl. Unter OSX habe ich das mit AVRDUDE noch nicht zum
Laufen bekommen, da es dort nicht gelingt, den HID-Treiber des OSes
dazu zu bewegen, dass man selbst zu Fuß mit dem Gerät reden kann.
(Ich müsste AVRDUDE mal auf die libhidapi umschreiben, aber dazu hat
mir bislang die nötige Zeit gefehlt.)
Rudi A. schrieb:> Was nehme ich denn für die gleichen Dinge am besten bei Windows.
Für ein spezielles Gerät, den AVR Transistor Tester, nutze ich eine
zusammengeschusterte AVR-Toolchain nach Michael D.
Aber nur, weil das alles Kommandozeilenfreaks sind und ich die
vorgefertigtes makefiles nutzen kann;)
Ansonsten bevorzuge ich Eclipse, allerdings liegt das momentan brach, da
der Digispark-Support hakelt - deswegen z.Zt. Arduino IDE 1.6.5
Ok, ich hab jetzt mal den Khazama AVR Programmer getestet und der gibt
mir die gleichen Resultate wie unter Mac. Also dass der Attiny komplett
leer ist, alle Bits auf 0 und die Signatur auch 0 ist.
Jetzt würde ich eigentlich auf einen Verkabelungsfehler tippen, jedoch
dass es das erste Mal immer klappt ist da seltsam.
Aber: wenn ich den uC aus der Halterung nehme, kommt exakt die gleiche
meldung.. Also entweder ist der ganz kaputt oder da ist noch was anderes
im Argen...
Rudi A. schrieb:> Ok, ich hab jetzt mal den Khazama AVR Programmer getestet und der gibt> mir die gleichen Resultate wie unter Mac. Also dass der Attiny komplett> leer ist, alle Bits auf 0 und die Signatur auch 0 ist.
Das bedeutet nur, dass der µC nicht auf die Initiativen des Programmers
reagiert. Er muss deshalb weder kaputt noch leer sein.
Ok, hab grade noch was anderes gelesen: Und zwar kann es sein, dass der
Attiny sich im SlowMode programmieren lässt und erkennen auch?
Auf http://www.fischl.de/usbasp/ sieht man ja im Schaltbild den Jumper1,
wenn man den setzt (hab ich bei mir nicht, aber kann man ja dranlöten),
ist der im SlowMode.
Ansonsten wenn morgen der andere Stick kommt, angeblich ja Made in
Germany, also kein China-Stick, werd ich dann den JP2 setzen und die
neuste Hex-Datei von 2011 von der Fischl-Seite drüberbraten und sehen,
obs besser wird...
Nachtrag: Es gibt wohl auch noch einen SCK-Jumper der den
Programmer-Takt runtersetzt, der wird aber wohl nur zum Firmware Update
gebraucht.
Rudi A. schrieb:> Auf http://www.fischl.de/usbasp/ sieht man ja im Schaltbild den Jumper1,> wenn man den setzt (hab ich bei mir nicht, aber kann man ja dranlöten),> ist der im SlowMode.
Wenn's den Jumper nicht gibt, ist zu erwarten, dass dessen Firmware
den vielleicht auch gar nicht unterstützt.
Ansonsten: ja, prinzipiell könnte das sein.
Jörg W. schrieb:> Rudi A. schrieb:>> Auf http://www.fischl.de/usbasp/ sieht man ja im Schaltbild den Jumper1,>> wenn man den setzt (hab ich bei mir nicht, aber kann man ja dranlöten),>> ist der im SlowMode.>> Wenn's den Jumper nicht gibt, ist zu erwarten, dass dessen Firmware> den vielleicht auch gar nicht unterstützt.>> Ansonsten: ja, prinzipiell könnte das sein.
Ok, kann ich denn irgendwie auslesen, welche Firmware auf dem Programmer
installiert ist? Macht avrdude das oder muss ich da in den USB-Optionen
z.B. unter Windows gucken?
Das Layout ist aber zu 99% gleich, wie bei dem Fischl-Stick den er
anbietet.
Rudi A. schrieb:> Ok, kann ich denn irgendwie auslesen, welche Firmware auf dem Programmer> installiert ist?
Nein, die USBasp-Firmware hat leider (meines Wissens) keine Methode,
mit der man sich eine Versionsnummer oder dergleichen zurückgeben
lassen könnte. Hätte ich mir für AVRDUDE durchaus gewünscht, sowas
zu haben.
Hmm hab den Jumper für den SlowMode mal gesetzt, aber ändert sich nichts
am verhalten. Wenn ich n neuen Attiny reinsetze und nur auslese mit
Burn-o-Mat behauptet er alle Fuses wären FF.
Mal sehen ob das gleiche morgen mit dem anderen auftritt und wenn nicht,
wie ich die "kaputten" wieder reparieren kann...
Ich hab nochmal weiter gelesen und manche Leute machen beim Flashen z.B.
einen 10k Widerstand an den Reset-Pin auf Vcc. Hab dazu jetzt beim
überfliegen des Datenblattes nichts gefunden?!
Und noch ne Frage: Beim Burn-o-Mat unter OS X kann ich beim Bratvorgang
eine Datei für "Flash" und eine für "Eeprom" auswählen, was ist denn da
der Unterschied und was ist das Richtige?
Die normale Betriebsspannung von knapp 5V liegt auch beim Attiny an,
habs grade nochmal nachgemessen, um vielleicht doch noch n Fehler zu
finden.
Rudi A. schrieb:> Ich hab nochmal weiter gelesen und manche Leute machen beim Flashen z.B.> einen 10k Widerstand an den Reset-Pin auf Vcc. Hab dazu jetzt beim> überfliegen des Datenblattes nichts gefunden?!
Hat damit auf jeden Fall nichts zu tun. Es gibt einen internen
Pullup, der externe (zusammen mit einem Kondensator) verbessert nur
die Störsicherheit.
> Und noch ne Frage: Beim Burn-o-Mat unter OS X kann ich beim Bratvorgang> eine Datei für "Flash" und eine für "Eeprom" auswählen, was ist denn da> der Unterschied und was ist das Richtige?
Die eine ist für den Flash und die andere für den EEPROM …
Programme liegen im Flash.
> Die normale Betriebsspannung von knapp 5V liegt auch beim Attiny an,
Die Dinger funktionieren ab 1,8 V (offiziell nur in der V-Version,
aber real sicher auch ohne).
Hab mal ein paar Fotos angehängt.
Der Versuchsaufbau ist auf 'nem Steckboard, da ist nur 1 LED gegen Masse
geschaltet, das ist alles. (kein Foto)
Es wird aber wohl daran liegen, dass der AVR Programmer ein veraltete
Firmware hat. Es gibt auch andere Leute im Internet, die ihren Attiny
"kaputt" geflasht/gefuses haben. Das erste mal flashen klappt, aber dann
wird irgendwie die Geschwindigkeit zu hoch eingestellt, dass der Flasher
nicht mehr mitkommt, wenn ich das richtig verstanden habe.
Und mit dem -tuF Befehl kann man per "sck 1000" die Geschwindigkeit
runter setzen und oder mit z.B. -B 4 dann neue Fuses setzen nach dem
Löschen.
Morgen kommt der neue/andere Programmer, der hat hoffentlich ne neue
Firmware. Dann probier ich zum einen das Flashen von neuen Attiny's aus
und zum anderen werde ich versuchen den veralteten Programmer, den ich
jetzt nutze, zu aktualisieren.
Tom schrieb:> Da fehlt ein Kondensator 100nF zwischen Vcc und GND.
Je nachdem, wie man's sieht: falls man jemals debugWIRE benutzen will,
dann muss er „fehlen“. Ansonsten würde auch dieser Kondensator
sehr wahrscheinlich das Problem des TE nicht beeinflussen.
Jörg W. schrieb:>> Da fehlt ein Kondensator 100nF zwischen Vcc und GND.>> Je nachdem, wie man's sieht: falls man jemals debugWIRE benutzen will,> dann muss er „fehlen“.
Du verwechelst grad den VCC-GND mit dem Reset-GND Kerko.
A. K. schrieb:> Du verwechelst grad den VCC-GND mit dem Reset-GND Kerko.
Ah ja, sorry. Zu früh am Morgen. ;-)
Ja, da gehört natürlich auf jeden Fall einer dran, und das Fehlen
eines solchen könnte in der Tat zu derartig verwundersamen Effekten
führen.
Guten Morgen,
nochmals Danke für die Antworten.
Also fehlt ein 100nF Kondensator? An welcher Stelle soll der denn
zwischen Vcc und Gnd? Direkt Am Attiny?
(So ein ungerichter Keramikkondensator und kein gepolter Elektrolyt?)
Jörg W. schrieb:> Warum zum Geier™ nicht endlich mal ein Tool, welches auch vom Hersteller> supportet ist?.....
In dem Post ist eigentlich alles gesagt. Gutes Werkzeug ist schon mehr
als der Halbe Weg..
Diese ganzen Spielzeugprogrammer fallen in die Kategorie "vom Bastler
für Bastler"
Rudi A. schrieb:> Also fehlt ein 100nF Kondensator? An welcher Stelle soll der denn> zwischen Vcc und Gnd? Direkt Am Attiny?
So nah wie möglich am µC! Das Ding heißt "Stützkondensator".
> (So ein ungerichter Keramikkondensator und kein gepolter Elektrolyt?)
Keramik, da er bessere Hochfrequenz-Eigenschaften hat (die sind hier
wichtig!).
Gruß Dietrich
Ok, hab ich mal gemacht - es hat auch auch was geändert (Weiß leider
nicht, ob durch den Slow-Jumper oder den Kondensator):
Die "kaputten" lassen sich nach wie vor nicht ansprechen - ABER wenn ich
einen neuen nehme, lassen sich jetzt die Fuses korrekt auslesen.
Ich hab das Lfuse-Bit auf E2 gesetzt, geschrieben und konnte auch wieder
lesen :) Also ein kleiner Erfolg.
(Ich hab zusätzlich den -B 60 Parameter verwendet, auch wenn er anzeigt,
dass er eben aufgrund der veralteten Firmware die Clock nicht verändern
kann.)
Ich hab zum Test das LED-Blink Programm drauf geladen und es klappt,
auch verifizieren geht. Jedoch nicht das erneute Beschreiben, wie
gehabt. Allerdings liest er jetzt die Device Signatur richtig aus.
Vorher war da immer nur 0.
Nachtrag: Das erneute Flashen geht jetzt! Er liest als lfuse E2 aus, das
ich gesetzt habe und hat jetzt ein anderes Programm geladen.
Das 2000ms Intervall zum blinken ist jetzt aber 8mal so schnell. Das
könnte am noch falschen F_CPU Wert im Makefile liegen...
Rudi A. schrieb:> Also fehlt ein 100nF Kondensator?
Bis gestern einschließlich habe ich weder einen externen Pullup noch
einen Reset Stützkondi benötigt, bei Verwendung eines einer
Programmierklammer wäre das auch recht umständlich, es heißt schließlich
(I)n(S)ystem(P)rogramming.
Dein verwendeter ASP hat ein modernes PCB-Layout ohne Ack-Jumper und
möchte per SW, also dem Duden, auf langsame! Übertragung aufgefordert
werdern, was mit der installierten FW aber wohl hapert.
Bovor ich auf die Arduino-IDE umgestiegen bin hatte ich (und habe noch)
einen fest auf LANGSAM gejumperten 4rt-USBASP, das hilft Dir aber auch
nicht weiter.
Grundsätzlich hilft Dir nur ein Löschen und anschließendes Neuschreiben
der Fuses, wobei zum Löschen auf langsame Übertragung geschaltet werden
muss.
Dazu ist wohl ein weiterer ISP-Programmer nötig, egal welcher
Beschaffenheit.
So, ich hab mal zum testen das gewollte Programm für den 433MHz Sender
draufgepackt und siehe da: es funktioniert alles. Wenn man nur erstmal
am Anfang die Fuses umstellt/erneut schreibt. Seltsam, aber naja.
Jetzt hab ich meinen zweiten AVR bekommen, der sollte eine aktuelle
Firmware haben, hat natürlich jetzt ein 6-Pin Anschluss, muss ich erst
rumlöten, da der andere ja 10-PIN hatte...
Ich werde dann probieren, ob ich eventuell langsam mit den "kaputten"
uC's sprechen kann, um sie zu löschen und die Fusebits neu zu setzen.
Sind ja immerhin 3 Stück.
Und natürlich zu guter letzt die Firmware upzudaten von Stick1. Bin ich
mir aber noch nicht sicher, ob es das Risiko wert ist, bzw. wie groß das
Risiko ist, ihn kaputt zu machen.
Also der neue Stick funktioniert auch soweit.
Jetzt hab ich mal geguckt, wie das mit dem Firmware Update gehen soll:
Sticks beide verbinden mittels 10-Pin -> 6-Pin, hab ich gemacht.
Beim zu updatenden Stick den Jumper2 angelötet an den Atmega8.
Unter Windows avrdude gestartet und probiert zu lesen -> geht nicht.
Anscheinend muss der Programmer, der den anderen Stick programmiert auch
im SlowMode laufen...
Leider gibts auch hier kein Jumper und es ist ein AT90USB162 verbaut.
Pin25 auf Masse legen geht hier wohl nicht, da die Pin Belegung anders
ist?!
Weiß jemand, wie ich den in den SlowMode bekomme? Also welchen Pin ich
nehmen muss?
Bei dem Atmega war es PC2(ADC2).
Laut Datenblatt des AT90USB162 ist ein PC2-Anschluss an Pin5, aber ist
der vergleichbar?
Naja, nachdem ich grade mit grobigen Fingern 3 Pins des Atmega verbunden
habe und die wieder freibekommen habe, lass ichs erstmal sein mit dem
Flashen.
Hab aber jetzt 2 funktionierenden Programmer, einen davon mit veralteter
Firmware.
Einer usbasp (alt) und einer stk500v2/avrispv2 (aktuell).
Jedoch hab ich 3 Attinys, die sich nicht mehr richtig ansprechen lassen
- wie bekomme ich die denn wieder hin?
Rudi A. schrieb:> Jedoch hab ich 3 Attinys, die sich nicht mehr richtig ansprechen lassen> - wie bekomme ich die denn wieder hin?
Stand schon da:
Catweazle schrieb im Beitrag #4293810:
> Jetzt darfst du dir einen HV-Programmer kaufen/basteln....
mfG Paul
Rudi A. schrieb:> Jedoch hab ich 3 Attinys, die sich nicht mehr richtig ansprechen lassen> - wie bekomme ich die denn wieder hin?
Steck sie mir in einen Briefumschlag mit Rückumschlag. Ich pack'
sie hier mal in einen STK500 rein.
Und das nächste Mal weißt du, warum CMOS-Bausteine unbedingt
Stützkondensatoren benötigen. ;-) (Das ist übrigens keine
Eigenart von Atmel, sondern prinzipbedingt bei CMOS so.)
Ja ich hab daraus gelernt :) Hab schon drei Stück programmiert mit
Testprogrammen und jetzt geht alles. Kann meine Funksteckdosen schalten
:)
Ok zu den Attiny's schick ich dir noch ne PM.
Nachtrag: allgemeine Frage: Brauchen CMOS-Bausteine IMMER
Stützkondensatoren? Immer 100nF rum? Also auch in der normalen Schaltung
oder nur beim Programmieren?
Rudi A. schrieb:> Brauchen CMOS-Bausteine IMMER Stützkondensatoren?
Ja.
> Immer 100nF rum?
Ist zumindest eine gute Hausnummer.
> Also> auch in der normalen Schaltung oder nur beim Programmieren?
Auch in der normalen Schaltung. Die Folgen sind vielleicht nur nicht
so fatal wie beim Programmieren. ;)
Der Hintergrund: CMOS zieht ja statisch keinen Strom(*). Im Moment
des Umschaltens jedoch müssen überall dort, wo sich am Ausgang eines
Gatters der Pegel ändert, kleine Kondensatoren umgeladen werden. Diese
Umladung ist relativ niederohmig (es soll ja schnell gehen), und
erzeugt aus diesem Grunde eine Stromspitze in der Versorgungsleitung.
Diese wiederum verursacht selbst an einigen Nanohenry der Zuleitung
bereits einen nennenswerten Spannungseinbruch. Daher muss man diese
Umladeenergie aus einem (oder mehreren) möglichst nahe gelegenen
Kondensator aufbringen.
(*) OK, mittlerweile sind die Strukturen so klein, dass auch der
Leckstrom eine Rolle spielt, aber das ist hier nebensächlich.
Ok gut, wieder was gelernt.
Vielen Dank für den tollen Support hier im Forum - hoffentlich kann ich
irgendwann auch mal was zurückgeben und anderen Anfängern helfen :)
Thread beobachten
Seitenaufteilung abschalten