mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik avrdude-ATTiny13-ohne Programmer


Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

PROBLEM NR 1

zur Zeit versuche ich den ATTiny13 aus dem 
Franzis-Mikrocontroller-Lernpaket unter Linux in Betrieb zu nehmen. 
Unter WindowsXP hat alles standardmässig funktioniert (gemäss 
Anleitung), unter Linux fehlt mir die Idee, wie ich den avrdude-Aufruf 
parametrieren muss um den MC zu initialisieren (Ziel: Hochladen von 
init.hex mit überbrücktem RES-GND).

Hauptproblem: Da ich ohne in Hardware ausgeführtes Programmiergerät 
arbeite, also den ATTiny13 lediglich mit dem mitgelieferten RS232-Kabel 
mit dem Computer verbinde, weiß ich nicht was ich für den Parameter -c 
(Programmer-ID) angeben muss. Eine Antwort auf diese Frage wäre wichtig 
für den nächsten Schritt, bzw die nächsten Fragen :-) Wer mir natürlich 
die komplette Parametrierung des avrdude-Kommandos schon sagen kann, ist 
herzlich willkommen. Leider habe ich bisher keinerlei Erfahrung im 
Umgang mit avrdude und bin deshalb völlig überfordert mit der Vielzahl 
der möglichen Parametrierungen (man avrdude). "Reines Ausprobieren" geht 
da einfach nicht.

Noch einige Daten zur Systemkonfiguration:
Laptop Bj 1999, RS232, SUSE 11.2 (nur Kommandozeileninstallation).

PROBLEM NR 2

Neben dem ATtiny beabsichtige ich auch einen ATmega328P zu betreiben. 
Für den liefern aber weder man avrdude noch avrdude.conf die 
Parametrierung der Part-ID (-p).

Kann mir hier geholfen werden ?

PS: Rafa Rafaelito ist natürlich ein Phantasiename, leider habe ich zu 
spät gelesen, dass das eigentlich nicht gewünscht ist. Wer es kann und 
will, darf meinen Namen gerne ändern in Ralf K.

Danke, Rafa (Spitzname)

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zumindest zum zweiten Problem kann ich Dir die Lösung sagen:
$ avrdude -c stk500 -p list 2>&1 | grep -ie mega328
  m328p = ATMEGA328P      [/etc/avrdude.conf:8547]

Zum ersten Problem: das ★könnte★ siprog[1]-kompatibel sein, das müsstest 
Du aber erst noch verifizieren. Die Programmer-ID wäre dann 'siprog' [2]

HTH

[1] http://www.lancos.com/siprogsch.html
[2]
$ avrdude -c list 2>&1 | grep -ie siprog
  siprog   = Lancos SI-Prog <http://www.lancos.com/siprogsch.html> [/etc/avrdude.conf:837]

Autor: Rafa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo g457, zunächst danke fuer Deine schnelle Antwort.

Zum Thema m328p: innerhalb vim gelingt es mir nicht ab Dateianfang 
mittels /m328p diesen Eintrag in avrdude.conf zu finden (Suchergebnis: 
String nicht gefunden). In Zeile 8547 steht bei mir was ganz anderes. 
Habe ich eine veraltete Version installiert ? Kann aber eigentlich nicht 
sein, da es das ist, was von openSUSE 11.2 per default installiert wird 
(mh, das muss natürlich nix heißen).

zum Thema ATTiny13: Das war auch meine Idee, d.h. ich nahm an, dass es 
sich bei meinem Kabel um einen der "ultra-cheap-bitbanging-programmers" 
handelt. D.h. ich habe auch schon siprog ausprobiert (ebenso wie dasa, 
dasa3 und ponyprog) In allen drei Fällen das gleiche Ergebnis:
avrdude: AVR device not responding
avrdude: initialization failed, rc=-1

Da es unter Windows funktioniert, kann es nicht an der Hardware liegen.


Das Kabel ist fast genau so bestückt, wie in avrdude.conf schematisch ab 
Zeile (~) 717 dargestellt (some ultra cheap programmers use 
bitbanging....). Die einzigen Unterschiede: Pin 1 (DCD), 6 (DSR), 9 RI) 
sind bei diesem Kabel nicht angeschlossen, bzw werden nicht auf die 
Schaltung geführt.

Und so versuchte ich mein Glück: avrdude -p t13 -P /dev/ttyS0 -c siprog 
-U flash:w:init.hex:i

Guesse aus LU, Ralf

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Habe ich eine veraltete Version installiert ? Kann aber eigentlich nicht
> sein, da es das ist, was von openSUSE 11.2 per default installiert wird
> (mh, das muss natürlich nix heißen).

Gute Frage. Hierzuworkstation läuft die Version 5.10, die bringt den 
m328p mit. Laut History [1] wird er seit 5.6 unterstützt.

> avrdude: AVR device not responding
[..]
> avrdude -p t13 -P /dev/ttyS0 -c siprog -U flash:w:init.hex:i

Der Aufruf sieht schon mal nicht schlecht aus. Bist Du sicher, dass es 
ttyS0 ist? Rein paranoia-mäßig mal überprüfen (obs noch andere Serielle 
gibt: 'dmesg | grep -ie ttys'; und ist die richtig(tm) verdrahtet (aka 
funktioniert ein anderes Gerät daran korrekt)?), ggf hülft auch ein Oszi 
an den Datenleitungen.

HTH

[1] Debian:/usr/share/doc/avrdude/NEWS.gz

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also das mit dem m328p könnte sich geklärt haben: Die installierte 
avrdude-Version ist bei mir: 5.5-112.3 :-(

Was den Tiny anbelangt:
ttyS0: Das ist amtlich der einzige COM-Port. demsg liefert: serial8250: 
ttyS0 at I/O 0x3fa (irq=4) is a 16550A
Und:
Wie gesagt, wenn ich das Windows-Programm, also das AVR-Studio mit dem 
selben Kabel auf den MC loslasse, funktioniert es.
Nebenbei, damit die Verwirrung nicht zu gross wird: Wenn ich von avrdude 
rede meine ich den alten Kommandozeilen-Laptop, wenn ich von Windows 
rede meine ich einen Desktop mit XP-Prof in einer SunBox. In beiden 
Fällen Suse 11.2 als Basis. (Ein geiles Betriebssystem, wie ich finde 
:-)

==> Was ich nicht mit Sicherheit sagen kann ist, ob auch der 
Laptop-Com-Port rein hardwaremässig wirklich funktioniert. Da ich kein 
Oszi am Start habe: Genügt es eine serielle Maus auszuprobieren um die 
Funktionstüchtigkeit des Com-Ports zu verifizieren ?

Jetzt wäre es natürlich interessant zu wissen, wie das AVR-Studio das 
avrdude-Kommando parametrieren würde :-) Wenn ich es richtig verstanden 
habe, ist avrdude aber nur unter Linux im Einsatz, oder gibt es da auch 
eine Windows-version? Aber selbst wenn, wie soll ich an diese Schicht 
herankommen, um die entsprechenden Infos zu saugen ?

Könnte die "veraltete" avrdude-version auch für das ATtiny13-Problem 
verantwortlich sein ? Wahrscheinlich nicht, aber dennoch würde mich 
Deine Meinung interessieren. In der Zwischenzeit fahnde ich nach einer 
avrdude-Version neuer als 5.5, bzw ab 5.6

Danke und Gruesse aus LU, Rafa

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Genügt es eine serielle Maus auszuprobieren um die Funktionstüchtigkeit
> des Com-Ports zu verifizieren ?

Wäre vollauf in Ordnung denke ich:-)

> Jetzt wäre es natürlich interessant zu wissen, wie das AVR-Studio das
> avrdude-Kommando parametrieren würde :-) Wenn ich es richtig verstanden
> habe, ist avrdude aber nur unter Linux im Einsatz, oder gibt es da auch
> eine Windows-version? Aber selbst wenn, wie soll ich an diese Schicht
> herankommen, um die entsprechenden Infos zu saugen ?

Müsstest nachschauen, was der Windows-Installer des Lernpakets alles 
installiert, aber ich nehme mal an, dass der seinen eigenen Uploader ins 
avrstudio reininstalliert. Ich hab aber mit selbigem noch nie 
gearbeitet, deswegen weiss ich das nicht genau. Eine Windows-Version von 
avrdude gibts prinzipiell, google kennt die Details.

Zum Abfangen von Parametern (aber nur interessant falls avrstudio auch 
den avrdude benutzt):

- Einfache Version: Eine Batch-Datei basteln, die alle Parameter 
'echo't. Die Datei muss dazu genauso heissen wie die exe (hier also 
vermutlich 'avrdude.bat') und dem Programmer unterschieben (hier: das 
Original umbenennen, z.b. in 'avrdude2.exe'). BTDT. Das ganze 
funktioniert aber nur, wenn der Systemcall im avrstudio auf 'avrdude' 
zeigt und nicht auf 'avrdude.exe'.

- Lange Version: Ein kurzes Programm (exe) schreiben, das nichts anderes 
tut als alle Parameter auf stdout auszugeben. Der Rest wie bei der 
einfachen Version. BTDT.

> Könnte die "veraltete" avrdude-version auch für das ATtiny13-Problem
> verantwortlich sein ? Wahrscheinlich nicht, aber dennoch würde mich
> Deine Meinung interessieren.

Dazu kann ich nichts sicheres sagen, nur soviel dass in der History 
nichts dergleichen auftaucht - nur dass dessen Unterstützung in Version 
4.4.0 dazugekommen ist. Ich vermute also mal, dass der Fehler eher 
woanders liegt. Hierzuworkstation funktioniert avrdude mit dem t13 
einwandfrei.

Dazu fällt mir noch ein: Klingel mal dein Board durch, welche Anschlüsse 
wohin gehen, und gleiche das mit der avrdude.conf ab. Leg dazu ggf. ein 
neues Programmiergerät an analog zu den bestehenden. Die Syntax scheint 
mir recht einfach gehalten zu sein.

HTH und viel Erfolg!

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich mach mal eben die Ingrid:

Ist dasda [1] der richtige(tm) Schaltplan? Dann wäre die Zuordnung

4/DTR -> PB0/MOSI
8/CTS -> PB1/MISO
3/TXD -> PB2/SCK

..und dann wäre ein Eintrag für die avrdude.conf etwa..
programmer
  id    = "franzislp";
  desc  = "Franzis Lernpaket Mikrocontroller";
  type  = serbb;
#  reset = ~3;
  sck   = 3;
  mosi  = 4;
  miso  = 8;
;

..was man mit dem reset macht (im avrdude (auf einen nicht benutzten Pin 
legen?) - aufm Board natürlich auf GND ziehen.. oder eine Brücke ziehen 
zu einem passenden Pin an der Seriellen?) und ob der avrdude das 
schluckt wäre noch auszutesten.

Wenn dann der Chip noch 'richtig rum' drin ist, die Schnittstelle passt, 
die Sonnenwinde nicht dazwischenfunken und die Mondphase auch mitspielt, 
dann kann eigentlich fast nix mehr schiefgehen.. ;-))

HTH

[1] ziemlich weit unten auf http://www.b-kainka.de/lpmikros.htm

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
g457 schrieb:
> Ist dasda [1] der richtige(tm) Schaltplan? Dann wäre die Zuordnung
>
> 4/DTR -> PB0/MOSI
> 8/CTS -> PB1/MISO
> 3/TXD -> PB2/SCK

