Hallo, für mein aktuelles Projekt bin ich momentan in der Planungsphase. Ich möchte eine Matrix von 80-120 Pixeln (genaue Zahl steht noch nicht) mit je einer RGB + Sensor mit einem Master steuern. Der Sensorwert ist dabei ausschlaggebend für den Wert der RGB (abhängig von der laufenden Applikation). Die HW für den Master lass ich erstmal noch etwas offen. Die Slaves sollen relativ klein, also eventuell mit einem attiny ausfallen. Der Master soll 3 Byte (RGB) und der Slave seinen Sensorstatus (1Byte) übermitteln. Ich möchte einen Bus einsetzen, um nicht ewig viele multiplexer verwenden zu müssen und das ganze relativ dynamisch zu halten um ggf zu erweitern. Meine Überlegung war, dass es mindestens 30 mal die Sekunde (Hz) aktualisiert werden soll, um für die Matrix auch "flüssige" Übergänge zu erhalten. Meine fixe Rechnung ergibt alleine an Daten für 100 Slaves x 3Byte(RGB)= 300Byte, macht bei 30Hz x 300Byte = 9kByte/s => 56kBit/s hinzu würde noch die Abfrage bzw. das Senden des Sensorwertes kommen. Die erste Idee kam mir mit I2C. Leider hab ich nur theoretisch Erfahrung mit diesem Bus und bevor ich unnötig in Bauteile investiere wollte ich hier mal nachfragen. Sind zb. die 100 oder 400kBit/s theoretische oder praktische Angaben? Oder hat jemand eine alternative Idee zur Ansteuerung der Pixel? den CAN-Bus hab ich aufgrund der relativ teuren Bauteile ausgeschlossen. Zudem würde der Master ständig Interrupts erhalten... Alternativ hatte ich auch schon an einen Echtzeitbus gedacht, wo die Daten auf den "fahrenden Zug" zu festgelegten Zeiten gelegt werden. Leider kenn ich hier keine günstige und leicht umsetzbare Variante. Ich habe auch vom DMX bus gelesen, jedoch ist dieser nur zur Ansteuerung (RGB) fähig, wenn ich das richtig verstanden habe, aber nicht für meine Abfrage des Sensors zu gebrauchen. Oder irre ich mich?! Wäre für Anregungen dankbar :)
I2C ist eher für die nahe Verbindung von ICs konzipiert, weniger für längere Strecken (zu störanfällig). Wie lange soll die Verbindung denn sein? Für längere Verbindung eher RS232, RS485, DMX (=RS485) oder CAN. RS485, CAN sind recht robust wg. symmetrischer Übertragung. DMX gibt's auch mit Rückkanal, Pin 4/5 kann man dafür verwenden (bei den Standard-DMX-Steckern), das ist aber nicht mehr recht genormt, soviel ich gerade gefunden habe. Was für den Hausgebrauch aber egal wäre.
Hallo Conny... du bist genau der richtige Ansprechpartner (anderer Threead) lach Leitungslänge ist abhängig von der Positionierung des Master uC. Das ganze soll für einen Tisch realisiert werden also 60x100cm beispielsweise... Ich hatte gelesen, dass i2c auch für längere Leitungen (zb Hausautomatisierung) genutzt wird, aber wohl mit geringer Taktrate CAN möchte ich aufgrund der Kosten eher in den Hintergrund rücken... RS485 bzw. DMX werde ich mir mal genau anschauen, danke schon mal für den Tipp
:
Bearbeitet durch User
Jaaa, genau, der Tisch... Hallo Tim! :-) Ja, da wäre eigentlich jeder Bus, der zusätzliche Bauteile braucht zu teuer. Ich hatte in dem Tisch-Thread ja die Idee aufgebracht das Prinzip der WS2811 zu nutzen, jeder Node schickt das Signal neu. Das finde ich eigentlich immer noch gut, denn dann ist die Leitungslänge einfach egal, das Signal wird immer aufgefrischt und muss nur ein paar cm weit ok sein. Man braucht keine Bustreiber und ist gegen Störungen völlig immun.
Das Prinzip der WS2811 finde ich auch an sich sehr gut. Ich sehe dabei nur ein Problem. Um einen Knoten anzusprechen muss das Signal durch alle vor ihm liegenden Teilnehmer geführt werden. Im Gegensatz zum Bus ist das eine ziemliche Zeitverschwendung denk ich. Zudem habe ich mich gefragt, wie die Abfrage des Sensorstatus ablaufen soll. Wer initiiert das? Soll der Master wieder für einen Knoten, durch alle anderen Knoten ein Request senden und dann auf Rückantwort warten(wieder durch alle Knoten zurück)? Das klingt für mich ziemlich umständlich und zeitraubend
Eine Verzögerung lässt sich vermeiden, wenn jedes Bit sofort weitergegeben wird, also nicht gepuffert. Das machen die WS2811 doch auch so? Rückkanal: Man könnte wie bei SPI zwei Leitungen verwenden und parallel im selben Takt die Chain direkt zurückübertragen. Etwas einfacher wird die Logik des Protokolls, wenn man noch eine Taktleitung hinzunimmt. Allerdings braucht man dann schon ein Kabel mit 4 Leitungen, wie bei SPI halt.
Angehängte Dateien:
-
MasterSlaveStruktur.png
4,8 KB
Conny G. schrieb: > Eine Verzögerung lässt sich vermeiden, wenn jedes Bit sofort > weitergegeben wird, also nicht gepuffert. Das machen die WS2811 doch > auch so? > > Rückkanal: Man könnte wie bei SPI zwei Leitungen verwenden und parallel > im selben Takt die Chain direkt zurückübertragen. > > Etwas einfacher wird die Logik des Protokolls, wenn man noch eine > Taktleitung hinzunimmt. Allerdings braucht man dann schon ein Kabel mit > 4 Leitungen, wie bei SPI halt. was heißt gepuffert, zumindest die entsprechenden werte müssen ja übernommen werden... ich habe mal eben fix in visio die Verdrahtung übernommen, so wie ich es von dir verstanden habe... mehr oder weniger ein durchführen der RGB und Sensorwerte durch alle Teilnehmer über 2 Leitung. Den Clock habe ich mal noch aussen vor gelassen. War das dein Gedanke?! Mir fehlt dabei immernoch der Denkanstoß, wie denn der Sensorwert übermittelt werden soll. Soll jeder Teilnehmer dauerhaft seinen Wert senden oder wie soll das geschehen? Es weiß doch kein Slave, wann er seinen Wert übertragen soll, weil der Master gar keine Anfrage beispielsweise sendet. Ich stehe bei dem Gedankengang gerade etwas auf dem Schlauch
Tim R. schrieb: > Mir fehlt dabei immernoch der Denkanstoß, wie denn der Sensorwert > übermittelt werden soll. Du nimmst Schieberegister die du über SPI anschließt. Eins kann dann z.B. als Schnittstelle für 8 digitale Sensorwerte dienen.
Die Skizze stimmt, genau so meine ich das. Ob man das Interface wirklich mit SPI implementiert oder Bitbanging muss man noch sehen. Vom Algorithmus her meine ich es so: Ich setze jetzt mal ein CLK voraus, das kann ja auch implizit durch ein fixes Timing geschehen (wie bei den WS2811). Dann wäre der Ablauf der folgende: In Richtung MOSI, also Master sendet eine Chain von Daten an den ersten Slave. Dann wäre der Ablauf der folgende: - durch eine vorhergehende Pause ist der "LATCH & RESET"-Zustand eingetreten, d.h. alle Slaves wissen: wenn jetzt was kommt, dann ist das der Anfang - Der Master sendet Bit für Bit an den ersten Slave - der erste Slave nimmt sich die ersten 8x3=24 Bits und schreibt sie in seinen Zwischenspeicher für den RGB-Wert - der erste Slave schreibt jedes weitere Bit direkt an den Ausgang ohne es weiter anzusehen - dasselbe tut jeder weitere Node - Pause: LATCH & RESET Das ist die Richtung "RGB an Slaves", von den WS2811 bekannt. Jetzt die Rückrichtung: es müsste also jetzt beim Master an MISO nach und nach, Bit für Bit die Chain an Daten aus den Slaves ankommen, also muss sich hier das ganze Spektakel umgekehrt abspielen. Während also die Bits in der "hin"-Richtung durchschieben, müssten ebenfalls die Bits in der Rück-Richtung durchshiften. - eine Pause = LATCH & RESET setzt alle Slaves in Startzustand. - wenn jetzt der erste Slave seine Daten bekommt, dann müsste er einfach gleichzeitig am Ausgang entweder seine oder die Daten des nächsten Node setzen. - er erhält also das erste Bit vom Master. Jetzt setzt er das erste Bit seiner Sensordaten. - nach den ersten 24 Bits (= seine RGB-Daten) sind seine Sensordaten durch (24 Bit Sensor-Daten) - ab dann lauscht er auf seinem Eingang für Sensordaten vom nächsten Node und er reicht jedes Bit, das dort ankommt direkt an den Master weiter - Spannenderweise passiert es genau zum selben Zeitpunkt, dass er seine 24 Bit RGB-Daten durchhat und dann die weiteren Bits weiterreicht wenn er die Daten des nächsten Node für Rück weiterreichen soll, das läuft also 100% parallel - der 2. Slave tut genau dasselbe Und kommt beim Hinsenden der RGBs genau der Strom an Sensordaten wieder zurück. Cool daran ist: - Die Datenübertragung dauert genauso lange wie es dauert die Daten seriell auf einen Bus zu schicken, da ist keine Zeitverzögerung - ich muss keine Nodes addressieren, also maximal effizient - für die bidirektionale Übertragung brauche ich keine Extrazeit, die Rückdaten kommen gleichzeitig - es ist völlig wurst, wieviele Slaves ich habe, solange meine Gesamtübertragungrate noch die gewünschte Framerate hergibt. Danach kann ich den Bus in Teile splitten und z.B. die ganze Kette in 2 Teile trennen und einfach 2x einspeisen, dann kann ich mit selber Framerate doppelt soviele Slaves - die Übertragung ist maximal Stör-un-anfällig, weil die Distanz zwischen den Clients kurz ist und das Signal jedesmal neu gesendet wird - ich brauche deshalb keine Tranceiver, die Attiny sind gleichzeitig die Tranceiver - Ich brauche nur 2 Leitungen mit GND, wenn ich es mit implizitem Takt mache. Man könnte es sogar mit einer Leitung schaffen, wenn man in das Protokoll noch einbaut, dass man den Slaves sagt: jetzt gehört die Leitung Euch! zum Beispiel: man sendet eine Chain von 0xffffff und weiss: jetzt kommen als nächstes solange Bits zurück (Mode: MISO), bis mindestens eine Pause von xx Millisekunden da ist, dann ist der Mode wieder MOSI. Sehr cool :-))
:
Bearbeitet durch User
Conny G. schrieb: > - es ist völlig wurst, wieviele Slaves ich habe, solange meine > Gesamtübertragungrate noch die gewünschte Framerate hergibt. naja je mehr slaves, desto länger wird auch die übertragungsrate, von daher hängt die anzahl der slaves schon damit zusammen oder nicht?! > Danach kann > ich den Bus in Teile splitten und z.B. die ganze Kette in 2 Teile > trennen und einfach 2x einspeisen, dann kann ich mit selber Framerate > doppelt soviele Slaves das ist ein Ansatz den ich die ganze Zeit schon im Hinterkopf hatte, also die Reihen oder Spalten aufteilen um eine bessere Aktualisierungsrate zu bekommen > - Ich brauche nur 2 Leitungen mit GND, wenn ich es mit implizitem Takt > mache. 2 Leitungen mit GND? meinst pull-downs? ich würde es mit zwei und nicht mit einer leitung machen, so erspart man sich denke stress und kann trotzdem ordentlich flink sein ansonsten klar, so hatte ich das ganze noch nicht betrachtet... klingt nach einem sehr einfachen Prinzip :-D das einzige was ich mich gerade frage, wenn der master was los schickt, müsste er theoretisch auf seinen input vom slave pollen oder per interrupt die daten übernehmen... Interrupts könnten den dann ganz schön "oft" unterbrechen aber glaube das ist peanuts oder?
:
Bearbeitet durch User
Tim R. schrieb: > Conny G. schrieb: > >> - es ist völlig wurst, wieviele Slaves ich habe, solange meine >> Gesamtübertragungrate noch die gewünschte Framerate hergibt. > > naja je mehr slaves, desto länger wird auch die übertragungsrate, von > daher hängt die anzahl der slaves schon damit zusammen oder nicht?! Das meine ich: zwar steigt die Übertragungszeit pro Slave an, aber - rein technisch betrachtet - ist es dem Master egal wieviel Slaves er hat, muss nur Bits rausschieben. Und wenn ich die Grenze erreiche: Bussplit, Kapazität verdoppelt. >> Danach kann >> ich den Bus in Teile splitten und z.B. die ganze Kette in 2 Teile >> trennen und einfach 2x einspeisen, dann kann ich mit selber Framerate >> doppelt soviele Slaves > > das ist ein Ansatz den ich die ganze Zeit schon im Hinterkopf hatte, > also die Reihen oder Spalten aufteilen um eine bessere > Aktualisierungsrate zu bekommen Ich würde zunächst mal sehen, dass möglichst alle Slaves an einem Strang hängen, das ist das einfachstmögliche Setup. Und für einen 10x10 Tisch sind es 100 Slaves. Jeder hat 24 Bits zu bekommen, ergibt 2400 Bits. Mal Framerate von 25 ergibt 25 x 2.400 Bits = 60.000 Bits pro Sekunde. Jetzt lassen wir mal vorsichtshalber den Bus mit 100 kBit fahren, dann sind wir m.E. nicht in einem technisch kritischen Bereich und brauchen nur einen Strang. Die WS2811 machen 800 kBit, also das 8-fache. Ich glaube man könnte locker 250 kbit anpeilen, dann kann auch ein 10x20 Tisch damit in einem Strang abgefackelt werden - und größer wird den Tisch kaum einer bauen, weil es dann ja schon 200 Slave-Schaltungen braucht. >> - Ich brauche nur 2 Leitungen mit GND, wenn ich es mit implizitem Takt >> mache. > > 2 Leitungen mit GND? meinst pull-downs? > ich würde es mit zwei und nicht mit einer leitung machen, so erspart man > sich denke stress und kann trotzdem ordentlich flink sein Nein, ich meine: GND, MOSI, MISO - um mal bei SPI Terminologie zu bleiben, obwohl es mit SPI nichts zu tun haben muss. Und eine Leitung wäre GND, MOSI/MISO, halte das für keinen großen Stress. Muss nur gezielt RGB-Frames dafür ausfallen lassen, d.h. es reduziert die Framerate ein bisschen und die Abtastrate der Touches deutlich. Das könnte man durch leichte Anhebung der Framerate kompensieren. Zum Beispiel: grundsätzliche Framerate 35 FPS, jeder 5. fällt aus für Touch-Sensing, dann habe ich 7x Touch pro Sekunde und 30 RGB-Frames. Problem mit unregelmässiger Refreshrate gibt's hier ja nicht, weil alle Slaves ja beim letzten RGB-Wert bleiben und weiterleuchten, nur die Aktualisierung "stockt" mal für eine 35stel Sekunde, das merkt niemand. Denke 7-10 Touchsensings pro Sekunden wären schon noch ok. Aber mit den Verhältnissen hier kann man ja spielen bis es passt. > > ansonsten klar, so hatte ich das ganze noch nicht betrachtet... klingt > nach einem sehr einfachen Prinzip :-D Bevor ich es niederschrieb war ich mir nicht ganz sicher, ob es funktionieren könnte. Jetzt bin ich mir sicher :-)
:
Bearbeitet durch User
dann sage ich abschließend dazu, fass es doch mal in ein dokument zusammnen und wir können zurück zum hauptthread "wandern" und den nächsten punkt der tagesordnung anpeilen... hehe
Tim R. schrieb: > dann sage ich abschließend dazu, fass es doch mal in ein dokument > zusammnen und wir können zurück zum hauptthread "wandern" und den > nächsten punkt der tagesordnung anpeilen... hehe Braucht es mehr als den Thread hier? Ansonsten, was für ein Dokument meinst Du, wo / Format usw? Wollen wir hier auf mikrocontroller.net einen Artikel "Interaktiver RGB-Tisch" beginnen, wo wir die Ergebnisse der Diskussionen dokumentieren?
Conny G. schrieb: > Tim R. schrieb: >> dann sage ich abschließend dazu, fass es doch mal in ein dokument >> zusammnen und wir können zurück zum hauptthread "wandern" und den >> nächsten punkt der tagesordnung anpeilen... hehe > > Braucht es mehr als den Thread hier? > Ansonsten, was für ein Dokument meinst Du, wo / Format usw? > Wollen wir hier auf mikrocontroller.net einen Artikel "Interaktiver > RGB-Tisch" beginnen, wo wir die Ergebnisse der Diskussionen > dokumentieren? ..ein Dokument in dem kurz festgehalten wird wie das ganze gedacht war, sprich meine kurze Skizze + Erklärung beispielsweise wäre ja ausreichend. Soll nichts großes sein. Nur Dokumentieren ist, wie in jedem anderen Projekt auch, wichtig denke ich :-D Kann man hier so einfach einen Artikel aufmachen? Also prinzipiell habe ich nichts dagegen einzuwenden, der Artikel müsste eben nur gepflegt werden... mein Vorschla wäre "RGB Touch Matrix"... wie man das dann verbaut (Tisch oder sonstiges) ist ja jedem selbst überlassen ;-) wir können auch gerne zum ursprünglichen Thread zurück kehren hehe
Also bevor ich jetzt lange quatsche, dass ich keine Zeit habe (das kann jeder), habe ich mir jetzt mal 15min genommen und das Ganze in einen Artikel geworfen: http://www.mikrocontroller.net/articles/RGB_Touch_Matrix Bitte gegenlesen, Rechtschreib- und Inhaltsfehler korrigieren. Vielleicht könntest auch selber noch schnell Deine Skizze einfügen?
:
Bearbeitet durch User
Was spricht eigentlich dagegen, in den Tisch LED-Ketten mit WS2811 einzubauen? Evtl. mehrere pro Kasten? Wäre das nicht hell genug? Schade ist halt, dass WS2811 nur 8 Bit PWM hat, mehr ist besser da die unteren Helligkeitsstufen so starke Stufen bilden. Diese Superflux RGB-LEDs scheint es nicht mehr zu geben: Der Link auf den Tisch ( http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html ) verweist ja auf http://www.ledstyles.de/ftopic8176.html und dort steht auf Seite 18 ein Rausverkauf der LEDs. Wenn man fertige LED-Ketten benutzt spart man sich zumindest das ganze Löten der LEDs. Dann bleibt nur der Sensor übrig, für den Bus oder Schieberegister usw. benötigt werden.
:
Bearbeitet durch User
Christian H. schrieb: > Was spricht eigentlich dagegen, in den Tisch LED-Ketten mit WS2811 > einzubauen? Evtl. mehrere pro Kasten? Wäre das nicht hell genug? Schade > ist halt, dass WS2811 nur 8 Bit PWM hat, mehr ist besser da die unteren > Helligkeitsstufen so starke Stufen bilden. > > Diese Superflux RGB-LEDs scheint es nicht mehr zu geben: Der Link auf > den Tisch ( > http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html ) > verweist ja auf http://www.ledstyles.de/ftopic8176.html und dort steht > auf Seite 18 ein Rausverkauf der LEDs. Da spricht nichts dagegen. Nur die fertigen Streifen sind etwas unhandlich. Man könnte aber die neu verfügbaren einzelnen 8mm LEDs nehmen Beitrag ""Sammelbestellung" für 8mm RGB LEDs mit WS2811 chip" (Da ist ein ws2811 drin) und davon 2-3 Stück pro Feld, dann könnte man auch mit 3x255 dimmen, also etwas mehr wie 9 Bit, statt nur 255.
Christian H. schrieb: > Was spricht eigentlich dagegen, in den Tisch LED-Ketten mit WS2811 > einzubauen? Evtl. mehrere pro Kasten? Wäre das nicht hell genug? Schade > ist halt, dass WS2811 nur 8 Bit PWM hat, mehr ist besser da die unteren > Helligkeitsstufen so starke Stufen bilden. > > Diese Superflux RGB-LEDs scheint es nicht mehr zu geben: Der Link auf > den Tisch ( > http://www.it-gecko.de/100pixel-rgb-led-tisch-inte... ) > verweist ja auf http://www.ledstyles.de/ftopic8176.html und dort steht > auf Seite 18 ein Rausverkauf der LEDs. > > Wenn man fertige LED-Ketten benutzt spart man sich zumindest das ganze > Löten der LEDs. Dann bleibt nur der Sensor übrig, für den Bus oder > Schieberegister usw. benötigt werden. http://www.leds.de/Low-Mid-Power-LEDs/SuperFlux-LEDs/SuperFlux-LED-RGB.html
Tim R. schrieb: > http://www.leds.de/Low-Mid-Power-LEDs/SuperFlux-LEDs/SuperFlux-LED-RGB.html Da sind die Helligkeiten von RGB aber extrem unterschiedlich, R und B Faktor 2, G sogar Faktor 10. Ich hab' übrigens einen Schmarrn vorgeschlagen mit den WS2811 LEDs - wir wollen ja direkt PWM'en, dann nutzen einem die ja nichts, ausser dass sie teuer sind.
Soll wirklich für jeden Slave ein Attiny geflasht werden? Alleine das Flashen dauert doch ewig, wenn man mal etwas ändern muss. Ich würde mir da wirklich überlegen, ob fertige WS2811-Kette plus Schieberegister für die Sensoren+je 8 Kabel pro gechainter Schieberegisterplatine nicht weniger Arbeit wäre. Wieviele Bauteile pro Slave sind denn geplant? Gibt es noch einen anderen Thread zu diesem Thema? Wo? Wegen dem vorgeschlagenen Protokoll: Warum muss sich die Übertragungsrichtung auf dem Bus umdrehen? Wäre es nicht möglich, einen Ring zu bilden und den Master auch wieder an das Ende der Kette anzuschließen, so dass jeder Slave nach den Farben seinen Status weiterschiebt und die anderen ihren Status irgendwie davorsetzen? Der Master bekäme dann erst seine Farben verzögert rein und dann die Statuswerte. Vielleicht geht das ja. Unter http://www.bunniestudios.com/blog/?p=3345 ist übrigens zu sehen, wie eine WS2811-Kette im Kreis wieder an den einen steuernden Attiny zurückgeführt wird, damit dieser die Länge der Kette ausmessen kann. Eine dynamische Längenmessung könnte man auch hier vorsehen, wenn man einen Ring bildet
Christian H. schrieb: > Soll wirklich für jeden Slave ein Attiny geflasht werden? Alleine das > Flashen dauert doch ewig, wenn man mal etwas ändern muss. Ich würde mir > da wirklich überlegen, ob fertige WS2811-Kette plus Schieberegister für > die Sensoren+je 8 Kabel pro gechainter Schieberegisterplatine nicht > weniger Arbeit wäre. Wieviele Bauteile pro Slave sind denn geplant? > Gibt es noch einen anderen Thread zu diesem Thema? Wo? Das ist der Thread: Beitrag "LED Tisch mit Berührungs-/Gegenstandserkennung" Ich programmiere eigentlich lieber 100 Tinys als dass ich 800 Kabelchen konfektioniere und anlöte. Und wenn man die Software mit 10 Prototypen einmal hat sind die Änderungen begrenzt. PWM - wenn's mal funktioniert, gibt es nichts zu ändern. Bus - dito Das einzige, was mit noch einfällt: die Kalibrierung der Toucherkennung könnte man konfigurieren wollen. Könnte man aber auch mit Buskommando machen, nehmen wir halt 4 Bytes pro Slave, 1. Byte CMD, 3 Bytes Daten. > > Wegen dem vorgeschlagenen Protokoll: Warum muss sich die > Übertragungsrichtung auf dem Bus umdrehen? Wäre es nicht möglich, einen > Ring zu bilden und den Master auch wieder an das Ende der Kette > anzuschließen, so dass jeder Slave nach den Farben seinen Status > weiterschiebt und die anderen ihren Status irgendwie davorsetzen? Der > Master bekäme dann erst seine Farben verzögert rein und dann die > Statuswerte. Vielleicht geht das ja. Was ist schlimm am Bus umdrehen? Halte ich für einfacher als die Daten beim Weiterschieben immer mehr werden zu lassen. > Unter > http://www.bunniestudios.com/blog/?p=3345 > ist übrigens zu sehen, wie eine WS2811-Kette im Kreis wieder an den > einen steuernden Attiny zurückgeführt wird, damit dieser die Länge der > Kette ausmessen kann. Eine dynamische Längenmessung könnte man auch hier > vorsehen, wenn man einen Ring bildet
Conny G. schrieb: > Was ist schlimm am Bus umdrehen? Halte ich für einfacher als die Daten > beim Weiterschieben immer mehr werden zu lassen. Die Daten müssen im Ring ja nicht immer mehr werden. Wenn ein Slave seine RGB-Daten erkannt hat, braucht er die ja nicht weitergeben; die anderen wollen davon ja sowieso nichts wissen. Stattdessen ersetzt er sie durch seinen Status. Der gesamte Datensatz wird im Ring also eher kürzer.
Nosnibor schrieb: > Conny G. schrieb: >> Was ist schlimm am Bus umdrehen? Halte ich für einfacher als die Daten >> beim Weiterschieben immer mehr werden zu lassen. > > Die Daten müssen im Ring ja nicht immer mehr werden. Wenn ein Slave > seine RGB-Daten erkannt hat, braucht er die ja nicht weitergeben; die > anderen wollen davon ja sowieso nichts wissen. Stattdessen ersetzt er > sie durch seinen Status. Der gesamte Datensatz wird im Ring also eher > kürzer. kommt dann meiner idee mit einem echtzeit bus ja ziemlich nahe... der slave ersetzt die ankommenden pakete einfach mit seinen eigenen und lässt den "zug" weiterrollen zur nächsten station.. das problem ist nur, desto mehr slaves desto länger wird die zeit der übermittlung
Tim R. schrieb: > Nosnibor schrieb: >> Conny G. schrieb: >>> Was ist schlimm am Bus umdrehen? Halte ich für einfacher als die Daten >>> beim Weiterschieben immer mehr werden zu lassen. >> >> Die Daten müssen im Ring ja nicht immer mehr werden. Wenn ein Slave >> seine RGB-Daten erkannt hat, braucht er die ja nicht weitergeben; die >> anderen wollen davon ja sowieso nichts wissen. Stattdessen ersetzt er >> sie durch seinen Status. Der gesamte Datensatz wird im Ring also eher >> kürzer. > > kommt dann meiner idee mit einem echtzeit bus ja ziemlich nahe... der > slave ersetzt die ankommenden pakete einfach mit seinen eigenen und > lässt den "zug" weiterrollen zur nächsten station.. > das problem ist nur, desto mehr slaves desto länger wird die zeit der > übermittlung Das ist bei jeder Chain so, auch bei den WS2811 und ist kein Problem, wenn die Grunddatenrate hoch genug ist, dass man noch auf seine Framerate kommt. Und ein Bus mit Adressierung hat letzten Endes ja genau dasselbe: Du musst mit jedem Slave einzeln reden und zwar nacheinander, also hast auch da einen serielle Übermittlung, zwar nicht in Chain, sondern 1:1, die Dauer ist aber dieselbe - sowohl Bus als auch uC können (bei einem Buseingang) nur 1 Verbindung gleichzeitig. Und bei mehreren Verbindungen kann man auch die Chain splitten und 2x 50% Daten senden und damit die Framelänge halbieren.
Nosnibor schrieb: > Conny G. schrieb: >> Was ist schlimm am Bus umdrehen? Halte ich für einfacher als die Daten >> beim Weiterschieben immer mehr werden zu lassen. > > Die Daten müssen im Ring ja nicht immer mehr werden. Wenn ein Slave > seine RGB-Daten erkannt hat, braucht er die ja nicht weitergeben; die > anderen wollen davon ja sowieso nichts wissen. Stattdessen ersetzt er > sie durch seinen Status. Der gesamte Datensatz wird im Ring also eher > kürzer. Das stimmt. Das bedeutet jeder Slave müsste die ersten 3 Bytes ignorieren und direkt weitergeben und sich erst die Bytes 4-6 als RGB nehmen. Das findet in der ersten Runde gleichzeitig statt: 1. Slave IN: R G B 1. Slave OUT: SA1 SB1 SC1 2. Slave IN: SA1 SB1 SC1 2. Slave OUT: SA1 SB1 SC1 ... über alle Slaves, bis zum Ende Heisst also, dass mit den ersten 3 Bytes, die gesendet werden hinten die ersten 3 Sensor-Bytes des ersten Slave rauskommen. Allerdings wohl nicht ganz synchron zu den gesendeten Daten, da intern in jedem Slave Mikrosekunden gebraucht werden um die OUT-Pins zu setzen, über 100 Slaves ergibt sich also eine Verzögerung von 100x ein paar Mikrosekunden, ca. 1 Millisekunde. In der 2. Runde: 1. Slave IN: R G B 1. Slave OUT: R G B 2. Slave IN: R G B 2. Slave OUT: SA2 SB2 SC3 3. Slave IN: SA2 SB2 SC3 3. Slave OUT: SA2 SB2 SC3 Jetzt ergibt sich aber doch ein Problem. Woher weiss der Slave 2 (und alle weiteren), dass er die ersten 3 Bytes ignorieren muss (letzte Runde), weil das die Sensordaten von Slave 1 sind. Dasselbe nun für Slave 3, der muss 6 Bytes ignorieren usw. Dafür gibt es m.E. keine Lösung, weil kein Slave seine Position in der Kette weiss und es auch keinen indirekten Anhaltspunkt dafür gibt.
Vielleicht könnte es so klappen: Der Controller schreibt ein 1-Bit um anzuzeigen, dass jetzt Farben kommen und dann alle Farbwerte und dann die Pause zum Latchen. Jeder Slave sieht die 1, holt sich 3 Byte Farbe, schiebt eine 1 und alle folgenden Bytes bis zur Pause durch. Dann schreibt der Controller nach der Pause eine 0 und macht wieder eine Pause. Jeder Slave der eine 0 nach der Pause sieht schreibt eine 0 und seinen Status (1 Bit) an den nächsten Slave und leitet dann alle Bits, die bis zur Pause kommen, an den nächsten weiter. Der Controller wird erst eine 1 und eine Pause sehen und dann eine 0 und dann die Status-Werte. Er muss auch mit dem Anfordern der Statuswerte nicht warten, bis alle Farben durch die Kette sind, der kann direkt nach der letzten Farbe und der Latch-Pause gleich die 0 und eine Pause senden. Könnte das klappen? Ich persönlich würde im Moment den Tisch aber auf Basis PCBs von Elecrow.com machen. Mit 20cmx20cm PCBs könnte man einen kleinen Tisch (50cm x 50cm Glasplatte) fast komplett auslegen und alle Bauteile einfach einlöten. Oder bei einem großen Tisch könnte man mit Panelizing 20cm lange, dünne PCB-Streifen machen lassen. Dann gibt es nicht soviele Kabel und man muss nur Steckverbinder und Buchsen in das PCB löten und kann auf den PCBs Verbindungen, Bauteile und Shiftregister verteilen. Dadurch spart man sich Kaufen oder Crimpen von Kabeln und das Programmieren der Mikrocontroller. Pro Platine eine Shiftregister für die IR-Sender und Empfänger und ein Bulletpixel. Oder pro 2 Platinen ein Shiftregister und noch 4 Steckverbinder mehr zur nächsten. Ist aber nur so ein Gedankenspiel... Hoffentlich sind die testweise bestellten Bulletpixel hell genug und gleichzeitig das PWM fein genug/dunkel genug.
Ich muß zugeben, daß ich das WS2811-Protokoll nicht kenne, war jetzt eher von UART ausgegangen. Conny G. schrieb: > Jetzt ergibt sich aber doch ein Problem. > Woher weiss der Slave 2 (und alle weiteren), dass er die ersten 3 Bytes > ignorieren muss (letzte Runde), weil das die Sensordaten von Slave 1 > sind. > Dasselbe nun für Slave 3, der muss 6 Bytes ignorieren usw. Zwei Lösungsmöglichkeiten sehe ich: 1. Man kann den Daten ansehen (z.B. am P-Bit oder einem expliziten Kommandobyte vorweg), ob es RGB-Daten oder Status ist. Dann sendet der Master einmal Dummy-Status und dann alle RGB-Daten. Ein Slave leitet alles durch, bis unmittelbar nach einem Status RGB-Daten kommen. Dann ist der erste RGB-Datensatz seiner und wird durch seinen Status ersetzt. Danach wieder Durchleiten... bis zum nächsten Wechsel Status-->Daten. 2. Es gibt einen expliziten Startcode, also ein Byte, das nicht in RGB-Daten oder Status vorkommt. Dann sendet der Master Start, gefolgt von den RGB-Daten. Ein Slave leitet alles durch, bis auf das Startbyte und den ersten RGB-Datensatz danach. Den nimmt er für sich und sendet stattdessen seinen Status, gefolgt von einem Startbyte.
startzeichen wäre am besten FF oder nicht? dann kann zwar nicht das maximale aus der LED geholt werden aber das wird man wohl verkraften... aber irgendein zeichen "das jetzt Daten kommen" muss denke ich gesetzt werden, sonst wird es problematisch
Also mir kommt das gerade zu umständlich vor, nur um einen Richtungswechsel des Busses zu vermeiden. Ich finde das viel einfacher einmal alle Bytes rein und auf Kommando alle Bytes raus. Da muss ich doch nicht künstlich irgendwelche Trigger-Konstellationen einführen um mit aller Gewalt einen Ringbus zu machen. Einfacher als Richtungswechsel ist es jetzt jedenfalls nicht mehr.
Das hängt von der Verdrahtung ab. Wenn alle parallel am Bus hängen, ist Richtungswechsel offensichtlich das einfachste. Wenn die Slaves jedoch eine Kette bilden, ist es naheliegend, diese zu einem Ring zu schließen; das spart das Umschalten sämtlicher Ein- und Ausgänge (oder das Verdrahten einer zweiten Kette für die Gegenrichtung).
Nosnibor schrieb: > das spart das Umschalten sämtlicher Ein- und Ausgänge (oder das Die werden ja nach Anzahl Umschaltungen monatlich abgerechnet :-) Spass beiseite, wen stört das Umschalten?
Eine Idee von mir wäre auch, einen Ring zu machen. Als Beispiel mit 3 Nodes. Anordnung ist dann: Master -> Node 1 -> Node 2 -> Node 3 -> Master... Man kann dann eine Art Verschachtelung von seriellen Schnittstellen machen. Der Master sendet ein High-Signal an Node 1, Node 1 an Node 2 usw. Dann schickt der Master die 3 Byte für Node 3 an Node 1, Node 1 sendet seinen Sensorwert an Node 2, Node 2 seinen Sensorwert an Node 3 und Node 3 seinen Sensorwert an den Master. Anschließend wird das Highsignal wieder auf Low gelegt. Im nächsten Schritt sendet der Master die 3 Byte für Node 2 an Node 1, Node1 sendet die 3 Byte für Node 3 an Node 2, Node 2 sendet den Sensorwert von Node 1 an Node 3 und Node 3 sendet den Sensorwert von Node 2 an den Master. Das ganze solange, bis der Master alle Daten gesendet bzw empfangen hat. Dies müsste mittels extra Leitung noch an die Nodes gegeben werden, damit diese die Werte der LED einstellen. Man könnte statt den Leitungen für Start oder Ende auch ein Timeout nutzen. Wenn nach x ms keine neuen Daten gekommen sind, dann die 3 Byte an LED und warten. Wenn neue Daten kommen (Slaveseite des Nodes), Sensordaten lesen. Nachteil ist, es ist etwas aufwendig und die Controller brauchen 2 gleiche Schnittstellen (z.B. 2x SPI). Einmal als Master und einmal als Slave. Vorteile: Die Software der Nodes ist identisch (keine Adressen o.ä.) und dazu unabhängig von der Anzahl der Nodes. Die brauchen nichts machen, außer die Daten, die sie bekommen weiter zu schicken, außer beim ersten mal, wo sie ihren eigenen Sensorwert lesen und schicken müssen. Die Erweiterung auf mehr Nodes ist nur Sache vom Master, dem man nur ein etwas größeres Array geben muss. Den Counter auf die Anzahl der Nodes -1 setzen und runterzählen. Die Entfernung spielt keine Rolle, da das Signal immer wieder aufbereitet wird. Durch geschicktes Anlegen der Nodes kann man auch die Leitung vom Letzten Node zum Master kurz halten. Als Beispiel anhand vom Nummernblock, wäre eine Mögliche Anordnung: 1,2,3,6,5,8,9,*,/, Num.Lock,7,4. Der Master wäre dann zwischen/neben 1 und 4 ;)
Michael Skropski schrieb: > Eine Idee von mir wäre auch, einen Ring zu machen. Als Beispiel mit 3 > Nodes. Anordnung ist dann: Master -> Node 1 -> Node 2 -> Node 3 -> > Master... Man kann dann eine Art Verschachtelung von seriellen > Schnittstellen machen. > > Der Master sendet ein High-Signal an Node 1, Node 1 an Node 2 usw. Das bedeutet ich brauche eine extra Leitung für diese Unterscheidung. > Dann schickt der Master die 3 Byte für Node 3 an Node 1, Node 1 sendet > seinen Sensorwert an Node 2, Node 2 seinen Sensorwert an Node 3 und Node > 3 seinen Sensorwert an den Master. Anschließend wird das Highsignal > wieder auf Low gelegt. > > Im nächsten Schritt sendet der Master die 3 Byte für Node 2 an Node 1, > Node1 sendet die 3 Byte für Node 3 an Node 2, Node 2 sendet den > Sensorwert von Node 1 an Node 3 und Node 3 sendet den Sensorwert von > Node 2 an den Master. > > Das ganze solange, bis der Master alle Daten gesendet bzw empfangen hat. > Dies müsste mittels extra Leitung noch an die Nodes gegeben werden, > damit diese die Werte der LED einstellen. > > Man könnte statt den Leitungen für Start oder Ende auch ein Timeout > nutzen. Wenn nach x ms keine neuen Daten gekommen sind, dann die 3 Byte > an LED und warten. Wenn neue Daten kommen (Slaveseite des Nodes), > Sensordaten lesen. > > Nachteil ist, es ist etwas aufwendig und die Controller brauchen 2 > gleiche Schnittstellen (z.B. 2x SPI). Einmal als Master und einmal als > Slave. Ja, das ist aufwändig und man braucht 2 Schnittstellen - damit ist ggüber der einfachen Daisy Chain, die nur 1 Busleitung und GND braucht und meistens die Daten hinsenden und auf eine spezielle Byte-Kette (0xffffff an alle) einmal den Rückkanal aufmacht nichts gewonnen. Im Prinzip geht's ja bei dem Busdesign um Folgendes: - möglichst wenige Leitungen, idealerweise neben GND nur eine - simples Protokoll - alle Slaves gleiche Software, gleiches Schema, keine Adressierung - höchstmögliche Effizienz, keine Adressierung > Vorteile: > Die Software der Nodes ist identisch (keine Adressen o.ä.) und dazu > unabhängig von der Anzahl der Nodes. Die brauchen nichts machen, außer > die Daten, die sie bekommen weiter zu schicken, außer beim ersten mal, > wo sie ihren eigenen Sensorwert lesen und schicken müssen. Dazu braucht's aber diese High/Low-Leitung, das ist schon mal mehr als Daisy Chain mit GND+1. > Die Erweiterung auf mehr Nodes ist nur Sache vom Master, dem man nur ein > etwas größeres Array geben muss. Den Counter auf die Anzahl der Nodes -1 > setzen und runterzählen. > > Die Entfernung spielt keine Rolle, da das Signal immer wieder > aufbereitet wird. Durch geschicktes Anlegen der Nodes kann man auch die > Leitung vom Letzten Node zum Master kurz halten. Als Beispiel anhand vom > Nummernblock, wäre eine Mögliche Anordnung: 1,2,3,6,5,8,9,*,/, > Num.Lock,7,4. Der Master wäre dann zwischen/neben 1 und 4 ;)
An welchen Attiny wurde eigentlich gedacht? Gibt es schon einen Schaltplan? Welche Timer, wieviele PWM-Bits wird der Attiny haben? Wird er UART oder USI haben? Schaut doch mal die WS28xxx Library von Adafruit an: Die schaltet um das Protokoll abzuwickeln die Interrupts aus und macht alles in Assembler, um das Timing exakt zu treffen. Genauso schaut mal in der Arduino-Software die SoftSerial Klasse an: Die hat im Empfangsinterrupt auch die CPU für sich alleine und wartet exakte Takte ab und beim Senden sowieso. Soll es Soft-PWM werden oder die Timer? Der Attiny85 hat doch garkeinen 16-Bit Timer und selbst mit 16-Bit-Timer gibt es je nach CPU nur 12 Bit PWM (was aber ausreichen sollte). Ich glaube nicht, dass man SoftPWM mit SoftSerial oder einem WS28xxx-kompatiblen Protokoll verbinden kann. Es wäre gut, TX und RX zu einer Kette zu verbinden. Dann kann der UART von z.B. dem attiny2313 unabhängig arbeiten und man hat die CPU für SoftPWM frei. Bei Protokollen in Software kann man die Reihenfolge jederzeit umdrehen. Bei Verwendung von USI oder UART vermutlich nicht und es muss wohl ein Ring sein oder ein adressierbarer Bus
:
Bearbeitet durch User
War ja auch nur ne Idee. Die Schnittstelle von einem Controller zum nächsten kann ja auch One-Wire sein. Dann hat man mit der "Timeout-Variante" auch nur eine Leitung In und eine Out. Ich persönlich würde aber 5 bis 10 cent mehr für den Controller ausgeben und dann die beiden SPI Schnittstellen nehmen, um die Software einfach zu haben und nicht noch extra eine Leitung per Software togglen zu müssen. Simples Protokoll ist es und Gleiche Software ohne Adressierung ist es auch. Doch wie gesagt, war ne Idee.
Conny G. schrieb: > Nosnibor schrieb: >> das spart das Umschalten sämtlicher Ein- und Ausgänge (oder das > > Die werden ja nach Anzahl Umschaltungen monatlich abgerechnet :-) > Spass beiseite, wen stört das Umschalten? Es bringt zusätzliche Komplexität und Fehlermöglichkeiten. Irgendwo mal ein Bit mißverstanden, und zwei Ausgänge arbeiten gegeneinander. OK, bei der nächsten Sync-Pause renkt sich das wieder ein, aber mich gruselt die Vorstellung trotzdem. Aber für das Protokoll kommt mir inzwischen auch der Vorschlag von Christian H. besser vor: der Master legt durch die Art des Startsignals fest, ob er RGB-Daten schreiben oder Status lesen will. Bei RGB-Daten nimmt jeder Slave den ersten Datensatz für sich und gibt dann das Startsignal und alle folgenden Daten weiter. Bei Status sendet der Slave das Startsignal und seinen Status und reicht dann alles weiter, was er empfängt (natürlich verzögert um eine Statuswortlänge, weil ja schon Daten hereingekommen sind, während er seinen Status gesendet hat). Das Startsignal kann bei UART ein "magic byte" sein, bei WS2811-ähnlicher Übertragung das erste Bit nach der langen Pause.
verstehe nich so recht was denn am oben gezeigten beispiel (bild) nun so verkehrt ist... man kann es zwar bidirektional mit umschaltung machen oder lässt den master explizit angeben welcher modus RGBschreiben oder TOUCHlesen aktiv ist... aber warum nicht wie oben beschrieben, parallel laufen lassen... master schreibt rgb daten und die slaves lassen auf einer zweiten leitung gleichzeitig ihre touchdaten laufen... maximale übertragungsrate bei 2 datenleitungen plus evtl. CLK
Tim R. schrieb: > verstehe nich so recht was denn am oben gezeigten beispiel (bild) nun so > verkehrt ist... man kann es zwar bidirektional mit umschaltung machen > oder lässt den master explizit angeben welcher modus RGBschreiben oder > TOUCHlesen aktiv ist... aber warum nicht wie oben beschrieben, parallel > laufen lassen... master schreibt rgb daten und die slaves lassen auf > einer zweiten leitung gleichzeitig ihre touchdaten laufen... maximale > übertragungsrate bei 2 datenleitungen plus evtl. CLK Hi Tim, da ist nichts verkehrt dran. Eigentlich geht die Diskussion ja drum, ob und wie man Hin- und Rückkanal mit nur 1 Draht abwickeln kann - das wäre halt cool, wenn man nur GND + 1 Leitung bräuchte und der Verkabelungsaufwand minimal ist. Weil GND + Power ist sowieso auf jeder Platine und eine windige Leitung von Platinchen zu Platinchen ist supereinfach angelötet. Sobald man 2 Drähte nimmt, hat man überhaupt kein Problem mehr, denn es ist simpel. Über einen Draht muss man halt ein paar Problemchen lösen, also quasi: Verdrahtungsaufwand sparen durch ein paar Stunden länger nachdenken. Und da ggf. mehrere Leute (vielleicht sogar Dutzende, Hunderte??) die Lösung nachbauen lohnt sich der Denkaufwand, weil jeder Nachbauer sich ein paar Stunden Verkabelung spart. 3 Minuten für: Anlöten von Header, Konfektionierung Flachbandkabel ergibt 100 x 3 Minuten = 300 Minuten = 5 Stunden. Plus extra Bauteile kosten für 100x Header und 100x Stecker und 100x ein paar cm Flachbandkabel = 10 Meter. Und: die Platinchen mit einem Flachbandkabel zu verbinden ist aufwändiger als 1 Bohrung nach unten durch zu machen und ein 0,5mm Käbelchen durchzufädeln. Und auch größere Tische werden deutlich einfacher, weil man für 200 oder vielleicht sogar mal 400 Slaves nicht 400 Stück Flachbandkabel konfektionieren will :-) (400 Kabel: 1.200 Minuten, 20h, fast drei Arbeitstage...)
ob ich nun ein oder zweidraht zwischen den pixeln verdrahte macht ja nun auch nicht den kohl fett... zumal man ja auch fertig isolierte adernpaare vllt schon wo günstig bekommt oder nicht?! naja gut auf die masse rechnet sich das schon... mal so nebenbei... gibts denn nicht relativ günstige platinenhersteller+bestückung? das würde bei 100platinen eine menge arbeit abnehmen^^ also löten ist glaube nur halb gut, steckverbindung wäre besser für evtl austauschen oder was auch immer...
:
Bearbeitet durch User
Tim R. schrieb: > ob ich nun ein oder zweidraht zwischen den pixeln verdrahte macht ja nun > auch nicht den kohl fett... zumal man ja auch fertig isolierte > adernpaare vllt schon wo günstig bekommt oder nicht?! > > naja gut auf die masse rechnet sich das schon... Ich habe mal ein Fussballdisplay gemacht mit 4 Ziffern à 7 Segmenten plus Doppelpunkt, jedes Segment einzeln verkabelt. Ich war überrascht einen ganzen langen Abend dafür zu brauchen... Verkabelei ist enorm zeitaufwändig, hatte ich schon ein paar Mal in Variationen. > mal so nebenbei... > gibts denn nicht relativ günstige platinenhersteller+bestückung? das > würde bei 100platinen eine menge arbeit abnehmen^^ Klar, das habe ich mir auch schon gedacht. 100 Miniplatinen bestücken ist eine Sisyphus-Aufgabe... > also löten ist glaube nur halb gut, steckverbindung wäre besser für evtl > austauschen oder was auch immer... Klar, aber 200 Stecker anbringen, das ist genau was einen verrückt macht :-) Vielleicht auch noch einen Crimpstecker mit Crimpkontakten: Adern eines Flachbandkabels auftrennen, jede Ader abisolieren, 3x oder 4x Crimpkontakt drauf, in den Stecker reinfummeln. Und das 200 Mal (vorne und hinten bei jedem Kabelchen), also 200x4 = 800x abisolieren, crimpen.
deswegen fragte ich ja eher nach "fertig lösung", weil das viel nerven und auch fehlerquellen vermeidet ;P
Dann erdreiste ich mich mal, diesen Thread wieder zu reaktivieren, mit ein paar konkreteren Ideen zu einer Lösungsmöglichkeit (eine Fertiglösung weiß ich jedenfalls nicht). Als Voraussetzungen habe ich gewählt: - UART, also byteorientiertes Protokoll. Günstiges Verhältnis von Datenrate zu Prozessorlast, wenn Hardware-UART vorhanden. - Ringstruktur, d.h. TX vom Master geht auf RX vom ersten Pixel, TX von jedem Pixel auf RX vom nächsten Pixel, TX vom letzten Pixel auf RX vom Master. Das ist ein Kompromiß aus minimalem Verdrahtungsaufwand (nur je eine Leitung zwischen zwei Pixeln) und Signalintegrität (geringe Leitungslänge, jeweils nur ein Sender und ein Empfänger an einer Leitung). Eine lange Pause (LP) dient zur Synchronisierung, d.h. nach einer langen Pause fängt eine neue Nachricht an. Festzulegen ist die Länge der langen Pause (d.h. Minimum, was der Master einhalten muß, und ein sinnvolles Entscheidungskriterium für die Pixel). Das erste Byte nach einer LP dient ggf. zur Synchronisierung (Framesync); es muß also schnell durchgereicht werden. Sollte kein Problem sein, der Sender ist ja frei (die Pause war schließlich lang genug). Natürlich gibt es pro Pixel eine Verzögerung von einer Bytelänge + etwas Verarbeitungszeit + Jitter (Interruptlatenz). Die Interruptlatenz kann man dadurch minimieren, daß der Prozessor in diesem Moment sowieso nichts anderes zu tun hat; die konstante Verzögerungszeit kann man bei Bedarf rausrechnen, wozu das Protokoll natürlich die Möglichkeit bieten muß, daß Pixel ihre Position im Ring erfahren. Das erste Byte (+ vielleicht noch ein zweites) nach einer LP gibt die Art der Nachricht an, z.B.: - RGB-Daten für alle Pixel (jeder nimmt vorne was weg und reicht den Rest weiter) - Framesync - Sensordaten von allen Pixeln (jeder sendet seinen Meßwert und reicht die anderen durch) - Zähler (jeder zählt den empfangenen Wert weiter, bevor er ihn weitergibt). Damit kennt jedes Pixel seine Position im Ring und kann den Framesync präzisieren, falls nötig. - Konfigurationsdaten (Gammakurven, Anpassung an Umgebungshelligkeit) für alle Pixel gemeinsam. Durchreichen & selber auch beachten. - Konfigurationsdaten (individuelle Helligkeitskorrektur) für alle Pixel einzeln. Ähnlich wie bei RGB-Daten. - Firmwareupdate? - ... Das erste Byte nach einer LP könnte auch zum Kalibrieren der Taktgenratoren dienen, falls die Pixel keinen Quarz haben. Angenommen, der UART empfängt bei total verdrehter Taktfrequenz wenigstens die ersten beiden Bits noch richtig, dann könnte man daran ein Kalibriersignal erkennen (und es weiterreichen, auch wenn die restlichen Bits verschoben sind und z.B. das Stopbit fehlt), das z.B. präzise jede Sekunde kommt. Jedes Pixel mißt die Zeit (in Taktzyklen) zwischen den Kalibriersignalen, und wenn es mehrere im ungefähr richtigen Abstand erkannt hat, kann es seine Taktfrequenz korrigieren. Am ersten Byte nach einer LP könnte ein Pixel erkennen, daß es wegen falscher Taktfrequenz Schrott empfängt, und dann bis zur neuen Kalibrierung nichts mehr durchreichen (außer Kalibriersignale). Die unterschiedlichen Taktfrequenzen werden auch beim Durchreichen Probleme machen. Angenommen das erste Pixel ist 1% langsamer als der Master, was ja für die Kommunikation noch überhaupt kein Problem sein sollte. Nun sendet der Master einen Satz RGB-Daten für vielleicht 100 Pixel, natürlich ohne Pause dazwischen. Nachdem das Pixel seine drei Bytes vorne rausgenommen hat, muß es den Rest durchreichen. Es sendet aber 1% langsamer als es empfängt, d.h. nach ca. 100 Bytes kann es das empfangene Byte nicht einfach ins Senderegister abladen, weil der Sender noch nicht bereit ist. Abhilfe: der Master sendet mit zwei Stopbits, die Pixel nur mit einem; das sollte uns ca. 10% Spielraum verschaffen. Das Einsammeln der Sensordaten wird ein ähnliches Problem bekommen. Da ist sowieso etwas Puffer nötig, damit ein Pixel zwischenspeichern kann, was es empfängt (und durchreichen muß), während es seinen eigenen Meßwert sendet. Abhilfe: der Master gibt das Timing vor, indem er (natürlich mit zwei Stopbits) ein "Formular" sendet, das die Pixel dann "ausfüllen". Der Master sendet also so viele leere Datensätze, wie Pixel im Ring sind, und jedes Pixel reicht alle Daten durch, bis auf den ersten leeren Datensatz; den füllt es vor dem Weiterreichen mit seinem eigenen Meßwert. Dafür ist es nötig, daß man dem ersten Byte eines Datensatzes ansieht, ob er noch leer ist, am einfachsten mit einem dafür reservierten Bit. Dann sehe ich noch ein Problem bei der RGB-Datenübertragung: nach der LP wird ein Syncbyte sofort durchgereicht, danach kommen die Daten. Beim ersten Pixel kommen die Daten sofort nach dem Syncbyte. Beim zweiten Pixel kommt eine 3 Byte lange Pause dazwischen (das erste Pixel hat ja die ersten drei Bytes herausgenommen). Das dritte Pixel sieht bereits eine 6 Byte lange Pause, usw.. Irgendwann kann man diese Pause nicht mehr von der LP unterscheiden. Abhilfe: Framesync und Datenübertragung trennen. Das Framesyncbyte (nach einer LP) wird sofort durchgereicht. Das RGB-Startbyte (nach einer LP) wird erst durchgereicht, wenn die eigenen Daten empfangen sind, so daß das nächste Pixel seine Daten unmittelbar hinter dem Startbyte bekommt. Dadurch wird die LP verlängert, was ihr nichts ausmacht. Nachteil: für jeden Frame sind zwei LP nötig. Andere Abhilfe: das Protokoll wird komplizierter. Ein RGB-Telegramm besteht aus Syncbyte, Dummybytes, Startbyte und Daten. Der Master sendet Sync, Start und die Daten. Die Pixel reichen alles sofort durch, außer das Startbyte. Da geben sie stattdessen ein Dummybyte aus, empfangen ihre RGB-Daten, senden beim Empfang ihres letzten Datenbytes ein Startbyte und reichen danach wieder alles durch. Dadurch wird die entstehende Pause mit Dummybytes unterbrochen, so daß keine LP daraus werden kann. Von hier ist es dann nur noch ein kleiner Schritt, statt eines Dummybytes gleich den Sensor-Meßwert zu übertragen, aber die Idee hatten wir ja schonmal.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.