Kurze Frage zu tpm2 und minidmx...

Nicht so hastig mit den jungen Pferden....

Du hast hier auf der einen Seite mini-DMX bzw. tpm2, die sich recht ähnlich sind, auf der anderen Seite DMX, das sich deutlich von diesen beiden Unterscheidet:

Startcode: Bei tpm2/mdmx ist es ein "magic Byte", bei DMX ein frame error
Blocklänge: bei tpm2/mdmx festgelegt ("frei" oder in Abstufungen), bei DMX nicht - da gibt es nur die maximale Länge 512 Byte, wenn ein 12-Kanal-Pult nur 12 Kanäle raus schickt, ist das auch in der Norm
Blockende: bei tpm2/mdmx ein "magic Byte", bei DMX nicht vorhanden.

daher auch die Unterschiede in der Handhabung:

übliche DMX-Empfänger verarbeiten die Daten sofort, also warten auf Frame Error (=Blockstart), dann Startbyte (0x00), dann Bytes abzählen bis zum eingestellten Kanal, dann die für den empfänger bestimmten Bytes gleich wegspeichern (= PWM einstellen) oder weiter schicken, dann interessieren die restlichen Bytes nicht mehr, es wird einfach auf den nächsten Frame Error gewartet...

bei mDMX/tpm2 ist es vorgesehen, dass die empfangenen Daten gepuffert weden, und erst dann, wenn ein gültiges Blockende-Byte empfangen wurde, weiter verarbeitet werden.

dadurch hast Du natürlich die Verzögerung von einem Frame, aber wen interessiert's...? - also, wenn die eingestellte Animation 22 ms später nach Knopfdruck auf der Matrix erscheint, oder der Scheinwerfer 22 ms später angeht, das stört ja nicht.

Du kannst das natürlich, wenn Du willst, auch bei mdmx/tpm2 so machen, dass Dir das Blockende-Byte egal ist, und Du die Daten gleich weiter verarbeitest - das ist dann zwar nicht so wie vorgesehen/"genormt", funktioniert aber natürlich auch.

der Unterschied ist dann zu sehen, wenn mal ein Fehler auftritt: bei warten auf Endbyte und Daten verwerfen, wenn das nicht stimmt, bleibt die Animation einfach kurz stehen, wenn Du die Daten ohne auf Endbyte zu prüfen gleich weiter schickst, gibt es wüstes Geflacker...

ja, "sicher" sind alle diese Protokolle (auch normales DMX) nicht, das spielt aber in der Praxis keine Rolle... wenn Du ne extrem gestörte Leitung hast, kannst Du sinnvoll eh' nix mehr drüber schicken, wenn alle 2 Minuten mal ein Byte falsch ist, sieht das kein Mensch

bei meiner mdmx- und tpm2-Empfangsroutine wird immer auf Endbyte geprüft, erst dann die Daten übernommen - gibt es einen Fehler, dann wartet die Empfangsroutine wieder auf das Startbyte.

da kann es nun natürlich passieren, dass dieses auch im Datenstrom vorkommt, die Routine also an der falschen Stelle "einrastet" - nur, sie zählt dann eben die Bytes ab und erwartet nach einer bestimmten zahl das Ende-Byte - dass das dann nun zufällig auch noch (fälschlicher Weise, im Datenstrom) an dieser Stelle vorkommt, dafür ist die Wahrscheinlichkeit *sehr gering*.

auch schon beim "einrasten": es gibt ja nicht nur das Startbyte, sondern bei mdmx noch danach das Blockgröße-Byte, bei tpm2 das Blockart-Byte, für beide nur eine begrenzte Auswahl - dass also eine Byte-Kombination, die einen gültigen Blockstart ergibt, zufällig in den Nutzdaten vorkommt, ist sehr unwahrscheinlich...

deswegen rastet die Empfangsroutine auch (schon getestet per Datenleitung mit Taster unterbrechen) sehr schnell (wohl 1, 2 Frames, jedenfalls praktisch keine erkennbare Verzögerung) wieder richtig ein, ich ergreife da auch keine weiteren Maßnahmen, wie gesagt, bei einem Fehler werden die bereits empfangenen Daten verworfen und einfach auf den nächsten Blockstart gewartet...

Wie gesagt, der Routine ist es egal, welche Bytes bei den *Nutzdaten* vorkommen, wenn sie mal richtig eingerastet ist.

Also auch wurscht, wenn Du Byte 250-252 auf diese Werte setzt, weil es werden ja nach dem (richtig erkannten) Blockstart 256 Byte abgezählt, und *dann* erst auf das Blockende-Byte geprüft.

