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)
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]
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
> 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
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
> 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!
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..
1
programmer
2
id = "franzislp";
3
desc = "Franzis Lernpaket Mikrocontroller";
4
type = serbb;
5
# reset = ~3;
6
sck = 3;
7
mosi = 4;
8
miso = 8;
9
;
..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
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
> 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?family_id=607
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
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
> 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
> 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.
>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
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.
> 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
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
da fehlt eine '2' (unmittelbar(!)) vor dem '>' (um stderr statt stdout
umzuleiten), also
1
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
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
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 !!!!
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
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:
1
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:
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:
1
...
2
avrdude: Calibrating delay loop... calibrated to 328 cycles per us
3
bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 53 00 ]
4
avrdude: AVR device initialized and ready to accept instructions
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.
> 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
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
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.
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
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:
Und so der Programmer-Eintrag "rafaprog" aus der /etc/avrdude.conf
1
#etwas Kommentar:
2
# 4/DTR -> PB0/MOSI
3
# 8/CTS -> PB1/MISO
4
# 3/TXD -> PB2/SCK
5
# Einen programmierbaren Reset gibt es nicht, der Pin-9 ist nicht belegt und fungiert als Phantomangabe
6
programmer
7
id = "rafaprog";
8
desc = "design rafa, serial-bitbanging";
9
type = serbb;
10
reset = 9;
11
sck = 3;
12
mosi = 4;
13
miso = 8;
14
;
und so das Ergebnis des Befehlsaufrufes :-(
1
avrdude: AVR device not responding
2
avrdude: initialization failed, rc=-1
3
Double check connections and try again, or use -F to override
4
this check.
5
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
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.
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
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
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 ;-)
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
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.
Thread beobachten
Seitenaufteilung abschalten