Jetzt hätt' ich auch mal 'ne kurze Frage ;-)
Ich versuche gerade, USBAVR-ISP aus
http://www.ullihome.de/index.php/USBAVR-ISP/de
unter Linux zu benutzen, und zwar zusammen mit dem AVRDUDE. Bis jetzt
funktioniert das bei mir so gut wie nicht, aber ich bin voller
Optimimus, dass sich das bald ändern könnte :-)
Erst mal Lob und Dank an die Entwickler von AVRDUDE, den ich seit
längerem erfolgreich mit meinem Parallelportdapter benutze, und
USBAVR-ISP der diesen aus der Mode gekommenen Adpater nun ersetzen
soll. Jörg und Christian sind hier im Forum ja häufig anzutreffen.
(Ich hoffe insgeheim ein wenig, dass genau diese beiden mein
Monster-Posting lesen werden. ;-) )
Vielleicht liegt's nur an meiner eigenen Dummheit (dann geht's ganz
kurz), deswegen zwei Fragen vorweg:
- Hat jemand schon mal die Kombination USBAVR-ISP + AVRDUDE + Linux
gebändigt? Dem folgenden Thread
Beitrag "USB AVR ISP"
nach zu schließen, geht USBAVR-ISP + AVRDUDE wohl generell noch
nicht, auch nicht mit Windows, nur dass die Fensterer nicht ganz so
sehr auf den AVRDUDE angeweisen sind.
- Gibt es unter Linux eine andere Programmer-Software, die mit
USBAVR-ISP funktioniert? Ich kenne nur noch UISP (der seit 2,5
Jahren nicht mehr gepflegt zu werden scheint) und Ponyprog. Von
keinem habe ich im Netz poitive Erfahrungsberichte mit USBAVR-ISP
gefunden.
Falls ihr eine der beiden Fragen mit Ja beantworten könnt, hat sich
alles erledigt, und ihr braucht nicht weiter zu lesen. Wenn nicht:
Ich habe mich in meiner Naivität hingesetzt und wollte einfach mal
schnell einen Tiny45 programmieren. Folgende Schritte habe ich
unternommen:
- Programmer-Board an den PC angeschlossen
Ergebnis: Das Board wird tatsächlich als ACM-Device erkannt, und es
erscheint ein /dev/ttyACM0
- AVRDUDE 5.4 aufgerufen mit
avrdude -p attiny45 -c avrisp2 -P /dev/ttyACM0 -t
um in den interaktiven Modus des AVRDUDE zu gelangen
Ergebnis:
avrdude: ser_send(): write error: Invalid argument
Das gleiche passiert, wenn ich root bin.
- In Minicom "menue\n" eingegeben, um in den Terminalmodus von
USBAVR-ISP zu gelangen. Ergebnis: Weder Terminalausgabe noch
blinkende LED.
- AVRDUDE aufgerufen mit
avrdude -p attiny45 -c avrisp2 -P usb -t
weil ich irgendwo gelesen habe, dass man für das STK500 "usb" als
Port angeben soll.
Ergebnis:
avrdude: usbdev_open(): did not find any USB device "usb"
- Sourcecode vom AVRDUDE angeschaut und festgestellt: -P usb
fragt die Vendor- und ProductID von Atmel ab. Der USBAVR-ISP hat
aber eine andere.
- Sourcecode vom AVRDUDE gepatcht, dass auch der USB-AVR-ISP erkannt
wird. Ergebnis:
avrdude: usbdev_open(): error setting configuration 1: could not \
set config 1: Device or resource busy
avrdude: usbdev_open(): did not find any USB device "usb"
- Auf http://www.obdev.at/products/avrusb/avrdoper.html gelesen, dass
CDC mit Low-Speed die USB-Spezifikation vergewaltigt, deswegen keine
Funktionsgarantie. Nach längerer Nachforschung festgestellt, dass
der Linux-Kernel ab 2.6 im UHCI-Treiber dies tatsächlich abfragt und
verhindert.
- Abfrage auskommentiert, Kernel neu gebaut
Ergebnis:
Terminalmodus geht
AVRDUDE mit -P usb bringt die gleiche Meldung wie vorher
AVRDUDE mit -P /dev/ttyACM0 meint:
avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
- "Yikes, welche Überaschung!" hab' ich mir gesagt nochmals wie
verlangt die Anschlüsse doppelt geprüft, aber ohne Erfolg.
- AVRDUDE mit -vvvv aufgrufen, STK500v2-Spezifikation runtergeladen,
beides verglichen und stutzig geworden. Source vom USBAVR-ISP
(stk500protocol.c) angeschaut und noch stutziger geworden:
1
caseSTK_CMD_SPI_MULTI:
2
{
3
...
4
for(i=1;i<lentx+1;i++)
5
{
6
if(i>=rxstart)
7
{
8
Buffer[STK_TXMSG_START+1+rxpos]=
9
ISP_transmit(progMultiParam->txData[i]);
10
rxpos++;
11
}
12
else
13
ISP_transmit(progMultiParam->txData[i]);
14
}
Yikes ;-), da wird ja das erste Byte von txData gar nicht an den AVR
übertragen, laut der AVRDUDE-Ausgabe müsste aber der 4-Byte-Befehl
zur Signaturabfrage vom in txData[0..3] landen. Die obige Routine
überträgt aber txData[1..4] an den AVR. Ergebnis: AVRDUDE und
USBAVR-ISP scheinen die Protokollspezifikation unterschiedlich
auszulegen. Wie kann es dann aber sein, dass sowohl IAVR Studio mit
USBAVR_ISP als auch AVRDUDE mit dem STK500-Board zusammenarbeiten?
- Überlegt, und zu folgender Vermutung gekommen: Das AVR Studio
überträgt zusätzlich zu den Befehlsdaten ein führendes Nullbyte,
vielleicht um das SPI-Datenregister auf dem Target-AVR "durchzu-
spülen". Da es kein Kommando 0x00 gibt, wird das Byte vom AVR
ignoriert. Wenn hingegen keine führende 0x00 (wie beim AVRDUDE)
gesendet wird, wird eben schon das erste Byte als Kommando
interpretiert.
- Basierend auf dieser Vermutung den AVRDUDE gepatcht, dass er die
führende 0x00 sendet
Ergebnis: Die drei Signaturbytes werden richtig gelesen und kommen
beim AVRDUDE an
RIESIG FREU
- Nun schnell mal eine Software auf den AVR zu spielen versucht
Ergebnis (nach ein paar Sekunden ungeduldigen Wartens):
Writing | ## ... | 3% 2.48s
avrdude: stk500v2_command(): unknown status 0x81
avrdude: stk500v2_paged_write: write command failed
Grrr! Also doch noch nicht.
Den Returncode 0x81 (STATUS_CMD_TOUT, Warning: Command timed out)
gibt's laut Spezifikation tatsächlich, wird vom AVRDUDE nur nicht
ausgwertet. Normalerweise dürfte es aber gar nicht erst zu diesem
Timeout kommen, da liegt wohl noch etwas anderes im Argen.
So, an der Stelle habe ich eine Frickelpause eingelegt und wollte mal
gerne die Stellungsnahme derjenigen abwarten, die sich damit
auskennen. Frickel ich überhaupt in die richtige Richtung oder habe
ich die einfache und naheliegende Lösung des Problems in meinem Eifer
vielleicht total übersehen?
Viele Dank schon mal!
PS: Falls jemand nun fragen sollte, warum ich nicht einfach den
AVR-Doper nehme: Ich brauche das Feature von USBAVR-ISP, im
Normalbetrieb des Target-AVRs bidirektional UART-Daten über USB
übertragen zu können. AVR-Doper kann das laut Webseite vom Target zum
PC, aber nicht umgekehrt.
Wow, ich hab zwar schon gemerkt das die CDC im Linux nicht geht hab aber
noch nicht weiter gesucht. Vorab, du bist da um Lichtjahre weiter als
ich je gesucht hab.
Das mit dem Kerneltreiber ist echt schade damit hat sich CDC unter Linux
wohl erledigt. Ich werde bei Gelegenheit mal einen Modus einbaun der
über HID arbeitet da gibts ja auch 1-2 protokolle die der avrdude
unterstützt.
oder siehst du noch ne andere Möglichkeit ohne den Kernel zu patchen ?
Den Fehler in der ISP Multi beseitige ich gleich.
>Wie kann es dann aber sein, dass sowohl IAVR Studio mit>USBAVR_ISP als auch AVRDUDE mit dem STK500-Board zusammenarbeiten?
für avrdude kann ich das nicht beantworten aber das AVR Studio benutzt
ISP Multi überhaupt nicht ich hab es lediglich für avrdude implementiert
und nie getestet. Laut aussage anderer soll es unter Windows aber mal
funktioniert haben wie kann ich nicht sagen.
>So, an der Stelle habe ich eine Frickelpause eingelegt und wollte mal>gerne die Stellungsnahme derjenigen abwarten, die sich damit>auskennen. Frickel ich überhaupt in die richtige Richtung oder habe>ich die einfache und naheliegende Lösung des Problems in meinem Eifer>vielleicht total übersehen?
Mhmm, ich bin dafür das du weiter eiferst aber auf die schnelle könntest
du die USBasp Firmware draufspielen die benutzt einen HID Modus der auch
von avrdude unterstützt wird. Damit lassen sich keine geschwindigkeiten
einstellen usw aber flashen soltest damit erstmal können.
Die Antwort kam aber fix! Ich hätte im optimistischten Fall mit einer
Stunde gerechnet, bis jemand das Posting aufmacht, es durchliest und
dann auch noch eine Antwort schreibt.
> Das mit dem Kerneltreiber ist echt schade damit hat sich CDC unter> Linux wohl erledigt.
Wenn ich das richtig gesehen habe, betrifft das wohl nur die Treiber
für die UHCI-Host-Controller (für Intel und VIA). Beim OHCI-Treiber
(für alle anderen Hersteller) habe ich eine entsprechende Abfrage
nicht gefunden.
> oder siehst du noch ne andere Möglichkeit ohne den Kernel zu patchen ?
Genau genommen ist nicht das CDC für Low-Speed verboten, sondern die
Bulk-Transfers. Ich habe von USB keine Ahnung, aber gibt es vielleicht
eine Möglichkeit, CDC ohne Bulk-Transfers zu implementieren? Oder wird
das zu langsam?
Ansonsten könnte man ja mal eine freundliche Anfrage an die Linux-
Entwickler richten, die Abfrage aus dem Treiber zu entfernen. Der
Linux-Kernel ist ja schließlich nicht damit beauftragt, den Standard
zu überwachen. Wenn ein Gerät standardkonform ist, wird es ohne
die Abfrage genauso funktionieren wie vorher, insofern ergeben sich
keine Nachteile. Ich werde mach nachschauen, ob es vielleicht schon
einen entsprechenden Antrag gibt.
> Den Fehler in der ISP Multi beseitige ich gleich.> ... das AVR Studio benutzt ISP Multi überhaupt nicht ich hab es> lediglich für avrdude implementiert und nie getestet.
Das erklärt einiges :-)
> Mhmm, ich bin dafür das du weiter eiferst ...
Ich werde mal sehen, was ich noch finden kann. Ach ja, da ist mir noch
eine Kleinigkeit aufgefallen: In Zeile 227 von stk500protocol.c steht:
1
if((i&8)==8)
2
usbPoll();
Sollte das nicht eher
1
if((i&7)==7)
oder (
1
if(i&7)==0)
Ich nehme an, du möchtest alle 8 Schleifendurchläufe den USB bedienen.
Das ist zwar kein Bug, aber vielleicht geht das Flashen mit der
Änderung ein paar µs schneller ;-)
> ... auf die schnelle könntest du die USBasp Firmware draufspielen> die benutzt einen HID Modus der auch von avrdude unterstützt wird.
Zum Programmieren kann ich auch meinen alten Parallelportadapter
verwenden (geht eben nicht mehr an jedem PC). Weswegen ich mich vor
allem nach etwas Neuem umgeschaut habe, ist der Wunsch, über ein
Kabel (USB) Programmieren und anschließend ohne Umstöpseln mit der
Anwendung auf dem Target kommunizieren zu können. Oder geht das mit
USBasp auch? Bisher habe ich ein Parallel- (zum Programmieren) und ein
RS-232-Kabel (zum Kommunizieren) benutzt, aber neuere Laptops haben
eben oft nur noch USB-Schnittstellen.
>Ich nehme an, du möchtest alle 8 Schleifendurchläufe den USB bedienen.>Das ist zwar kein Bug, aber vielleicht geht das Flashen mit der>Änderung ein paar µs schneller ;-)
Nee, da hast du nen Denkfehler wenn ich usb nur jedes 9. mal bediene
geht das flashen schneller. Der Wert ist aber "frei nach Schnauze"
implementiert. Du kannst ja testen ob es mit jedem 12. oder 20. mal
immernoch sauber funktioniert dann wirds schneller. Allerdings flash ich
öfter mal atmega64 damit die ziemlich voll sind und die paar sekunden
fürs flashen haben mich noch nicht gestört.
>Genau genommen ist nicht das CDC für Low-Speed verboten, sondern die>Bulk-Transfers. Ich habe von USB keine Ahnung, aber gibt es vielleicht>eine Möglichkeit, CDC ohne Bulk-Transfers zu implementieren? Oder wird>das zu langsam?
Also soweit ich weiss ist CDC generell nur für Bulk Transfers gedacht,
was macht es für einen sinn, versteh ich jetzt gar nicht. Du kannst ja
mal dienen Patch an die Kernel Mailinglist schicken mal sehn was
passiert.
>ohne Umstöpseln mit der>Anwendung auf dem Target kommunizieren zu können. Oder geht das mit>USBasp auch?
nein, natürlich nicht dazu wäre die CDC ja auch zwingend erforderlich
...
Oder wärs für dich auch OK über HID z.b. libusb mit deinem Target zu
komunizieren ? Das könnt ich bei der HID Implementierung mit machen...
>> Ich nehme an, du möchtest alle 8 Schleifendurchläufe den USB>> bedienen. Das ist zwar kein Bug, aber vielleicht geht das Flashen>> mit der Änderung ein paar µs schneller ;-)>> Nee, da hast du nen Denkfehler wenn ich usb nur jedes 9. mal bediene> geht das flashen schneller.
Ob jedes 8. oder 9. Mal, spielt sicher keine große Rolle. Aber
((i&8)==8) ist wahr für i==0bxxxx1xxx, also für 8, 9, 10, 11, 12, 13,
14, 15, dann wieder für 24, 25, 26, 27, 28, 29, 30, 31 usw.
Du rufst also usbPoll() in sehr ungleichen Zeitabständen auf, was
sicher nicht beabsichtigt ist.
> Oder wärs für dich auch OK über HID z.b. libusb mit deinem Target zu> komunizieren ? Das könnt ich bei der HID Implementierung mit> machen...
Das wäre fast genauso gut. Das einzige, was damit nicht geht, wäre die
Kommunikation über ein Terminalprogramm, aber darauf könnte ich auch
verzichten.
>Du rufst also usbPoll() in sehr ungleichen Zeitabständen auf, was>sicher nicht beabsichtigt ist.
Ist mir vorhin auch aufgefallen, mir kommt das auch etwas unbekannt
naja.
Beim pagemode müsste manns eh viel seltener aufrufen auf die schnelle
fällt mir dazu aber auch nix wirklich Geniales ein.
>Das wäre fast genauso gut. Das einzige, was damit nicht geht, wäre die>Kommunikation über ein Terminalprogramm, aber darauf könnte ich auch>verzichten.
ist notiert ich weiss aber nicht wann ich dazu komm das mal zu
implementiern.Ist eigentlich kein großes ding aber die paar Stunden
wolln auch abgezwackt sein.
> ist notiert ich weiss aber nicht wann ich dazu komm das mal zu> implementiern.Ist eigentlich kein großes ding aber die paar Stunden> wolln auch abgezwackt sein.
Nur keine Eile, aber ich danke dir schon mal für deine Bereitschaft!
Mit dem Abzwacken der Stunden habe ich gerade auch so meine Probleme.
yalu wrote:
>> ... das AVR Studio benutzt ISP Multi überhaupt nicht ich hab es>> lediglich für avrdude implementiert und nie getestet.>> Das erklärt einiges :-)
Das ist praktisch historischer Ballast bei avrdude. avrdude hat ja
mal als ISP-Programmiersoftware angefangen, die das komplette ISP
selbst macht (an einfachen Parallelport-Dongles). Als dann jemand
(ich glaube, es war Brian Dean selbst) STK500-Support gebraucht hat,
hat er das implementiert, indem er die existierende ISP-Implementierung
in SPI-Multi-Kommandos des STK500 umgesetzt hat. :-/ Manches davon
ist zwar mittlerweile in echte STK500-Kommandos gewandelt worden
(zum Beispiel alles, was als paged operation ablaufen kann/muss),
aber einige Überreste des alten SPI-Multi-Salats sind halt immer noch
da.
Wenn das jemand in echte STK500-Kommandos umwandeln will: nur zu!
@yalu
Done.
In der Bootloader Software ist jetzt ne USBasp kompatible Firmware dabei
die aus jedem aktuelleren avrdude nutzbar sein sollte die hat auch
entsprechende Bootloaderspezifische Erweiterungen und die
Debugschnittstelle ist auch drüber nutzbar. Ich mach noch n kleines
Beispielprogramm wie man mit libusb an die Debugschnittstelle rankommt.
Wenn dus schneller haben willst kannst du dir die nötigen infos auch aus
dem Firmware Source holen...
Super, hört sich gut an!
Ich werd's am Wochenende mal ausgiebig testen, vorher komme ich leider
nicht dazu, weil ich die meiste Zeit außer Haus bin.
> Wenn dus schneller haben willst kannst du dir die nötigen infos auch> aus dem Firmware Source holen...
Wie gesagt, vor Wochenende passiert sowieso nix, dann werde ich
schauen, was schon alles tut :-)
Auf jeden Fall schon mal vielen Dank für die Arbeit, die du
reingesteckt hast und die sicher nicht wenig war. Ich bin gespannt
auf's Wochenende ...
So, jetzt:
Ich habe jetzt deine neue Firmware kompiliert und auf einen Mega168
gespielt. Hat ein Bisschen gedauert, weil ich erst rausfinden musste,
welches die für meinen Zweck richtigen Quellcodemodule und Defines
sind. Das steht ja alles in den aps-Dateien, wie ich irgendwann
rausgefunden habe, da ich aber kein AVR-Studio habe, musste ich mich
von Hand durch den XML-Code wühlen. Mit den richtigen Informationen
wurde das Programm aber ohne Probleme gebaut.
Der avrdude -c usbasp hat den Programmer dann auch sofort erkannt, nur
nicht den als Target angeschlossenen Tiny13, was aber an dem relativ
hohen defaultmäßigen SPI-Takt von 750 kHz lag.
Als ich den kleiner gemacht habe, funktionierte alles perfekt! Und das
ohne jegliche Patches an deiner Firmware, am avrdude oder am
Linux-Kernel. So gefällt mir das :-)
Als Nächstes wollte ich die Ausgabe von Debug-Informationen über die
serielle Schnittstelle des Targets testen. Wie ich deinem Quellcode
entnommen habe, werden die vom Programmer über den UART empfangenen
Zeichen gepuffert und über den USB ausgegeben. Ich muss mich jetzt mal
USB- und libusb-mäßig etwas schlauer machen. Dann wollte ich ein
kleines Programm schreiben, das diese Zeichen auf dem Bildschirm
ausgibt.
Aber da gibt es ja noch das AVRISPTool, zu dem ich bisher nur den
Quellcode und ein paar Screenshots gefunden habe. Es scheint in
Freepascal geschrieben zu sein, was auf meinem Rechner aber (noch)
nicht installiert ist. Da gibt es die Möglichkeit, verschiedene
Parameter des Programmers zu setzen. Und in folgendem Screenshot
http://www.ullihome.de/images/Avrisptool4.png
ist rechts unten ein leeres weißes Feld zu sehen. Werden hier
vielleicht die Debug-Daten angezeigt? Wenn ja, werde ich mir den
Quellcode mal etwas näher ansehen (obwohl mein Pascal schon vor
Urzeiten ausgetrocknet ist :_)) und den Freepascal-Compiler saugen.
Geht die serielle Übertragung eigentlich auch anders herum, also vom
PC über den Programmer zum Target?
Auf jeden Fall noch einmal vielen Dank für deine Arbeit. Ich glaube,
dass das mein künftiger Standard-Programmer werden wird, da er alles
hat, was ich mir von so einem Teil erhoffe und ich mittlerweile auch
etwas Einblick in seine Interna habe. Ich muss mir nur noch die
Hardware ordentlich aufbauen (Im Moment habe ich nur eine geliehene
und eine breadboardbasierte :-)).
Ich muss mich jetzt mal
USB- und libusb-mäßig etwas schlauer machen. Dann wollte ich ein
kleines Programm schreiben, das diese Zeichen auf dem Bildschirm
ausgibt.
Ja, ist aber kein grosses problem den Code kannst fast komplett aus dem
AVR-ISP Tool übernehmen endweder du stutzt ihn nur zurecht und machst ne
kleine freepascal kommandozeilen app.
oder du übersetzt dir das ganz noch nach c was auch in 5 min erledigt
sein sollte...
wenn du probleme hast sags ruhig dann mach ich mal n sample.
>Aber da gibt es ja noch das AVRISPTool, zu dem ich bisher nur den>Quellcode und ein paar Screenshots gefunden habe.
Da hast aber schlecht geguckt :p
http://www.ullihome.de/index.php/USBAVR-ISP-Download/de#Software_2
Da findest Windows und Linux Versionen vom AVR-ISP Tool macOS kommt
nächste Woche vielleicht da hab ich noch etwas Probleme mit libusb
>Es scheint in>Freepascal geschrieben zu sein, was auf meinem Rechner aber (noch)>nicht installiert ist.
jain, genauer ist es mit Lazarus geschrieben das ist quasi n
Plattformunabhängiges Delphi welches Freepascal als compiler verwendet.
lazarus.freepascal.org da gibts packages für linux, windows und macos.
>Da gibt es die Möglichkeit, verschiedene>Parameter des Programmers zu setzen. Und in folgendem Screenshot>http://www.ullihome.de/images/Avrisptool4.png>ist rechts unten ein leeres weißes Feld zu sehen. Werden hier>vielleicht die Debug-Daten angezeigt?
Ja
>Wenn ja, werde ich mir den>Quellcode mal etwas näher ansehen (obwohl mein Pascal schon vor>Urzeiten ausgetrocknet ist :_)) und den Freepascal-Compiler saugen.
Naja Pascal ist ja gut genug lesbar als das es jeder der mal n bissle
programmiert hat lesen können sollte
>Geht die serielle Übertragung eigentlich auch anders herum, also vom>PC über den Programmer zum Target?
ja ist in der firmware implementiert nur im avr-isp tool noch net
>Auf jeden Fall noch einmal vielen Dank für deine Arbeit. Ich glaube,>dass das mein künftiger Standard-Programmer werden wird, da er alles>hat, was ich mir von so einem Teil erhoffe und ich mittlerweile auch>etwas Einblick in seine Interna habe. Ich muss mir nur noch die>Hardware ordentlich aufbauen (Im Moment habe ich nur eine geliehene>und eine breadboardbasierte :-)).
Joa, gibt ja auch schon n paar andere Firmwares und ist kaum noch Arbeit
ne neue Firmware zu implementieren wenn man mal was braucht hab letzte
woche in 4h nen i2c logger dazugebastelt.
Thread beobachten
Seitenaufteilung abschalten