sonst wäre das natürlich Quatsch, weil da würde ja immer ein Block abgebrochen werden, wenn irgendwo in den Nutzdaten 0xA5 vorkommt...

Zitat von Counterfeiter

Das tpm2 kann doch bis 2^16 Bytes senden. Um das nun Normgerrecht mit zwischenspeichern zu implementieren brauch ich einen Controller der 65kByte SRAM hat. Und das haben wohl die wenigsten 8 Bitter...

klar, aber wann braucht man schon mal wirklich über 65.000 Kanäle...? - bzw. wenn man die braucht, geht das so (mit nem einfachen ATMega) eh' nicht, allein schon wegen der nötigen Datenrate...

hängt halt von der Anwendung ab - z.B. bei meiner mdmx/tpm2-auf-WS2801-Umsetzung bruache ich keinen doppelten Puffer, weil die Pixel selbst ja auch einen haben - ich speichere bis zu 3.072 Bytes (=1.024 RGB-Pixel, das geht noch gut über USB mit 1 MBit) im Mega644p, ist der Frame komplett, wird er an die Pixel geschickt, die das ja dann wiederum speichern, bis was neues kommt...

bei anderen Anwendungen (noch mehr Pixel über Ethernet o.ä.) braucht man dann eh' nen größeren/schnelleren µC (STM32 o.ä.), hat dann auch mehr Speicher...

Zitat von Counterfeiter

Bei richtigem DMX ist das schon anders... dort wird ja ein Startzeichen gewählt, welches nicht eins der normalen 0 bis 255 Werte entsprechen kann, damit ist es immer eindeutig wann der Start ist und es sollte keine Probleme geben...

ja, da ist das Startzeichen Frame Error und Nullbyte hinterher - kann aber auch versehentlich mal vorkommen, und dann gibt's Geflacker... habe ich in einer Location regelmäßig, wenn ich keinen Splitter dazwischen mache...

Zitat von Counterfeiter

Hab Bedenken, dass mdmx sich bei der falschen "Scheinwerfereinstellung" ewig nicht richtig einschwingt...

das müsste wie gesagt ein großer Zufall sein, nicht nur, dass das Endebyte stimmt, sondern dass es eben auch noch an der richtigen Stelle kommt - das ist dann schon *deutlich* unwahrscheinlicher als 1 : 256 - und bei ner laufenden Animation ändert es sich auch noch ständig

Zitat von Counterfeiter

P.S. Mit "professionellen DMX Sendern" meinte ich keine Slaves, sondern USB DMX Wandler....

ganz unterschiedlich, da gibt's div. Protokolle, wie über USB kommuniziert wird - eben z.B. Mini-DMX, Enttec, Dworkin, oder was anderes - beim E:Cue nano ein "geheimes" proprietäres Protokoll, usw.

Zitat von Counterfeiter

Also Wenn zufällig 3 Daten-Byte hintereinander beim mdmx Protokoll die Konstellation Endbyte,Startbyte,Paketgrößenbyte einnehmen, kann es beim Einschalten... also beim Einschwingen auf das Startbyte zu einer dauerhaften Fehlinterpretation kommen (solange die 3Daten-Bytes so bestehen bleiben)... oder seh ich das falsch?

Nee, das siehst Du richtig, wenn gerade zufällig hintereinander diese drei Bytes im Nutzdatenstrom vorkommen, dann kann die Routine auch an der falschen Stelle einrasten, so lange, bis sich daran was ändert.

Dafür sollte die Wahrscheinlichkeit dann 1 : 16.777.216 sein, wenn ich richtig gerechnet habe...? - bzw. ca. 1 : 5.592.405, weil es für das dritte Byte ja drei Möglichkeiten gibt (3 Framegrößen bei Mini-DMX, 3 Blockart-Bytes bei tpm2)...?

Da wurde auch schon drüber diskutiert, im Zusammenhang mit Mini-DMX und dann auch tpm2, da ist's halt Definitionssache: Wenn man für das Protokoll definiert, dass erst der Empfänger laufen muss, bevor der erste Frame gesendet wird, kann da auch nix passieren - ausser bei nem Übertragungsfehler, aber k.A., wie hoch die Wahrscheinlichkeit dafür ist, dass anschließend ein statisches Bild mit genau der Bytefolge kommt...? - wohl eben 1 : 5.592.405, weil ja ein Ereignis unabhängig vom anderen ist....? (Mathe schwach bei mir...)