Also nun weiß ich weder wer Ingrid ist :-), noch was "dasda[1]" oder 
"richtige(tm)" bedeuten (Du beziehst Dich wohl auf die 
avrdude.conf-Einträge. Was ich weiß ist: Die Zuordnung ist genau so wie 
im Schaltplan des Lehrbuchs auf S 12 (falls Dir das Werk vorliegt).

>..und dann wäre ein Eintrag für die avrdude.conf etwa..
>
>programmer
>  id    = "franzislp";
>  desc  = "Franzis Lernpaket Mikrocontroller";
>  type  = serbb;
>#  reset = ~3;
>  sck   = 3;
>  mosi  = 4;
>  miso  = 8;
>;

Darüber hatte ich schonmal nachgedacht, habe mich aber nicht getraut es 
umzusetzen :-( Weil ich eben nicht sicher war wie ich MISO und MOSI 
zuzuordnen habe (mir fehlte genau Deine Angabe: PB0/MOSI...etc). Klar 
MasterOutSlaveIn, usw. schon klar soweit. Allerdings steht irgendwo im 
Lehrbuch, daß DTR nur für eine erhöhte Spannungsversorgung gedacht sei, 
oder so ähnlich. Das hat meine Idee dann wieder über den Haufen 
geworfen. Ausserdem zweifelte ich ständig am Programmer-Problem. egal... 
Wie dem auch sei. Dank Deiner Hilfe habe ich jetzt sehr viel 
auszuprobieren. Aktuell habe ich die 5.10 installiert und arbeite an der 
Verbindung zwischen m328p und dem Rechner. Anschliessend bastele ich den 
avrdude.conf-Eintrag für den ATtiny13. Sobald ich Neues weiß gebe ich 
Dir hier Bescheid.

Vielen Dank für die Hilfe, Rafa (Ach doch... die INGRID !!!! das ist 
doch die, die nix davon versteht, aber prima zuhört ? und dabei dem 
Sprecher seinen Knoten im Hirn lösen hilft ?

Lach... Rafa

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Also nun weiß ich weder wer Ingrid ist :-), noch was "dasda[1]" oder
> "richtige(tm)" bedeuten (Du beziehst Dich wohl auf die
> avrdude.conf-Einträge. Was ich weiß ist: Die Zuordnung ist genau so wie
> im Schaltplan des Lehrbuchs auf S 12 (falls Dir das Werk vorliegt).

Die Ingrid bezieht sich hier auf eine Usenet-Wendung [1] (und das [1] 
auf den Verweis in der Fußnote 1) :-) Das Lehrbuch liegt mir leider 
nicht vor, deswegen ja der Verweis auf den möglichen Schaltplan. Anhänge 
wie '(tm)', '(c)' und '(r)' können ersatzlos gestrichen werden ;-)

> mir fehlte genau Deine Angabe: PB0/MOSI...etc

Das steht im Datenblatt, falls Du das noch nicht vorliegen hast, dann 
schnellstens nachholen - ich hoffe Du kannst Englisch. Gibts bei Atmel 
zum runterladen [2]. Nicht erschrecken ob dessen Umfang, dafür steht da 
praktisch alles haarklein drin.

> Anschliessend bastele ich den avrdude.conf-Eintrag für den ATtiny13.

Viel Erfolg!

> Ach doch... die INGRID !!!! das ist doch die, die nix davon versteht,
> aber prima zuhört ? und dabei dem Sprecher seinen Knoten im Hirn lösen
> hilft ?

Ne also ich hoffe ich verstehe mehr davon als nur zuzuhören ;-) Aber 
diesen Hintergrund kenn ich noch gar nicht, muss ich mal nachforschen 
:-)

HTH

[1] http://de.wikipedia.org/wiki/Ingrid#Sonstiges
[2] http://atmel.com/dyn/products/datasheets_mcu.asp?f...
insbesondere
    http://atmel.com/dyn/resources/prod_documents/doc2535.pdf
für den tiny13 oder
    http://atmel.com/dyn/resources/prod_documents/doc8126.pdf
für den tiny13A

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, dann gebe ich jetzt auch die Ingrid :-)

Meine Idee mit der Ingrid kommt aus irgendeinem Buch mit irgendeinem 
Kapitel "Fehlersuche bei MiKrocontrollerprogrammierung" oder so. Demnach 
(so erinnere ich mich jetzt) bezeichnet man das im Englischen 
Rubberducking (hat also mit Ingrid gar nix zu tun). Worum gehts: Bei der 
Fehlersuche erklärt man sein Problem einer Testperson, die selbst gar 
nichts von dem Problem verstehen muss. Es genügt völlig sich das Problem 
so im Kopf zurecht zu legen, dass man es jemandem erklären kann. Alleine 
dieses Erklären, und das ist tatsächlich meine persönliche Erfahrung, 
schafft oft Klarheit im Kopf so daß einem die Lösung quasi schon während 
des Erklärens selbst einfällt. Der hilfreiche Knackpunkt ist dabei die 
Notwendigkeit die oft diffusen und ungeordneten Gedanken in eine für 
Menschen verständliche Reihenfolge zu bringen und auszusprechen. 
Irgendwann hat wohl ein Programmierer den Anfang gemacht und sich eine 
Gummiente auf den Bildschirm gestellt, um dieser dann sein Problem zu 
erklären :-) Deshalb der Begriff Rubberducking. D.h. ch wollte aus Dir 
also eine Gummiente namens Ingrid machen... :-) Aber damit wollte ich 
natürlich nicht sagen, Du würdest nichts von der Materie verstehen :-) 
Natürlich nicht. Schließlich hast Du längst gezeigt, dass Du zumindest 
"etwas" davon verstehst !!

Gute Nacht, bis demnächst mit hoffentlich besseren Nachrichten als immer 
nur: Geht nit...

Rafa

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK,

das mit dem selbstdefinierten Programmer war teilweise von Erfolg 
gekrönt. Den Reset habe ich jetzt erstmal auf einen unbenutzten Pin 
gelegt (9). Gibt man keinen Reset an, meckert avrdude. Mit Reset auf 
Pin9 lässt sich das Teil endlich initialisieren.
Nach ATtiny-Datenblatt müsste der POR über den Pin 3, also den TXD-Pin 
auch gehen. reset = ~3. (was bedeutet in dem Zusammenhang die Tilde ?) 
Damit gebe ich dem avrdude zwar eine doppelte Pinbelegung an, was aber 
nicht zu stören scheint. Die Meldung ist in beiden Fällen die gleiche:

AVR device initialized and ready to accept instructions.

Allerdings meldet sich der Tiny in beiden Fällen mit der flaschen 
Signatur. avrdude liest: 0x000102. Erwartet aber: 1E 90 07.

Muss mich das beunruhigen ?

Dir einen guten Tag, Rafa...der jetzt den Riemen runter macht

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nach ATtiny-Datenblatt müsste der POR über den Pin 3, also den TXD-Pin
> auch gehen.

Wo steht das (und was ist ein POR)? Ein Reset wird normalerweise nur 
beim Einschalten (Power-on Reset, POR), von extern (am /RESET-Pin), 
durch den Watchdog (sofern aktiviert) oder durch einen Brown-out (sofern 
dessen Erkennung aktiviert ist) ausgelöst.
Und nebenbei bemerkt: die Pins werden bei der 'Kerbe'/dem 'Punkt' 
beginnend entgegen dem Uhrzeigersinn gezählt, 'TXD' von der Seriellen 
hängt also auf IC-Pin 7 :-)

> reset = ~3. (was bedeutet in dem Zusammenhang die Tilde ?)

Ich vermute mal Logik-Invertierung. Z.B. beim siprog wird die 
Reset-Leitung mit einem NPN runtergezogen(!), das Signal auf der 
Seriellen muss also invertiert werden um das Gewünschte zu erreichen.

> Damit gebe ich dem avrdude zwar eine doppelte Pinbelegung an, was aber
> nicht zu stören scheint.

Potentiell gefährlich!

> Allerdings meldet sich der Tiny in beiden Fällen mit der flaschen
> Signatur. avrdude liest: 0x000102. Erwartet aber: 1E 90 07.
> Muss mich das beunruhigen ?

Ja, weil das heisst dass die Kommunikation grundsätzlich schief geht. 
Ist zwar schon mal besser als 'geht gar nicht', aber noch nicht gut. 
Wenn man nach 'avrdude 0x000102' googelt (die Signatur wird erstaunlich 
oft obwohl fehlerhaft doch 'gleich falsch' ausgelesen..) findet man fast 
immer einen Zusammenhang mit der Taktfrequenz. Versuch mal die 
Programmierfrequenz runter zu drehen (-i, Details in der Manpage), 
vorsichtshalber einfach mal extrem langsam anfangen.

HTH

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achja, Rubberducking, das muss ich mir merken :-)))) </Ingrid>

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Potentiell gefährlich!

O.o....dann mal schnell wieder auf die 9 :-)

NEEEEE... das darf doch nicht wahr sein... ich bin in der "Zeile" 
verrutscht!

Vcc liegt natürlich nicht an PB2 sondern an Vcc :-) und das wäre dann 
der  8te Fuss des Igels, also nicht 7 und damit nicht SubD-3. Wieviele 
Igel wohl schon ihr Leben lassen mussten wegen Übermüdung des Proggers ?

Was heißt das dann für die Angabe des Reset-Pins ? Wenn ich in den 
Schaltplan sehe, bezieht Vcc seine Spannung über den 5V Spannungsregler, 
der wiederrum seine Spannung über die beiden Dioden aus der Leitung zu 
Pin4 und Pin7 des Sub-D erhält. Mh... Also Pin3 ist es definitiv nicht 
:-)

Das was in Kapitel 8 zum Thema Reset steht, führt bei mir zu der 
Annahme, dass es für den Tiny eigentlich keinen programmierbaren 
Reset-Pin gibt, also auch keine angebbare Belegung dafür. Der external 
Reset scheidet bezüglich Programmierbarkeit aus, der POR findet 
automatisch beim Einschalten statt und der Brown-Out-Reset würde 
erfordern, dass die SubD-Pins 4 und 7 jeweils so programmiert werden 
können, dass am Ausgang des Spannungsreglers ein Pegel anliegt, der 
innerhalb des BrownOut-Triggerbereichs liegt. --> Nix mit 
programmierbarem Reset über den serbb.
Es dürfte aber möglich sein die Pins 4 und 7 programmtechnisch 
abzuschalten. Was dann einem programmierbaren POR entsprechen würde. 
Angeben lässt sich das aber im avrdude.conf nicht. Damit bleibt es bei 
der 9.


Was die Tilde anbelangt: im avrdude.conf gibt es auch die Schreibweise 
zB Reset != TXD. Eigentlich hatte ich diese Schreibweise als 
Schreibweise zur Signalinvertierung verstanden... Wenn nun aber avrdude 
diesen c-Code nicht versteht, gilt vielleicht "~" == "!=".

Was die Frequenz anbelangt, beschäftige ich mich jetzt also mit der 
i-Option :-)

Vielen Dank für Deine Geduld, was bedeutet eigentlich HTH ?

Sobald es Neuigkeiten gibt melde ich mich wieder, Ralf

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mh,

