ws2801 firmware - data latch verzögern

Hallo,

ein FIFO und ein kleiner Regler wäre hier besser. Du nimmst Daten entgegen bis zu einer bestimmten Grenze (w)... danach versuchst du, so lange wie die WS2801 gefüttert werden sollten, den Fifo bei der Füllstandsgrenze/Sollwert w zu belassen. Das machst du indem du den SPI Clock immer rauf unter runter schaltest. Ein einfach programmierter PI Regler würde das sicher gut hinbekommen. Kommt das "Ende Signal" sagst du dem Regler einfach: Sollwert w = 0

Wollte mal ähnliches programmieren, war mir dann aber zu schade um die Zeit, weil ich einfach keine 5000 Pixel zum befeuern brauche und der RAM immer locker ausreicht

Grüße

Basti

*edit* Sollwert "w" heißt es offiziell... nicht das das Platzhalter X jemanden verwirrt...

Hallo,

ja ich denke du verstehst mich falsch...

Also ein Fifo ist ein Buffer indem du alle eingehenden USB Daten reinstecken kannst und das erste was reingeht, bekommst du beim lesen wieder heraus. Was du Regeln musst ist der Füllstand des FiFos, er darf während USB noch Daten für das WS2801 Frame schickt, weder überlaufen (Daten gehen verloren) noch leer werden (WS2801 latchen zu zeitig). Die zu Regelnde Größe kann dabei nur der SPI Clock sein. Also wie schnell du die Daten an die WS2801 schickst.

Ein einfacher Zweipunktregler mit nur zwei SPI Geschwindigkeiten tut es sicher auch. PI Regler wäre halt das Sahnehäubchen

Grüße

Basti

P.S. Ist nichts anderes wie den Füllstand eines Behälters regeln, wenn der erstmal nicht leer werden darf, aber das Medium nur in Schüben kommt

Zitat von michuNeo

ok got it,

you got it not!

Das würde heißen, dass der FiFo Buffer so groß sein muss, dass das größte USB "Lag" nicht länger dauern darf als vom Sollwert w bis auf Fullstand 0 mit der langsamsten SPI Ausgabegeschwindigkeit. Das könnte z.B. auch ein 8 Byte großer FiFo schaffen....

Nehmen wir wieder den Behälter und ein größerer Behälter (die WS2801 Kette) steht darunter. Du füllst den oberen Behälter Langsam bis zum mittleren Füllstand und öffnest dann das Ventiel zum unteren Behälter (SPI Senden an). Dann fließt das Medium in den unteren Behälter. Nimmt der Füllstand zu sehr ab, drehst du das Ventil wieder etwas zu (SPI langsamer takten). Ist der Behälter wieder über der hälfte, drehst du das Ablassventil wieder etwas auf.
Die Folge ist: Die hast immer einen Fluss zum unteren Behälter, da du ein kleineren Bufferbehälter vorgeschalten hast...

ALSO, besser kann ichs nun wirklich nicht erklären. SORRY

gut erklärt, Basti!

Michu: Ich würde mal folgendes probieren: Da steht doch oben was drin, dass man da irgendwie ein Delay einstellen kann, also die Ausgabe verlangsamen:

Zitat

// these delays allow for more reliable transmission on long wires
// 6 total "nop" are recommended for best speed
// 9 total may still allow max speed, if you're lucky...
// more than 9 will slow the speed

Wenn ich das richtig verstanden habe, ist bei diesem Teensy/Arduino-Zeugs ja schon ein Puffer für den USB-Empfang drin, also das ist jetzt nicht so wie bei mir in asm, wo ich auf jedes empfangene Byte gleich reagiere(n muss) und das weiter verarbeite, sondern die landen erst mal in nem Buffer...(?)

also einfach mal da bei der Ausgabe die Geschwindigkeit bisschen runter drehen, evtl. reicht das schon, dass keine zu große Lücke entsteht...

Problem ist hier halt wie immer der Datendurchsatz, wie schnell geht das denn, 1 Mbit, 2 Mbit, oder hat der Teensy nen Xmega mit nativ USB...?

weil bei 5.000 Pixel und hlabwegs vernünftiger Framerate hast Du dann halt andererseits auch keine Lücke mehr, die Du ja brauchst zum latchen...

Zitat

ist diese verzögerung grösser als 500us (und die clock line low ist) schaut der ws2801 den datentransfer als beendet an und zeigt die neuen daten an. das führt dann natürlich zu fehler in der anzeige.

was nun? ich habe versucht, die clock line auf high zu belassen, bis ich die letzten daten rausgeschickt habe, leider ohne erfolg (geflacker).

das Problem dabei ist: dem WS2801 ist das hier wurscht, ob Clock low oder high ist, einfach wenn der Takt für 500 µs fehlt, dann wird gelatcht

das ist wieder mal so ne Sache, sehr schade, die *hätten* das ja so machen können, dass der Reset nur ausgeführt wird, wenn clock 500 µs auf low ist, und wenn's high bleibt, passiert einfach nix - dann hätte man alle Zeit der Welt beim Übertragen, kein Problem, wenn ne Lücke entsteht... einfach Clock nach jedem Bit erst mal auf high lassen, und nur wenn man definitiv latchen will, dann für 500 µs auf low legen

aber da hätte es wohl paar Transistoren mehr in dem Chip gebraucht und war dann zu viel Arbeit, das zu designen...

Hab' mir das Ding mal angesehen - der hat schon nen Puffer für die USB-Pakete, wenn ich das richtig sehe... also nicht in der Firmware, aber in der HW des µC

das ist nicht so wie bei mir mit Atmega und FT232, da kommen die Bytes der Reihe nach über den USART rein (der Puffer ist dort im FT232), bei jedem Byte gibt's auf dem ATMega nen Interrupt, und ich schicke das Byte weiter oder mache sonst was damit.

Hier ist ja der USB-Controller im µC, der empfängt ein komplettes USB-Paket (hier eben die 64 Byte) und schreibt das in's RAM - ist das Paket empfangen, dann liest die SW diese 64 Byte raus und schickt sie direkt weiter... (*da* ist dann kein Puffer mehr)

gibt's zwischen 2 Paketen nun ne längere Pause, dann auch bei der Ausgabe - Du könntest also, wie beschrieben, die Ausgabe mal langsamer machen, so dass er auch während der "Wartezeit" weiter Daten aus diesem USB-Puffer ausgibt - nur, Du musst das halt so timen, dass die Ausgabe nicht zu lange dauert, also dass nicht schon ein neues USB-Paket das alte überschreibt, während Du noch Daten ausgibst...

da halt mal mit diesen nops rumspielen, wie beschrieben, bis es passt...

wo kommen denn die Daten her...? - das finde ich schon ungewöhnlich, also wenn Du da komplette Frames in Pakete aufgeteilt schickst, dass da solche Wartezeiten (> 500 µs) entstehen können - evtl. kann man da auf PC-Seite ja noch was "tunen", dass die Daten gleichmäßiger raus kommen...?