Zitat von Pesi

das müsste wie gesagt ein großer Zufall sein, nicht nur, dass das Endebyte stimmt, sondern dass es eben auch noch an der richtigen Stelle kommt - das ist dann schon *deutlich* unwahrscheinlicher als 1 : 256

Da habe ich übrigens Quatsch erzählt (wohl doch zu früh aufgestanden :D): es wird einfach an der Stelle auf ein Byte geprüft, und die Wahrscheinlichkeit, dass da im Nutzdatenstrom das Blockende-Byte kommt, ist eben 1:256, unabhängig davon, wie lang der Block ist...

nur, das alleine reicht noch nicht, dass die Routine falsch einrastet, dazu muss eben auch noch Start- und Blockgröße/Art-Byte an der richtigen Stelle dazu stimmen...

Zitat von Counterfeiter

Das selbe gilt für tpm2, dort ist es nur nicht ganz so akut, da ja hier noch die Bytezahl genau passen muss... also die Wahrscheinlichkeit ist hier viel höher, dass es sich wieder einschwingt...

deswegen stimmt das auch nicht, ist bei mini-Dmx (da werden ja auch die Nutzdaten-Bytes gezählt, es gibt ne feste Länge) ja auch so, dass zufällig dieses Byte stimmen müsste, also bei beiden Protokollen gleiche Wahrscheinlichkeit, dass sie falsch einrasten...

EDIT:

Zitat von Counterfeiter

Da müsste ich doch Fehler bekommen, wenn ich z.B. Kanal 250 auf 165 (0xA5, Blockende), Kanal 251 auf Blockstart -> 90 (0x5A) und den Kanal 252 auf Blockgröße 256 -> 161 (0xA1) setze....

Passiert aber nicht... wo ist denn nun mein Denkfehler... =)

Ach, meinst Du das so, dass Du gerade extra zum Testen diese Kombination dauerhaft sendest, und dann mal absichtlich die Leitung unterbrichst, um zu sehen, ob es falsch einrastet...? - und das passiert aber nicht..?

Zitat von Counterfeiter

hast du schon mal einen ähnlichen Test versucht?

Ehrlich gesagt nicht, ich benutze das Protokoll ja hauptsächlich zum ansteuern von Matritzen, da habe ich den Fall, dass sowas mal auftrittt, einfach ausgeschlossen, weil ja praktisch immer Animationen laufen und sich der Datenstrom ständig ändert...

Zitat von Counterfeiter

Ja ich denke die Wahrscheinlichkeit liegt eher bei den 1 : 16.777.216 da ja bei einer falschen Länge, dass Startbyte wieder erkannt werden müsste....

Hatte mal LK Mathe, ist aber laaaang her, und gut war ich da auch nicht...

Denke aber, das müssten lauter voneinander unabhängige Ereignisse sein, die Wahrscheinlichkeiten also Multipliziert:

Erst wird auf das Startbyte gewartet, kommt keins, von vorne, auch die Rechnung.

wird eins erkannt, ist es zu 1:256 wahrscheinlich, dass es ein "falsches" ist - dann wird auf das Blockgröße-Byte gewartet - da es hier 3 gibt (A0, A1, A2) ist dort die Wahrscheinlichkeit 3:256, das zufällig eines dieser drei Bytes kommt. Dann werden die Bytes abgezählt (entweder 96 oder 256 oder 512) und dann geprüft, ob das Blockende-Byte kommt.

Und hier ist wieder die Wahrscheinlichkeit 1:256, dass das zufällig passt, und zwar *völlig unabhängig davon*, was vorher passiert ist, also ob die Blockgröße nun 96, 256 oder 512 Bytes war.

Also Gesamtwahrscheinlichkeit (1:256) * (3:256) * (1:256) = ca. 1 : 5.592.405

lasse mich aber gerne durch ein Mathe-Genie eines besseren belehren, würde mich auch (zum Verständnis des Ganzen) interessieren, ob ich das richtig gerechnet habe...

Zitat von Counterfeiter

Wie gesagt, es geht mir nicht darum hier das Protokoll zu kritisieren, dass ist schon ausreichend für ne Lichtansteuerung....

Natürlich! - wie gesagt, es ist sogar "sicherer" als normales DMX (wobei, das kann man wohl nicht so genau ausrechnen, wie hoch die Wahrscheinlichkeit ist, dass es irrtümlich einen Frame Error gibt, und danach ein Nullbyte kommt).

