Fragen über Fragen

[yahp]

Hallo,

momentan habe ich leider nur einen recht groben Überblick über den 2131. Daher wird mir aus den bislang vorliegenden Codeschnipseln des Projekts nicht alles klar.

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?


Freue mich auf die Klärung dieser Probleme und interessante Diskussionen

[tschosef]

Hai Hai,

schöne Fragen. Aber Fragen bringt bei Bilda wohl nichts (mehr?). Irgendwie ist das halb tot hier. Verwendest Du Linux? Glücklicher, dann könnte es mal (irgendwann mal) gehen, wenn die Kernel da sind usw..

Ich versuch mit biegen und brechen das mit windows zu realisieren. Bin drann, habs aber auch noch nicht "vernünftig" hin bekommen.

SEHR erschwerend ist die etwas magere Komunikation hier im Forum.
Ich weis, alle warnen "Windows wird zu langsam sein"... aber was solls.

Scanner, die 40 000 PPS machen, leiste ich mir eh nicht, und wenn dann könnt ich mir auch andere Hardware leisten.
Meine machen vielleicht 10000PPS, Mots wohl noch weniger?

Hab einige Stunden damit verbracht das Datenblat des AN2135 (nicht der AN2131, wie Du geschrieben hast) durch zu lesen und zu verstehen.

Hast Du Ahnung von 8051er Asembler? Vielleicht könntes Du mir dann ja etwas helfen.