Die avrdude-Parameterliste ergänzt um 10 msec Verzugszeit, mit "-i 10" 
führt dazu, dass die Signatur gelesen werden kann. D.h. eigentlich 
sollte jetzt alles OK sein. Eigentlich....
Beim Hochladen von init.hex (1018 Bytes) überprüft avrdude dann 
freundlicherweise auch gleich, ob die Daten dort richtig ankamen, indem 
das Geschriebene zurückgelesen und mit der Quelle (init.hex) verglichen 
wird.

Dabei gibt es dann das nächste Problem: Bereits das erste geschriebene 
Byte stimmt nicht mit der Quelle überein:

avrdude: verifying
avrdude: verification error, first mismatch at byte 0x0000
         0x7f != 0x00
avrdude: verification error, content mismatch

Damit aber nicht genug: Vermutlich durch die -i 10 kommt noch folgende 
Meldung hinzu:

avrdude: safemode: lfuse changed! Was 82, and is now 0

Auf die Frage, ob ich das rückgängig machen will, antworte ich zur 
Sicherheit erstmal mit "yes".

Jetzt wieder etwas Rubberducking: Im Franzis-Lehrbuch steht auf Seite 
22:

"....blablabla... Das Lernpaket arbeitet mit dem 9,6MHz-Oszillator und 
dem Teiler, sodass der Prozessortakt 1,2 MHz beträgt...".

Das ist schön vom Lernprogramm, unter Windows funktioniert ja auch alles 
wunderbar (Init, RC-Oszi-Kalibrierung etc.). Die Frage ist nun, wie ist 
das avrdude-Kommando zu parametrieren, dass es den Tiny ebenfalls mit 
9,6MHz und dem Teiler 8 betreibt. Wenn das gelingt, sollte es eigentlich 
funktionieren.. sag ich jetzt mal so :-)

Also nochmal rein in "man avrdude"...

Hasta pronto, Rafa (Sende auch das Rubberducking WEIL so ->Möglichkeit 
Antworten zu bekommen und Beteiligung der "lernenden Community" am 
Lernprozess :-) Schliesslich geht es ja um ein Lernpaket.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>avrdude: safemode: lfuse changed! Was 82, and is now 0

>Auf die Frage, ob ich das rückgängig machen will, antworte ich zur
>Sicherheit erstmal mit "yes".

Zum Glück klappt das schreiben ja nicht. Fuses schreiben sollte man 
wirklich nur, wenn sichergestellt ist, daß alles, aber auch wirklich 
alles, problemlos funktioniert.

>Die Frage ist nun, wie ist
>das avrdude-Kommando zu parametrieren, dass es den Tiny ebenfalls mit
>9,6MHz und dem Teiler 8 betreibt.

avrdude betreibt überhaupt nix. Das versucht nur, Daten in den Prozessor 
zu schreiben. Die Frequenz, mit der der Prozessor läuft, wird weiterhin 
vom Experimentierboard bestimmt.

Oliver

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Oliver,

Danke für die Antwort.

Soweit bin ich mittlerweile aber auch :-) Deine Angabe entspricht 
nämlich dem, was im Datenblatt zum ATtiny steht (Kap. 6.2.4. zum Thema 
Default Clock Source). Per Default arbeitet der Tiny13 mit 9,6 MHz und 
dem Teiler 8, d.h. alles, was diesbezüglich für den Betrieb unter 
Windows gilt (Lernsoftware), gilt auch automatisch für den Betrieb mit 
dem avrdude.

Worin besteht dann der Unterschied ? Weshalb lässt sich der Tiny über 
das Winsdows-Lernprogramm problemlos die init.hex hochladen, jedoch 
nicht mit dem avrdude-Kommando unter Linux. Warum kann die Signatur erst 
verifiziert werden, wenn ich zusätzlich "-i 10" parametriere, also quasi 
erst an der Signal-Phasenverschiebung herumschraube, dann mit dieser 
Konfiguration aber keine Datenübertragung verifizieren kann ? Fragen 
über Fragen, leider hat mich Deine Antwort diesbezüglich nicht weiter 
gebracht.

Kommt da noch ein Nachschlag ? Wäre schön, danke im Voraus.. Ralf

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf K. schrieb:

> Worin besteht dann der Unterschied ?

Dazu müsstest du analysieren, was das Windows-Tool macht.  Die Quellen
von AVRDUDE gibt's zumindest. ;-)

> Weshalb lässt sich der Tiny über
> das Winsdows-Lernprogramm problemlos die init.hex hochladen, jedoch
> nicht mit dem avrdude-Kommando unter Linux.

Weil da noch irgendwas faul ist...

> Warum kann die Signatur erst
> verifiziert werden, wenn ich zusätzlich "-i 10" parametriere, also quasi
> erst an der Signal-Phasenverschiebung herumschraube,

Das ist keine "Phasenverschiebung", das ist schlicht und ergreifend
die SPI-Taktfrequenz.  Wenn deine CPU nur mit 1,2 MHz getaktet wird,
dann muss der SPI-Takt kleiner als 300 kHz sein (einschließlich
aller Toleranzen).  Selbst, wenn er 300,0001 kHz ist (oder die
Prozessorfrequenz [RC-Oszillator!] eben nur 1,1998 MHz), kracht
es irgendwann, weil das SPI-Sampling mal eine Flanke am SCK verpasst
zu erfassen.

Mit -i10 bist du auf der sicheren Seite (100 kHz SPI-Takt).

Die "10" da sind übrigens Mikrosekunden, keine Millisekunden.

> dann mit dieser
> Konfiguration aber keine Datenübertragung verifizieren kann ?

Das müsstest du jetzt deinen Programmierer fragen.  Wenn du -vvvv
(viermal ein "vau") als Optionen mit aufnimmst, kannst du das
komplette Herumwackeln der Bits mit verfolgen.

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Moderator,

natürlich Mikrosekunden... Vor lauter Wald .... :-)

Was Deine Erklärung zum Thema Phasenverschiebung anbelangt.... gut, das 
nannte ich deswegen so, weil im Datenblatt von delay-time die Rede 
war...

eigentlich geht es also darum: das Abtasttheorem muss eingehalten 
werden. D.h. die Abtastfrequenz muss mindestens das 2,5fache (wenn ich 
mich richtig an die MSRT-Vorlesung erinnere) der abzutastenden 
Signalfrequenz betragen. Geht es darum ? (nur zum Verständnis).

Leider habe ich keinen Programmierer den ich fragen könnte, ich arbeite 
mit Bit-Banging über ein ganz normales serielles Kabel. -vvvv kann ich 
natürlich dem avrdude mitgeben... und sehen was da so angezeigt wird.

Verstehe ich Dich richtig: Wenn es gelingt die Signatur zu verifizieren 
(durch Angabe von -i 10) ist das Thema SPI-Frequenz eigentlich als 
Fehlerquelle auszuschliessen und die Fehlersuche muss an anderer Stelle 
weitergehen ?

Wenn dem so ist: Wo soll ich denn nun weitersuchen ?

Zusammenfassung: Mittels Lernprogramm unter Windows gehts, mit avrdude 
eben nicht.

Danke fuer Deine Antwort(en) :-), Gruss aus Lu, Ralf

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf K. schrieb:

> eigentlich geht es also darum: das Abtasttheorem muss eingehalten
> werden. D.h. die Abtastfrequenz muss mindestens das 2,5fache (wenn ich
> mich richtig an die MSRT-Vorlesung erinnere) der abzutastenden
> Signalfrequenz betragen. Geht es darum ? (nur zum Verständnis).

In diesem Fall mehr als das 4fache.  Hängt mit der internen
Taktverarbeitung im AVR zusammen.  Ja, aber im Prinzip ist es
das Abtasttheorem.

> Verstehe ich Dich richtig: Wenn es gelingt die Signatur zu verifizieren
> (durch Angabe von -i 10) ist das Thema SPI-Frequenz eigentlich als
> Fehlerquelle auszuschliessen und die Fehlersuche muss an anderer Stelle
> weitergehen ?

Es ist nicht völlig auszuschließen (wenn du nur knapp über dem f/4
bist, braucht das bisschen Signatur möglicherweise noch nicht
genügend Taktflanken, als dass da wirklich bereits eine verschluckt
wird), aber zumindest ist es nicht mehr sehr wahrscheinlich.

Wie genau die Mikrosekundenzahl nach dem -i funktioniert, hängt
ein bisschen davon ab, wie gleichmäßig dein System belastet ist.
Unter Posix-artigen Systemen benutzt AVRDUDE hier eine Schätzung
für eine Verzögerungsschleife, die daraus ermittelt wird, dass am
Anfang eine volatile-Variable 100 ms lang herunter gezählt wird.
Von der Anzahl der durchlaufenen Schleifen wird dann geschlussfolgert,
wie viele Zählschritte man pro Mikrosekunde benötigt.  Wenn nun die
Systemlast während der Schleifenkalibrierung kurzzeitig höher war,
wird ggf. ein zu geringerer Wert ermittelt.

> Wenn dem so ist: Wo soll ich denn nun weitersuchen ?

Im -vvvv.  Such die Stelle, ab der die Kommunikation suspekt wird.

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stop: Bevor ich noch irgendeine Sekunde mit Fehlersuche zubringe, bitte 
ich den, ders weiß, um Antwort auf folgende Frage(n):

Es ist ständig von Programmern die Rede. Würde mir denn ein Wechsel vom 
Bitbanging zu einem Programmiergerät helfen ? D.h. hätte ich es dann 
einfacher Fehler zu lokalisieren, bzw wären dann eh weniger 
Fehlerquellen zu erwarten ? Wenn ja, welchen Programmer empfehlen denn 
die Profis, wenn ich damit sowohl den ATtiny13, als auch den ATmega328p 
betreiben will ? Preise ?
Bezugsquelle?

Bis zur Antwort versuche ich mich mit Abendessen und dann dem Erstellen 
und Senden einer Datei mit dem Inhalt des -vvvv- Ergebnisses. 
Gegenwärtig ist es so, dass auch die -i 10 nicht mehr hilft. 
Offensichtlich unterliegt das Brettchen irgendwelchen 
Temperatureinflüssen, die es mal ermöglichen die Signatur zu 
verifizieren und ein anderes Mal wieder nicht... :-(

Danke, Ralf

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf K. schrieb:

> Es ist ständig von Programmern die Rede. Würde mir denn ein Wechsel vom
> Bitbanging zu einem Programmiergerät helfen ?

Sehr wahrscheinlich, weil dann die ganzen Timing-Geschichten in
den Controller dieses Gerätchens verlager werden.

> Wenn ja, welchen Programmer empfehlen denn
> die Profis, wenn ich damit sowohl den ATtiny13, als auch den ATmega328p
> betreiben will ? Preise ?

AVRISPmkII, AVR Dragon.  Letzterer ist eine ziemliche eierlegende
Wollmilchsau, mit dem kannst du auch debuggen.

Dann noch diverse Low-Cost-Varianten davon bis hin zu Eigenbauten.

> Bezugsquelle?

Bspw. CSD Electronics, oder der Shop von Benedikt Sauter ("shop"-
Link hier links im Forum).

> Bis zur Antwort versuche ich mich mit Abendessen und dann dem Erstellen
> und Senden einer Datei mit dem Inhalt des -vvvv- Ergebnisses.

Bitte streich sie mal auf das Wesentliche zusammen.

> Gegenwärtig ist es so, dass auch die -i 10 nicht mehr hilft.

Du kannst testhalber den Wert nach -i auch größer machen.

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Würde mir denn ein Wechsel vom Bitbanging zu einem Programmiergerät
> helfen ?

Das wäre schon mal eine mögliche Fehlerquelle weniger ;-)