da wurde wie gesagt bereits ausgiebig im Forum diskutiert, ein User hat das Protokoll (mini-DMX damals) stark kritisiert, der hatte da aber was falsch verstanden, ist davon ausgegangen, dass es reicht, wenn diese Kombination in den Nutzdaten vorkommt, um einen Fehler auszulösen, nicht bedacht, dass ja die Bytes gezählt werden, und erst dann wieder auf Startbyte geprüft wird...

Mini-DMX gibt's ja schon länger, und da hat man nie irgendwo was gelesen, dass es Probleme machen würde - hatte ich anfangs auch zum ansteuern meiner Matritzen benutzt, jetzt eben tpm2...

kommt wie gesagt letztlich auf den Kanal an, ist der stark gestört, bekommst Du mit dem besten Protokoll sinnvoll keine Daten drüber, gibt es ab&zu mal ein falsches/verlorenes Byte, fällt das gar nicht weiter auf...

mir ging es anfangs auch so (bei mini-DMX), dass ich davor gestanden bin und mir gedacht habe "wie soll das überhaupt funktionieren", aber ich habe es mir dann so zusammen gereimt...

der Pepe macht das übrigens bei seinem eigenen Glediator-Protokoll viel einfacher: der beschränkt die Nutzdaten auf 1-255 statt 0-255, und 0 ist dann der Startcode...

so ist der auch eindeutig, aber dafür hat er nur noch insg. 16.387.064 Farben statt 16.777.216 - den Unterschied sieht jedoch kein Mensch, er rechnet das auch auf 10 Bit um und hat damit *für's Auge* doch wieder mehr Abstufungen, weil bei den nativ 8 Bit sieht kein Mensch, ob die Helligkeit nun 250 ist oder 255...

dafür ist es etwas fehleranfälliger, hier reicht es, wenn irrtümlich mal ein Nullbyte kommt, und die Empfangsroutine geht davon aus, dass ein neuer Block beginnt - bei ausreichend sicherer Übertragung aber eben auch kein Problem...

Zitat von Counterfeiter

nur nen kleinen Fifo pro DMX Kanal / WS SPI Kanal, damit ich empfangen kann und dabei genug Zeit hab den Break einzuleiten und das Startbyte zu senden... sonst würden in der Zeit sicher ein paar Bytes verschütt gehen....

Du willst also mdmx bzw. tpm2 empfangen und dann DMX bzw. WS2801 ausgeben, ohne Pufferung, also jedes Byte praktisch gleich weiter schicken...?

bei DMX kein Problem, man hat ja genug Zeit, durch das Startbyte und Blocksize-Byte, die sind zusammen so lang wie der Frame Error (vorausgesetzt, die Daten kommen auch mit 250 k rein) - ist hier z.B. so gemacht...

bei WS2801 und großer Datenmenge funktioniert das mit dem direkt weiter schicken evtl. nicht mehr, weil man da einfach keine 1-ms-Lücke mehr hat für den WS2801-Reset - bei meiner tpm2-auf-WS2801-SW (geistert irgendwo im Forum rum) wird daher gepuffert, und da die Daten dann schneller raus geschickt werden, als sie rein kommen, entsteht so "automatisch" die Pause für die Datenübernahme...

Auf jeden Fall!

Zitat von Counterfeiter

meinte eher die Wahrscheinlichkeit das das Protokoll auf der falschen Stelle einrastet, ist halt nochmal um den Faktor 3 kleiner

Achso, Missverständnis - ich meinte die Wahrscheinlichkeit, dass irgendwelche "Zufallsdaten/falsche Daten" als korrekter Frame erkannt werden - Du meintest die Wahrscheinlichkeit, dass die Routine dauerhaft an der falschen Stelle einrastet, bei sich nicht ändernden Daten...(?)

da ist's dann natürlich noch mal 3x unwahrscheinlicher, weil der 3er-Block muss ja regelmäßig im richtigen Abstand kommen, und da gibt's ja auch wieder drei Möglichkeiten dafür (nach 96, 256 oder 513 Bytes Nutzdaten...)

bzw., es gibt ja zusätzlich noch ne 50:50 Chance, dass die Routine doch an der richtigen Stelle einrastet, also insg. dann 1 : 33.554.432

Zitat von Counterfeiter

Ich werde versuchen den SPI Clock dem UART Clock anzupassen, dann brauch ich nicht so riesige Buffer...

das funktioniert dann natürlich, wenn der Sender immer Blöcke schickt, mit Lücken (500 µs - in der Praxis eher 1 ms) dazwischen.

