Forum: Mikrocontroller und Digitale Elektronik schwierigkeiten passenden Bus zu finden


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Tim R. (herrvorragend)


Lesenswert?

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

von Conny G. (conny_g)


Lesenswert?

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.

von Tim R. (herrvorragend)


Lesenswert?

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
von Conny G. (conny_g)


Lesenswert?

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.

von Tim R. (herrvorragend)


Lesenswert?

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

von Conny G. (conny_g)


Lesenswert?

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.

von Tim R. (herrvorragend)


Angehängte Dateien:

Lesenswert?

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

von Mike (Gast)


Lesenswert?

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.

von Conny G. (conny_g)


Lesenswert?

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
von Tim R. (herrvorragend)


Lesenswert?

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
von Conny G. (conny_g)


Lesenswert?

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
von Tim R. (herrvorragend)


Lesenswert?

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

von Conny G. (conny_g)


Lesenswert?

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?

von Tim R. (herrvorragend)


Lesenswert?

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

von Conny G. (conny_g)


Lesenswert?

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
von Christian H. (c_h)


Lesenswert?

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
von Conny G. (conny_g)


Lesenswert?

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.

von Tim R. (herrvorragend)


Lesenswert?

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

von Conny G. (conny_g)


Lesenswert?

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.

von Christian H. (c_h)


Lesenswert?

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

von Conny G. (conny_g)


Lesenswert?

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

von Nosnibor (Gast)


Lesenswert?

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.

von Tim R. (herrvorragend)


Lesenswert?

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

von Conny G. (conny_g)


Lesenswert?

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.

von Conny G. (conny_g)


Lesenswert?

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.

von Christian H. (c_h)


Lesenswert?

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.

von Nosnibor (Gast)


Lesenswert?

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.

von Ast E. (vis)


Lesenswert?

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

von Conny G. (conny_g)


Lesenswert?

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.

von Nosnibor (Gast)


Lesenswert?

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

von Conny G. (conny_g)


Lesenswert?

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?

von Michael S. (rbs_phoenix)


Lesenswert?

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

von Conny G. (conny_g)


Lesenswert?

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

von Christian H. (c_h)


Lesenswert?

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
von Michael S. (rbs_phoenix)


Lesenswert?

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.

von Nosnibor (Gast)


Lesenswert?

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.

von Tim R. (herrvorragend)


Lesenswert?

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

von Conny G. (conny_g)


Lesenswert?

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

von Tim R. (herrvorragend)


Lesenswert?

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
von Conny G. (conny_g)


Lesenswert?

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.

von Tim R. (herrvorragend)


Lesenswert?

deswegen fragte ich ja eher nach "fertig lösung", weil das viel nerven 
und auch fehlerquellen vermeidet ;P

von Nosnibor (Gast)


Lesenswert?

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.