Avrdoper(hid) Debian11 Avrdude

[Ingo W. (uebrig)]

Hallo in die Runde,

erster Hinweis: dies ist kein Hilferuf, sondern eher ein 
Erfahrungsbericht mit möglichen Lösungen. Ich weiss auch nicht, ob dies 
Thema hier überhaupt noch für Jemanden relevant ist, im Zweifelsfalle 
einfach ignorieren!

Vor über 10 Jahren, hatte ich mir 2 AVRDOPER gebaut und lange Zeit als 
primäre Programmieradapter genutzt (damals noch als CDC mit AVR-Studio 
unter Windows). Für "normalen" Kram nutze ich inzwischen aber nur noch 
selbstgebaute USBASPs, die Doper werden nur noch alle paar Jahre 
rausgekramt, wenn es um was 8-beiniges mit wegprogrammiertem Reset geht 
(HVSP), zuletzt hier:
Beitrag "Re: Gerät bauen, welches Rauschen produziert (kein Scherz)"
Dies war jetzt kein Problem, die Käfer habe ich mit SPI programmiert und 
den Reset am Schluss deaktiviert. Aber zu diesem Anlass hab ich den 
Doper mal wieder rausgekramt und festgestellt, dass es inzwischen ein 
Kommunikationsproblem gibt.
Dann hab ich es auf einem etwas älteren Reserverechner, ebenfalls 
Debian11/64 getestet, hier funktioniert es (Ist der 1. Workaround).
Da ich gerade einen Banana-Pi mit aktuellem Bücherwurm im Test habe, der 
eigentlich für einen anderen Zweck vorgesehen ist, ebenfalls getestet: 
funktioniert auch.
RasPi 1A und 1B, mit Buster oder Bullseye funktionieren nicht.

Also verträgt ich der USB-HID Tunnel zwischen Doper und Avrdude 
irgendwie nicht mit meinem Brot und Butterrechner.
Im BIOS finde ich auch keine Konfigurationsoptionen für die 
USB-Hardware.

Da inzwischen regelkonforme USB-UARTs sowohl als Käfer, als auch als 
Module gut und preisgünstig verfügbar sind, und die UART-Schnittstelle 
auf den SPI-Steckverbinder geführt ist, habe ich mich entschlossen, den 
gesamten USB-Stack aus dem Doper zu entfernen und die Kommunikation über 
die UART herauszuführen. Zum Glück passt der 12MHz-Quarz zu den 
115200Baud, so dass hier kein Wechsel erforderlich ist.

Folgende Änderungen waren dazu erforderlich:
entfernen von usbdrv und serial(debug) aus dem makefile.
Der wesentliche Umbau betrifft die main.c
Die hardware.h sieht bei mir etwas anders aus, als original, da ich die 
Schaltung etwas angepasst habe. Wer die original HW benutzt, sollte hier 
auch die Originaldatei verwenden. Meine Hardware ist im "circuit"-Ordner 
(target und pdf).

Damit wird der Doper jetzt wie ein STK500 behandelt und über 
/dev/ttyUSB# (oder com# unter Windows) angesprochen und würde wohl sogar 
mit dem AVR-Studio funktionieren.

Für mich hat die Lösung den Vorteil, dass ich mit meinem 
"Lieblingsrechner", ohne zusätzlichen Platz auf dem Tisch auskomme.

Falls Jemand vor dem gleichen Problem stehen sollte, gibt es 
zummindestens ein paar Lösungsansätze.

[C-hater (c-hater)]

Ingo W. schrieb:

> Aber zu diesem Anlass hab ich den
> Doper mal wieder rausgekramt und festgestellt, dass es inzwischen ein
> Kommunikationsproblem gibt.

Hmm... Interessant. Muss ich direkt mal probieren. Ich habe auch noch 
einen Doper irgendwo rumliegen. Auch seit Jahren nicht mehr benutzt, da 
mit aktuellen Windows-Versionen halt schon seit vielen Jahren nicht mehr 
benutzbar.

Aber bei Linux gab es ja einen Workaround, der aus dem 
nicht-standardgerechten V-USB-CDC eine Art Pseudo-CDC gemacht hat, bei 
dem die Burst-Endpoints zu Interrupt-Endpoints mutierten, sofern die 
maximale Paketgröße lt. Descriptor im zulässigen Bereich für so einen 
war. Mit dem Ziel, das Dingens aber insgesamt doch noch als serielle 
Schnittstelle verfügbar zu machen. Und das hat auch gut funktioniert.

Könnte durchaus sein, das dieser Workaround nach der langen Zeit 
inzwischen wieder rausgeflogen ist.

Wenn das so ist, habe ich wieder ein Stück vollständig obsoleten 
Elektronikschrott mehr. Aber immerhin: den Mega8 werde ich problemlos 
retten können. Gute alte gesockelte DIL-Technogie ;o)

[Ingo W. (uebrig)]

Das ist mit "HID-Modus" gemeint.
In der "hardware.h" gibt es zwei Schalter, mit denen jeweils der CDC- 
oder HID-Modus aktiviert wird. Unter WindowsXP konnte man den 
Bulk-Transfer, welcher für den CDC-Modus benötigt wurde, im LowSpeed 
Betrieb illegalerweise noch freischalten, später ging aber auch das 
nicht mehr.
Wenn dein Doper noch für CDC programmiert ist, wirst du ihn wohl neu 
programmieren müssen. Es gab aber auch die Option, beide Stacks zu 
aktivieren, dann musste mit einem Jumper der Modus festgelegt werden. 
Das hab ich aber bei mir nicht drin.
Für den HID-Modus musste damals extra ein Modul in AVRDUDE eingebaut 
werden. Vor einigen Jahren, hat das auch noch gut funktioniert (Ubuntu, 
aber auch ein anderer Rechner).
Mir ist es aber lieber, wenn die AVRDUDE-Entwickler sich um den 
"simple-uart-updi-modus" kümmern, als um so einen Exoten, wie den 
doper-hid-modus, daher der Umbau auf "echten UART".