direkt "anpassen" musst Du das auch nicht - der SPI muss die Bytes halt schnell genug weg schaffen können

Zitat von Counterfeiter

Das Problem liegt dann vielleicht eher daran die Daten ohne eine Unterbrechnung von 500 us in die WS Treiber zu bekommen...

Da sehe ich weniger das Problem - wenn Du mit mind. 250 kBaud empfängst, und der Sender gleichmäßig raus schickst, sind es ja max. 40 µs von Byte zu Byte (Lücke noch kleiner, Byte braucht ja auch etwas zum senden).

Das Problem ist dann eben eher bei großen Datenmengen - wenn Du z.B. Frames mit 3.072 Bytes hast, 1 MBit/s und 30 fps, dann ist zwischen zwei Frames keine Lücke mit 1 ms mehr über - also machen die WS2801 dann keinen Reset...

Ja, was soll es denn nun werden...? mdmx bzw. tpm2 empfangen (sehr ähnlich), und dann DMX raus oder WS2801....?

bei DMX raus ziemlich egal, da dürfen ja große Lücken zwischen den Bytes sein... bei WS2801 raus jedoch nicht, bei WS2811/TM1804 etc. sogar noch weniger...

beim WS2811 hatte ich sogar schon Probleme, dass meine Empfangsroutine (bei nem speziellen Projekt, die musste da auch noch Befehle auswerten) schon die Ausgabe zu lang unterbrochen hat, so dass die WS2811 dann nen Reset bekommen haben. Beim direkt weiter schicken kann natürlich auch schnell mal so ne Lücke entstehen, wenn der Sender mal kurz hängt...

Da wäre (Du machst ja XMega, oder?) natürlich DMA ne super Sache, also wenn das so geht, dass man dem einfach sagt "so, jetzt den Block von hier bis da über SPI raus hauen" und der macht das dann völlig selbstständig "nebenbei", geht das so...? - ich muss mir den echt mal zu Gemüte führen, das würde dann bei mir solche Probleme mit den WS2811 easy aus der Welt schaffen...

Doppelt puffern musst Du da aber nicht, mache ich auch nicht - das Prinzip ist da folgendes: Die Empfangsroutine schreibt die empfangenen Bytes in einen RAM-Puffer - ist der Frame komplett (gültiges Blockenede-Byte erkannt), wird die Ausgabe gestartet. Aus dem selben Puffer.

Diese erfolgt aber schneller (bei mir SW-SPI, gemessen ca. 2 MBit/s) als die Daten rein kommen, deswegen können die neu eintreffenden Daten nicht die alten im RAM überschreiben, alles, was vom aktuell ausgegebenen/gepufferten Frame überschrieben wird, ist ja schon draussen...

und dadurch entsteht eben auch diese Lücke für den WS2811-Reset, würden die Daten im selben Tempo ausgegeben wie sie empfangen werden, und es kommen viele daten rein, gibt es auch bei der Ausgabe keine Lücke mehr...

das mit dem kleinen FIFO stelle ich mir etwas kompliziert vor - wie wolltest Du das machen, der wird erst mal gefüllt, und wenn er voll ist, die Ausgabe gestartet, im selben Tempo, wie die Daten rein kommen...? - und dann puffert der praktisch das ab, wenn beim Sender mal kurz ne Pause entsteht...?

das ist halt schwer zu timen - erfolgt die Ausgabe genauso schnell wie das empfangen, dann wird der Puffer kleiner, wenn beim Sender ne kurze Pause ist - nach 2, 3 Pausen ist der FIFO dann leer, und Du hast die selbe Situation, wie wenn Du gleich weiter schicken würdest... erfolgt die Ausgabe schneller, ist der FIFO gleich leer, ist sie langsamer, läuft er recht schnell über...

