Kleine Schaltung: SPI nach WS2811-Umsetzer mittels Standard-Logik-Bausteinen

  • Tom, bau die Schatung sauber auf 'ner Platine auf, statt auf 'nem Steckbrett.
    Dann werden die Signale schon deutlich besser aussehen.


    Achte auf Entkoppelkondensatoren, dichtest möglich an den Versorgungsanschlüssen der ICs.


    Beim Platinenlayout achte auf sternförmige Verbindung der Spannungsversorgungsanschlüsse (inkl. GND) zu einem gemeinsamen Sternpunkt - eine Kombination aus Elko und Kerko, dem die Versorgungsspannung vom Netzteil zugeführt wird.
    Dein Steckbrett-Aufbau weicht von diesem Ideal natürlich sehr ab.


    Wenn die Eingangssignale vom RasPi über 'ne Leitung zugeführt werden, solltest Du diese terminieren, um Reflexionen weitgehend zu minimieren.


    800 kHz sind eben schon fast ein MHz. Da treten schon allerhand Schmuddeleffekte auf, wenn die Leitungsführung suboptimal ist.


    Und: Wer misst misst Mist ...
    Ein Oszi belastet eine Signalquelle. Dass kann sich positiv auswirken, indem Störungen bedämpft werden. Dann sieht ein gemessenes Signal besser aus, als es ohne angeschlossenem Oszi tatsächlich ist.
    Gerade die Signale vom RasPi, wenn diese über eine Zuleitung kommen und nicht terminiert wurden, werden sicherlich deutlich vom Oszi-Tastkopf beeinflusst.

  • Ach ja, auch nochwas, was die Doppeltrigger auslösen könnte:


    Wenn du den HC-Typ verwendest und SCK vom Raspi mit 3,3 V Pegel kommt, dann bist du ziemlich genau am Rande des Thresholds vom HC bei 5V (0,7 x 5 V = 3,5 V). Wenn dann beim Rechtecksignal bei den aufsteigenden Flanken aufgrund der Verkabelung noch etwas Überschwingen und Ringing auftritt, kann es eben durchaus zu Doppeltriggern aufgrund des Schwingens um den Thresholdwert herum bei kleinen Pulsweiten kommen (weil die Dauer des Ringings länger als die Pulsdauer ist). Mit dem HCT-Typ sollte das nicht mehr auftreten, da dort der Threshold mit ca. 2 V deutlich unterhalb der Schwing-Amplitude liegt. Auch deshalb ist hier ein HCT-Typ eigentlich unabdingbar.


    Gruss
    Neni

  • Nochmals Hallo


    @Neni:
    Die Variante mit dem übrigen XOR als zusätzlicher Puffer habe ich auch getestet. Hat aber nix gebracht.
    Die Anmerkung zum Thema HCT ist einleuchtend. Habe den Chip schon bestellt und bin gespannt was passiert.
    By the way: Ich bin tatsächlich in der Nähe von Zürich zuhause


    Irrlicht:
    Mit ist klar, dass die Steckbrettgeschicht doch sehr suboptimal ist. ;) Ist ja auch nur ein Versuch.
    Sobald klar ist, dass sich die Schaltung wie gewünscht verhält werde ich natürlich eine Platine ätzen. Wird sicher wieder eine längere Übung bis ich ein halbwegs brauchbares, einseitiges Platinenlayout gezeichnet habe.
    Den Tipp mit der Stromversorgung habe ich begriffen, aber den Hinweis auf die Terminierung der Datenleitung vom Raspi verstehe ich nicht ganz (Bin halt eher der Software als der Hardware Mensch). Kannst Du mir einen Tipp geben was Du da genau machen würdest? Danke.


    Viele Grüsse


    Tom

  • Zitat

    Den Tipp mit der Stromversorgung habe ich begriffen, aber den Hinweis
    auf die Terminierung der Datenleitung vom Raspi verstehe ich nicht ganz

    Suchfunktion des Forums, Suchwort: "Terminierung".
    Ergebnisliste:
    http://www.ledstyles.de/index.…58&highlight=Terminierung


    Daraus ein gut erklärtes Posting von Neni:
    8x8 RGB Tisch - Schaltungsprüfung ;)



    Was übrigens gerne vergessen wird, wenn es um Frequenzen in Digitalschaltungen geht:
    Entscheidend für die Leitungsreflexion bei Fehlanpassung ist nicht die Frequenz des Signals an sich.
    Entscheidend ist allein die Frequenz, die aufgrund der Flankensteilheit des Treibers möglich wäre!
    Bei einem nahezu perfekt rechteckförmigen Signal wäre die mögliche Frequenz halt sehr hoch.


    Also: Man wünscht sich, dass ein Treiber ein rechteckförmiges Signal raus gibt.
    Erst recht wünscht man sich, dass dieses Signal genau so beim Empfänger ankommt.
    Was aber ankommt, hat plötzlich Überschwinger. Diese treten auch dann auf, wenn das eigentliche Signal nur eine Frequenz von wenigen Herz hat! Nur sieht man es auf dem Oszi dann nicht mehr.
    Es tritt bei jedem Flankenwechsel auf, egal wie oft diese Wechsel pro Sekunde erfolgen.


    Bei RS-232, wenn man da mit Störungen durch zu lange Leitungen zu kämpfen hat, hilft es, mit der Baudrate runter zu gehen. Denn dann hat die Leitung genug Zeit, sich einzuschwingen. Der Empfänger versucht sich dann den Pegel im eingeschwungenen Zustand heraus zu picken.


    Mit Terminierung beseitigt man die Überschwinger weitestgehend, der Empfänger "sieht" also saubere Signale, dadurch kann man mit der Frequenz der Nutzdaten rauf.


    Lese mal hier:
    http://www.mikrocontroller.net/articles/Wellenwiderstand

  • Gnar, die Forensoftware hier so so buggy!
    Ich bearbeite das letzte Posting jetzt nicht nach, sonst wird mir wieder alles geschreddert.
    Ledstyles ist echt das Forum mit der tollsten Community! Wenn doch nur die Software funzen würde.


    Zitat

    Wird sicher wieder eine längere Übung bis ich ein halbwegs brauchbares, einseitiges Platinenlayout gezeichnet habe.

    Probiere mal Scooter-PCB:
    http://www.hk-datentechnik.de/scooter-pcb.php


    Ist alt, wird nicht mehr gepflegt, hat keinen integrierten Schaltplaneditor. Ist aber kostenlos und hat die IMHO beste Bedienbarkeit, von der sich Eagle gerne mal was abgucken könnte.
    Menüs, Layerfarben und Tastenkürzel kann man selbst definieren, dann wird es richtig easy.

  • Servus zusammen,
    hab mir das Thema hier mal ein wenig zu Gemüte geführt. Feine Anregungen gibt es hier.
    Ich hab die hier rumgeisternde Schaltung noch ein klein wenig optimiert (Bauteile weg optimiert) und bin schließlich auf die Schaltung die ihr hoffentlich im Anhang findet gekommen.

    Bis auf die Timings die bei LTSpice offenbar mehr Schrott als sinnvolles ergeben, hat sie in der Simulation sehr gut funktioniert. In der Simulation hab ich durch ausprobieren für die Cs 330pF und für die Rs 1k und 3k ermittelt. Naja, ich vertraue da mal mehr auf eure praktischen Versuche und Werte und hab daher diese in den Schaltplan geschrieben...
    Wenn sich jetzt noch jemand findet der sie testen kann... ich kann das gerade leider mangels ICs nicht.


    Funktionieren sollte das dank des AHCT dann auch mit den 3.3V aus dem RasPi oder mit sonstigem 3.3V SPI auf 800kHz.
    Der SlaveSelect ist high-active. Also SS > 2V selektiert, SS < 0.7V deselektiert. Nur sollte man nicht zu früh deselektieren, sonst könnte das letzte Bit sofern es eine "1" ist etwas gekürzt werden (was die WS2811 ICs allerdings sicherlich nicht einmal stört).


    Viel Spaß damit. Testen werde ich die Schaltung wohl nicht vor ein bis zwei Wochen können, da ich die Teile alle erst bestellen muss...


    Ach ja, das NAND am Ausgang kann auch durch 2 Transistoren mit Pullup ersetzt werden (Emitter an GND, Basis mit vorwiderstand an die invertierten Ausgänge, Collectoren verbinden und mit einem z.B. 1k Widerstand nach 5V). Alternativ geht auch ein OR-Gatter an den nicht invertierten Ausgängen.

  • Hallo


    Noch eine kleine Idee zum Thema Schaltung vereinfachen:
    800khz ergibt pro Bit 1.25us. Der Ws2811 erwartet für eine 1 einen Puls von 0.6us. Ev könnte man ein Monoflop einsparen und für die 1 Pulse direkt auf das Clocksignal vom SPI zurückgreifen um einen Puls von 0.625us zu erhalten. Die Genauigkeit dürfte vermutlich ausreichend sein.


    Gruss


    Tom

  • 800khz ergibt pro Bit 1.25us. Der Ws2811 erwartet für eine 1 einen Puls von 0.6us. Ev könnte man ein Monoflop einsparen und für die 1 Pulse direkt auf das Clocksignal vom SPI zurückgreifen um einen Puls von 0.625us zu erhalten. Die Genauigkeit dürfte vermutlich ausreichend sein.


    Ich glaube der Vorschlag kam schon einmal. Ist prinzipiell möglich und die Genauigkeit sollte auch sehr gut ausreichen, nur hast du dann immernoch den kurzen "0"-Puls und der braucht halt irgend einen Monoflop. Das kann man dann zwar mit nem NE555 aufbauen, aber das benötigt dann wieder mehrere Logikgatter am Eingang für ein SlaveSelect etc. Die 74xx123 haben bereits zwei Monoflops integriert und das auch noch mit passender Eingangslogik. Die Schaltung von mir oben benötigt "nur" 2 ICs, 2 Widerstände und 2/4 Kondensatoren (2 Kondensatoren für die Schaltung, 2 für die Stromversorgung, Hardliner können also sogar noch die 2. zwei Cs einsparen)


    Wo ich gerade parallel noch dran bin (Hilfe erwünscht) ist ein kleiner AVR, der die Umsetzung in nur einem Chip erledigt. Passend wären da z.B. die AVR ATtiny25, weil die dank einer PLL mit einer 16MHz-internen-Taktquelle angetrieben werden können und durch vertrimmen des internen RC eventuell sogar auf 20MHz aufgebohrt werden können. Meinen Überlegungen nach müssten aber die 16MHz knapp ausreichen. Würde ich einen Timer-Counter sinnvoll in einen single-Shot-Modus bewegen können, dann käme man evtl sogar mit geringerer Taktfrequenz aus... :S

  • Hier noch ein kleiner Nachtrag zu meinem Versuchsaufbau (siehe Beitrag weiter oben)
    :
    Heute habe ich den 74HCT123 erhalten und natürlich sofort einige Versuche unternommen.


    Mit dem HCT Typ müssen die Timmingkomponenten angepasst werden. Die Wiederstandswerte habe ich beibehalten und statt den 100pF Cs solche mit 220pF verwendet. Damit passen die Pulsweiten recht genau.


    Leider wird der Betrieb dadurch nicht stabiler. Es kommt bei der Ausgabe auf dem Stripe immer noch zu Fehlern. Auf den ersten bilck scheinen die ersten Bytes verschluckt zu werden. Muss ich aber noch genauer rausfinden.

  • Leider wird der Betrieb dadurch nicht stabiler. Es kommt bei der Ausgabe auf dem Stripe immer noch zu Fehlern. Auf den ersten bilck scheinen die ersten Bytes verschluckt zu werden. Muss ich aber noch genauer rausfinden.

    Was ich schon die ganze Zeit denke:
    SPI und das Timing des Pixelcontrollers sind ja in keiner Weise synchronisiert.
    Im Grunde müsste das SPI-Timing absolut perfekt auf das Timing des Pixelcontrollers abgestimmt sein, was es aber nicht ist.
    Da kann ich mir sehr gut vorstellen, dass ab und zu Bits verschluckt werden.


    Es ist ja schön, dass die Pulse am Ausgang der Umsetzerschaltung zum Pixelcontroller passen.
    Aber was nützt das, wenn die SPI-Bytes nicht als ein völlig gleichmäßiger Stream kommen, sondern ab und zu mit kleinen Pausen dazwischen, weil der RasPi nebenbei noch andere Dinge macht?
    In dem Moment wäre auch der Datenstrom zum Pixelcontroller nicht mehr korrekt, obwohl die Pulsweiten stimmen.

  • Eine Pause interpretiert der Pixelcontroller als das Ende des Datenstroms und als Übernahmesignal zum Aktualisieren der LEDs.
    Alles, was nach der Pause kommt, wird als neuer Datenstrom behandelt.


    IMHO müsste eigentlich ein FIFO her, groß genug, um den kompletten Datenstrom für die jeweilige Anzahl LEDs aufzunehmen.
    Aus dem FIFO dann mit perfektem Timing für den Pixelcontroller abspulen.


    Dann kann der RasPi mit beliebigen Pausen seine Daten per SPI senden - das Befeuern des Stripes beginnt erst dann, wenn die Daten für alle LEDs im FIFO sind.

  • Meine Überlegung dazu ist gerade, einen kleinen µC zu nehmen und jeweils 3 Byte (1Pixel) zu Puffern und dann direkt im entsprechenden Format wieder zu Senden. Hierbei könnte man dann auch im µC die Bytes so aufblasen, dass jedes Bit zu einem Byte wird, das mit 8-facher Geschwindigkeit über dessen SPI gesendet wird ("1" => 0b11110000; "0" => 0b11000000), sodass man direkt mit dem µC das passende Signal generiert. Ein µC mit 2 SPI-Schnittstellen wäre dann natürlich Vorausgesetzt und einer mit DMA wäre genial...
    Solche µCs (STM32 z.B.) haben aber dann vermutlich sowieso schon wieder so viel Speicher, dass man gleich alle Daten Buffern könnte...

  • Ja, Du sprichst es aus, Don.


    Wobei das alles dann fast schon wieder bekloppt ist. Am Ende hängt man einen RasPi hinter den RasPi.
    OK, so in der Art gehe ich auch gerne vor. 'Nen AVR entlasten, durch hintendranhängen eines zweiten Controllers.
    Die sog. "intelligenten Displays" machen ja ebenfalls genau so was. Diese nehmen Hochsprachenbefehle entgegen und kümmern sich dann selbst um die Ausgabe der Grafik.


    Aber zu dem Puffern aller Daten: Obwohl das als der Königsweg erscheint, sei angemerkt, dass das auch den blöden Nebeneffekt der Zeitverzögerung beinhaltet.
    OK, es ist nicht viel. Aber wenn ein langer Stripe im Takt zur Musik angesteuert werden soll, summieren sich halt die Zeiten, die schon der steuernde Controller (der die Effekte bereit stellt) an sich braucht und die FIFO-Funktion der Umsetzerschaltung, die erst dann loslegt, wenn der Puffer komplett voll ist.
    Sind natürlich nur Sekundenbruchteile, will es aber erwähnt haben.

  • Aber zu dem Puffern aller Daten: Obwohl das als der Königsweg erscheint, sei angemerkt, dass das auch den blöden Nebeneffekt der Zeitverzögerung beinhaltet.


    Naja, aber vom Raspi zum µC kann man ja dann auch vollgas die Daten rumtakten, wenn der eh schon Puffert. Und man könnte mit dem Empfang des ersten Bytes auch schon beginnen das erste Byte wieder zu senden, da man vermutlich davon ausgehen kann, dass die Daten schneller vom Raspi kommen als sie durch die LEDs wandern können. Und schon ist die Verzögerung auf wenige µs reduziert...

  • Wenn man das Signal direkt ab SPI erzeugen will, wäre es ev einen Versuch wert das direkt mit dem Raspi zu machen. Mit 4mhz SPI Frequenz könnte das ev hinkommen. Muss morgen mal überprüfen ob der Raspi auf MOSI nach jedem Byte zwingend kurz auf low schaltet oder ob zwischen den Bytes auch ein High Status möglich ist.
    Falls ja, sollte es möglich sein jedes zu übertragende Byte auf 5 Bytes aufzublasen, diese mit 4mhz auszugeben und so ein passendes Signal zu erhalten.


    Wurde sowas schon mal versucht?

  • lizard.king ich glaube du wirst sporadische Fehler generieren. Da das Raspi ja die Datenbytes mit unregelmäßigen pausen zwischendrin sendet wird wohl der Takt nichteinmal mehr während eines Bytes des WS2811-Signals ungestört bleiben und damit vermute ich kommt der Chip dann nicht mehr klar. Ich vermute man muss dem Chip 24 Bit in seinem Format und konstantem 400/800kHz takt übertragen und darf dann bis zu 49µs pause machen bevor man das nächste Pixel überträgt... Damit schätze ich kommt er klar, alles andere wird er nicht verstehen.
    Im Worst case muss der Takt allerdings sogar während der gesamten Übertragung konstant bleiben und wenn das der Fall ist haben die Raspis so ziemlich verkackt... denn das geht nicht ohne echtzeitfähiges Betriebssystem, welches das auf dem Raspi afaik nicht ist. Dann hilft wirklich nurnoch ein großer Puffer...

  • Hier noch mal eine Vereinfachung der Schaltung (die Lösung mit nur einem Monoflop):

    Die Bauteile sind in kleinen SMD-Gehäusen erhältlich, so dass sich das Ganze sehr platzsparend aufbauen lässt. Der 2G08er ist ein dual UND und der 1G32er ist ein single ODER. Beim 74LVC1G123 (single Monoflop) ist unbedingt die Version von NXP und nicht die von TI (SN74LVC1G123) zu nehmen, da nur die NXP-Version laut Datenblatt mit einer Threshold-Spannung von 0 auf 1 von max. 2,7 V (2,2 V typ.) bei 5 V Betriebsspannung spezifiziert ist. Die Schaltung ist für den SPI-Standardmodus 0 (CPOL=0, CPHA=0) ausgelegt. Die Schaltung hier ist auch noch etwas Timing-Sicherer als die Modifikation von Don Luigi oben und auch als meine mit dem 123er Monoflop, da auf jeden Fall keine 'falschen' Trigger enstehen können, selbst wenn durch widrige Umstände (längere Kabel, versch. Impedanzen etc.) der Pegelwechsel am MOSI mal VOR dem entsprechenden Pegelwechsel am SCK vom Monoflop erkannt wird (in meiner vorigen 123er-Schaltung waren da zur Vermeidung die zusätzlichen Gatter als Verzögerer drin). CS in dieser Schaltung selektiert analog zu der von Don Luigi bei High-Pegel. Für Testzwecke lässt sich die Schaltung natürlich auch mit 74AHCT123, 74AHCT08 und 74AHCT32 in DIP-Gehäusen auf einem Steckbrett aufbauen, wenn man die nicht benötigten Eingänge an Masse legt. Von Wired-OR- oder Wired-NAND-Konstrukten mit Transistoren oder MOSFETs und PullUp-Widerständen (einige kOhm) würde ich bei solchen Schaltungen (mit relativ schnellen/kurzen Timings) generell abraten, weil die Flanken-Zeiten asymmetrisch werden. Fallende Flanken sind schnell, steigende hingegen langsam (je nach der Summe der parasitären Kapazitäten), was zu Timing-Problemen führen kann.


    Ich kenne den Raspi nicht, weswegen ich nichts dazu sagen kann, ob er in der Lage ist, einen ausreichend stabilen Datenstream (Pausen < 50 µs) per SPI aufrecht zu erhalten. Aber viele ARM-µCs haben eingebaute DMA-Controller, welche auch Kanäle vom Speicher zur eingebauten Peripherie (wie SPI, UARTs etc.) anbieten. Hat der ARM im Raspi nicht auch sowas, was man dann ev. nutzen könnte? Dann müsste man 'nur' den jeweiligen Speicher-Block schnell mit daten füllen, der DMA würde dann für das stabile Befüllen des SPI sorgen.


    Gruss
    Neni

  • Laut Datenblatt werden aber nur Pausen länger als 50 us als solche erkannt, kurze Pausen sollten also kein Problem sein!

    Doch, das ist genau das Problem - ich habe mit den WS2811 auch schon viel rumprobiert, und festgestellt, dass die (meine zumindest) bereits ca. 7 µs als Reset interpretieren.


    turi (von dem habe ich die) hat dann mit den Chinesen gemailt wegen den 50 µs, es hat sich raus gestellt, dass das wohl "andersrum" gemeint ist: Also nicht, für nen Reset müssen mind. 50 µs Pause sein, sondern es ist garantiert, dass spätestens nach 50 µs Pause ein Reset gemacht wird, der kann aber auch schon früher kommen...


    das hat mir auch Schwierigkeiten bereitet, weil 7 µs auf nem AVR mit 20 MHz auch nicht so viel Takte sind, die können schon bei ner USART-ISR auftreten, musste deswegen bei einem Projekt da auch nen SW-FIFO einbauen...


    ich habe auch festgestellt, dass es völlig wurscht ist, wo diese Pause auftritt, also ob zwischen 2 Bits in einem Byte, oder zwei Bytes, oder nach 3 Bytes (also "zwischen zwei ICs"), ab 7 µs warten gibt's Fehler...


    schade, die hätten nur die Pause wirklich so machen sollen, dass der Reset wirklich erst nach 50 µs auftritt, dann hätte man mehr (meist genug) Zeit, zwischen zwei Bits noch irgendwas zu machen... und da der Reset ja nur nach jedem Frame kommt, ist die Ausgabe immer noch schnell genug...


    Ein µC mit 2 SPI-Schnittstellen wäre dann natürlich Vorausgesetzt und einer mit DMA wäre genial...

    So macht Basti (Counterfeiter) das, mit nem XMega, er "rechnet" vorab den auszugebenden Frame um (2 Bit werden zu einem Byte) und schiebt den dann per DMA völlig ungestört über den SPI raus... das bläht natürlich die Datenmenge ziemlich auf...


    nur, so ein beschriebener 3-Byte-Umsetzer hilft ja auch wieder nix, wenn die Daten mit Pausen rein kommen - es ist wie gesagt egal, ob die 7 µs zwischen zwei Bits, zwei Bytes, oder 2 ICs sind...


    aber, der Pi hat doch bestimmt auch DMA und genug Speicher, statt noch mal was extra ranzuklemmen, kannst Du das nicht direkt im PI ebenfalls so machen, also jeden Frame erst mal umbasteln, und dann das Ganze per DMA raus schicken...?

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!