> D.h. hätte ich es dann einfacher Fehler zu lokalisieren, bzw wären dann
> eh weniger Fehlerquellen zu erwarten ?

Letzteres. Zumindest bei 'Fertiggeräten'.

> Wenn ja, welchen Programmer empfehlen denn die Profis, wenn ich damit
> sowohl den ATtiny13, als auch den ATmega328p betreiben will ? Preise ?
> Bezugsquelle?

Ich streiche mal 'Profi' und gebe meinen Senf dazu: Die gibts recht 
zahlreich. AVR ISP mk2 zu etwa EUR 40 (braucht u.U. ein Firmwareupdate, 
das nur von Windows aus eingespielt werde kann), STK500 zu etwa EUR 80 
(bringt eine ganze Experimentierplatine mit), AVR Dragon ab etwa EUR 50 
(etwas ESD-empfindlich sagt man, es ist zweckmäßig sich noch ein Gehäuse 
dazu zu basteln), das Jtagice mk2 gibts regulär für grob EUR 300 (kann 
dafür etwas mehr.. wers braucht) und es geht auch noch teurer.

Das sind alles Geräte von Atmel, die gibts in den üblichen(tm) Shops. 
Gibt auch noname-Alternativen (teils zweifelhafter Qualität), z.B. (aber 
nicht ausschließlich) in der Bucht. Und es gibt 
Open-Source-Alternativen, z.B. den USBprog [1] für knapp EUR 40 (der 
afaik auch unter Linux recht gut unterstützt wird).

Wenn ich mich nochmals entscheiden müsste (hierzuworkstation werkelt ein 
selbstgebratener STK500v2-kompatibler Klon ausgesprochen zuverlässig) 
würde ich zum USBprog greifen. Dazu ein kleines Steckbrett (hab ich für 
ein paar Euros fuffzich bekommen) und eine stabile Stromversorung (hier 
ein kleines Labornetzgerät, tut aber auch ein Festspannungsnetzteil, 
ggf. mit einem Spannungsregler dahinter).

So, </Senf> ;-)

