Hi! Ich habe (wie in einem anderen Thread schongesagt) meine eigene Applikation auf das CDC Beispiel von ATMEL aufgesetzt. Ob die Daten als Interrupt oder Bulk laufen ist erst einmal egal, da kann später optimiert werden. Also ich habe nun in meinem AVR einen virtuellen UART und auf meinem PC einen virtuellen COM4, der über usbser.sys sauber funktioniert, aber... Mein AVR sendet fleißig Daten, die er von anderer Stelle bekommt und das recht schnell nach dem Start. Meine Terminal (HTerm, Hyperterminal und andere eigene Software) verlieren aber jedes Mal die Verbdindung zum usbser.sys, wenn ich meinen AVR neu starte. Beheben kann man das nur, in dem man auch das Terminal neu startet, nachdem der AVR gebootet ist und sich im Device-Manager wieder als COMx bereit gemacht hat. Nun trudeln aber schon Daten ein, während ich das Terminal Programm noch nicht laufen habe und diese werden nicht abgenommen. Also bleibt der USB-Stack im AVR irgendwann stehen. Ich kann also meinen AVR nur Booten, wenn ein Terminal über usbser.sys die Daten abholt, kann aber das Terminal nur starten, wenn usbser.sys einen AVR gefunden hat... Hmpf! Die Abfrage if( Is_device_enumerated()) funktioniert nicht, da sie TRUE ist, sobald der AVR über usbser.sys eingeklinkt wurde. Damit weiß ich aber noch nicht, ob auch ein Terminal an usbser.sys hängt, dass die Daten auch abnimmt. Was brauche ich: ATMEL hat bzgl. der Modem Status / Control Lines leider nur ein TBD im Quelltext stehen. Daher fehlen mir auch die Informationen, wo und wie ich die virtuellen RTS,CTS,DSR... finden kann. Frage1: Hat da jemand detaillierte Informationen was die usbser.sys da zur Verfügung stellt? Frage2: Reicht usbser.sys eine Information an das USB-Device durch, ob überhaupt eine Terminal-Software am virtuellen COM Port hängt? Vielen Dank schon mal vorab Gruß, Ulrich
Hallo Ulrich, CDC ist Bulk-Transfer. Für Interrupt-Transfer brauchst Du keine usbser.sys. Ich kenne jetzt das Beispiel von Atmel nicht, aber Du kannst ja den AVR so programmieren, dass er erst anfängt zu senden, wenn er vom Terminal ein Start-Zeichen empfangen hat. Gruß Ralf
Also noch einmal anders herum: Ich habe eine Software, die eine alte Steuerung über die Serielle anspricht. Die neue Steuerung, basierend auf einem AT90USB1287, soll zuerst einmal weiter ein serielles Device emulieren, womit also beim CDC bin. Das macht eine Windows-Programmierung erst einmal überflüssig. Ich bin so weit gekommen, dass ich weiß, dass der Event eines Status Line Change durch den Stack von ATMEL durchgereicht wird. Ich habe die Software jetzt nicht hier, aber es fehlt in der unvollendeten Version von ATMEL das wValue dass den Zustand dieser status-lines beinhaltet und ich habe noch nicht heraus gefunden, wie ich daran komme. Gruß, Ulrich
Es gibt scheinbar nicht sehr viele, die mit den AVRUSB Chips arbeiten... Aber vielleicht können auch die helfen, die es low-level machen in einem ATmega8 oder ähnlichem. Grundsätzlich habe ich ein Verständnisproblem, wie ein Device einem Host mitteilen kann, dass es eine Status-Änderung hat. Vorstellbar sind ja zwei Wege: 1. Das Device sendet als Interrupt eine Status Änderung. D.h. der Host wird zyklisch über Status-Änderungen automatisch informiert. 2. Das Device wird vom Host über den CONTROL Endpoint mit dem Request GET_STATUS abgefragt, wenn sich auf der Host-Seite eine an das Device angekoppelte Software für diesen Status interessiert. Speziell auf das CDC Device bezogen: 1. Auf der phys. Seriellen ändert sich CTS, weil das daran angeschlossene Gerät ( z.B. altes Modem) einen vollen Puffer hat. Per INTERRUPT_EP aktualisiere ich den Status des virtuellen COM-Ports auf dem HOST PC. Wenn das dortige Terminal nun was senden will, stellt es fest, das CTS weg ist und wartet, bis es wieder kommt. 2. Auf der phys. Seriellen geht CTS auf low, der AVR merkt sich dies in einem Register. Nun will das Terminal auf dem HOST PC über den virtuellen COM Port senden und fragt diesen nach seinem Status. Diese Anfrage löst eine CONTROL Message GET_STATUS / GET_SERIAL_STATE aus, die der AVR mit dem aktuell gültigen state beantwortet. Leider finde ich keinerlei Dokumentation über das mögliche Verhalten der usbser.sys, bzw, welchen Weg sie wünscht oder unterstützt, oder welche Konfigurationen man übertragen muss, damit das eben funktioniert. Die USB Class Definition for Communication Devices schweigt sich über den zu verwendenden Enpoint für die Notification Event Notifications aus. Hat jemand eine Doku zu usbser.sys? Verwendet jemand Status Updates via Interrupt-Enpoint? Hat jemand eine funktionierende USB-Serial Bridge, die alle Hardware Handshakes unterstützt als source zum lesen und lernen? Fragen über Fragen und vielen Dank im Voraus für jeden Hinweis! Gruß, Ulrich
Probier mal: http://www.cygnal.org/ubb/Forum9/HTML/000945.html http://www.cygnal.org/ubb/Forum9/HTML/000935.html
Hi Urlauber! Danke für die Links. Geht etwas wild zu im ersten Thread, ich bin daher nicht nicht ganz sicher, was das Fazit dieser Forschungen sind. Ich denke aber, dass es bislang keinem gelungen ist, das Hardware-Handshake mit dem usbser.sys wirklich funktionierend abzubilden. Da ich keinen eigenen Treiber schreiben will, und das entwickelte Gerät auch nur Firmenintern verwendet werden soll, werde ich vermutlich unkonventionell vorgehen: Ich fake die Prolific VID/PID und melde mich als solches am USB Bus an. Zum einen sind Prolific basierende Produkte weit verbreitet und zum Anderen haben sie einen Linux Treiber in Sourcecode veröffentlicht, es stellt also nur eine kleine Hürde da, Vendor-Spezifische Teile im USB Device nachzubilden. Leider fehlt mir für die Treiberentwicklung für Windows (und Linux) einfach die Zeit und das Knowhow. Leider, weil es ein schöner Wiki Beitrag geworden wäre, eine voll funktionsfähige USB/CDC Implementation zu schreiben. Ich bin mir aber nicht im klaren, welchen Level an Glückshormonen bei Prolific aufkommt, wenn ich deren VID/PID fake und deren Treiber missbrauche. Also, jetzt muss ich mal sehen, ob es mit dem Prolific-Treiber funktioniert, dazu will er aber meinen Rechner neu starten. Bis später also :) Gruß, Ulrich
Hi! Das Problem ist gelöst. Zusammen mit ein paar Hinweisen vom ATMEL support geht nun auch das Handshake. Das cdc_demo_1.0.3 wurde um die Funktionen erweitert und ich habe es ATMEL zur verfügung gestellt. Sie werden noch die nötigen Adaptionen für andere Compiler als den AVRGCC einpflegen und es dann online stellen. Für alle, die nicht warten können und nur den gcc verwenden, ist das Demo hier im Anhang. Es zeigt u.a. auch, wie man im CDC mode Interrupt-Messages generiert. Gruß, Ulrich
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.