V-USB Digispark Pro Verbindung mit Win x86 Vista,win7

[Gerhard F. (proli)]

Zum Einsatz von Microkontrollern im Home-Bereich wollte ich mich durch 
eigene Experimente einarbeiten. Dazu habe ich einen Digispark Pro 
angeschafft und diesen über USB mit meinen Win-PCs Vista oder Win7 
verbunden. Auf den PCs ist die DigistumpArduino IDE 1.5.8C installiert, 
eingestellt auf Digispark Pro 16MHz .
Das Hochladen von kleinen Programmen mit der IDE funktioniert 
einwandfrei und simple Zeitsteuerprogramme machen, was sie sollen. Der 
Bootloader stellt also zum Hochladen die virtuelle USB-Schnittstelle des 
Digispark Pro bereit, die IDE erkennt diese und kann darüber korrekt 
Programmcode hochladen.

Will man als Nutzer zur Steuerung von Programmen vom PC aus über  V-USB 
mit dem Digispark Pro kommunizieren, muss die Schnittstelle innerhalb 
des  Anwendungsprogramms dafür vorbereitet werden. Die dafür 
bereitgestellten Libraries wie DigiUSB, DigiKeyboard, DigiCDC werden in 
den Beispielprogrammen der IDE benutzt.

Nun das Problem:
Meine PCs erkennen V-USB nur ganz selten, und nach dem Hochladen von 
Programmcode ist selten einmalig mit dem Programm "Monitor" eine 
Reaktion des Digispark erkennbar. Hierzu ein paar Screenshots, die das 
Problem verdeutlichen sollen:
Ich vermute Fehler in den x86 V-USB Treibern.
Ich bitte Euch um Hilfe und Hinweise zu einer systematischen 
Fehlersuche. Wer hatte ähnliche Probleme und wie konnten diese gelöst 
werden.

[doedel (Gast)]

ich meine, das ist ein Problem mit der CDC Bibliothek. Dazu gibt's auf 
dem Hersteller-Board auch eine Diskussion:

http://digistump.com/board/index.php/topic,1519.0.html

[Gerhard F. (proli)]

Danke zunächst für den Hinweis.
Die Beiträge zu diesem Thema im Digistump Forum verfolge ich auch. Die 
umfangreichen Beiträge von Defragster und dem Administrator zum Thema 
zeigen das Ringen um eine Lösung in der CDC Library, doch eine 
letztendlich brauchbare allgemeine Lösung kann ich noch nicht erkennen. 
In dem englischsprachigen Forum kann ich aber nicht mitdiskutieren, dazu 
bin ich nicht sicher genug in Englisch. Deshalb habe ich hier meine 
Fragen gestellt.

Ich habe die Hoffnung, dass ich hier jemand finde, der das Problem kennt 
und einen Weg zur Lösung aufzeigen kann.

Zur Sache noch meine Frage:  Ich halte es für möglich, dass ich mit dem 
DigiUSB Monitor deshalb einmalig eine Sendung empfangen konnte, weil ich 
den Monitor zum richtigen Zeitpunkt am Ende des Bootladevorgangs 
gestartet hatte.
Was macht es eigentlich so schwer, die im Bootloader steckende Lösung 
zur Kommunikation auf die AnwendungsLibraries zu übertragen? Es geht 
doch "nur" um die nicht zeitkritische Übertragung weniger Byte für 
Steuerzwecke. Oder sehe ich das prinzipiell falsch?

[Peter (Gast)]

Gerhard F. schrieb:
> Was macht es eigentlich so schwer, die im Bootloader steckende Lösung
> zur Kommunikation auf die AnwendungsLibraries zu übertragen?

Ohne es zu wissen wäre es möglich, dass der Bootloader auf USB HID Basis 
erstellt ist (wie des öfteren zu sehen), im Gegensatz zu USB CDC. Es 
sind also unterschiedliche Protokolle.

Da CDC auch höhere Geschwindigkeiten als 64kBytes/s unterstützen sollte 
(was es aber bei VUSB nicht macht), könnten die Probleme daher kommen.

[Gerhard F. (proli)]

