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)

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

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

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

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

> 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

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.

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

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.

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

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.

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

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.

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

avrdude -Parameterliste- > datei 2>&1

damit landet alles in der Datei.

Gruß Sven

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.

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

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 ?

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 !!!!

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

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.

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.]

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.

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

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.

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 :-)

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

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

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.

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

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.

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

C und Opensource.  C++ wäre vielleicht aus heutiger Sicht besser
gewesen.

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

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!

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

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.)

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

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.

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

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