Hi!
Yahp wrote:Brauchts wirklich nen Kerneltreiber? Cypress selbst hat ein Appnote für eine User-Space Kommunikation. Da's die Kerneltreiberquellen momentan nicht gibt, kann ich nicht rausfinden, wie es mit der übertragung gedacht ist. Im Testprogramm werden immer einfach Datenblöcke rausgeschoben. Was ist, wenn der interne FIFO voll ist?
Die Datenübertragung soll mittels isochroner USB-Transfers von statten gehen.
Ein bILDA-Punkt besteht aus 5 Bytes (X,Y,R,G,B). Angenommen der Benutzer stellt 50000pps ein, so müssen pro Sekunde 250000 Bytes übertragen werden. Also in jedem USB-Frame, welches 1ms dauert, 50 Punkte = 250 Bytes. Der Treiber teilt dem USB Stack diese benötigte Bandbreite mit und reserviert dadurch 250 Bytes eines jeden USB Frames ( also ca. 25% des Frames). Alle anderen Transferarten (wie Bulk-, oder Interrupttransfers) teilen sich die restlichen 75%. Aufgabe des Treibers ist nun in jedes Frame jeweils 50 Punkte=250 Bytes zu packen. Der Treiber enthält nochmal einen eigenen Puffer, um diese 250 Bytes auch immer im Kernelspeicher vorrätig zu haben, da die Frames in einem Hardware- Interrupt Kontext gefüllt werden. Daher ist das im Userspace wohl auch nicht möglich. Die libusb unterstützt AFAIK auch keine isochronen Transfers.
Isochrone Datentransfers sind für flüchtige strömende Daten gedacht; es wird keine Überprüfung der Daten vorgenommen. Liesst der Mikrocontroller die empfangenen Daten nicht rechtzeitig, sind sie beim Start des nächsten Frames verloren.
Das entspricht aber auch der Natur der Scannausgabe: Was nützt es mir zu wissen, dass der nächste Punkt garantiert grün ist, wenn diese Information (wie z.B. durch einen Übertragungsfehler) eine Sekunden zu spät kommt? Einzelne falsche Werte sind in der Regel problemlos zu tolerieren.
Tschosef wrote:SEHR erschwerend ist die etwas magere Komunikation hier im Forum.
Sorry, dass ich in letzter Zeit hier ziemlich Abwesend war.
Tschosef wrote:Ich weis, alle warnen "Windows wird zu langsam sein"... aber was solls.
Ich glaube nicht, dass es noch stark von der Geschwindigkeit des Betriebssystems abhängt, ob es möglich ist diese paar Punkte auszugeben. Hat man die Timingprobleme gelöst hat der Rechner mit der eigentlichen Ausgabe kaum noch arbeit. Auf heutigen GHz-Rechnern geht das sicher sogar mit CP/M oder DOS (huhu Gento
).
Tschosef wrote:Hat eigentlich außer der/dem Entwickler selber irgendjemand BILDA bei sich zu hause schon mal laufen gesehen? Irgendwelche Punkte? Irgendeine DA-Wandler Ausgabe? (ich mein jetzt nicht leuchtende LED`s).
Ich glaube nicht. Das wird sich aber hoffentlich bald ändern.
Yahp wrote:Ich will die USB Geschichte jetzt erstmal von meinem Kumpanen übernehmen (der gar keine Zeit mehr hat - während ich nur keine Zeit habe
, daher hab' ich momentan erstmal nur den Grundüberblick über die Thematik.
Die Firmware sollte eingentlich mit jedem Betriebssystemen funktionieren. Ich würde ja behaupten, dass es einfacher ist Tschosefs Software isochrone Transfers beizubringen anstatt eine neue Firmware zu erfinden.
Yahp wrote:> SEHR erschwerend ist die etwas magere Komunikation hier im Forum.
Der 'Chefentwickler' scheint halt nicht immer da zu sein
Yahp wrote:> Scanner, die 40 000 PPS machen, leiste ich mir eh nicht, und wenn dann könnt ich mir auch andere Hardware leisten.
Sag das nicht. Wenn du nach dem Erwerb eines (oder besser zweier) CT 6210 blank bist, bleibt dir nix anderes übrig.
Oh, ein Leidensgenosse.
Selbes Problem hier.
Yahp wrote:Den 2135 gibts nicht bei Segor, Farnell, RS, bei Reichelt sowieso nicht... Ich hab hier nur ein Angebot von MSC ab fünf Stück - allerdings wahrscheinlich nur an Geschäftskunden...
Einzelstücke für Privat gibt es bei
www.braintechnlogy.de.
Yahp wrote:Das Ding ist ja, dass du innerhalb eines USB-Frames (1 ms) die Daten aus dem Puffer des Endpoints in den Speicher des 8051 transferieren musst. Von dort geht es dann per Timerinterrupt weiter...
Die EZUSB-Entwickler waren so freundlich extra zwei Rambereich für isochrone Transfers in den Chip zu integrieren, die jeweils 1kb gross sind.
Damit ist es möglich gleichzeit Daten vom USB (ohne zutun der CPU) in den einen Speicherbereich zu empfangen und aus dem anderen Speicherbereich Daten zu lesen. Die beiden Speicherbereich werden automatisch zu jedem Framebeginn vertauscht (ping-pong-buffer). Angesprochen wird dieser Buffer über eine einzige Adresse, die bei jedem Zugriff das nächste Byte im Puffer liefert. Ergo muss die CPU keine Blöcke kopieren (was auf einem 8051 auch viel zu lange dauern würde). Dann kommt noch das "fast transfer"-Feature ins spiel. Ist dieses aktivert, liesst der EZUSB bei einem Lesebefehl nicht nur die Daten aus dem Puffer, sondern legt diese auch an den Datenbus und erzeugt einen Impuls auf der WR-Leitung.
Ein einzelner Befehl ( movx a,@dptr ) führt dann dazu, dass
-Ein Byte aus dem Puffer gelesn wird
-Der Adresszeiger des Puffers erhöht wird
-Das Byte im Akkumulator plaziert wird
-Das Byte an den Datenbus gelegt wird
-Ein Impuls auf der WR-Leitung erzeugt wird
Ganz automagic. Tolle Sache.
@Tschosef:
"movx a,@dptr" ist ein Lesebefehl für (normalerweise externes) RAM, kein Schreibbefehl. Es handelt sich also um einen "fast tranfer" des EZUSB, nicht um einen normalen RAM-Schreibzugriff.
Tschosef wrote:DAS GEHT ABER NUR MIT DEM AN2135.
Ja. Der AN2135 hat anstelle des Port B den Datenport, der für die fast Transfers nötig sind. Ich bin auch erst 'drauf reingefallen, da das in der Dokumentation nicht ganz so genau erwähnt wird.
)