> Offensichtlich unterliegt das Brettchen irgendwelchen
> Temperatureinflüssen, die es mal ermöglichen die Signatur zu
> verifizieren und ein anderes Mal wieder nicht... :-(

Könnte auch eine kalte Lötstelle sein. Oder zu lange Kabel. Oder 
Störungen auf selbigem. Vielleicht die Geschwindigkeit testweise noch 
weiter drosseln?

HTH

[1] http://www.embedded-projects.net/index.php?page_id=165

--
http://de.wikipedia.org/wiki/HTH

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg, g457,

das mit der kalten Lötstelle kann man ausschliessen, da ich letzte Woche 
extra zur Sicherheit noch ein zweites identisches Tiny-Brettchen 
geordert habe und die Probleme bei beiden Versionen (selbst gebraten und 
gekauft) die gleichen sind. Das Kabel ist immer gleich lang (Das 
Signaturverifizieren ging ja schonmal) und die Temperatur hier ist 
eigentlich ziemlich konstant. Die SPI-Taktfrequenz habe ich testweise 
auch schon gedrosselt. Ohne Erfolg.

Da es mir bisher immer nur gelang höchstens die Signatur zu 
verifizieren, ich aber offensichtlich (wie auch Oliver ähnlich anmerkte) 
noch nie irgendwas auf das Brettchen schreiben konnte (mit avrdude von 
Laptops-Com-Port aus), vermute ich jetzt langsam doch Probleme mit dem 
Com-Port des Laptops. Das Teil ist immerhin schon fast erwachsen (11 
Jahre alt).

Zu allem Übel gelingt es mir auch gerade nicht via

avrdude -Parameterliste- > datei

den Infostrom in eine Datei umzulenken um sie Euch zur Ansicht 
zuzusenden. Mit sämtlichen Linux-Standard-Kommandos gelingt das immer 
problemlos. Bei avrdude bleibt die Protokoll-Datei leer.

Heute ist nicht mein Tag...
Jetzt werde ich noch ein wenig versuchen eine Protokolldatei ins Rennen 
zu werfen und wenn das nicht geht, wird ein Programmierer geordert (auf 
dem Laptop ist nur die Kommandozeile installiert, also nix mit 
Screenshot usw). Alles Weitere dann, sobald das Teil hier ist.

Danke an Euch alle vorab und ggf. schönes WE (falls keine -vvvv-Datei 
mehr von mir kommt), Ralf

Autor: Sven K. (svenk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
avrdude -Parameterliste- > datei 2>&1

damit landet alles in der Datei.

Gruß Sven

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> avrdude -Parameterliste- > datei

da fehlt eine '2' (unmittelbar(!)) vor dem '>' (um stderr statt stdout 
umzuleiten), also
avrdude .. 2>datei

Was mir noch einfällt.. aber ich weiss es nicht genau.. es wäre denkbar, 
dass der avrdude die Reset-Leitung braucht (der Ablauf könnte etwa so 
aussehen: Reset, Signatur lesen, Reset, Flash schreiben, Reset, ..), 
dann käme er mit ohne selbiger natürlich aus dem Tritt.

Schließ die doch testweise mal an (aber an eine ausgehende Leitung an 
der Seriellen!), falls Du einen NPN und einen passenden Basiswiderstand 
zur Hand hast dann z.B. so wie in obigem siprog-Schaltplan angegeben.

HTH

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wieder mal die Ingrid:
Ich habs jetzt eben mal mit einer ähnlichen (lies: komplett anderen) 
Hardware nachgestellt: STK500v2-Nachbau von Tuxgraphics, tiny2313. Zum 
beobachten eine LED in den Reset-Pullup geklemmt und siehe da: 
Zwischendrin kommt tatsächlich ein Reset, und zwar beim 'chip erase' 
(gute Frage ob davor oder danach, so schnell sind meine Augen nicht und 
ein Speicherossi hab ich nicht zur Hand :-((( Wild drauflosvermutet 
würde ich vermuten danach weil beim 'chip erase' auch die lockbits 
zurückgesetzt werden.

Wenn ich hierzuworkstation den 'chip erase' weglasse (mit -D resprektive 
manuell davor ausgeführt hab mit -e, bei jenem blinkt die LED 
entsprechend), dann ist zumindest optisch kein weiterer Reset erkennbar.

-> Resetleitung anklemmen! (Ohne chip-erase lässt sichs nicht 
vernünftig(tm) flashen)

HTH

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
g457 schrieb:
> Was mir noch einfällt.. aber ich weiss es nicht genau.. es wäre denkbar,
> dass der avrdude die Reset-Leitung braucht (der Ablauf könnte etwa so
> aussehen: Reset, Signatur lesen, Reset, Flash schreiben, Reset, ..),
> dann käme er mit ohne selbiger natürlich aus dem Tritt.

Ja, klar, die /RESET-Leitung des AVR is immanenter Bestandteil des
ISP-Protokolls.  Sie wirkt gewissermaßen (zusammen mit der ISP-
Signatur) als "slave select" für den SPI-Slave, den der zu
programmierende AVR ja letztlich darstellt.

Autor: Ralf K. (elgitanito)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Freu,

also Ihr seid ja wirklich richtig nett :-) So als wäret Ihr gespannt wie 
es weiter geht, bzw als wolltet Ihr mich vor dem Sprung aus dem Fenster 
bewahren, lol :-)

Warum meine Einfachversion ohne 2, bzw 2>&1 nicht funktionierte... keine 
Ahnung. Egal. Wie heißt es doch so schön:

Wie man es macht... ist es verkehrt.

Aber kaum macht man es richtig.... oh wunder.... gehts :-)

Es ging dann mit avrdude -paramlist- > datei 2>&1 Mit g457's Vorschlag 
ging es nicht (also nur die 2 vor das Grösserzeichen) warum auch immer.
Der Nachteil an Svens Lösung: Man bekommt nicht mit, wann der Prozess 
fertig ist. D.h. es wird gar nichts mehr am Terminal ausgegeben. Aber 
das lässt sich bestimmt auch machen.

Also hier die ungekürzte -vvvv Datei. Ungekürzt deshalb, weil ich sowas 
heute zum ersten Mal sehe und nicht wirklich abschätzen kann, mit 
welcher Info Ihr was anfangen könnt und mit welcher nicht.

Viel Spass und Erfolg damit... was lange währt...

Grüsse und muchisimas Gracias, Rafa

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, aber wir (g457 und ich) haben uns gestern schon den Kopf zerbrochen, 
wie man bei der vorliegenden Schaltung einen Reset-Pin angibt. Beim 
Tiny13 gibt es den nicht, oder doch ?

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stoooop... Dass wir hier nichts durcheinander bringen: Gemäss 
Franzis-Lehrbuch-Anleitung habe ich die ganze Zeit, also während des 
Übetragens der init.hex, einen Kurzschluss zwischen Reset und GND. Also 
ganz ohne Reset mache ich es ja nicht...

Müsste das nicht reichen ? Beim Windows-Prog gehts ja auch so !!!!

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, eigenes Zitat von einem Ingrid-Posting :-)

> Zwischendrin kommt tatsächlich ein Reset, und zwar beim 'chip erase'
> (gute Frage ob davor oder danach, so schnell sind meine Augen nicht und
> ein Speicherossi hab ich nicht zur Hand :-((( Wild drauflosvermutet
> würde ich vermuten danach weil beim 'chip erase' auch die lockbits
> zurückgesetzt werden.

Wobei ich mich noch präzisieren muss: Es kommt nicht 'ein Reset', 
sondern der Chip ist mehr oder weniger 'im' Reset - nur zwischendurch 
eben nochmals erneut. Der Ablauf sieht hier etwa so aus (und ist bei 
einem tiny13 sicher nicht viel anders):
/RESET runterziehen (dann ist er 'im' Reset, das geschieht bei Dir mit 
der Drahtbrücke für dauerhaft), Signatur lesen, chip-erase auslösen, 
/RESET hoch- und wieder runternziehen (das ist 'ein' Reset, der 
funktioniert bei dir wegen der Drahtbrücke nicht), dann den Flash 
beschreiben, /RESET wieder hoch (bei Dir wäre das 'Drahbrücke 
abziehen').

Das mit den Umleitungen ('>', '2>', '2>&1', ..) ist immer so eine Sache, 
da kommt es nämlich auf die genaue Reihenfolge an (und die ist nicht 
unbedingt intuitiv). Aber Hauptsache es hat funktioniert :-) Die 
Interpretation des Outputs überlasse ich aber gerne anderen ;-)

Achja bevor ichs vergess: /RESET anschließen!

HTH

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi g457,

/Reset anschließen geht vorläufig nicht, dazu muss ich erst den 
Transistor und einen passenden Widerstand besorgen. Also frühestens 
Morgen, vorausgesetzt ich finde hier in der Nähe einen Laden, wo man 
sowas kaufen kann (statt Internet-Bestellung).

Dann wäre also zu erledigen:

Siprog-Schaltung hinsichtlich passendem Widerstand und Transistor 
durchsehen.
Verlötung auf irgendeinen freien Pin (vorzugsweise 9) legen. Alternativ 
gingen auch der Pin 1 und der Pin 6. Welcher davon wäre ja dann 
eigentlich egal, weil avrdude darüber informiert wird (*.conf) welcher 
Pin verwendet wird. Oder verstehe ich da wieder was falsch ?

Gruss, Rafa

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf K. schrieb:

> Warum meine Einfachversion ohne 2, bzw 2>&1 nicht funktionierte... keine
> Ahnung.

Weil AVRDUDE den Filedescriptor 1 (stdout) dafür reserviert, dass
man dort die gelesenen Daten ausgeben kann.  Das kann Sinn haben,
bspw. in:
avrdude ... -U lfuse:r:-:h -U hfuse:r:-:h

Damit würde man die Werte für lfuse und hfuse als hexadezimale
Zahlen (mit 0x) nach stdout ausgeben:
$ avrdude -p attiny84 -c jtag2isp -P usb -U lfuse:r:-:h -U hfuse:r:-:h > fuses.txt

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.16s

avrdude: Device signature = 0x1e930c
avrdude: reading lfuse memory:

Reading | ################################################## | 100% 0.05s

avrdude: writing output file "<stdout>"
avrdude: reading hfuse memory:

Reading | ################################################## | 100% 0.05s

avrdude: writing output file "<stdout>"

avrdude: safemode: Fuses OK

avrdude done.  Thank you.


Wenn man nun aber nicht an dem gesamten "Trallala" interessiert ist,
kann man nur die Ausgabedaten in eine Datei umlenken oder in eine
Pipe schreiben:
 avrdude -p attiny84 -c jtag2isp -P usb -U lfuse:r:-:h -U hfuse:r:-:h | cmp -s - fuses.txt; echo $?

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.15s

avrdude: Device signature = 0x1e930c
avrdude: reading lfuse memory:

Reading | ################################################## | 100% 0.05s

avrdude: writing output file "<stdout>"
avrdude: reading hfuse memory:

Reading | ################################################## | 100% 0.05s

avrdude: writing output file "<stdout>"

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

0

Hier wurde das Ergebnis gegen die Datei "fuses.txt" verglichen.
Das Ergebnis des Vergleichs ist der Rückkehrstatus von "cmp",
entweder 0 für "OK", oder 1 für "Unterschiedlich".

(Mittels -qq bekommt man AVRDUDE noch dazu, auch die Statusmeldungen
auf stderr nicht mehr auszugeben.)

> Also hier die ungekürzte -vvvv Datei.

Irgendwas ist bei dir schweinelangsam.  Dein Programmer benötigt
allein 22 Versuche, bis er endlich das Echo auf das "program
enable"-Kommando bekommt, das ist die Zeile:

bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 53 00 ]

Dass er anschließend beim Lesen nur Nullen liest, deutet auch auf
irgendein Problem mit der Hardware hin.  Wenn der Flash nicht
beschrieben worden wäre, würde er 0xFF zurück lesen.

Hier mal zum Vergleich die Ausgabe eines einfachen avrdude -vvvv mit
dem relativ verbreiteten "Ponyprog"-Adapter, der von der Bauart
ungefähr deinem Simpel-Adapter entspricht:
...
avrdude: Calibrating delay loop... calibrated to 328 cycles per us
bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 53 00 ]
avrdude: AVR device initialized and ready to accept instructions

Reading |                                                    | 0% 0.00sbitbang_cmd(): [ 30 00 00 00 ] [ 00 30 00 1E  
bitbang_cmd(): [ 30 00 01 00 ] [ 00 30 00 93 ]
Reading | #################                                  | 33% 0.00sbitbang_cmd(): [ 30 00 02 00 ] [ 00 30 00 0C ]
Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e930c
bitbang_cmd(): [ 50 00 00 00 ] [ 00 50 00 62 ]
avrdude: safemode read 1, lfuse value: 62
bitbang_cmd(): [ 50 00 00 00 ] [ 00 50 00 62 ]
avrdude: safemode read 2, lfuse value: 62
bitbang_cmd(): [ 50 00 00 00 ] [ 00 50 00 62 ]
avrdude: safemode read 3, lfuse value: 62
avrdude: safemode: lfuse reads as 62
bitbang_cmd(): [ 58 08 00 00 ] [ 00 58 08 DF ]
avrdude: safemode read 1, hfuse value: df
bitbang_cmd(): [ 58 08 00 00 ] [ 00 58 08 DF ]
avrdude: safemode read 2, hfuse value: df
bitbang_cmd(): [ 58 08 00 00 ] [ 00 58 08 DF ]
avrdude: safemode read 3, hfuse value: df
avrdude: safemode: hfuse reads as DF
bitbang_cmd(): [ 50 08 00 00 ] [ 00 50 08 FF ]
avrdude: safemode read 1, efuse value: ff
bitbang_cmd(): [ 50 08 00 00 ] [ 00 50 08 FF ]
avrdude: safemode read 2, efuse value: ff
bitbang_cmd(): [ 50 08 00 00 ] [ 00 50 08 FF ]
avrdude: safemode read 3, efuse value: ff
avrdude: safemode: efuse reads as FF
bitbang_cmd(): [ A0 01 FC 00 ] [ 00 A0 01 FF ]
bitbang_cmd(): [ A0 01 FD 00 ] [ 00 A0 01 FF ]
bitbang_cmd(): [ A0 01 FE 00 ] [ 00 A0 01 FF ]
bitbang_cmd(): [ A0 01 FF 00 ] [ 00 A0 01 FF ]

bitbang_cmd(): [ 50 00 00 00 ] [ 00 50 00 62 ]
avrdude: safemode read 1, lfuse value: 62
bitbang_cmd(): [ 50 00 00 00 ] [ 00 50 00 62 ]
avrdude: safemode read 2, lfuse value: 62
bitbang_cmd(): [ 50 00 00 00 ] [ 00 50 00 62 ]
avrdude: safemode read 3, lfuse value: 62
avrdude: safemode: lfuse reads as 62
bitbang_cmd(): [ 58 08 00 00 ] [ 00 58 08 DF ]
avrdude: safemode read 1, hfuse value: df
bitbang_cmd(): [ 58 08 00 00 ] [ 00 58 08 DF ]
avrdude: safemode read 2, hfuse value: df
bitbang_cmd(): [ 58 08 00 00 ] [ 00 58 08 DF ]
avrdude: safemode read 3, hfuse value: df
avrdude: safemode: hfuse reads as DF
bitbang_cmd(): [ 50 08 00 00 ] [ 00 50 08 FF ]
avrdude: safemode read 1, efuse value: ff
bitbang_cmd(): [ 50 08 00 00 ] [ 00 50 08 FF ]
avrdude: safemode read 2, efuse value: ff
bitbang_cmd(): [ 50 08 00 00 ] [ 00 50 08 FF ]
avrdude: safemode read 3, efuse value: ff
avrdude: safemode: efuse reads as FF
avrdude: safemode: Fuses OK

avrdude done.  Thank you.


Ich habe jetzt keine Flash-Datei angegeben, sodass der
Programmiervorgang nach dem "program enable" und dem Lesen der Fuses
sofort wieder beendet wird.  Gut zu sehen ist aber, dass bei mir das
"program enable" bereits im ersten Versuch funktioniert.

Entweder hat deine serielle Schnittstelle eine Problem, oder du hast
ein viel zu langes Kabeln angeschlossen.

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Siprog-Schaltung hinsichtlich passendem Widerstand und Transistor
> durchsehen.

Das ist ein 0815-NPN, hier [1] ein BC547. Basiswiderstand 10k, und 15k 
von B nach E. Falls Du im Geschäft keine bekommst, dann könntest Du auch 
die gute alte Grabbelkiste durchsuchen. Standard-NPN-Transistoren sind 
in so ziemlich in allen Altgeräten zu finden (abgesehen vielleicht von 
Mixer und Herdplatte..). Die Widerstände sind in der Größe ebenfalls 
nicht sonderlich kritisch.

> Verlötung auf irgendeinen freien Pin (vorzugsweise 9) legen. Alternativ
> gingen auch der Pin 1 und der Pin 6. Welcher davon wäre ja dann
> eigentlich egal [..]

Hauptsache die Richtung stimmt :-) Die Pins 9 (RI, ring indicator), 6 
(DSR, data set ready) und 1 (DCD, data carrier detect) gehen Richtung PC 
(also genau falsch).
Ich weiss nicht, welche Pins du noch frei hast, geeignet sein sollten 
die folgenden: 7 (RTS, request to send), 4 (DTR, data terminal ready) 
und 3 (TXD, transmit data).

Nur der Vollständigkeit halber zur Erinnerung: In der avrdude.conf ist 
die Logik am /RESET dann natürlich zu invertieren ('~3').

Und jetzt viel Spaß beim basteln!

[1] http://www.lancos.com/e2p/siprog_base.png

Autor: Heiko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf K. schrieb:
> Da es mir bisher immer nur gelang höchstens die Signatur zu
> verifizieren, ich aber offensichtlich (wie auch Oliver ähnlich anmerkte)
> noch nie irgendwas auf das Brettchen schreiben konnte (mit avrdude von
> Laptops-Com-Port aus), vermute ich jetzt langsam doch Probleme mit dem
> Com-Port des Laptops. Das Teil ist immerhin schon fast erwachsen (11
> Jahre alt).

Bei diesen Schaltungen, die die Betriebsspannung aus dem COM-Port 
beziehen, ist das nicht ganz unüblich. Besonders bei Laptops, die 
gelegentlich mal nicht die "normalen" +-12V ausgeben, sondern deutlich 
weniger (Details zu "normal" unter http://de.wikipedia.org/wiki/RS232)

Würde wohl auch zum Fehlerbild passen, denn beim Schreiben des 
FLASH-Speichers wird swiw mehr Strom verbraucht und es reagiert 
kritischer auf Schwankungen als das Lesen der Signatur. Und manchmal 
reicht es nichtmal für die Signatur...

Hast du ein Multimeter? Wenn ja, miss doch mal VCC nach während des 
Programmiervorgangs.

Schriebst du nicht, du hättest auf dem Desktop auch ein Linux, bzw. das 
Windows ohnehin nur in einer virtuellen Maschine, oder habe ich das 
falsch verstanden? Dann probier das Ganze doch mal auf dem Desktop.

Oder bau dir probehalber ein sp12: 
http://www.xs4all.nl/~sbolt/e-spider_prog.html damit habe ich wesentlich 
bessere Erfahrungen gemacht als du gerade mit deinem seriellen Teil. 
Oder schließ mal testweise 5V an den Kondensator hinter den beiden 
Dioden an.

Ich kann ansonsten auch das usbprog empfehlen, habe das in der Uni 
benutzen dürfen (für AVR und für Xilinx CPLDs) und will mir demnächst 
auch eins bauen, weil mein neuer Laptop nur noch USB hat.

MfG, Heiko

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf K. schrieb:


> Verlötung auf irgendeinen freien Pin (vorzugsweise 9) legen.

Die siprog- (alias Ponyprog-)Definition sieht so aus:
programmer
  id    = "siprog";
  desc  = "Lancos SI-Prog <http://www.lancos.com/siprogsch.html>";
  type  = serbb;
  reset = ~3;
  sck   = 7;
  mosi  = 4;
  miso  = 8;
;

Die Tilde vor der 3 besagt, dass das Signal negiert ist (durch den
Transistor).  Im Prinzip kannst du den Transistor wohl auch
weglassen, dann auch die Tilde weglassen.

Pin 9 ist der "ring indicator", das ist ein Eingang.  Pin 1 ist
"data carrier detect" und Pin 6 ist "data set ready", ebenfalls
beides Eingänge...

[Edith: dass du dir nur Eingänge ausgesucht hast, hatte schon
g457 vor mir festgestellt.]

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Heiko schrieb:

> Bei diesen Schaltungen, die die Betriebsspannung aus dem COM-Port
> beziehen, ist das nicht ganz unüblich.

Huch!  Die wollen wirklich die Betriebsspannung aus dem seriellen
Port gewinnen?  Das finde ich sehr gewagt, und AVRDUDE hat dafür
keine Vorkehrungen (d. h. es kann nicht gezielt die verbliebenen
Ausgänge auf +(5...12) V ziehen).  Sowas ist nur für den Parallel-
port eingebaut worden.

Dem Ziel-Controller sollte man also schon eine eigene Energiequelle
spendieren.

Da ich meinen "siprog"-Adapter ja nun gerade mal wieder in den
Fingern hatte, musste ich ihn auch mal fotografieren. ;-)

Beitrag "Re: Zeigt her Eure Kunstwerke !"

> Würde wohl auch zum Fehlerbild passen, denn beim Schreiben des
> FLASH-Speichers wird swiw mehr Strom verbraucht und es reagiert
> kritischer auf Schwankungen als das Lesen der Signatur.

Ja, die Schreibvorgänge werfen chipintern eine Ladungspumpe an, die
die Programmierspannung (12...15 V oder sowas) erzeugt.

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aaaaalso Ihr da,

nach Eueren Informationen sieht es also offensichtlich doch nach einem 
Port-Problem aus. Ein zu langes Kabel kann es nicht sein (wie gesagt 
unter Windows auf einem anderen Rechner mittels USB-RS232-Umsetzer 
funtkioniert es (und da ist die Gesamtlänge dann doppelt so lang)). Und 
das mit dem Reset wird so auch nicht gehen, da alle Pins, die in Frage 
kommen, bereits belegt sind.

Meine eingangs des Thread gestellte Frage ist ja damit auch beantwortet: 
Wie muss ich avrdude parametrieren, damit es geht. Und offensichtlich 
ist es so, dass man an der Parametrierung des avrdude nichts mehr 
verbessern kann und auch andere Varianten (zB im Terminal-Mode gezielt 
irgendwelche Korrekturwerte in den Prozessor schreiben) nicht zum Ziel 
führen würden.

Mein Linux-Desktop mit XP in Sun-VM hat nur USB-Anschlüsse.
Der Laptop hat 1 Com, 1 USB-1, kein Windows sondern nur Linux als 
Kommandozeile.

Bevor ich also den Lötkolben auspacke, sehe ich erst nach einer Lösung 
über USB. Und ich habe das USB-RS232-Umsetzer-Kabel. Für dieses muss man 
allerdings unter Windows einen Treiber installieren. Es handelt sich um 
ein PL-2303 von dem ich bisher nicht sagen kann ob es einen Treiber im 
Linux-Kernel hat, oder ob es da aus yast heraus etwas zu installieren 
gibt. Herstellermässig ist nicht von Linux die Rede :-(

Wenn das auch nicht geht, bleibt also nach Euerer Meinung noch die 
Möglichkeit eine Lösung über eine externe Spannungsquelle zu versuchen. 
Ein variabel einstellbares Netzteil wäre schon vorhanden. Vielleicht ist 
das sogar noch eher sinnvoll, als nach der USB-Lösung zu sehen.


Fest steht: Dank Euerer Hilfe habe ich sehr viel gelernt !! Als 
Maschinenbauer (Dipl. Ing.) habe ich von solchen Sachen nämlich 
eigentlich keine Ahnung. Bisher programmierte ich S7, Jetter, Jumo, 
Addidata usw. Also entweder fertige SPSen oder Einbauhardware mit 
Treibern (alles unter Windows, C und C++). Hier befinde ich mich also 
auf völligem Neuland und kam dank Eurer Geduld schon ziemlich weit. 
Eigentlich wollte ich doch nur ein "Bisschen Assembler lernen :-)"

Sobald es was Neues gibt melde ich mich die Tage nochmal. Also immer mal 
reinschauen :-)

Nochmal vielen Dank an g457, Jörg, Oliver, Sven, Heiko, Ingrid und Edith 
:-)

Grüsse aus LU, Gute Nacht, hasta luego, Ralf
Und zum Thema: Zeigt her Euere Kunstwerke :-)  :
http://www.myspace.com/artenuestro

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf K. schrieb:
> Es handelt sich um
> ein PL-2303 von dem ich bisher nicht sagen kann ob es einen Treiber im
> Linux-Kernel hat

Aber latürnich.  PL2303 ist mehr oder weniger ein Standard-Teil.

> Ein variabel einstellbares Netzteil wäre schon vorhanden. Vielleicht ist
> das sogar noch eher sinnvoll, als nach der USB-Lösung zu sehen.

Auf jeden Fall!  Also, die USB-Lösung ist langfristig sicher
sinnvoll, aber die bekommst du möglicherweise vor dem Wochenende
nicht mehr hin, die externe Versorgung dagegen schon.

Im Prinzip kann man möglicherweise auch AVRDUDE so umbauen, dass es
die Spannungsversorgung auf dem seriellen Port ermöglicht (parallel
gibt's das ja schon), aber da mag ich gerade keine Zeit investieren.

Autor: Heiko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf K. schrieb:
> Fest steht: Dank Euerer Hilfe habe ich sehr viel gelernt !! Als
> Maschinenbauer (Dipl. Ing.) habe ich von solchen Sachen nämlich
> eigentlich keine Ahnung.

Lass dich davon nicht ins Bockshorn jagen - mein Chef meinte heute zu 
mir (zum xten Mal): "Aber du bist schon Maschinenbauer, oder?".

Vielleicht klappts ja mit dem USB-Wandler, der könnte stabilere Pegel 
liefern als der Laptop selbst.

MfG, Heiko

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

Zwischenstand: Das Anschliessen einer externen Spannungsquelle hat die 
Situation am Lap nicht verbessert. (das musste ich natürlich gleich zum 
Frühstück ausprobieren... mein Weib schüttelt blos noch den Kopf :-)

Im nächsten Schritt werde ich nun auf dem Desktop unter Linux versuchen 
das Brettchen über den USB-Umsetzer in Betrieb zu nehmen....

Schönen Samstag :-)

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon wieder ich:

Damit das Thema irgendwie doch noch zu einem Abschluss kommt: 
(möglicherweise haben ja andere ähnliche Probleme und suchen hier nach 
Lösungen)

Hier meine Interpretation dessen, was ich die Tage mit dem ATtiny unter 
Windows mit der Lernsoftware und Linux mit avrdude erlebt habe, unter 
Berücksichtung dessen, was im Franzis-Lehrbuch in den Kapiteln 2.3 und 
9.3 zum Thema Oszillatorkalibrierung geschrieben steht:

Die Windows-Lernsoftware verfügt offensichtlich über eine Routine, die 
noch vor dem Initialisieren, bzw vor dem ersten Übertragen des 
Bootloaders, eine Feinabstimmung der Frequenzen vornimmt. Gemäss den 
Ausführungen in Kapitel 9.3 ist das ein relativ simpler Vorgang, der 
allerdings genau so (wie beschrieben) nur für den Tiny13 funktioniert. 
Die wesentlich allgemeiner gehaltene avrdude-Software verfügt nicht über 
diese Routine. D.h. nach meiner Ansicht ist die Lernsoftware auf den 
ATtiny13 extra angepasst worden.

Den Beweis dieser Annahme würde ich aus rein sportlichen Gründen gerne 
versuchen anzutreten, allerdings nur, wenn ich schon das könnte, was ich 
eigentlich durch das Betreiben des Lernpaketes erst noch lernen möchte, 
nämlich Assembler.

Dann würde ich avrdude zunächst im Terminalmode betreiben und gemäss den 
Angaben in 9.3 die entsprechenden Bytes zur Feinabstimmung übertragen 
und erst dann die gesamte Initialisierung durchführen.

Sollte sich jemand für die Inhalte der erwähnten Kapitel interessieren 
oder auch für den Schaltplan des Brettchens, so könnte ich die 
entsprechenden Seiten scannen und hier zum Herunterladen bereit stellen.

Sollte ich mit der Annahme Recht behalten, erwarte ich auch für den 
Betrieb mit avrdude vom Desktop aus über USB ähnliche Probleme wie ich 
sie mit dem Laptop hatte.

Grüße ans Forum, Ralf

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg,

oder soll ich Dich besser mit "Eure Hoheit oder so" ansprechen :-)

