Hallo zusammen Ich experimentiere gerade mit der USB-Schnittstelle des LPC2148. Gerne möchte ich die USB-Schnittstelle in einer Interrupt-Service-Routine laufen lassen. Ich habe das Beispiel von Bertrik Sikken zum Laufen gebracht, allerdings muss hier in der Hauptschleife immer eine Routine aufgerufen werden. Das ist für meinen Fall nicht brauchbar. Mich würde interessieren ob jemand von Euch auch schon an diesem Thema gearbeitet hat und falls ja, wie er es gelöst hat. Verwendet man eine Timer-Routine o.ä. Irgendwie muss man es ja auch schaffen, dass sich der PC ja nicht mitten drin verabschiedet, wenn mal 1s nichts über die Schnittstelle gesendet wird I arbeite übrigens mit einem gcc-Compiler und einem Olimex-Board, wie hier im shop zu haben:) Beste Grüsse und vielen Dank für Eure Tipps Geri
Hallo Gerhard, diese Routine behandelt meist den "allgemeinen" USB Transfer. Das beginnt dann damit, dass die USB-Interrupt-Leitung gepollt wird (in der Hauptschleife), um zu sehen, was es Neues auf dem Bus gibt: welcher Interrupt ist aufgetreten? Welcher Endpoint ist gemeint? Setup-Packet angekommen? ... usw. Du brauchst keinen Timer. Es sollte möglich sein, diese Routine (mit wenigen Anpassungen) vom Interrupt aus aufzurufen. Voraussetzung: man kennt sich in der USB-Spezifikation ein wenig aus. Es gibt ein Buch von J. Axelson, darin ist das Ganze recht gut erklärt. Gruß Ralf
Hallo Ralf Vielen Dank für Deine Hilfestellung! Das klingt mal schon sehr positiv! Ebenen, ich habe mir nur gedacht, dass MS-Windows o.ä. laufend eine Rückmeldung vom Client benötigt um festzustellen, dass noch ein Gerät angeschlossen ist. Schön wäre es eben, wenn der gesamte Datentransfer im Hintergrund ablaufen kann, ähnlich wie man es bei der RS232 machen kann. Dein genannte Link zum Buch schaut vielversprechend aus, danke! Denke, diese Schnitttelle ist recht komplex. Werde meine Suche im Web noch ein wenig ausweiten. Es wundert mich eben, dass ich im Web dazu noch kein Beispiel gefunden habe. Hätte gedacht, dass dieses Problem viele betrifft. Vielleicht ist es aber nicht so ein grosses..:) Beste Grüsse und nochmals vielen Dank für Deine Hinweise Geri
Ach ja, kennt jemand zu diesem Thema vielleicht auch noch eine online-Literaturquelle? Beste Grüsse Geri
Der Grund warum das beim µC kaum jemand interrupt-gesteuert macht, ist einfach der, daß es wenig Sinn macht. Bei einer reinen Software-Implementierung wie USBtiny &co braucht man die noch, sobald der µC aber Hardwareunterstützung für USB hat, ist es einfacher ohne. Der ganze Datentransfer wird ja von der Hardware gemacht, die Software muss nur ab und an nachschauen, ob wieder ein komplettes Frame angekommen ist, das bearbeitet werden muss. Ob du das jetzt früher oder später machst, ist egal. Also besser im Hauptprogramm, wenn eh Zeit ist, und nicht in einer ISR, wo du dir nur einen unnötigen jitter auf evtl wirklich zeitkritische Interrupts holst.
Hallo Ernst Vielen Dank für Dein Feedback. Du hast bestimmt recht. Ich verstehe deine Argumente. Dummerweise habe ich eine Echtzeitanwendung, bei der eine hoch priore Funktion die unter Umständen mehrere Sekunden läuft. Momentan funktioniert das Programm mit der Uart-Schnittstelle. Ueber Uart wird byte für byte eingelesen. Sobald ein neuer vollständiger Befehl da ist wird ein Flag gesetzt. Dieses Flag wird von der hoch prioren Funktion laufend gepollt. Ist das Flag gesetzt, dann wird das neue Kommando sofort ausgeführt. Das funktioniert sehr gut, nur eben nicht mit USB:) Das Polling einer Variable funktioniert dann halt recht schnell. Deshalb die ISR oder gibt es hier Deiner Meinung nach vielleicht einen bessere Lösung? Beste Grüsse Geri
Hmm, mit der USB-Behandlung in der ISR sparst du dir dann aber auch nicht viel, oder? Dann wird dein hochpriorisierter Task ständig von der USB-ISR unterbrochen, die dann relativ viel Zeit verbraucht. Wenn das nix macht, als Quick&Dirty Methode das usb-pollen, wie oben schonmal geschrieben, einfach in einen Timer-Interrupt packen. Ansonsten isses warscheinlich mehr zum umschreiben an deinem USB-Stack. /Ernst
Hallo Ernst Vielen Dank für Deine Rückmeldung. Verstehe ich dich dann richtig? 1.) codiere eine Timer-ISR, welche z.B. alle 100ms aufgerufen wird und die USB-Verbindung zum PC am Leben erhält 2.) frage in der hochprioren Task ein Flag ab, welches angibt ob ein neues Frame vorhanden ist. Gibt es zu Punkt bei USB auch so ein Flag etwa bereits schon? Beste Grüsse Geri
Wie wärs mit usb-interrupt initialisieren und im interrupt die USBHwISR() aufrufen?!? das funktioniert bei mir sehr gut...
Hallo Andreas Das klingt sehr interessant. Wenn ich Ralf und Ernst richtig verstanden habe, dann übernimmt USBHwISR() die Hintergrundaufgaben, die man ggf. auch zyklisch in einer Timer-Interruptroutine aufrufen könnte. Irgendwo müsste es für mich auch eine Flag geben, welches mir anzeigt ob neue Daten vorhanden sind. Mich würde aber sehr interressieren, wie Deine Lösung aussieht. Kannst du mir hier bitte vielleicht weitere Hinweise geben wich ich das konkret lösen kann oder zumindest einen Link der mit die Sache klarer macht? Vielen Dank nochmals und beste Grüsse Geri
Das verstehst du schon richtig, dass du den usb controller duch die USBHwISR() "pollst". also initialisierst du nen usb-interrupt (siehe timer-interrupt-beispiel bei winarm) und packst in den handler die USBHwISR() und fertig. wenn du dann noch flags für dateneingang brauchst schreibst du die _HandleBulkIn/_HandleBulkOut-funktionen rein...
Hallo Andreas Vielen Dank für Deine Rückmeldung. Nun bin ich etwas durcheinander. Soll USBHwISR() nun in eimem TimerInterrupt oder durch einen "USB-Interrupt" - so wie du schreist - aufgerufen werden?:) Ziat " ..also initialisierst du nen usb-interrupt (siehe timer-interrupt-beispiel bei winarm) und packst in den handler die USBHwISR() und fertig." Punkt 2 habe ich gecheckt:) Ach ja, mit welchen libraries kommunizierst du eigentlich PC-seitig? Beste Grüsse Geri
nix timer-interrupt. kannst dir dazu nur das winarm-example zum erstellen eines interrupts (als allgemeines bsp) anschauen. die USBHwISR() kommt dann in den usb-interrupt... pc-seitig arbeite ich mit libusb...
Hallo Rupplyn Vielen Dank, genau so habe ich es gestern Nacht auch noch gemacht. Funktioniert bis jetz einwandfrei. Werde diese Lösung dann allen zur Verfügung stellen. Nun bin ich an libusb dran. Das UBS-Testprogramm erkennt mein LPC2148-USB-Programm. Ich arbeite aber mit Delphi. Hierzu habe ich eine Portierung von libusb im Internet gefunden. Hier komme ich leider nicht weiter. Irgendwie stürzt mein Programm gleich ganz am Anfang ab. Vielleicht ist es so, dass sich die zwei libusb-Versionen auf dem Rechner nicht vertragen... Beste Grüsse und vielen Dank Geri
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.