www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AT90USB an usbser.sys Handshake?


Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Potter S. (potter68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Urlauber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Link zu dem andern Thread:
Beitrag "AT90USB an usbser.sys Handshake?"

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.