Lange Leitung Dünner Draht... eben habe ich im avrdude.conf-Kopf 
gelesen, dass Jörg Wunsch mindestens Mitautor der avrdude-Software 
ist...

Na, dann bin ich hier ja bestens aufgehoben.

Du schriebst:

> Auf jeden Fall!  Also, die USB-Lösung ist langfristig sicher
> sinnvoll, aber die bekommst du möglicherweise vor dem Wochenende
> nicht mehr hin, die externe Versorgung dagegen schon.

Also wie gesagt... externe Spannungsversorgung brachte keine 
Verbesserung. Jetzt versuche ich die USB-Lösung vom Linux-Desktop aus. 
D.h. avrdude ab Kommandozeile, über PL2303-Usb-Umsetzerkabel auf 
"RS232-Kabel" zum Com-Port des ATtiny13...

Natürlich geht das nicht so, wie ich mir das denke.... Warum weißt Du 
das offensichtlich schon vor mir ? :-)

Vorarbeiten:

Mit genau dieser Hardwarekonfiguration (Kabellänge ~1,5m) funktioniert 
alles prima vom Franzis-Lernprogramm (AVR-Studio?) aus meiner 
VirtualBox-XP-Installation heraus (wie gehabt) (nach Treiberinstallation 
für den PL-2303).

RES-GND ist zum Initialisieren überbrückt

Der PL-2303 ist meiner Yast-Hardware-Verwaltung bekannt. Hier muß ich 
also gar nichts machen (wie Du ja auch schon angedeuted hast). Oder doch 
?

So sieht der avrdude-Aufruf aus:
avrdude -p t13 -P /dev/ttyUSB0 -c rafaprog -i 10 -U flash:w:/home/rafa/bin/init.hex:i

Und so der Programmer-Eintrag "rafaprog" aus der /etc/avrdude.conf
#etwas Kommentar:
# 4/DTR -> PB0/MOSI
# 8/CTS -> PB1/MISO
# 3/TXD -> PB2/SCK
# Einen programmierbaren Reset gibt es nicht, der Pin-9 ist nicht belegt und fungiert als Phantomangabe
programmer
  id    = "rafaprog";
  desc  = "design rafa, serial-bitbanging";
  type  = serbb;
  reset = 9;
  sck   = 3;
  mosi  = 4;
  miso  = 8;
;