@Peter, @doedel
Eure Hinweise haben mich veranlasst, mich mit der USB-Spezifikation zu 
belesen (https://de.wikipedia.org/wiki/Universal_Serial_Bus) und im 
Forum des Herstellers Digistump die Diskusion zum Problem nochmals 
durchzusehen. Auch habe ich die DigistumpArduino IDE 1.5.8C neu 
installiert. Damit sollten eigentlich alle x86-Treiber für die 
Zusammenarbeit mit dem Device Digistump Pro zur Verfügung stehen , siehe 
hierzu die vorhandenen Treiber in meinem PC (Treiber.png ). Die Treiber 
sind auch nach der sourceforge-Seite 
(http://sourceforge.net/p/libusb-win32/wiki/Home/) auf dem neuesten 
Stand.
Für meine Versuche habe ich nach diesen Vorarbeiten DigiUSB benutzt. Als 
Testprogramme habe ich Echo- und Blink-Beispiele benutzt. Echos oder 
andere Ausgaben konnte ich mit dem Seriellen Monitor nicht erhalten, 
obwohl der Bootloader die Beispiele anstandslos compiliert und 
installiert hatte.
Der Win-Gerätemanager zeigt nach dem Anschließen kurzzeitig das Gerät 
als libusb-win32 Usb Devices an (Kein HID, obwohl aus den Treiberdetails 
class 03 zu entnehmen ist).
Nach der Bootmanager Wartezeit von 5 sec wird das Gerät erneut so 
angezeigt, jedoch nur, wenn DigiUSB im Programm initialisiert ist und 
ständig weitere DigiUSB- Anweisungen ohne größere Verzögerungen 
innerhalb der Loop-Schleife aufgerufen werden. Dies Verhalten ist, so 
meine ich, bei einer V-USB Schnittstelle nachzuvollziehen.
Nach vielen erfolglosen Versuchen, den Digispark Pro zur Kommunikation 
zu bewegen, habe ich endlich herausgefunden, dass mir vom deutschen 
Anbieter "cboden" ein älteres Exemplar aus der Kickstarter Serie 
geliefert wurde:
Digispark Pro v 1.0  Kickstarter Edition!  BAC-G  94V-0  32/14
Sehr wahrscheinlich wurde diese Version mit einem älteren Bootloader 
ausgeliefert. Ich habe den Verdacht, dass die mit der aktuellen 
DigistumpArduino-IDE 1.5.8C gelieferten Treiber dazu nicht kompatibel 
sind.
Gibt es hier jemand, der mit einem Exemplar aus der  Kickstarter Serie 
gearbeitet hat und die Kommunikation zum Laufen bringen konnte? Welche 
Treiberversion wurde dazu eingesetzt.
Trotz der Besonderheiten einer V-USB Schnittstelle sollte es doch 
möglich sein, den Digispark Pro für kleine Steuerungsaufgaben 
einzusetzen, die ein Minimum an  Monitoring und Befehlsübermittlung vom 
x86-PC erfordern. Ich hoffe sehr, dazu hier eine Antwort zu bekommen.

[Frank K. (fchk)]

Dein Problem ist das VUSB. Das wird in der AVR-Welt gerne verwendet, 
weil die AVRs mit Hardware-USB nicht in Lochraster-kompatiblem DIL 
vorliegen.

Dadurch das VUSB eine reine Software-Lösung ist, ist es nicht 100% zum 
USB 2.0 Standard kompatibel.

Eine große Einschränkung ist, dass es ein LowSpeed Device ist. HID geht 
damit, CDC geht damit nicht, jedenfalls nicht standardkonform. CDC 
braucht Bulk Endpoints, und Bulk Endpoints sind bei LowSpeed Devices 
gemäß des aktuellen USB 2.0 Standards nicht erlaubt. Punkt. Wer es nicht 
glaubt:
http://www.usb.org/developers/docs/usb20_docs/usb_20_060115.zip
Daraus dann usb20.pdf, Abschnitt 5.8.3 "Bulk Transfer Packet Size 
Constraints" (im PDF ist das Seite 81), und da steht dann ganz klar "A 
low-speed device must not have bulk endpoints."

Linux mag das vielleicht tolerieren, Windows ab Vista toleriert es 
nicht. Und wenn Du etwas verwendest, was nicht standardkonform ist, 
musst Du Dich nicht wundern, wenn es Probleme gibt.

Beispielsweise hat der Hersteller von blink(1) 
(http://blink1.thingm.com) in der zweiten Hardwareversion den 
VUSB-basierten Tiny85 in die Tonne getreten und durch einen PIC16F1454 
mit zertifiziertem Hardware-Fullspeed-USB 2.0 ersetzt, weil es bei 
Kunden immer wieder zu Problemen kam - vor allem an USB3-Ports.

Also Augen auf beim Käsekauf.

fchk

[bianchifan (Gast)]

Gerhard F. schrieb:
> Wer hatte ähnliche Probleme und wie konnten diese gelöst
> werden.
1. meine Wenigkeit
2. bislang nicht, da uninteressant

Digispark pro kenn' I net, ich hatte mir ein triple Digispark(ATTiny85) 
zugelegt, nachdem ich zu Jahresbeginn davon erfahren hatte.

Zunächst die Fakten:
Einen Digi habe ich mit IDEs malträtiert, beim Einstecken wird er von 
Win7 erkannt und unter libusb gelistet, nach ca. 3 sec verschwindet das 
Gerät und auf dem PCB blinkt eine LED.
Ein jungfräulicher Digi wird erkannt und bleibt gelistet, nach ca. drei 
sec blinkt die LED ebenfalls, aber deutlich langsamer, 1Hz oder so.

Mein Hauptproblem ist die IDE.
Eigentlich will ich Arduino entsorgen, leider läuft eclipse damit noch 
nicht 100% sexy und momentan habe ich keine Böcke auf Ursachenforschung.
Der Digispark wurde von dem testweise einmalig installierten Digistump 
IDE-Gebrimbel einwandfrei erkannt, mir ist aber nicht der Sinn nach 
Dritt- unf Viert-IDEs, das Zeuchs ist sofort wieder verschwunden.
Der Digistump-Aufsatz für die Standard-Arduino-IDE hat bei mir nie 
gefunzt.
Lt. Entwicklerauskunft klappt das, wenn ich die Hardware Definitionen 
nicht im User-Verzeichnis unterbringe, sondern direkt auf C: in den 
Arduino-Stammbaum...Pustekuchen
Eine Installation per Hardwaremenager aus der aktuellen IDE (1.6.4) 
rennt ebenfalls ins Nirwana...

Ende letzte Woche habe ich eine neue Digistump-Version runtergeleden, 
die schlummert aber noch vor sich, ebenso wie diverse Forks.

Momentan nutze ich den Tiny85 ausschließlich via Fremd-V-USB und ISP, 
sprich Chinamann-USBASP, klappt hervorragend.

Vielleicht solltest Du mal den Betreiber des Guloshops kontaktieren oder 
einen Blick in den Quellcode seines "Guloprog", einem USBASP auf 
ATTiny85 Basis, werfen.

[Gerhard F. (proli)]

Heute will ich mich endlich zu Wort melden und mitteilen, was aus der 
Sache geworden ist.

Im Ergebnis der Diskussion und der Auswertung der vorliegenden Literatur 
und der Suche nach alternativen Lösungen habe ich mich von der Nutzung 
des Digispark Pro für mein Vorhaben im Home Bereich abgewendet. Ich bin 
jetzt davon überzeugt, dass  Digispark  und Digispark Pro, wenn sie denn 
programmiert sind, für kleine Steueraufgaben und geringen verfügbaren 
Platz gut geeignet sind, aber trotz der vorhandenen Mini-USB-Buchse 
keine standardgerechte USB-Kommunikation darüber  zulassen. Eine 
funktionierende USB-Kommunikation ist aber für mich bei der Entwicklung 
und Testung von Programmcode unverzichtbar.

Ich schätze, die mit einer sauberen USB-Schnittstelle ausgerüsteten 
Arduino-Boards sind im Amateurbereich für die Programmentwicklung und 
Testung viel besser geeignet. Am Markt sind Arduino Bauteile 
beziehungsweise kompatible Bauteile aus Fernost zu moderaten Preisen 
erhältlich, wovon ich Gebrauch gemacht habe. Es hat aber mehrere Wochen 
gedauert, bis meine Bestellung bei mir eintraf.
Ein Arduino Uno R3 und ein nachgeschalteter  4 Kanal Relaisbaustein 
sowie die neue Arduino IDE 1.6.5. standen damit für die 
Programmentwicklung und den Test meiner kleinen Steuerung bereit.

Meine Erfahrung: Die Kommunikation mit einem über USB verbundenen 
Windows PC x86 klappt auf Anhieb. Der in der Arduino IDE bereitgestellte 
serielle Monitor hat mit Ein-und Ausgaben über den USB-Port keinerlei 
Probleme. So konnte ich mich auf die Erarbeitung und den Test des 
Programmcode voll konzentrieren.

Heute kann ich zufrieden sagen, der Einstieg in die Mikrocontroller 
Programmierung ist geschafft. Die Möglichkeit, hier im Forum Fragen 
stellen zu dürfen und Anregungen zu erhalten, hat mich auf den richtigen 
Weg geführt. Dafür bedanke ich mich.

Ich will kurz noch mitteilen,  wozu ich die kleine Steuerung benutze, 
die von meinem Home-PC aus bedient wird.
Aufgabe 1: Fern-Einschalten meines Home-PCs für Remote über das Internet
Aufgabe 2: Überwachung des Remote-PC
Aufgabe 3: Steuerung eines Fütterungsautomaten
Bei Interesse gehe ich gern darauf näher ein.

Motiviert durch den Einblick, was alles mit Mikrocontrollern kreativ 
selbst machbar ist, werde ich sicher weitere Steuerungsvorhaben im 
Heimbereich in Angriff nehmen. Dafür  würde ich gern grafische 
Benutzeroberflächen (GUI) zur komfortablen Bedienung vom Windows-PC aus 
und für die Bedienung über das Internet mit einem Android-Handy nutzen 
wollen (ein lauffähiges Programm für den PC und eine App für das 
Android-Handy). Hierzu nehme ich gern auch unterstützende Hinweise an. 
Besonders frage ich mich, ob "Processing" das richtige Hilfsmittel für 
dieses Vorhaben ist. Gibt es einen deutschsprachigen Workshop, der die 
einzelnen Arbeitsschritte behandelt, mit denen man am Ende zu einem 
lauffähigen Programm kommt?
Eure Hinweise sind  willkommen. Vielleicht sollte ich diese Fragen in 
einem neuen Thread ansprechen.