[C-hater (c-hater)]

Ingo W. schrieb:

> Das ist mit "HID-Modus" gemeint.

Nein, das kam erst später. In den Quellen, aus denen mein Doper 
programmiert wurde, gibt es noch keinerlei HID-Zeugs.

Und das war damals(tm) auch kein Problem. Sowohl das damals aktuelle 
WindowsXP als auch die damaligen Linuxe haben die für Lowspeed-Devices 
lt. Standard eigentlich illegalen Burst-Endpoints problemlos geschluckt. 
Ohne jegliche Workarounds. Das wurde schlicht von den 
Hostadapter-Treibern überhaupt nicht gepüft.

Irgendwann kam dann aber irgendjemand darauf, dass diese Verhalten u.U. 
die Funktionsfähigkeit des Busses beeinträchtigen könnte (wenn nämlich 
die Grenzen der Burst-Transfers tatsächlich mal von so einem 
Lowspeed-Device ausgenutzt werden würden). Draufhin beeilten sich die 
OS-Hersteller, dieses Problem zu fixen. Microsoft halt knallhart: Bugfix 
und gut isses. Scheiß auf die Anwender.

Bei Linux wurde es ebenfalls gefixed, aber es gab halt zusätzlich diesen 
Workaround, der die Funktion der existierenden Geräte weiterhin 
gewährleistet hat (wenn sie halt lt. Descriptor innerhalb der 
Lowspeed-Beschränkungen blieben). Standardgerecht war der Workaround 
aber halt nicht, deswegen ist es gut möglich, dass er inzwischen 
rausgeflogen ist.

Morgen werde ich das einfach mal ausprobieren. Und wenn's nicht mehr 
geht: ist's mir auch egal. Dann zuppe ich halt den Mega8 aus der Fassung 
und der Rest landet im Elektronikschrott.

[C-hater (c-hater)]

C-hater schrieb:

> Morgen werde ich das einfach mal ausprobieren.

So, habe ich jetzt getan (unter Linux Mint 21.1 MATE). Funktioniert wie 
vor Jahren einwandfrei. Auch wenn (oder vielleicht gerade weil?) nur 
eine wirklich steinzeitliche Version von avrdude im Repository ist.

Logs siehe Anhänge.

[Ingo W. (uebrig)]

Bin jetzt noch einmal in mich gegangen. Den Wechsel von CDC auf HID 
hatte ich beim Wechsel von Windows XP zu 7 gemacht, weil ich der Meinung 
war, dass Bulk-Transfer für Low-Speed Geräte illegal ist. Habe 
inzwischen hier aber auch andere Auffassungen gefunden, z.B. von Jörg: 
Beitrag "Re: USB CDC (virtual Com-port) mit hohen Datenraten verwenden"
Auf der AVR-CDC Seite 
http://www.recursion.jp/prose/avrcdc/driver.html#linux steht (wohl seit 
über 10 Jahren):
"Linux <2.6.31 does not allow the low-speed bulk transfer. Replace the 
kernel to 2.6.31 or higher."
Also habe ich mal ein AVR-CDC geflasht, RxD mit TxD gebrückt und habe im 
Putty meine gesendeten Zeichen zurückbekommen. Also geht AVR-CDC 
zummindest bei mir unter Debian 11.
Also die Firmware für den Doper wieder auf CDC zurück geändert und ihn 
über /dev/ttyACM0 angesprochen - funktioniert, beste Lösung.
Eine Rückfalloption habe ich ja gegebenenfalls immer noch.
Man lernt also wirklich nicht aus.

[C-hater (c-hater)]

Ingo W. schrieb:

> weil ich der Meinung
> war, dass Bulk-Transfer für Low-Speed Geräte illegal ist.

Ist er definitiv. Deswegen haben ja auch alle relevanten OS die 
entsprechenden Bugfixes vorgenommen, damit diese illegalen 
Konfigurationen nicht mehr akzeptiert werden, zunindest nicht mehr 
"unbesehen".

> Habe
> inzwischen hier aber auch andere Auffassungen gefunden, z.B. von Jörg:
> Beitrag "Re: USB CDC (virtual Com-port) mit hohen Datenraten verwenden"
> Auf der AVR-CDC Seite
> http://www.recursion.jp/prose/avrcdc/driver.html#linux steht (wohl seit
> über 10 Jahren):
> "Linux <2.6.31 does not allow the low-speed bulk transfer. Replace the
> kernel to 2.6.31 or higher."

Diese Darstellungen sind falsch. Bulk für LowSpeed ist und bleibt 
illegal. Der Workaround löst das prinzipielle Problem dadurch, dass er 
halt Endpoints, die lt. Config Bulk sind, zu Interrupt-EPs mutieren läßt 
(wenn sie innerhalb der Limits für Interrupt-Transfers sind).

Das löst aber "nur" das potentielle technische Problem bezüglich des 
Busses, wegen dem der Standard LowSpeed-Devices halt Bulk-Endpoints 
verbietet.

Das entsprechende Gerät verstößt aber natürlich weiterhin gegen den 
Standard und der Workaround auch. Lt. Standard dürfte es diesen 
Workaround nicht geben und auch das Gerät nicht. Da beisst die Maus kein 
Faden ab.

Standard-Fetischisten dürfen solche Geräte also nicht benutzen, 
Pragmatiker hingegen schon...

[Joe L. (joelisa)]

*** Bester Faden seit Monaten ***