und so das Ergebnis des Befehlsaufrufes :-(
avrdude: AVR device not responding
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.
avrdude done.  Thank you.

Dabei denke ich folgendermaßen (und mit Sicherheit falsch): 
Angeschlossen ist das Gerät über den Umsetzer an USB0, also gebe ich 
auch diese Schnittstelle an. Als Ziel habe ich aber den RS232-Port des 
ATtiny, weshalb ich auch hier den selben Programmierer "rafaprog" in 
avrdude.conf verwende, wie bei den Laptop-Versuchen.

Was ich natürlich erwartet hatte, war wenigstens das, was auch bei den 
Laptopversuchen heraus kam, d.h. einen wenigstens ab und zu 
funktionierenden Signaturcheck. Offensichtlich bekomme ich aber gar 
keine Kommunikation zu Stande, weil da bei mir wohl ein nicht 
unerheblicher Wissensmangel hinsichtlich der USB/RS232-Nutzung besteht.

Nun die Fragen:

-Worin besteht mein Denkfehler ?
-Weshalb meintest Du, das mit dem Umsetzer sei vor dem Wochenende nicht 
mehr hinzubekommen ?
-Welchen nächsten Schritt schlägst Du vor ?

Vielen Dank vorab und einen schönen Sonntag, Grüsse aus LU, Ralf

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich hab mir gerade die Schaltung des Lernpakets
angesehen. Die bezieht aus RTS (7) bzw. DTR (4) ihre
Betriebsspannung. Wenn man jetzt DTR als MOSI verwendet,
sollte sichergestellt sein, dass RTS die Spannung liefert.
Vielleicht muss man das noch avrdude mitteilen.
Oder einfach extern versorgen und den Spannungsregler auslöten.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
> enn man jetzt DTR als MOSI verwendet,
> sollte sichergestellt sein, dass RTS die Spannung liefert.
> Vielleicht muss man das noch avrdude mitteilen.

Wie schon weiter oben geschrieben, dafür hat AVRDUDE bei den seriellen
Bitbang-Adaptern einfach keinerlei Vorkehrungen.  (Bei den parallelen
gibt es sowas.)  Die Funktion einer derartigen Mimik ist ohnehin sehr
zweifelhaft, da meiner Erinnerung nach bei RS-232 nur sowas wie 1 mA
als Stromergiebigkeit gefordert wird.  Gut, für einen ATtiny13 mit
1 MHz wäre das gerade so mit minimaler Reserve ausreichend, für mehr
reicht es aber nicht.

Soll nicht heißen, dass man derartiges nicht auch noch ins AVRDUDE
rein bekäme (man könnte bei der Parallelport-Implementierung Anleihe
nehmen), aber die Frage ist, ob sich derartiger Aufwand wirklich
lohnt.  Dieses Franzis-Paket ist der erste (und möglicherweise einzige)
Fall, bei dem mir derartiges bislang untergekommen ist.

Ich blicke beim Pinout des ganzen Teils gerade nicht durch und
verstehe nicht mehr, welches Pin eigentlich auf welchen Pegel gezogen
werden soll.  Im Prinzip kann man das auch als Einzelfalllösung so
machen, dass Ralf sich eine lokal gehackte Version von AVRDUDE baut,
die den Pin passend einstellt.  Wenn mir jemand hier aufschreibt, was
genau geändert werden muss, kann ich einen entsprechenden Patch
liefern.

Autor: Ralf K. (elgitanito)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Markus, hallo Joerg,

mittlerweile habe ich das Lernpaket genutzt um etwas Assembler zu lernen 
und verstehe jetzt so auch etwas mehr von der RS232-Kommunikation. Im 
Lernpaket enthalten sind u.a. auch drei Programm zum Studieren der 
RS232-Übertragungsstrategie (wie sie für das Lernpaket bzw die 
WinSoftware-LPmikro realisiert wurde).

Nun ist es ja so, dass es auf dem Tiny-Brettchen keinen Hardware-UART 
gibt und deshalb die gesamte Kommunikation zwischen Tiny und PC auf der 
Tiny-Seite durch die Software emuliert wird. Wenn man sich die 
Lehr-Programme zum Thema RS232 diesbezüglich ansieht, erkennt man 
vielleicht wo der Hase im Pfeffer liegt: Die Delay-Anweisungen, sowie 
die nach meinem Geschmack "willkürlich scheinenden" nop-Anweisungen 
(siehe RS232_Autobaud), lassen darauf schliuessen, dass bei der 
Entwicklung der LPmikro-Kommunikation das Speicheroszi das wichtigste 
Hilfsmittel war. D.h. hier wurde eine sehr spezifische Feinabstimmung 
implementiert, damit die Programme sich problemlos im Bit-Banging-Modus 
betreiben lassen.
Nun vermute ich, dass die RS232-Kommunikation innerhalb des 
Lernprogramms LPmikro ebenfalls derartige "Tricks" enthält, damit die 
Kommunikation ohne externe Spannungsversorgung und ohne speziellen 
Programmer funktioniert.

Leider gibt es den Source-Code des LPmikro nicht zur öffentlichen 
Verfügung, sonst könnte man sich hier Gewissheit versachaffen. Aber wozu 
? Dieser Thread hier entstand ja eigentlich nur aufgrund meiner 
Dickköpfigkeit :-) Ich wollte halt unbedingt eine Lösung unabhängig von 
Windows und unabhängig von weiter anzuschaffender Hardware haben.

Da es mit dem AVR ISP mkII problemlos unter Linux mit avrdude 
funktioniert, sollten wir uns mit dem Bit-Banging hier nicht weiter 
beschäftigen.
Das Umprogrammieren des Avrdude hatte ich als Lösung für mich auch schon 
in Betracht gezogen, allerdings müsste ich dann auch noch Java lernen... 
und das passt mir gerade überhaupt nicht in den Kram. Ausserdem habe ich 
(noch) kein Speicheroszi. Und ohne Oszi dürfte es sehr schwierig werden 
die "Tricks" auch in avrdude zu implementieren.

Hat jemand ein gebrauchtes Speicheroszi zu günstigen Konditionen 
anzubieten ?

Danke für Euere Antworten !

ich wünsche allen einen schönen und friedlichen Frühling !

Gruss, Ralf

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf K. schrieb:
> Da es mit dem AVR ISP mkII problemlos unter Linux mit avrdude
> funktioniert, sollten wir uns mit dem Bit-Banging hier nicht weiter
> beschäftigen.

OK.

> Das Umprogrammieren des Avrdude hatte ich als Lösung für mich auch schon
> in Betracht gezogen, allerdings müsste ich dann auch noch Java lernen...

Ich wüsste nicht, wofür.  Ich kann es auch nicht. ;-)  (Habe mal
entfernt was drüber gehört und es bis zu einem "Hello world" gebracht,
aber nicht weiter.)

> Ausserdem habe ich
> (noch) kein Speicheroszi. Und ohne Oszi dürfte es sehr schwierig werden
> die "Tricks" auch in avrdude zu implementieren.

Die reine Spannungsversorgung kann man möglicherweise mit einem
Voltmeter ausklingeln.

> Hat jemand ein gebrauchtes Speicheroszi zu günstigen Konditionen
> anzubieten ?

Nicht mehr, mein letztes habe ich für kleines Geld einem Studenten hier
verkauft.  Das fiel aber für mich persönlich ausdrücklich unter
"Nachwuchsförderung" ;-), sonst hätte ich es teurer verkauft.

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Joerg,

demnach ist avrdude nicht in Java programmiert ? Wie komme ich dann auf 
die Idee ? Ich glaube irgendwann irgendwie irgendwo gelesen zu haben, 
avrdude sei in Java erstellt worden. So entstehen Gerüchte :-)

Wenn also nicht in Java, in was dann ? C ? C++ ? Basic ? Pascal, 
Fortran? Wenn in C/C++, würde ich mir vielleicht des Lernens wegen die 
eine oder andere Routine ganz gerne mal anschauen. Äääähhm... aber 
Open-Source ist es schon.. ? Oder etwa auch nicht ?

Gruss, Ralf

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C und Opensource.  C++ wäre vielleicht aus heutiger Sicht besser
gewesen.

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Joerg,

nun bin ich nicht nur dickköpfig, sondern auch noch neugierig:-)

Und von der Neugierde getrieben stöberte ich ein wenig in den 
Source-Files von avrdude, mit dem Ziel DIE Stelle zu finden, an der ich 
für die Kommunikation mit dem Brettchen einzelne Leitungen ein- bzw 
ausschalten kann. In der Datei bitbang.c wurde ich fast fündig: Da gibt 
es die Funktion setpin(). Die Suche nach dem Code für diese Funktion 
endete allerdings erfolglos.

Mit:

 find /usr/src/debug/avrdude-5.10 -type f -exec grep -n ' setpin(' {} 
/dev/null \;

kann ich zumindest innerhalb des avrdude-5.10 - Verzeichnisses keine 
Datei mit der Definition von setpin() finden.
Ähnlich erging es mir mit der Funktion usb_control_msg().

Jetzt zwei Fragen:

1-Gibt es irgendwo eine Erklärung des gesamten Programmgerüstes des 
avrdude-Projektes, bzw dessen Struktur ? Das wäre praktisch, da es doch 
insgesamt ziemlich viel Code ist und man schnell den Überblick verliert 
bei dem Versuch den roten Faden zu finden.

2-Wo befinden sich die Definitionen der Funktionen, die ich im 
Stammverzeichnis nicht finden kann. Also wo ist der Code von zB setpin 
zu finden ? Was mich wundert ist, daß ich nicht einmal in irgendeiner 
h-Datei einen Verweis auf diese Funktion finden kann.


Gruss und vorab Danke, Ralf

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,
ich habe die Lösung:
ich habe die avrdude.conf um folgendes ergänzt:
programmer
  id    = "franzis";
  desc  = "serial port banging, reset=!rts sck=txd mosi=dtr miso=cts";
  type  = serbb;
  reset = ~7;
  sck   = 3;
  mosi  = 4;
  miso  = 8;
;
Es wird nun so getan, als ob die RTS-Leitung Reset ist,
das ganze negiert.
die wird dann auf + gezogen, was zur Spannungsversorgung ausreicht.
Probiert unter WindowsXP auf com1 mit
avrdude 5.6 und der Oberfläche avrdude-gui 1.0.5
Unter Linux muss ich erst noch probieren ;-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf K. schrieb:

> Mit:
>
>  find /usr/src/debug/avrdude-5.10 -type f -exec grep -n ' setpin(' {}
> /dev/null \;
>
> kann ich zumindest innerhalb des avrdude-5.10 - Verzeichnisses keine
> Datei mit der Definition von setpin() finden.

Dein Fehler ist das Leerzeichen.

setpin() ist gewissermaßen eine Methode des jeweiligen programmers.
Auch, wenn das kein C++ ist, so stecken da einige OO-Ansätze drin.
bitbang.c wiederum ist nur eine Zwischenschicht, die die gemeinsamen
Methoden aller bitbang-Adapter abstrahiert.  Darunter liegen dann die
Implementierungen serbb_posix.c (serial bitbangers, Posix-style OS),
serbb_win32.c (serial bitbangers, Win32 OS), par.c (parallel
bitbangers, FreeBSD/Linux/Solaris, diese werden über freebsd_ppi.h,
linux_ppdev.h und solaris_ecpp.h abstrahiert) und ppiwin.c (parallel
bitbangers, Win32 OS).  MacOS X kennt wohl keine physischen seriellen
und parallelen Ports und wird daher hier nicht bedient.

Jeder von diesen implementiert seine setpin-Methode, z. B.
par_setpin() in par.c.

> Ähnlich erging es mir mit der Funktion usb_control_msg().

Die gehört zur libusb, auf der AVRDUDE aufsetzt (sofern direkter
USB-Support benötigt wird, ist ja bei dir nicht der Fall).