ich würde das wirklich so machen, dass ich einen Frame komplett puffere (bzw. ich selbst mach's ja auch so ;)), so in der Größe wie es "sinnvoll" ist, passt das ja auch in nen ATMega...

bei mir z.B. 1.024 Pixel (3.072 Bytes) mit 25 fps, das kann man auch noch vom zeitlichen her verarbeiten - dass ich in dem µC keine Frames mit 10.000 Byte puffern kann, ist mir egal, weil die könnte ich auch von der Geschwindigkeit her gar nicht mehr verarbeiten, bzw. die haben bei 1 MBit/s dann auch keine vernünftige Framerate mehr...

klar, da ginge noch Ethernet statt USB, aber da ist's ja das selbe: Auch wenn ich so nen Ethernet-Controller habe, der mir den ganzen TCP/IP-Stack abnimmt, wo praktisch nur noch die UDP-Frames rauspurzeln, diese muss ich ja auch noch "behandeln", da kann ich mit nem ATMega auch keine 500.000 Byte/Sek "wegschaufeln"... bzw. könnte gerade gehen (wären bei 20 MHz dann 40 Takte/Byte), aber da bekomme ich sie nicht mehr schnell genug raus, dass der WS2801 noch seine Reset-Pause hat...

wie meinst Du das mit "ComPort Programme die mit 1 MBit/s senden?" - das hängt doch dann eher vom Treiber ab, oder..? - Glediator z.B. kann über den COM-Port mit 1 Mbit senden, hterm auch, gibt bestimmt noch mehr Programme...

Zitat von Counterfeiter

z.B. muss man bei MiniDMX zu WS ja wissen, wie viel Shiftregister bedient werden müssen...

Hm, bei mir ist das so, wenn z.B. ein mdmx-Block mit 256 Bytes rein kommt, dann werden auch 256 Bytes ausgegeben... wenn einer mit 512 rein kommt, werden 512 ausgegeben.. wie viele davon nun tatsächlich benutzt werden, ist ja egal...

Zitat von Counterfeiter

Öhm, dem XMega USB Treiber ist es völlig egal was man an stopbits und baudrates in Windows einstellt.

Dem FTDI-Treiber auch - also, es ist egal, was in der Systemsteuerung drin steht, die SW stellt die Baudrate ein...

Zitat von Counterfeiter

als darum muss ich mir echt keine Sorgen machen... ist total egal welche Software mit welcher baudrate sendet

also, dann verstehe ich die Frage weiter oben aber nicht, mit den Com-Port-Programmen, die 1 MBit senden...?!?

Zitat von Counterfeiter

Ja, ich weiß, beim FTDI isses anders... warum auch immer

Ganz klar: Weil da der Com-Port nicht völlig virtuell ist, sondern hinten kommt ja in HW ein serielles Signal raus mit Start- und Stoppbits und ner bestimmten Baudrate, der FTDI muss einfach wissen, *wie* das da raus kommen soll, das sagt ihm eben der Treiber...

nur dafür ist das da, weil vom PC bis in den FTDI ist's ja das selbe wie bei Dir, die Daten kommen einfach über USB immer richtig in den FTDI rein - nur der muss die dann ja auch noch seinerseits ausgeben...

bei Dir fällt das weg, weil es ja praktisch "komplett virtuell" ist, es gibt nirgendwo mehr ne *tatsächlich vorhandene* serielle Schnittstelle mit ner Baudrate etc.

Zitat von Counterfeiter

Hm, dann müsste ich ja doch alles zwischenspeichern, da ja die ersten Bytes als letztes reingespielt werden müssen

Nein - der WS2801 funktioniert nicht wie ein übliches Schieberegister, hier werden die Bytes in der "richtigen" Reihenfolge rein geschoben.

Also die drei Bytes für das erste Pixel zuerst - die speichert der sich, und schaltet dann auf "Durchzug" - die nächsten 3 Bytes sind also für den 2. WS2801 die "ersten drei Bytes", die er wiederum für sich nimmt und dann weiter leitet... usw.

*wenn* das so wäre, dass die Reihenfolge umgekehrt ist, dann müsstest Du *sowieso* zwischenspeichern, egal wie viele Pixel Du ansteuerst....

Die Ausgabe ist in der Hauptschleife, dort wird nix anderes gemacht - die Empfangsroutine setzt ein Flag, wenn ein Frame komplett ist, dann startet die Ausgabe in der Mainloop...

die wird dann natürlich immer wieder mal von neu ankommenden Bytes unterbrochen, also wenn er in die Empfangs-ISR springt... für ein paar (30? - müsste ich genau nachzählen) Takte..

und zwischen jedem Byte ist ne kurze Lücke, wo das für die Ausgabe "zerlegt" wird (bzw. halt die eigentliche SW-SPI-Routine aufgerufen wird), sowie zwischen jeweils 3 Bytes ne etwas längere, weil die Ausgabe-Routine das da aus dem RAM holen muss und ggfs. noch Bytes umsortieren etc. (das hätte ich bei HW-SPI aber auch)

sieht dann ungefähr so aus:

(Das ist für APA101, ist bei WS2801 aber genauso, nur halt immer 3 Bytes am Stück statt 4 wie hier...)