Ich bin halt damit beschäftigt mal eben 8051er Assembler zu lernen (kann bis jetzt "nur" PIC`s), und diese ziemlich umfangreiche EZ-USB Geschichte zu verstehen. Na in ein zwei Wochen wirds wohl vielleicht laufen.

FRAGE AN ALLE
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).

Das mit dem FIFO ist ne interessante Frage. Kann das überhaupt auftreten daß der voll ist? Ist das Auslesen nicht schneller als das Buffer Füllen? Weis ich jetzt grad garnicht. Da die DLL die ich verwende diesen ISO Übertragungsmodus nicht unterstützt, und ich "nur" Fast Block Transfers machen kann ergibt sich das Problem warscheinlich garnicht. Wobei ich da genau weiß, daß der USB-Core dann ein "NAK" sendet, wenn er keinen Bufferplatz hat, bis er wieder frei ist. Denk mal bei ISO gehts dann ähnlich.

Was ist das für ein Appnote? Link??

Grüße derweil
Erich

[yahp]

Moin, moin,

> Aber Fragen bringt bei Bilda wohl nichts (mehr?). Irgendwie ist das halb tot hier.

Na hoffentlich nur *halb* tot...


> Verwendest Du Linux? Glücklicher, dann könnte es mal (irgendwann mal) gehen, wenn die Kernel da sind usw..

Ich habe beide Möglichkeiten und muss mal sehen. 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.


> SEHR erschwerend ist die etwas magere Komunikation hier im Forum.

Der 'Chefentwickler' scheint halt nicht immer da zu sein


> 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.


> Hab einige Stunden damit verbracht das Datenblat des AN2135 (nicht der AN2131, wie Du geschrieben hast) ...

Tut mir leid, ich verwechsel die immer wieder. Was mich aber zu der Frage bringt, wo ihr die Controller herhabt. Segor und RS haben nur die 2131.

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...


> Hast Du Ahnung von 8051er Asembler? Vielleicht könntes Du mir dann ja etwas helfen.

Ich kanns versuchen. Habe allerdings nie so viel mit dem 8051 gemacht. Bin omentan mehr für die AVR. Am EZUSB gibts zwar einige Dinge, die Performance bringen (Fast-Transfer und Autopointer), aber wenn ich mir die Instruction Table so anschaue, wünsch ich mir immer nen AVR, der ist einfach schneller... Und dann die ganzen @'s und #'s im Quellcode ;-P


> Ist das Auslesen nicht schneller als das Buffer Füllen?

Wenn das Auslesen schneller wäre, würde der Puffe irgendwann leer sein und du könntest nicht unterbrechungsfrei scannen...

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...


> Was ist das für ein Appnote? Link??

Ist irgendwo bei Designressources versteckt.




Viele Grüße

[tschosef]

also... punkt für punkt.

den AN2135 hab ich bei Braintechnology.de bestellt. kostete so 15 euronen plus Versand per nachnahme.

<<<innerhalb eines USB-Frames (1 ms) die Daten aus dem Puffer des Endpoints in den Speicher des 8051 transferieren musst>>>

NÖ!
In der Firmware läuft das (soweit ich das verstanden hab) so:
Wenn SOF (start of frame) auftaucht, kommt inerrupt. Der startet den Timer2 der Controlers.

Immer wenn der Timerinterupt kommt, werden 5 Bytes mit dazupassenden PortC "Ausgegeben". Das läuft so:

Der Controler tut so, als ob er das Byte aus dem FIFO Buffer in einen externen Ram über den Datenbus (Also PortB) schreiben würde.
So kommt auch das WR signal zustande, was WR1 von den DA Wandlern bedient. Anstatt Ram Speicher hängen die 5 DA Wandler am PortB

Lediglich Port C muß noch "manuell" bedient werden.

Vom FIFO Buffer wird NICHTS in irgendeinen Speicher "zwischengespeichert".

OKAY??? Oder liege ich völlig falsch?

Ist der Buffer Leer, wird die Warn LED angemacht, und der nächste Timer interupt abgewartet.

Tjo..... glaub so läft das. DAS GEHT ABER NUR MIT DEM AN2135. Der 31er unterstützt diese Art des Auslesens (autopointer usw.) scheinbar nicht.


gruß
Erich

[yahp]

Mahlzeit,


> den AN2135 hab ich bei Braintechnology.de bestellt. kostete so 15 euronen plus Versand per nachnahme.

Schon fast unverschämt, der Preis...


> In der Firmware läuft das (soweit ich das verstanden hab) so:
Wenn SOF (start of frame) auftaucht, kommt inerrupt. Der startet den Timer2 der Controlers.

Bei genauem hingucken in den unkommentierten *eg* Quelltext könnte das evtl. sogar stimmen...

> Immer wenn der Timerinterupt kommt, werden 5 Bytes mit dazupassenden PortC "Ausgegeben". Das läuft so:

Das ist doch dann aber ungünstig, weil man dann ja aufhören muss, wenn der Buffer leer ist. Somit gibts keine streng gleichzeitigen Punktabstände...

Was die Ausgabe betrifft, so habe ich das schon verstanden.

> OKAY??? Oder liege ich völlig falsch?

Wahrscheinlich hast du recht. Hier kollidierten einfach meine Unkenntnis vom 8051, der Quellcode und meine Wunschvorstellungen.

> Tjo..... glaub so läft das. DAS GEHT ABER NUR MIT DEM AN2135. Der 31er unterstützt diese Art des Auslesens (autopointer usw.) scheinbar nicht.

Ja, wenn ich 31 sage, meine ich 35 So musst du das bei mir sehen ...


Viele Grüße

[afrob]

Hi!

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.

SEHR erschwerend ist die etwas magere Komunikation hier im Forum.

Sorry, dass ich in letzter Zeit hier ziemlich Abwesend war.

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 ).

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.

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.

> SEHR erschwerend ist die etwas magere Komunikation hier im Forum.
Der 'Chefentwickler' scheint halt nicht immer da zu sein

> 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.

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.

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.

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.

[yahp]

Hi.

Ah, endlich, der Meister persönlich...


Isochron:

Das diese Transferart verwendet werden muss, habe ich auch schon erkannt... Würde mir gerne deine Kernelquellen anschauen. Hoffentlich sind die nicht so überdokumentiert, wie der Firmwarecode des Controllers ;->


' ... 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. '

Ja, so klingts vernünftig.

Die Sache mit dem Endpointpairing ist mir ein Begriff. Die kopiererei schaft der EZUSB in einer halben Millisekunde, also in einem halben Frame
Ich kann immer noch nicht glauben, dass es geht ...

Kommentier doch bitte mal im Firmwarecode die Teile SOF und point_isr, damit ich verstehen kann, wie's funktioniert
oder erklärs hier noch ein wenig. Die Punktausgabe muss ja *ununterbrochen* laufen, nicht wie Tschosef schreibt, jedesmal erst in der SOF angemacht werden. Denn das würde ja bedeuten, dass sie immer mal aus ist, und somit nicht streng gleichzeitige Punktabstände produziert...

Viele Grüße[/quote]

[tschosef]

seehr schön!

Also, ich hab für mich selber versuch zeile für zeile zu kommentieren.
bin nicht besonders gut, deswegen evtl. mal so ne aussage, wie" schreibbefehl" anstatt lesebefehl...
wer will, kann ja mal meine "kommentare" haben, und mir auch gleich sagen, was ich da falsch "gecheckt" habe. Diese sind allerding keineswegs Professionell... nur so`n geschreibsl von mir.

was hier geschrieben wird find ich trotzdem klasse. endlich tut sich was (wenn auch "nur" diskussion).

@ Yahp
wich weis nicht ob jedes mal beim SOF Interupt der Timer gestartet wird. Ich meinte (glaube also nur) das beim ersten mal passiert. Kann mich auch täuschen.

prima, weitermachen
grüße
Erich

[afrob]

Würde mir gerne deine Kernelquellen anschauen. Hoffentlich sind die nicht so überdokumentiert, wie der Firmwarecode des Controllers ;->

Es hat einen Grund, warum die noch nicht mal im CVS zu finden sind . Das ist noch work-in-progress.

Die Sache mit dem Endpointpairing ist mir ein Begriff. Die kopiererei schaft der EZUSB in einer halben Millisekunde, also in einem halben Frame
Ich kann immer noch nicht glauben, dass es geht ...

Endpoint Pairing funktioniert nur für Bulk Transfers.
Der EZUSB muss eben *gar*keine* Daten kopieren, sondern schiebt die Daten vom isochronen Buffer, der als FIFO arbeitet direkt, an die DA-Wandler ohne die Daten selbst anzufassen.

Kommentier doch bitte mal im Firmwarecode die Teile SOF und point_isr, damit ich verstehen kann, wie's funktioniert oder erklärs hier noch ein wenig.

Ja, da fehlen in der tat noch einige Kommentare...

Also, ich hab für mich selber versuch zeile für zeile zu kommentieren. bin nicht besonders gut, deswegen evtl. mal so ne aussage, wie" schreibbefehl" anstatt lesebefehl...
wer will, kann ja mal meine "kommentare" haben, und mir auch gleich sagen, was ich da falsch "gecheckt" habe.

Kanst du die Datei mit deinen Kommentaren bitte bilda-devel@linux-laser.org oder mich schicken? Dann weiss ich ungefähr wo noch Kommentare fehlen.

Die Punktausgabe muss ja *ununterbrochen* laufen, nicht wie Tschosef schreibt, jedesmal erst in der SOF angemacht werden. Denn das würde ja bedeuten, dass sie immer mal aus ist, und somit nicht streng gleichzeitige Punktabstände produziert...

Die Punktausgabe wird eigentlich unabhängig vom USB Transfer kontinuierlich vom Timer aufgerufen. Allerdings gilt es zu berücksichtigen
- dass alle Punkte garantiert vor dem Umschalten des Buffers ausgegeben wurden
- dass direkt nach dem SOF ja der SOF Interrupt aktiv ist
- dass ~50ns vor dem Wechsel der Buffer keine Daten mehr gelesen werden können
- dass USB Datentransfer und Timerinterrupt mit der Zeit langsam auseinanderdriften können

Daher wird im SOF der Timer auf einen definierten Wert gesetzt, und zwar so, dass kein Timer Interrupt auftritt, während der SOF Interrupt noch läuft, und der letzte Punkt rechtzeitig vor dem automatischen Wechsel der Buffer ausgegeben wurde. Durch diese synchronisation auf dem SOF ist auch ein auseinanderdriften vermieden. (Dies macht das Timing der Laserausgabe abhängig vom korrekten Timing des SOF, was aber kein Problem darstellt, da alle USB Controller diesen aus einem quarzstabilen Takt ableiten). Der Timer Interrupt ist nur dann nicht aktiv, wenn der Buffer leer ist, was während der laufenden Ausgabe nicht vorkommen sollte.

[tschosef]

Hai Afrob,

ist ja echt ausgefuchst..... woher weist Du wie man das macht? Oder ist das nicht von Dir?
Ich schick Dir morgen mal meine "komentare".

Naaaaaaaabend.
Erich

[yahp]

Hallo,

habe die letzten zwei Tage wie verrückt mein 8051-Wissen wieder halbwegs aufpoliert und die EZ-USB Anleitung gefressen. Zumindest beginne ich jetzt zu verstehen, was gemacht wird


> Es hat einen Grund, warum die noch nicht mal im CVS zu finden sind . Das ist noch work-in-progress.

Na, gut, aber die Testprogramme sind auch noch keine Release-versionen

> Endpoint Pairing funktioniert nur für Bulk Transfers.

Ja, mittlerweile habe ich das auch eingesehen. Das doublebuffering der isochronen endpoints läuft anders -> auch toll.


> Die Punktausgabe wird eigentlich unabhängig vom USB Transfer kontinuierlich vom Timer aufgerufen. Allerdings gilt es zu berücksichtigen

Schon klar.


> - dass alle Punkte garantiert vor dem Umschalten des Buffers ausgegeben wurden

Richtig, aber das passt dann ja, wenn der Timerinterrupt entsprechend eingestellt ist.

> - dass direkt nach dem SOF ja der SOF Interrupt aktiv ist

Ja, ist klar. Aber damit kann man ja auch den Timer synchronisieren (wie du selber schreibst).

> - dass ~50ns vor dem Wechsel der Buffer keine Daten mehr gelesen werden können

WICHTIG!
Das ist genau der Punkt über den ich gestern gelesen habe, gut, dass du es ansprichst. Laut meinem Datenblatt ist diese Zeit nämlich 10 µs (mikro - nicht nano !!!) und es wird empfohlen 50 µs vor dem SOF mit Zugriffen auf den FIFO aufzuhören.

Ich sehe hier noch Diskussionsbedarf. Bitte gib' mir das Dokument, aus dem deine Werte stammen. So recht mag ich die nämlich nicht glauben, da dass für nen 24/4 MHz getakteten Prozi schon recht knapp ist...



Viele Grüße

[afrob]

Ich schick Dir morgen mal meine "komentare".

Danke für die Kommentare, ich werde sie teilweise in dir Firmware einfügen.

> - dass ~50ns vor dem Wechsel der Buffer keine Daten mehr gelesen werden können

WICHTIG!
Das ist genau der Punkt über den ich gestern gelesen habe, gut, dass du es ansprichst. Laut meinem Datenblatt ist diese Zeit nämlich 10 µs (mikro - nicht nano !!!) und es wird empfohlen 50 µs vor dem SOF mit Zugriffen auf den FIFO aufzuhören.

Du hast natürlich Recht, es sind 50 µs. Tatsächlich eingehalten werden aber nur 10 µs.
Bei 50kpps ist der Abstand zwischen den Punkten 20 µs. Der Timer muss im SOF eben so gesetzt werden, dass die Ausgabe 9 µs nach dem SOF beginnt, um 11 µs vor dem nächten SOF fertig zu sein...

[yahp]

Hallo,

warum hast du eigentlich zwei verschiedene Interfaces eingebaut? Ich kann nicht erkennen, wofür das gut sein soll?


Viele Grüße

[afrob]

warum hast du eigentlich zwei verschiedene Interfaces eingebaut? Ich kann nicht erkennen, wofür das gut sein soll?

Es handelt sich um ein Interface mit zwei "alternate settings". Die Standardeinstellung reserviert keine USB Bandbreite für den isochronen Endpoint, die andere Einstellung die für die Ausgabe erforderliche Bandbreite.
So braucht bILDA nur dann Bandbreite, wenn auch tatsächlich etwas ausgegeben werden soll. Wenn bILDA direkt nach dem Einschalten 25% der USB Bandbreite reservieren würde, würden sicher einige Nutzer diese Bandbreite z.B. beim übertragen von Datei aus einer Digicam etc. vermissen.

[yahp]

Hi,

nicht schlecht, muss man schon sagen. Ziemlich ausgefuchst die Sache.

Aber die Leute sollen Scannen, nicht fotografieren


Viele Grüße

[Gast]

Hiho.

Neue Frage:

Gehe ich recht in der Annahme, dass ich die umsetzung der Standard Device Requests nicht mit dem Cypress Controllcenter austesten kann?

Noch eine Frage (oder besser nochmal)

Warum nicht einfach das Alternate Setting 2 nehmen, was schon im EZUSB drinnen ist? Das hat ISO-Pipes mit 256 Byte Fifo?


Viele Grüße

[yahp]

Hi nochmal,

sorry, aber schon wieder ohne Namen unterwegs gewesen... (Reboot durch USB-Fehler )

Grüße