> 1-Gibt es irgendwo eine Erklärung des gesamten Programmgerüstes des
> avrdude-Projektes, bzw dessen Struktur ?

Leider nicht.  "Historisch gewachsen", sage ich da nur. ;-)


Schön, dass du einen Weg gefunden hast!

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Joerg, (und Markus weiter unten)

am Leerzeichen liegt es nicht, denn ich habe die Suche auch ohne das 
Leerzeichen laufen lassen, also mit

find /usr/src/debug/avrdude-5.10 -type f -exec grep -n 'setpin(' {} 
/dev/null \;

die Version mit Leerzeichen war nur der letzte meiner 3 Versuche und hat 
sich deshalb hier eingeschlichen :-)

Mit dieser Zeile finde ich auch die von Dir genannten Funktionen:

par_setpin...
serbb_setpin... aber eben nicht die setpin( ohne Vorsatz.

>Die gehört zur libusb, auf der AVRDUDE aufsetzt (sofern direkter
>USB-Support benötigt wird, ist ja bei dir nicht der Fall).

soetwas hatte ich auch vermutet, allerdings hätte ich dann einen Verweis 
auf diese Funktion in einer header-Datei erwartet. Woher soll der Linker 
sonst wissen, daß er die libusb einbeziehen soll ?


Hallo Markus:

Wenn Du Dir den Thread nochmal durchsiehst, wirst Du finden, dass ich es 
auch schon einmal mit genau dieser avrdude.conf-Version versucht habe, 
also mit

programmer
  id    = "rafaprog";
  desc  = "design rafa, serial-bitbanging";
  type  = serbb;
  reset = ~7;
  sck   = 3;
  mosi  = 4;
  miso  = 8;

Leider hat es aber nicht so funktioniert, also unter Linux ab 
Kommandozeile mit avrdude. Sollte es so bei Dir zum Ergebnis führen, 
würde ich natürlich schon gerne wissen warum:-)

Gruss, Ralf

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf K. schrieb:

> Mit dieser Zeile finde ich auch die von Dir genannten Funktionen:
>
> par_setpin...
> serbb_setpin... aber eben nicht die setpin( ohne Vorsatz.

Weil das eine Methode ist.  Guck einfach mal in eine der genannten
Dateien ganz nach unten, da siehst du, wie die Methoden des jeweiligen
programmer-Objekts initialisiert werden.

>>Die gehört zur libusb, auf der AVRDUDE aufsetzt (sofern direkter
>>USB-Support benötigt wird, ist ja bei dir nicht der Fall).

> soetwas hatte ich auch vermutet, allerdings hätte ich dann einen Verweis
> auf diese Funktion in einer header-Datei erwartet.

#include <usb.h>

Die Headerdatei wird irgendwie im System installiert, die ist nicht
Bestandteil von avrdude.  Der configure-Script erkennt dabei selbst-
ständig, ob eine libusb im System gefunden werden kann.  (Ggf. muss
man ihm dabei helfen, indem man CPPFLAGS mit der passenden -I-Option
und LDFLAGS mit der passenden -L-Option im Environment setzt, falls
sie nicht im Standardsuchpfad von Compiler und Linker installiert
ist.)

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Joerg,

bevor ich Dir weiterhin Deine Zeit stehle, schaue ich mir jetzt erst 
einmal einige Basics an, zB hier:

http://www.linux-fuer-alle.de/doc_show.php?docid=178

Zwar dachte ich, ich würde viel von C verstehen, schliesslich habe ich 
jahrelang ganz gut Geld damit verdient, aber unter Linux sieht das 
irgendwie alles etwas anders aus, als ich es von meiner Arbeit unter 
Windows gewohnt bin... So wie es aussieht, braucht es keinen Leitfaden 
für die avrdude-Struktur, sondern einen Leitfaden, wie die 
Programmierstrukturen unter Linux generell funktionieren (Bibliotheken, 
Header-Files, Gerätetreiber usw.). Wo steht was im System, was ist schon 
vorhanden, bzw wo bekommt man es her, was muss selbst erledigt werden 
usw, usw ?. Also erstmal die Basics studieren...

Als erfahrener Entwickler, der Du ja bist: Hast Du vielleicht den einen 
oder anderen sinnvollen Literaturtip oder Web-Tip ?. Mittelfristig plane 
ich Anwendungen unter Linux zu entwickeln, wobei diese Anwendungen 
natürlich auch zB über USB mit verschiedenen Hardwarekomponenten 
kommunizieren können sollen. ZB über USB zum Arduino oder dem 
Tiny-Brettchen, Soundkarte, Grafik, Drucker.. was es halt so braucht).
Mir fehlt ein guter Guide, also eine Anleitung für den roten Faden. 
Unter Linux geschieht es doch relativ schnell, daß man vor lauter Wald 
schnell keine Bäume mehr erkennt...


Bis demnächst und Danke !!

Gruss, Ralf

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf K. schrieb:

> So wie es aussieht, braucht es keinen Leitfaden
> für die avrdude-Struktur,

Naja, die ist auch nicht gerade aufgeräumt und sonderlich geradlinig.
Besonders krass wird das, wenn du dort in die Verzahnung von STK500v2-
und JTAG ICE mkII-Programmer reinfasst.  Das liegt daran, dass diese
Teile firmwaremäßig auch gegenseitig Clones enthalten (das JTAG ICE
mkII und der AVR Dragon enthalten intern den ISP-Modul vom AVRISPmkII,
sprechen aber das etwas aufwändigere Protokoll des JTAG ICE auf der
Schnittstelle, während der STK600 das einfachere Protokoll des
AVRISPmkII spricht, aber intern die JTAG-Routinen des JTAG ICE mkII
integriert hat -- irgendwasn kriegste da einen Knoten im Gehirn ;-).

> sondern einen Leitfaden, wie die Programmierstrukturen unter Linux
> generell funktionieren (Bibliotheken, Header-Files, Gerätetreiber
> usw.).

Wobei AVRDUDE zwar auf FreeBSD und später Linux aufgewachsen ist, aber
natürlich seit langem auch eine native win32 app ist.  Ein großer Teil
der Abstraktion und der Tests, was im jeweiligen System an
Möglichkeiten existieren, wird dabei von autoconf/automake erledigt,
also all dem, was am Ende im configure-Script (und den diversen
Makefile.in-Dateien) mündet.

> Als erfahrener Entwickler, der Du ja bist: Hast Du vielleicht den
> einen oder anderen sinnvollen Literaturtip oder Web-Tip ?

Leider nicht.  Erstens bin ich im Linux auch nicht allzu sehr zu Hause
(ich bin mit FreeBSD aufgewachsen und benutze es nach wie vor privat,
während ich in der Firma vor einem Linux sitze), außerdem habe ich das
im Laufe der Jahre mehr oder weniger im Selbststudium erlernt zu
Zeiten, als es noch kein Internet gab.  Kurzes Gugeln brachte mir noch
das hier zu Tage:

http://www.cs.cf.ac.uk/Dave/C/CE.html

Das scheint mir die Grundlagen ganz gut zu beschreiben.

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallole,

dieser Link hat mir schon etwas geholfen, merci.
So langsam kommt Licht ins Dunkel. Leider kann man dieses Tutorium nicht 
downloaden (Geht nur für eingeschriebene Studenten die ein Passwort 
haben).

Learning by doing kenne ich nur zu gut. In meiner C-Zeit unter Windows 
(von 1994-2001) musste ich ebenfalls ohne Google auskommen und habe mir 
damals auch alles (c, c++, Windowsprogrammierung) per Selbststudium 
angeeignet (natürlich mit Hilfe entsprechender Fachliteratur.

Das avrdude-Projekt (im Prinzip eine eierlegende Wollmilchsau :-)) ist 
wahrscheinlich aufgrund seiner Komplexität weniger dafür prädestiniert 
als Studienobjekt verwendet zu werden.

Am Besten wird es sein, das eine oder andere Projekt von unten her 
selbst zu entwickeln und so das nötige Rüstzeug für grössere Aufgaben zu 
bekommen. Zum Glück muss ich ja nicht bei Null anfangen :-)

Schönes WE, und Gruss, Ralf

Autor: Ralf K. (elgitanito)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachschlag

eine sehr hilfreiche Seite, um mehr Licht ins Dunkel zu bringen 
(bezüglich Programmierung unter Linux) ist:

http://ibiblio.org/pub/linux/docs/

Hier gibt es nahezu für jedes Problem ein ausführliches How-To. Sehr gut 
erklärt und i.d.r. mit ausführlichen Beispielen.

Sogar eine sehr ausführliche Abhandlung zum Thema 
AVR-Controller-Programmierung unter Linux gibt es da :-)

Die beste Hilfeseite zum Thema Linuxprogrammierung, die ich seit langem 
gefunden habe !

In der Hoffnung, dass es auch anderen gefällt und weiter hilft.

Gruesse ans Forum, Rafa

Autor: Physiker (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Habe auch das Franzis Lernpaket und gleich mehrere attiny 13. Bisher 
habe ich immmer mit der mitgelieferten Software programmiert, 
funktioniert bei mir auch unter Linux (Ubuntu Karmic) mit Wine. Da ich 
einen USB seriell Adapter verwende (Conrad), braucht schon das Lernpaket 
ewig, um den Bootloader in den tiny zu übertragen. Irgendwo, wohl hier 
im Forum, habe gelesen, dass man den avrdude verlangsamen kann.

Um unabhängig zu werden, wollte ich dann doch mal den avrdude 
ausprobieren. Irgendwann will man dann doch mal seine eigene Schaltung 
programmieren...

Dafür würde die avrdude.conf so wie bei Markus ergänzt:

programmer
  id    = "franzis";
  desc  = "serial port banging, reset=!rts sck=txd mosi=dtr miso=cts";
  type  = serbb;
  reset = ~7;
  sck   = 3;
  mosi  = 4;
  miso  = 8;
;

Wichtig scheint mir reset wirklich invertiert auf Pin 7 zu legen, um das 
kleine Board über den Spannungsregler LP2950 zu versorgen. Ich hatte 
zuerst vergessen die Steckbrücke für das Reset per Hand zu setzen und 
das Blinkprogramm, das noch im tiny war, lief während avrdude ohne 
Erfolg versuchte zu programmieren. Danach war ich allerdings sicher, das 
der tiny Strom bekam.

Danach dann nochmal mit Steckbrücke anderes(!) Blinkprogramm auf den 
tiny laden.
Ich habe verschiedene delays ausprobiert und war bei 1000 Mikrosekunden 
erfolgreich.
Mein Aufruf sieht dann so aus:

avrdude -p t13 -P /dev/ttyUSB0 -c franzis -U flash:w:blink2.hex:i -i 
1000 -v

Die Ausgabe ist angehängt.

Für die Stromversorgung gibt es ein kleines Python Programm:

import serial


ser = serial.Serial("/dev/ttyUSB0",2400,bytesize=serial.EIGHTBITS, 
parity=serial.PARITY_NONE,stopbits=serial.STOPBITS_ONE,timeout=5,xonxoff 
=0,rtscts=0)  # open first serial port

used_port = ser.portstr       # check which port was really used
print used_port

ser.setRTS(True)

ser.setDTR(True)

while 1:
    pass

Das Ausschalten geht natürlich durch ein analoges Python Programm.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.