Forum: Mikrocontroller und Digitale Elektronik Projektidee RGB Pixel mit Touch


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 Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Hallo,

Aufbauend auf den alten Thread 
(Beitrag "LED Tisch mit Berührungs-/Gegenstandserkennung") soll hier die 
Projektidee für einen Touch Pixel für diverse Anwendungen fortgeführt 
werden, der aus verschiedenen Gründen leider etwas kurios verlief. 
Könnte man für diesen Thread einen Mod begeistern der die Übersicht 
behält oder kann man selbst für einen Thread "übergeordnete" Funktionen 
evtl. erhalten ? :-)

Ansonsten trotzdem danke an die vielen Leuten die Ihren meist sinnhaften 
Senf dazugegeben haben ;-P
Danke auch an Conny G., der den Artikel dazu schon mal angefangen hat!
#http://www.mikrocontroller.net/articles/RGB_Touch_Matrix
Diesen versuche ich soweit es mir möglich ist zu pflegen damit das 
Projekt für jederman nach Vollendung nachbaubar ist. Es soll also eine 
einfache und kostengünstige Lösung gefunden werden, welche für jeden 
Bastler realisierbar ist.

Deshalb hoffe ich auf rege Beteiligung, ich würde mich freuen. Viele 
Leute haben zumindest ihr Interesse gezeigt. Ich zähle auf euch :-)

Also nochmal:
Worum geht es?
Die ursprüngliche Idee war, einen Glastisch mit darunter liegenden 
RGB-Pixeln auszustatten, welcher zudem über eine Touchfunktion verfügt. 
Die Pixel werden über Holzwände voneinander getrennt, sodass diese 
unabhängig voneinander agieren sollen. Ziel ist die verschiedenen Pixel 
leuchten zu lassen, je nach dem wie der User es gerade möchte. Zudem 
kann das Touch als schönes Feature verwendet werden. Es sollen 
Handbewegungen bzw. im allgemeinen Gegenstände detektiert werden und 
anschließend können verschiedenste Farbaktionen die Reaktion sein (der 
Fantasie sind nur geringe Grenzen gesetzt) :-) Also beispielsweise: 
Gegenstand/Hand erkannt -> RGB leuchtet

Wie soll das ganze realisiert werden?
Aufbauend auf dem alten Thread soll eine flexible Pixellösung gefunden 
werden. Durch verschiedene Pixel können nicht nur einfache Tische 
sondern diverse Formen und Größen realisierbar sein. Deswegen ist das 
erste große Ziel die Pixel zu entwickeln.

bisherige Eigenschaften für einen Pixel kurz zusammengefasst:
-Pixelgröße 50x50mm
-Touch-Erkennung über eine IR-LED plus eine Fotodiode
-RGB Beleuchtung über eine oder sogar mehrere RGB-LEDs

Baustellen, welche nun der Reihenfolge nach diskutiert werden sollten 
(und ich hoffe diese gelingt auch, sodass am Ende nicht wieder alte 
Themen aufgegraben werden ;-) )
-Festlegung einer Platinengröße
-Festlegung der IR-LED + IR-Sensor Bauteile sowie der Höhe der Pixel zum 
korrekten detektieren....hier möchte ich gerne die Tests von Karol 
Babioch vorzeigen welcher einen Test dazu gestartet hat (danke)
https://www.youtube.com/watch?v=SClKqD01_uU&feature=youtu.be
-Festlegung eines uC + evtl. weitere Komponenten
-Einigung auf eine Busansteuerung und dessen Ausführung(Bauteile) Dieser 
Punkt sollte evtl. mit dem uC zusammen in Betracht gezogen werden
-Versorgungsspannung
-Befestigung der Pixel

Die ersten Punkte sollten schnell erledigt sein, ich möchte diese nur 
gern noch einmal festhalten.
zum ersten Punkt: die Platinengröße spielt denke ich weniger eine große 
Rolle. Hauptsache sie passt in einen 50x50mm Pixel! Deshalb schlage ich 
die Größe von 45x45mm als Maximalgröße vor, sodass die Trennwände 10mm 
Platz zwischen den Pixeln haben. Die Trennwände können auch dünner 
dimensioniert werden, so erhält man noch einen "Pufferabstand".

Deshalb eure Meinung: Platinengröße 45x45mm? Kleiner? Größer?

Danach geht es mit dem nächsten Punkt weiter :-) Ich hoffe auf große 
Beteiligung

http://www.mikrocontroller.net/articles/RGB_Touch_Matrix

: Bearbeitet durch User
von Sam .. (sam1994)


Bewertung
lesenswert
nicht lesenswert
Ich verstehe noch nicht den Kritikpunkt an den Led Panels mit 16 oder 25 
Pixeln. Einzig alleine die Flexibilität sinkt leicht. Allerdings glaube 
ich, dass diese Pixel fast ausschließlich flächenfüllend eingesetzt 
werden. Da stören die Panels nicht. Besonders die "kostengünstige" 
Lösung würde ein Panel eher erfüllen. Es widerspricht auch nicht dem 
Gitter - das kann man auch auf die Platinen setzen. Ich hoffe das dieser 
Punkt, Panel vs Pixel, noch nicht festgelegt ist. Ich sehe große 
Vorteile im Preis und auch im Aufbau, dagegen nur kleine Abstriche in 
der Flexibilität. Falls doch halte ich mit ab sofort raus.

Ich finde es gut, dass du diese Diskussion mit einem neuen Thread 
strukturiert lenken möchtest. Vielleicht wäre es jedoch sinnvoller für 
die verschiedenen Punkte jeweils eigene Threads anzulegen. Sonst gibt es 
wahrscheinlich das gleiche Chaos wie im anderen Thread.

: Bearbeitet durch User
von Konrad S. (maybee)


Bewertung
lesenswert
nicht lesenswert
Tim hat es im Eröffnungspost nicht so deutlich betont, dass dies der 
Thread für "ein Pixel - eine Platine" sein soll. Doch genau das ist der 
Sinn des neuen Threads. Sicher wird es einige Gemeinsamkeiten mit einer 
möglichen Mehr-Pixel-Platine geben, aber hier steht dieser Punkt nicht 
zur Diskussion.

Sam .. schrieb:
> Falls doch halte ich mit ab sofort raus.

... aber bitte immer noch hier mit einem Auge mitlesen. ;-)

Wenn jemand einen Thread für eine Mehr-Pixel-Platine aufmacht, dann 
würde ich die Diskussion dort auch gerne verfolgen. Also im 
ursprünglichen Thread Beitrag "LED Tisch mit Berührungs-/Gegenstandserkennung" bitte 
einen Link darauf posten.

von Borislav B. (boris_b)


Bewertung
lesenswert
nicht lesenswert
Konrad S. schrieb:
> im hat es im Eröffnungspost nicht so deutlich betont, dass dies der
> Thread für "ein Pixel - eine Platine" sein soll.

Das halte ich nicht für sinnvoll. Bist du sicher, dass es so gemeint 
ist? Hier soll es doch eher darum gehen, ein bestimmtes, klar 
definiertes Endprodukt zu bauen:

 - Tisch aus RGB-LED-Matrix
 - Scharf getrennte Pixel
 - IR Touch pro Pixel
 - usw.

Ob man das nun mit ein- oder mehr-Pixel Platinen umsetzt, macht dafür ja 
keinen Unterschied. Die ein-Pixel Lösung hat jedoch nur Nachteile 
(höherer Aufwand, höhere Kosten) und keine Vorteile.

Warum sollte man also mit Gewalt auf dieser Lösung bestehen?

: Bearbeitet durch User
von Basti (Gast)


Bewertung
lesenswert
nicht lesenswert
Wieviel sind denn für die Einzelplatine? Nicht das das hier bald ein 
Selbstgespräch wird...

Ich find es gut, dass der Tim mit aller Macht am Ball bleiben will!
Jetzt brauchen wir noch so einen Projektmanager für die Mehrpixel 
Platine, sonst ist da bald die Luft raus...

Grüße

Basti

P.S. Stimme für mehrpixelplatine...

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
lesenswert
nicht lesenswert
Es ist doch vollkommen egal, ob das Einzelplatinen sind oder nicht. Man 
bestellt doch sowieso mit einem bestimmten "Nutzen" und damit 
quadratzentimeterweise. Gezahlt wird die Gesamtfläche. In wieviele 
Stückchen die Platine vom Platinenhersteller geschnitten wird, ist meist 
vollkommen schnuppe.

Also konzentriert Euch auf Einzelplatinen. Je kleiner, desto billiger.

von Sam .. (sam1994)


Bewertung
lesenswert
nicht lesenswert
> Also konzentriert Euch auf Einzelplatinen. Je kleiner, desto billiger.

Bei der Preiskalkulation geht es weniger um die Platinen sondern mehr um 
die Bauteile darauf. Bei Panels können Mikrocontroller und Treiber für 
mehrere Leds genutzt werden. Das senkt den preis drastisch da der 
Mikrocontroller u.a. das teuerste Bauteil sein wird.  Ich habe dazu im 
alten Thread ein Rechenbeispiel mit Preisen für 1000 pixel gemacht. Da 
kam ich auf unter 30cent/pixel. Selbst ein ähnlichet preis wird mit 
Einzel Pixeln nicht möglich sein.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
lesenswert
nicht lesenswert
Sam .. schrieb:
> Bei der Preiskalkulation geht es weniger um die Platinen sondern mehr um
> die Bauteile darauf. Bei Panels können Mikrocontroller und Treiber für
> mehrere Leds genutzt werden. Das senkt den preis drastisch da der
> Mikrocontroller u.a. das teuerste Bauteil sein wird.

Finde ich im alten Thread auch eine Schaltung dazu? Oder wirfst Du das 
hier nur in den Raum, um den bisherigen Stand (nämlich 1µC pro Pixel) 
einfach hier mal wieder so in Frage zu stellen und auch diesen Thread 
wieder gegen die Wand zu fahren?

Ich selber baue übrigens gerade einen Multitouch-Table mit 1 MegaPixel. 
Dafür brauche ich 4 IR-Laser, 1 PC, einen Beamer, eine Glasplatte und 
eine Webcam.

Kosten: 0,14 Cent pro Pixel. Unschlagbar.

Und damit bin ich hier endgültig raus.

: Bearbeitet durch Moderator
von Borislav B. (boris_b)


Bewertung
lesenswert
nicht lesenswert
Frank M. schrieb:
> Finde ich im alten Thread auch eine Schaltung dazu? Oder wirfst Du das
> hier nur in den Raum

Ist das nicht einleuchtend? Beispiel bei einer 4x4 Platine: Anstatt 16 
µCs brauchst du so nur einen (etwas größeren).

Frank M. schrieb:
> einfach hier mal wieder so in Frage zu stellen und auch diesen Thread
> wieder gegen die Wand zu fahren?

Warum gegen die Wand fahren? Eher in die richtige Richtung lenken.

Frank M. schrieb:
> Ich selber baue übrigens gerade einen Multitouch-Table mit 1 MegaPixel.
> Dafür brauche ich 4 IR-Laser, 1 PC, einen Beamer, eine Glasplatte und
> eine Webcam.
>
> Kosten: 0,14 Cent pro Pixel. Unschlagbar.
>
> Und damit bin ich hier endgültig raus.

Schön für dich. Ist aber nicht das Konzept, um das es hier geht. Daher 
ist der Preis pro Pixel auch nicht vergleichbar...

von asterix (Gast)


Bewertung
lesenswert
nicht lesenswert
Boris P. schrieb:
> Schön für dich. Ist aber nicht das Konzept, um das es hier geht. Daher
> ist der Preis pro Pixel auch nicht vergleichbar...

Und die 4x4 Lösung ist nicht das Konzept, um das es hier geht. Es war 
die Nachfrage nach einer PIXELPLATINE und diese galt es zu lösen

Nur weil ihr am Preis mausern wollt, wollen es vielleicht nicht 
unbedingt die anderen ;-)

Ich verstehe das Problem nicht einen zweiten Thread für die 
"Multi-Pixel" zu eröffnen, dann kann man zweigleisig fahren... viele 
hier verfolgen das sicherlich mit Interesse aber wollen eben auf einer 
Pixelplatine einen flexiblen Aufbau starten

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
lesenswert
nicht lesenswert
Boris P. schrieb:

>> Kosten: 0,14 Cent pro Pixel. Unschlagbar.
>>
>> Und damit bin ich hier endgültig raus.
>
> Schön für dich. Ist aber nicht das Konzept, um das es hier geht. Daher
> ist der Preis pro Pixel auch nicht vergleichbar...

Genau, Du hast es erkannt. Ist genau NICHT das Konzept, um das es HIER 
geht. Deshalb hab ich das Beispiel hier genannt. Leider ist bei Dir 
dabei nicht das Licht aufgegangen...

Dieser neue Thread wurde extra aufgemacht, damit HIER eine PIXELPLATINE 
diskutiert wird. Was passiert? Schon ist Sam wieder da und will mehrere 
Pixel auf einer Platine unterbringen...

Daher: Sams Ansatz ist genau NICHT das Konzept, um das es HIER geht. Das 
kann er (und vielleicht Du auch) in irgendeinem anderen Thread erörtern.

Wieviele neue Threads muss man denn noch aufmachen?

: Bearbeitet durch Moderator
von Borislav B. (boris_b)


Bewertung
lesenswert
nicht lesenswert
Frank M. schrieb:
> Genau, Du hast es erkannt. Ist genau NICHT das Konzept, um das es HIER
> geht. Deshalb hab ich das Beispiel hier genannt. Leider ist bei Dir
> dabei nicht das Licht aufgegangen...

Es geht um eine Pixelplatine, genau. Wer hat gesagt dass darauf nur 
genau EIN Pixel sein darf?

Frank M. schrieb:
> Daher: Sams Ansatz ist genau NICHT das Konzept, um das es HIER geht. Das
> kann er (und vielleicht Du auch) in irgendeinem anderen Thread erörtern.

Soll also am Ende jeder, der an dem Projekt mitmachen will, seinen 
eigenen Thread aufmachen? Halte ich nicht für geschickt.

Aber gut, wenn dieser Thread sich ausschließlich mit Ein-Pixel-Platinen 
beschäftigt, werde ich mich natürlich sofort raushalten. Sorry für die 
unnötigen Beiträge meinerseits.

von Sam .. (sam1994)


Bewertung
lesenswert
nicht lesenswert
@Frank
Wenn das der Grundgedanke ist, dann kann man das auch so direkt in die 
Anforderungen schreiben, damit es keine Missverständnisse gibt. Und du 
musst dich gar nicht beschweren, dass ich nochmal nachhake, wenn du mit 
einem Nullargument wie

Frank M. schrieb:
> Es ist doch vollkommen egal, ob das Einzelplatinen sind oder nicht. Man
> bestellt doch sowieso mit einem bestimmten "Nutzen" und damit
> quadratzentimeterweise. Gezahlt wird die Gesamtfläche. In wieviele
> Stückchen die Platine vom Platinenhersteller geschnitten wird, ist meist
> vollkommen schnuppe.
>
> Also konzentriert Euch auf Einzelplatinen. Je kleiner, desto billiger.

kommst. Das ist vom Aspekt des Gesamtpreises einfach nur inhaltlich 
falsch. Statt unhöflich zu werden hätte man das anders und auch mit 
einem anderen Ton klären können.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
lesenswert
nicht lesenswert
Boris P. schrieb:
> Es geht um eine Pixelplatine, genau. Wer hat gesagt dass darauf nur
> genau EIN Pixel sein darf?

Das geht aus den letzten 3 Beiträgen des Ursprungsthreads hervor.

> Soll also am Ende jeder, der an dem Projekt mitmachen will, seinen
> eigenen Thread aufmachen? Halte ich nicht für geschickt.

Wir kommen auf keinen grünen Zweig, wenn hier drei Parteien mitmischen 
und alle ihre eigene Lösung propagieren. Wenn man den Ursprungsthread 
von Anfang an liest, erkennt man, dass bereits viel Zeit und 
Überlegungen in das Konzept geflossen ist und die Leute, die 
ursprünglich daran beteiligt waren, sich nach Abwägen und vielem Hin und 
Her auf einen µC pro Pixel geeinigt haben.

Das war ja schon mal ein Ergebnis, auf das man aufbauen konnte! Wenn nun 
wieder andere Vorschläge gemacht werden, dann ist das einfach nur noch 
kontraproduktiv. Und das Schlimmste: Man fängt wieder von vorne bei Null 
an! So wird man nie und nimmer fertig!

> Aber gut, wenn dieser Thread sich ausschließlich mit Ein-Pixel-Platinen
> beschäftigt, werde ich mich natürlich sofort raushalten. Sorry für die
> unnötigen Beiträge meinerseits.

Leute, ich hatte Euch gebeten, den Ursprungsthread von Anfang an zu 
lesen. Ich finde es einfach nur schade, wenn Ihr das nicht tut und bis 
heute nicht kapiert habt, worum es geht.

Sam .. schrieb:
> Wenn das der Grundgedanke ist, dann kann man das auch so direkt in die
> Anforderungen schreiben, damit es keine Missverständnisse gibt.

Hier

  Beitrag "Re: LED Tisch mit Berührungs-/Gegenstandserkennung"

hatte ich Euch (und gerade Dich!) gebeten, den Thread von Anfang an zu 
lesen. Das hast Du geflissentlich ignoriert... sonst wärest Du nicht 
schon wieder mit einer Multipixel-Lösung hier angetrabt. Über die Gründe 
Deiner Ignoranz will ich gar nicht erst Vermutungen anstellen, sonst 
legst Du mir das noch als irgendeine Bösartigkeit aus.

> Das ist vom Aspekt des Gesamtpreises einfach nur inhaltlich falsch.

Zeige mir bitte Deine detaillierte Berechnung der Kosten pro Pixel... 
mit allen Klemmen, Drähten und dem Drumherum.

Deine Berechnung der Kosten im alten Thread halte ich schlichtweg für 
eine Milchmädchenrechnung. Sobald Du mehrere Pixel pro µC ansteuern 
willst, brauchst Du Peripherie drumherum. Und die kostet auch.

Gerade das hier:

  http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html#Platine

wollen wir nicht. Darüber waren wir uns schon einig.

Mein Minimal-Vorschlag, dieses Konzept

  Beitrag "Equinox-Uhr mit 60 ATtinys"

hier als Vorlage zu nehmen, wurde zwar nicht akzeptiert, aber ich habe 
mich damit arrangiert.

: Bearbeitet durch Moderator
von Sam .. (sam1994)


Angehängte Dateien:

Bewertung
lesenswert
nicht lesenswert
Eigentlich wollte ich mich hier raushalten. Aber du forderst mich ja 
geradezu auf...

Der alte Thread ist mir übrigens bekannt. Vom ersten bis zum letzten 
Beitrag.

Frank M. schrieb:
> Zeige mir bitte Deine detaillierte Berechnung der Kosten pro Pixel...
> mit allen Klemmen, Drähten und dem Drumherum.

Ich habe bewusst Sachen weggelassen, die man bei beiden Lösungen im 
gleichen Maße braucht. Daher sind Klemmen und Drähte nicht eingeflossen. 
Wer es wirklich günstig haben möchte kann auch festverdrahten, statt 
Klemmen zu benutzen. Das steht jedem frei.

> Deine Berechnung der Kosten im alten Thread halte ich schlichtweg für
> eine Milchmädchenrechnung. Sobald Du mehrere Pixel pro µC ansteuern
> willst, brauchst Du Peripherie drumherum. Und die kostet auch.

Für dich jetzt noch ein Mal mit Quellen. Ich gehe von 1600 Pixeln (100 
Platinen) aus und rechne OHNE Leds, Photodioden, Klemmen und Drähte, 
Kondensatoren und Widerstände. Diese kommen bei beiden Rechnungen dazu, 
außerdem ist der Verdrahtungsaufwand bei Panels erheblich geringer. 
Widerstände und Kondensatoren sind zu vernachlässigen, da sie vom 
Gesamtpreis weniger als einen Cent ausmachen.

Die Peripherie, die man benötigt, besteht aus einem 
Konstantstromschieberegister + Mosfets, die zusammen eine Matrix bilden. 
am µC reichen 8 Pins um die ganze Matrix zu bedienen. Mit der Matrix 
kann man gleichzeitig aus die Photodioden multiplexen. Man benötigt nur 
noch 4 ADC-Eingänge. Die IR-Dioden schließt man an die 
Konstantstromschieberegister an.

Ich habe die Tabelle anhängt. Je nach dem was man auswählt, landet man 
um die 30cent pro pixel. Insgesamt halte ich 50 pro pixel mit LEDs gut 
machbar.

: Bearbeitet durch User
von Experte (Gast)


Bewertung
lesenswert
nicht lesenswert
Mal eine Zwischenfrage: Benötigt man überhaupt extra Sensoren? Kann man 
nicht einfach die LEDs als Sensoren verwenden.

Man könnte doch für < 1ms einen Lichtpuls auf einer LED erzeugen und die 
benachbarte LED registriert das reflektierte Licht und fungiert für 
diesen kurzen Zeitraum als Sensor...


Die Idee ist vielleicht Murks, ist mir aber eben gekommen...

von Konrad S. (maybee)


Bewertung
lesenswert
nicht lesenswert
Experte schrieb:
> Die Idee ist vielleicht Murks,

Ist sie, zumindest in dieser Situation. Karol Babiochs Versuche haben 
kein Übersprechen zwischen Pixel-Zellen ergeben.

von Sam .. (sam1994)


Bewertung
lesenswert
nicht lesenswert
Das Verfahren funktioniert - das habe ich schon mal getestet. Nachteil 
ist aber, dass die Leds dann nie ganz aus sind und die Empfindlichkeit 
von Leds als Photodiode ist auch nicht das wahre, ganz zu schweigen von 
dem Umgebungslicht als neue Störquelle.
Ich weiß nicht was genau von Karol getestet worden ist. Natürlich muss 
man die roten Leds als Empfänger nutzen, da bei ihnen die 
Austrittsarbeit am geringsten ist.

von Karol B. (johnpatcher)


Bewertung
lesenswert
nicht lesenswert
Experte schrieb:
> Die Idee ist vielleicht Murks, ist mir aber eben gekommen...

Kannst du gerne probieren. In der Theorie funktioniert das sicherlich 
auch ganz wunderbar. Auch habe ich schon Aufbauten gesehen, die sich 
diesen Effekt zu Nutze machen. Ich bezweifle allerdings ganz stark, dass 
du damit durch das Glas hindurch etwas detektieren wirst können. 
Unabhängig davon müsste man sich dann Gedanken zur Synchronisation 
einzelner benachbarter Pixel einfallen lassen. Die bisher angedachten 
Überlegungen zur Datenübertragung würden so etwas gar nicht ermöglichen.

Sam .. schrieb:
> Ich weiß nicht was genau von Karol getestet worden ist.

Sam .. schrieb:
> Der alte Thread ist mir übrigens bekannt. Vom ersten bis zum letzten
> Beitrag.

Dann solltest du auch wissen was ich getestet hatte ;). Im Spiel waren 
IR-LEDs und IR-Photodioden.

Mit freundlichen Grüßen,
Karol Babioch

von Sam .. (sam1994)


Bewertung
lesenswert
nicht lesenswert
Karol Babioch schrieb:
> Dann solltest du auch wissen was ich getestet hatte ;). Im Spiel waren
> IR-LEDs und IR-Photodioden.

Sehr witzig. Ich weiß nicht wie du diesen Effekt genau getestet hast:

Konrad S. schrieb:
> Karol Babiochs Versuche haben
> kein Übersprechen zwischen Pixel-Zellen ergeben.

Mit roten Leds als Empfänger im klaren Gehäuse funktioniert das 
durchaus. Aber ich glaube auch nicht, dass es über eine Glasscheibe 
funktionieren wird.

: Bearbeitet durch User
von Karol B. (johnpatcher)


Bewertung
lesenswert
nicht lesenswert
Sam .. schrieb:
> Sehr witzig. Ich weiß nicht wie du diesen Effekt genau getestet hast:

Durch Herumspielen mit einem "echten" Aufbau. Wird doch auch im von mir 
geposteten Video deutlich, dass das Ganze ziemlich zuverlässig 
funktioniert und nur die jeweils richtigen Zellen aktiviert werden. Die 
ungewollte Interaktion zwischen benachbarten Zellen war nämlich ein 
Bedenken.

Mit freundlichen Grüßen,
Karol Babioch

: Bearbeitet durch User
von Sam .. (sam1994)


Bewertung
lesenswert
nicht lesenswert
Ja, die Erkennung im Video sah schon sehr reif aus. Ich dachte Konrad 
wollte andeuten, dass du auch versucht hast die RGB-Led als Photodiode 
zu verwenden.

von Karol B. (johnpatcher)


Bewertung
lesenswert
nicht lesenswert
Sam .. schrieb:
> dass du auch versucht hast die RGB-Led als Photodiode
> zu verwenden.

Nein, und ich kann mir ehrlich gesagt nicht vorstellen, dass das 
funktioniert, zumindest nicht unter den gegebenen Voraussetzungen 
(Störquellen, Glas, etc.). Ich lasse mich aber gerne vom Gegenteil 
überzeugen. Allerdings würde das auch eine andere Verdrahtung erfordern. 
Die zum Teil vorgeschlagenen LED-Treiber wären damit gänzlich aus dem 
Spiel.

Mit freundlichen Grüßen,
Karol Babioch

von Experte (Gast)


Bewertung
lesenswert
nicht lesenswert
War vermutlich eine Schnapsidee von mir. Zumal eine zusätzliche 
Photodiode ja auch nicht besonders viel Aufwand macht, gemessen an dem 
Ansteuerungsaufwand den man im anderen Fall hätte.

:-)

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Tim R. schrieb:
> Projektidee für einen Touch Pixel für diverse Anwendungen fortgeführt
> werden

Und ich dachte die Beschreibung und der Threadname "RGB Pixel mit Touch" 
wären eineindeutig :-(

von hagbard (Gast)


Bewertung
lesenswert
nicht lesenswert
Tim R. schrieb:
> Und ich dachte die Beschreibung und der Threadname "RGB Pixel mit Touch"
> wären eineindeutig :-(

Also ich fand das zusammen mit den Beiträgen im alten Thread eigentlich 
sehr eindeutig, dass es hier um EINEN Pixel gehen soll.

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
hagbard schrieb:
> Also ich fand das zusammen mit den Beiträgen im alten Thread eigentlich
> sehr eindeutig, dass es hier um EINEN Pixel gehen soll.

Danke, ich hatte schon Selbstzweifel!

wie soll das nun hier weitergehen, Vorschläge? ;-)

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
okay dann kann der Thread auch gelöscht werden oder so...

ich mach mein eigenes Ding ;-) :-P

von Borislav B. (boris_b)


Bewertung
lesenswert
nicht lesenswert
Tim R. schrieb:
> okay dann kann der Thread auch gelöscht werden oder so...
>
> ich mach mein eigenes Ding ;-) :-P

Naja, nachdem man alle potentiellen Mitbastler vergrault hat, passiert 
halt nicht mehr so viel ;-)

Ich habe mich auch schon an eine Eigen-Konstruktion begeben...

von Christian H. (c_h)


Bewertung
lesenswert
nicht lesenswert
Es wäre toll, wenn ihr beide Euren Fortschritt posten könntet, z.B. 
Fotos, Layout, Schaltplan, Kosten pro Pixel. Es wäre wirklich spannend 
zu lesen und sehr interessant. Und wenn es Fortschritt gibt, springen 
bestimmt wieder Leute auf und helfen, und sei es nur die Stückzahlen zu 
erhöhen für Bestellungen.

Ich habe im Moment leider keine Zeit, Tests mit der von mir 
favorisierten Lösung mit Schieberegistern für IS471F und dem TLC zu 
machen :-(

von asterix (Gast)


Bewertung
lesenswert
nicht lesenswert
Boris P. schrieb:
> Tim R. schrieb:
>> okay dann kann der Thread auch gelöscht werden oder so...
>>
>> ich mach mein eigenes Ding ;-) :-P
>
> Naja, nachdem man alle potentiellen Mitbastler vergrault hat, passiert
> halt nicht mehr so viel ;-)

Ja, dass habt ihr gut hinbekommen, wenn du es so hinstellen möchtest 
lach.. ;-)

von Borislav B. (boris_b)


Bewertung
lesenswert
nicht lesenswert
asterix schrieb:
> wenn du es so hinstellen möchtest

Um Dich zu zitieren:

asterix schrieb:
> Ich verstehe das Problem nicht einen zweiten Thread für die
> "Multi-Pixel" zu eröffnen, dann kann man zweigleisig fahren... viele
> hier verfolgen das sicherlich mit Interesse aber wollen eben auf einer
> Pixelplatine einen flexiblen Aufbau starten

von hagbard (Gast)


Bewertung
lesenswert
nicht lesenswert
Ich lese eigentlich nur interessier mit und möchte gar keinen Tisch 
bauen.
Wenn es denn mal eine Pixelplatine gibt würde ich vielleicht ein paar 
wenige mitbestellen, um das mal auszuprobieren.
Sowas wie aus Karols Versuchen würde mir ja schon reichen, da ich ja 
nicht die Problematik der hunderten Pixel hätte...

von asterix (Gast)


Bewertung
lesenswert
nicht lesenswert
Boris P. schrieb:
> asterix schrieb:
>> wenn du es so hinstellen möchtest
>
> Um Dich zu zitieren:
>
> asterix schrieb:
>> Ich verstehe das Problem nicht einen zweiten Thread für die
>> "Multi-Pixel" zu eröffnen, dann kann man zweigleisig fahren... viele
>> hier verfolgen das sicherlich mit Interesse aber wollen eben auf einer
>> Pixelplatine einen flexiblen Aufbau starten

Also ich finde es ja toll wenn viele mitmachen und ihre Ideen 
präsentieren... aber die Tatsache das dein/euer verspäteter Einwand 
nicht angenommen wurde und ihr zur Übersicht auf einen eigenen Thread 
gebeten wurdet... bedeutet, dass du ausgeschlossen wurdest? Und die 
Tatsache, dass nun ein zweiter extra Thread durch erneutes 
"ich-will-meine-Meinung-durchsetzen" dadurch versaubeutelt wurde, 
erkennst du nicht? Das klingt leicht egozentrisch und dickköpfig ;-) 
(möchte dich nicht angreifen)

hagbard schrieb:
> Ich lese eigentlich nur interessier mit und möchte gar keinen
> Tisch

die stillen Mitleser können auch gern mitposten, denn so ist es für die 
"aktiven" schwer zu beurteilen, wie denn nun der Bedarf der User ist. 
Ich bin an Pixeln und einem Tisch interessiert, deswegen finde ich es 
echt schade, wie hier vorgegangen wurde... vielleicht raufen sich ja 
einige nochmal zusammen, macht doch mehr Spaß als wenn man alleine 
werkelt :-)

von Conny G. (conny_g)


Bewertung
lesenswert
nicht lesenswert
Also ich hab durch die Aktion gelernt, dass so ein Projekt nur über eine 
Forumsdiskussion zu bewerkstelligen ziemlich schwierig bis unmöglich 
ist.
Mir hat das wiederholte diskutieren derselben Themen zunehmend weniger 
Spass gemacht. Und als dann der Thread förmlich explodierte von neuen 
Mitdiskutierern konnte ich schon gar nicht mehr hinterherkommen beim 
Mitlesen, geschweige denn die Lösung wieder in eine Richtung bringen, 
die mir selber gefällt. Da hab ich dann aufgegeben.
Viele Köche verderben den Brei.
Ich meine, es muss ein kleines Team von 2-5 Mann sein, dass in einer 
geschlossenen Gruppe zusammenarbeitet und ggf auch ab und zu mal einen 
Skype Call zu einem Thema hat um es festzunageln.
So wie auch Softwareprojekte am besten und effizientesten funktionieren.
Architektur kann man nicht basisdemokratisch mit zwei bis vier Dutzend 
Leuten machen.

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Conny G. schrieb:
> Ich meine, es muss ein kleines Team von 2-5 Mann sein, dass in einer
> geschlossenen Gruppe zusammenarbeitet und ggf auch ab und zu mal einen
> Skype Call zu einem Thema hat um es festzunageln.
> So wie auch Softwareprojekte am besten und effizientesten funktionieren.
> Architektur kann man nicht basisdemokratisch mit zwei bis vier Dutzend
> Leuten machen.

..genau diesen Ansatz verfolge ich seit ein paar Tagen.
Wenn du noch Interesse hast, schick ich dir demnächst mal eine Mail und 
dann kann man weiter schauen

von Conny G. (conny_g)


Bewertung
lesenswert
nicht lesenswert
Tim R. schrieb:
> Conny G. schrieb:
>> Ich meine, es muss ein kleines Team von 2-5 Mann sein, dass in einer
>> geschlossenen Gruppe zusammenarbeitet und ggf auch ab und zu mal einen
>> Skype Call zu einem Thema hat um es festzunageln.
>> So wie auch Softwareprojekte am besten und effizientesten funktionieren.
>> Architektur kann man nicht basisdemokratisch mit zwei bis vier Dutzend
>> Leuten machen.
>
> ..genau diesen Ansatz verfolge ich seit ein paar Tagen.
> Wenn du noch Interesse hast, schick ich dir demnächst mal eine Mail und
> dann kann man weiter schauen

Cool. Interesse ja, Zeit knapp. Hab noch ein - für meine Verhältnisse - 
größeres Beleuchtungssteuerungsprojekt abzuschließen und komme da schon 
kaum zu.

von Inteteressent (Gast)


Bewertung
lesenswert
nicht lesenswert
Ist das Projekt nun komplett eingeschlafen? Ich gehoerte zu der Fraktion 
"stiller Mitleser" und habe alle dazu gehoerigen Threads mit Interesse 
verfolgt. Leider leuder scheint es nix neues zu dem Thema zu geben. Oder 
hat jemand eine solche Platine mal gebastelt? Oder eine mit mehrere 
LEDs?

von Karol B. (johnpatcher)


Bewertung
lesenswert
nicht lesenswert
Inteteressent schrieb:
> Ist das Projekt nun komplett eingeschlafen?

Nein. Ich tausche mich mit Tim R. und einem weiteren Mitbastler von Zeit 
zu Zeit intern per E-Mail aus. Wir überlegen derzeit eine private 
Mailing-Liste bzw. Forum und Wiki aufzusetzen, sodass man alles in Ruhe 
unter seinen Mitstreitern diskutieren und Fortschritte dokumentieren 
kann.

Wirklich neuartiges gibt es bisher aber nicht zu berichten, das würden 
wir sicherlich ankündigen. Derzeit sind wir mit dem Versuchsaufbau zum 
Testen des UART Rings beschäftigt.

Ich persönlich habe aber davon abgesehen hier jeden kleinen Schritt an 
die "große" Glocke zu hängen, weil ich die vielen nutzlosen Diskussionen 
in der Vergangenheit als nervig empfand. Ständig kamen neue Leute mit 
neuen bzw. "besseren" Ideen, ohne unsere Überlegungen bzw. die 
Anforderungen zu kennen und wollten das Projekt in eine gänzlich andere 
Richtung stoßen. Letztendlich hatte ich das Gefühl, dass man sich nur 
wiederholt hat. Zumindest Tim R. sieht das wohl sehr ähnlich.

Der neue Ansatz ist es nun erst einmal im "stillen Kämmerchen" einen 
Prototypen zu entwickeln und diesen dann vorzustellen. Dann kann man 
zwar immer noch über Pro- und Kontras diskutieren, hat aber zumindest 
mal etwas konkretes in der Hand.

Bei Interesse könnt ihr euch gerne bei mir melden, dann würde ich euch 
in unsere Überlegungen mit einschließen. Ich bin auch gerne bereit ganz 
prinzipiell über unseren Ansatz zu diskutieren und was man anders/besser 
machen könnte, dann aber anhand eines konkreten Anforderungskatalogs und 
nicht im vorher geführten Stile.

Mit freundlichen Grüßen,
Karol Babioch

: Bearbeitet durch User
von Ein weiterer Interessent (Gast)


Bewertung
lesenswert
nicht lesenswert
Hallo,
ich bin vor einigen Tagen auf den vorherigen Beitrag und diesen Beitrag 
gestoßen und habe diese mit Interesse gelesen. Hat sich nach August 
letzten Jahres noch einmal etwas in diesem Projekt getan? Ich konnte 
leider keine aktuelleren Beiträge mehr finden. Falls welche existieren 
sollten wäre ich für einen kleinen Hinweis dankbar.

von Asterix (Gast)


Bewertung
lesenswert
nicht lesenswert
Eine kleine Gruppe hatte sich gefunden, um das Thema erstmal "extern" 
aufzurollen... leider ist das aber aus Zeitgründen auch erstmal im Sande 
verlaufen...
Ich denke das also kein weiterer Fortschritt erkennbar ist

von rgb (Gast)


Bewertung
lesenswert
nicht lesenswert
Hallo,

da ich derzeit an diesem Thema dran bin, greife ich diesen Thread 
einfach noch mal auf

ich habe mir diese RGBs besorgt:
http://www.elv.de/rgb-led-fuer-rgbc555.html
diffus, 80° Öffnungswinkel, 10mm groß

mein Ziel:
ein ca. 10x10cm (evtl. auch größer) Pixel voll ausleuchten. Ich habe 
einen solchen Pixel mit satiniertem Glas mit 79% Lichtdurchzlässigkeit 
und 5cm Höhe gebaut und die RGB entsprechend reingesetzt. Stromstärke 
durch einen vorgesetzten Poti reguliert und geschaut, was möglich ist. 
Die Höhe habe ich auch verändert indem das Pixelgehäuse einfach etwas 
hochgehalten wurde. Das erfreudige war, dass keine punktuelle 
Beleuchtung zustande kam und das Licht sich am Glas sehr gut "verteilt" 
hat.

mein Problem:
Die Pixelwände bzw Ecken wurden nicht wirklich ausgeleuchtet. Die 
Helligkeit hat von Innen nach Aussen abgenommen. Wie kann ich dieses 
Problem lösen? Ich habe wie gesagt Stromstärke und Höhe bzw. Abstand 
zwischen RGB und Glas dynamisch verändert, aber keinen brauchbaren 
Zustand erreicht.
Ist die RGB dafür geeignet oder kann mir jemand eine bessere empfehlen? 
Vielleicht mehrere RGBs für einen Pixel? Was leider den Stromverbrauch 
der Pixelzelle in die Höhe treiben würde

ich bin dankbar für Hilfe

von Conny G. (conny_g)


Bewertung
lesenswert
nicht lesenswert
Das ist eine rein geometrische Angelegenheit.
Die Lichtstärke an einem Punkt nimmt mit dem Quadrat der Entfernung ab. 
Wenn Du 5cm entfernt bist und einen 10x10 Pixel hast, dann ist die 
Entfernung der Ecke 7cm, in der Mitte 5cm.
Also ist die Ecke 1,5x soweit entfernt und die Lichtstärke an dieser 
Stelle 1/(1,5)^2 = 0,44 von der Mitte.

Du müsstest also den Abstand soweit vergrößern, dass dieser Unterschied 
nicht mehr so stark ausfällt.
Sagen wir Das Licht in der Ecke soll nur 20% weniger stark sein, also 
0,8. Rechnung also Rückwärts 1/x^2 = 0,8 oder 1 = 0,8 x x^2 oder x^2 = 
1/0,8 oder x = sqrt(1/0,8) = 1,1.
Also darf der Abstand in der Ecke nur 10% größer als der Abstand in der 
Mitte sein.
Das geht jetzt mit dem Pythagoras, ich hab das aber gerade der 
Einfachheit halber im Cad-Programm probiert - ich käme auf einen Abstand 
von ca. 15cm wo das der Fall ist.
Dabei verlierst Du aber durch den Abstand schon wieder jede Menge Licht, 
der nicht auf dem Glas sondern an den Seitenwänden landet.

M.e. muss es mehr als 5cm sein, aber keine 15cm, ich denke bei 8-10cm 
sollte es gut genug sein.

von mic (Gast)


Bewertung
lesenswert
nicht lesenswert
Kann so eine platine herstellen.
8 io Pins.
Zwei sind für Kommunikation reserviert.
VerWendung:
IR beacon.
Charliplex 6way borg led oder rgb led

von Markus M. (adrock)


Bewertung
lesenswert
nicht lesenswert
...dadurch wird natürlich der Aufbau der "Platte" relativ "dick".

Dünner geht nur mit mehr LEDs (also z.B. 4 anstelle von einer), die man 
dafür natürlich dann nicht so hell laufen lassen muss.

So ein Pixeltisch wäre immer noch cool, ist aber leider eine ziemliche 
Materialschlacht und somit mit einigen Kosten verbunden, wenn es denn 
mehr Pixel sind und auch noch Touch.

von rgb (Gast)


Bewertung
lesenswert
nicht lesenswert
Ich wollte das ganze einfach mal empirisch ermitteln und nicht 
berechnen, weil viele Faktoren eingebracht werden müssen. Trotzdem danke 
für diese Beispielrechnung

Ich probiere es gleich noch einmal mit ca 8-10cm Abstand, jedoch bin ich 
ziemlich sicher, dass dadurch die Lichtausbeute auf dem Glas nicht 
bemerkenswert besser wird

Ein "dicker" Aufbau ist eigentlich genau das was ich vermeiden wollte.. 
Ich probiere dennoch erstmal weiter. Ansonsten müssten wohl doch mehrere 
RGBs km einen Pixel

@Markus
Die Idee vom Pixel war eine dynamische Verwendung. Das ganze muss nicht 
in einem riesen Projekt wie z.B. einem Tisch enden. Ich hab damit 
kleineres vor :-)

von Conny G. (conny_g)


Bewertung
lesenswert
nicht lesenswert
Klar, mit 4 LEDs statt einer in der Mitte kannst Du den Abstand 
verringern, vermutlich halbieren. Wenn man viele Pixel machen will 
kostet das halt zuviel.

von mic (Gast)


Bewertung
lesenswert
nicht lesenswert
Will jetzt konkret nachfragen ob Interesse besteht
Oder nicht.
Platine wird zwischen ca 3cm und 4cm sein.

Aktuell ist dies die geplante Belegung.
IR TX
Ir RX
3x led
2x comm
1x RC ADC

3x Led kann auch MIT charliplex verwendet werden,
Oder mit mehreren LEDs, da optional Transistor.

IR rx wird nur der Carrier ausgewertet.
ADC ist als Batteriespannung sowie Helligkeit Sensor gedacht.
Als standalone ist bei comm i2c Speicher geplant,
Als store and forward Speicher sowie Logging oder RF Modul.

von rgb (Gast)


Bewertung
lesenswert
nicht lesenswert
Conny G. schrieb:
> Klar, mit 4 LEDs statt einer in der Mitte kannst Du den Abstand
> verringern, vermutlich halbieren. Wenn man viele Pixel machen will
> kostet das halt zuviel.

Genau deshalb versuche ich eine 1-RGB-Lösung zu finden.

mic schrieb:
> Will jetzt konkret nachfragen ob Interesse besteht
> Oder nicht.
> Platine wird zwischen ca 3cm und 4cm sein.

Sorry, aber ich kann deinen Beiträgen einfach nicht folgen

von mic (Gast)


Angehängte Dateien:

Bewertung
lesenswert
nicht lesenswert
Hier mal ein Schaltplan zur Diskussionsgrundlage.
Es sind hier mehrere Bestueckungsmöglichkeiten vorhanden, ohne
Transistoren, ohne current limiters, ... .

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Conny G. schrieb:
> Klar, mit 4 LEDs statt einer in der Mitte kannst Du den Abstand
> verringern, vermutlich halbieren. Wenn man viele Pixel machen will
> kostet das halt zuviel.

Die Frage wäre halt, welche RGBs für einen vernünftigen Preis?!

von Konrad S. (maybee)


Bewertung
lesenswert
nicht lesenswert
Ast E. schrieb:
> Die Frage wäre halt, welche RGBs für einen vernünftigen Preis?!

Die RGB-LEDs hier gibt es immer noch:
RGB Touch Matrix: Bauteil-Kandidaten

von chris (Gast)


Bewertung
lesenswert
nicht lesenswert
Konkret nochmals die Frage.
Pixel PCB mit uc, IR led usw
Preislich ca 80 cent.
Oder panel 4x4cm mit 16 pixel in ca 3.5 fache.

von Conny G. (conny_g)


Bewertung
lesenswert
nicht lesenswert
chris schrieb:
> Konkret nochmals die Frage.
> Pixel PCB mit uc, IR led usw
> Preislich ca 80 cent.
> Oder panel 4x4cm mit 16 pixel in ca 3.5 fache.

Frage zurück:
Willst ein Auto kaufen. 4 Räder, Motor Auspuff. Benzin.
Preis 10.000.
Oder mit Anhänger.

von chris (Gast)


Bewertung
lesenswert
nicht lesenswert
Kein Thema.
Bin gerade dabei  ein IR beacon zu entwerfen,
Wobei dieselbe Platine auch noch andere Funktionen alternativ 
ermöglichen soll.
Mit otp uc  und derzeit ist es noch möglich Design wünsche einzubringen.

von rgb (Gast)


Bewertung
lesenswert
nicht lesenswert
Hi
ich muss mal nachfragen, weil ich gerade etwas ähnliches entwickel:
ich habe 4 Pin RGBs und würde gerne mehrere davon betreiben, um eine 
größere Fläche zu beleuchten. Dann muss ich diese parallel mit jeweils 
Widerständen verschalten, is das korrekt? das klingt nach unnötig viel 
Widerständen. Bei 4 RGBs sind das schon 4x3 Widerstände statt nur 3 :-(
Hat jemand eine plausible Lösung?

von Conny G. (conny_g)


Bewertung
lesenswert
nicht lesenswert
rgb schrieb:
> Hi
> ich muss mal nachfragen, weil ich gerade etwas ähnliches entwickel:
> ich habe 4 Pin RGBs und würde gerne mehrere davon betreiben, um eine
> größere Fläche zu beleuchten. Dann muss ich diese parallel mit jeweils
> Widerständen verschalten, is das korrekt? das klingt nach unnötig viel
> Widerständen. Bei 4 RGBs sind das schon 4x3 Widerstände statt nur 3 :-(
> Hat jemand eine plausible Lösung?

Du kannst sie auch in Serie schalten und mit höherer Spannung betreiben.
Die LEDs haben eine bestimmte Durchlassspannung bei einem bestimmten 
Strom (siehe Datenblatt), z.B. irgendwas 2 Volt.
Du kannst die 4 Rot in Serie schalten, das ergibt 4x2 = 8 Volt.
Dann betreibst Du die LEDs an 9 Volt und setzt davor einen Widerstand 
der den Strom auf den gewünschten Strom einstellt (sh. Datenblatt), zum 
Beispiel 10mA. Wenn sich die LEDs von den 9V die 8V nehmen bleiben für 
den Widerstand 1V bei 1mA, R=U/I ergibt 1000 Ohm.
Dasselbe machst Du für alle weiteren Farben der LEDs.

: Bearbeitet durch User
von rgb (Gast)


Bewertung
lesenswert
nicht lesenswert
Conny G. schrieb:
> Du kannst sie auch in Serie schalten und mit höherer Spannung betreiben.
> Die LEDs haben eine bestimmte Durchlassspannung bei einem bestimmten
> Strom (siehe Datenblatt), z.B. irgendwas 2 Volt.
> Du kannst die 4 Rot in Serie schalten, das ergibt 4x2 = 8 Volt.

Danke für deine Antwort. Das ist mir soweit auch bewusst. Ich betreibe 
das ganze mit 12V über Transistoren geschaltet. Jedoch habe ich 4 Pin 
RGBs, sprich Common Anode und 3 dazugehörige PWM Eingänge. Und bei einer 
gemeinsamen Masse, kann ich schlecht die LEDs in Reihe schalten, oder? 
Ich habe irgendwie in der Richtung gerade ein Verständnisproblem

von S R (Gast)


Bewertung
lesenswert
nicht lesenswert
rgb schrieb:
> Und bei einer
> gemeinsamen Masse, kann ich schlecht die LEDs in Reihe schalten, oder?

Genau, das geht nicht. Also entweder 6-beinige nehmen, hellere oder eben 
4-beinige mit mehr Widerständen.

Einen Tod musst du sterben...

von rgb (Gast)


Bewertung
lesenswert
nicht lesenswert
S R schrieb:
> rgb schrieb:
>> Und bei einer
>> gemeinsamen Masse, kann ich schlecht die LEDs in Reihe schalten, oder?
>
> Genau, das geht nicht. Also entweder 6-beinige nehmen, hellere oder eben
> 4-beinige mit mehr Widerständen.
>
> Einen Tod musst du sterben...

Danke für die Bestätigung. Lag ich leider doch richtig. Kennt jemand 
einen Händler mit nicht alt zu teuren 6 Pin (bedrahtet) RGBs?

von Markus M. (adrock)


Bewertung
lesenswert
nicht lesenswert
Nein. RGB LEDs, bedrahtet, ohne gemeinsame Anode/Katode sind sehr 
speziell und somit teuer. Du wirst Dein Design ändern müssen oder SMD 
verwenden.

von rgb (Gast)


Bewertung
lesenswert
nicht lesenswert
Markus M. schrieb:
> Nein. RGB LEDs, bedrahtet, ohne gemeinsame Anode/Katode sind sehr
> speziell und somit teuer. Du wirst Dein Design ändern müssen oder SMD
> verwenden.

Schade. Ich würde gerne ein paar Prototypen auf Lochraster aufbauen 
wollen und nicht gleich mit SMD Bestückung und richtigen PCBs anfangen.
Da eine RGB für die große Fläche nicht ausreicht, möchte ich im Grunde 4 
RGBs über jeweils eine PWM für R-G-B laufen lassen. Was für 
Designänderungen könnte ich denn vornehmen? Das ganze über Multiplexer 
lösen wäre mir jetzt eingefallen, aber das ist ganz schön aufwendig. Bin 
für jeden Tipp dankbar

von Markus M. (adrock)


Bewertung
lesenswert
nicht lesenswert
Naja, ein paar SMD-LEDs kannst Du auch auf Lochraster löten. Einfach 
Drähtchen anlöten und dann wie gehabt. Musst nur schauen wenn Du die 
drähte dann auf der Lochrasterseite anlötest, dass sie sich nicht von 
der LED lösen.

Und PLCC6 ist jetzt noch nicht so klein (ca. 5x5 mm), hier gibt es z.B. 
passende LEDs:

http://www.led1.de/shop/smd-leds/smd-led-bauform-plcc6/led-smd-bauform-plcc6-rgb-werrgb01-c1m.html

von rgb (Gast)


Bewertung
lesenswert
nicht lesenswert
danke für den Tipp, ich werde mir mal etwas überlegen.

ich habe noch eine Frage. Ich möchte statt 5x5cm einen 20x20cm Pixel 
entwickeln. Das Thema der Beleuchtung hatten wir gerade. Wie steht es um 
die "touch" Funktion. Ich würde neben den RGBs auch weitere IR Leds 
einsetzen. Ich frage mich nur gerade, ob eine in der Mitte positionierte 
IR Diode entsprechend auch Reflexionen erkennen kann die nicht 
unmittelbar in der Mitte sondern durch auch an den Seiten(durch die 
weitere IR LEDs) erkennen kann?

von chris (Gast)


Bewertung
lesenswert
nicht lesenswert
Die ir Dioden auf einer Tischplatte sind doch seitlich, oder habe ich da 
was nicht ueberissen?
Andernfalls geht dies bei einer Tischplatte doch nur mit eingeschränkten 
Umweltbedingungen.

von Markus M. (adrock)


Bewertung
lesenswert
nicht lesenswert
...das hängt vom Öffnungswinkel der IR-Diode und dem Abstand zur 
Tischplatte / Objekt ab. Mit ein wenig Geometrie kann man das 
ausrechnen...

Schau mal in die Datenblätter, dort ist das eigentlich immer sehr genau 
beschrieben unter "Directional characteristics" als relative 
Empfindlichkeit in Abhängigkeit vom Einfallswinkel.

von Peter B. (shaphard)


Angehängte Dateien:

Bewertung
lesenswert
nicht lesenswert
Hallo Leute,

ich habe vor ein Paar Tagen diesen Thread und den vorangegangenen 
Entdeckt und ich habe beide gelesen (2 Tage hats gedauert).
Ich habe mit ein paar Schulkollegen einen LED Tisch als Schulprojekt 
gebaut nach dem Vorbild von Julius:
http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html

Wir haben aber den Tisch etwas größer gemacht nämlich 16x16 Pixel.
Wie ja schon festgestellt wurde, ist die Verkabelung einen leichte 
Hölle...
Da wir beim Bau auch diverse Probleme hatten und ich gerne einen zweiten 
Tisch bauen möchte der viele Probleme beseitigt, möchte ich hier das 
Projekt kurz vorstellen. Bilder hab ich ein paar angehängt.

RGB-LED-Tisch mit 16x16 Pixeln und Touch Sensor für jedes Pixel

Verwendete Bauteile:
LED-Treiber: TLC5940
RGB-LED: Superflux 4-Pin RBG-LED
IR-Empfänger: IS471F
Multiplexer: 74HCT4067
Glasplatte: 70% lichtdurchlässige VSG Milchglasscheibe
µC: ATxmega256A3U
Bluetooth: BTM 222

Nach dem Projekt sind wir auch der Meinung, der Schlüssel liegt in der 
Pixel Platine.
Um die Verkabelung stark zu reduzieren ist es Sinnvoll den LED Treiber 
direkt auf der Pixelplatine zu haben und nicht jedes Pixel von einer 
Hauptplatine aus anzufahren. Besser ist es nur die Platinen 
untereinander mit ein paar Drähten zu verbinden.
Das Touch Einlesen haben wir ja über Multiplexer gelöst. heist aber auch 
von jedem Pixel muss ein Kabel zur Hauptplatine, also wie auch hier 
schon diskutiert sollte das ganze auch über einen Bus eingelesen werden.
Wir haben für die LED-Treiber mit dem SPI Bus gearbeitet, diese hat 
allerdings durch die Leitungslänge die wir letztendlich hatten nur 
Probleme bereitet. Sodas ich sagen muss hier empfiehlt sich ein andere 
Bus.
Da ich ja hier schon einige Vorschläge gesehen habe und für mich SPI und 
I2C auch ausscheiden wäre ich auch eher für UART zum einlesen des Touch, 
wir haben in unserem Projekt auf eine ADC Wandlung verzichtet für den 
Touch, war aber nie ein Problem. Denke aber es ist sehr wichtig das dass 
einlesen sehr schnell geht z.B. wenn mann über den Tisch wischt und die 
Pixel an und ausgehen sollen dann macht sich ein "langsames einlesen" 
doch optisch bemerkbar.

Leider hat sich hier ja immer noch kein endgültiges Design und Bus 
durchgesetzt, aber ich denke beim Bus für die Kommunikation liegt der 
Knackpunkt.
Gibt es mittlerweile schon fortschritte von Conny, Ast Erix, usw.?

PS: ach ja eine LED pro Pixel hat wunderbar gereicht unsere Pixel haben 
6x6x6cm, wobei die tiefe auch noch reduziert werden könnte.

So und jetzt bin ich mal gespannt ob noch jemand in dem Thread lebt :-)

von Conny G. (conny_g)


Bewertung
lesenswert
nicht lesenswert
Ich lese noch mit.
Der Thread ist ja damals wg. unendlicher im-Kreis-Diskussionen wg. 
laufend neuer Mitleser, die wieder alles von vorne infrage stellten 
woanders hin umgezogen. Aber auch da gings nicht mehr lange weiter.
Ich bin grundsätzlich noch daran interessiert, wie man so einen Tisch 
effizient baut. Aber habe viel Arbeit derzeit (nicht-elektronisch) und 
meine Projekte-Pipeline ist zu lang (elektronisch), d.h. auf ein Jahr 
werde ich nicht dazukommen.

Glückwunsch zur überstandenen Hölle! Der Tisch sieht gut aus, aber man 
hat wohl vom Verkabeln den Rest des Lebens die Nase voll :-)

: Bearbeitet durch User
von Volker S. (vloki)


Angehängte Dateien:

Bewertung
lesenswert
nicht lesenswert
Geht auch ohne Verkabelung. Die Fotos zeigen einen Prototyp für einen 
4x15 Tisch mit 10x10cm großen Pixeln.
Auf jedem "Knochen" Modul befinden sich 4 RGB LEDs die von einem TLC5971 
(in der Mitte) angesteuert werden.
Dazu kommen nochmal 4 Sharp IS471 IR-Detectoren.
Die einzelnen Module werden einfach zusammen gesteckt und über einen SPI 
Bus (SN74HC165TI Schieberegister zum einlesen der IR-Sensoren auf jedem 
Modul) angesteuert.
Die Steuerung übernimmt ein PIC18 der über einen SN75176B auch an ein 
DMX512 Bussystem angeschlossen werden kann.

Das ganze wurde von Studierenden der Mechatronik/Medizintechnik im 3. 
oder 4. Semester 2013 realisiert.

Inzwischen gibt es ja mehrere günstige RGB LEDs mit integriertem 
Treiber. Jetzt müsste es nur noch welche mit integriertem IR-Sensor 
geben und das ganze wäre ein Kinderspiel ;-)

: Bearbeitet durch User
von Conny G. (conny_g)


Bewertung
lesenswert
nicht lesenswert
Genial!
Das lässt sich prima modular weiterentwickeln für 16x16-Tische, einfach 
das ganze mal vier in der Vertikalen und in Reihe schalten. Strom ggf. 
für jede vertikale Zeile.
Ein 1x4-Modul (oder 1x5) ist eine sinnvolle Basis für einen Bus über 
alle Module.

von Christian (Gast)


Bewertung
lesenswert
nicht lesenswert
Wäre es möglich, dazu auch die Schaltpläne und Layouts zu posten?

Danke
 Christian

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
@Conny: schön das du noch dabei bist... aber leider immer noch nix draus 
geworden ist.

@Volker: Auch ein sehr schönes Konzept, die Leiterbahnen sehen gefräst 
aus.
Das müsste sich ja relativ leicht auch verkleinern oder vergrößern 
lassen. Ist absolut eine Überlegung wert.

Hab grade mal angefangen einen IR-Empfänger zu suchen der schon SPI oder 
UART hat. Sowas scheint es auch zu geben mit integriertem 
Mikrocontroller, war leider noch nix günstiges dabei.
Da ja das Ziel eigentlich eine 1 Pixelplatine ist ;-)

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Conny G. schrieb:
> Ein 1x4-Modul (oder 1x5) ist eine sinnvolle Basis für einen Bus über
> alle Module.
1x5 wäre mit dem 4-fach LED Treiber schwierig ;-)

Christian schrieb:
> Wäre es möglich, dazu auch die Schaltpläne und Layouts zu posten?
Ich versuch mal die Leute zu fragen, ob das geht. (Die sind vermutlich 
schon nicht mehr an der Hochschule)

von Conny G. (conny_g)


Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Conny G. schrieb:
>> Ein 1x4-Modul (oder 1x5) ist eine sinnvolle Basis für einen Bus über
>> alle Module.
> 1x5 wäre mit dem 4-fach LED Treiber schwierig ;-)

Ich würde mich vom Konzept und dessen Weiterentwicklung her zunächst mal 
nicht an die Bauteile gebunden fühlen :-)
Würde man LEDs mit eingebautem Treiber verwenden, fällt diese 
Beschränkung nämlich direkt weg.
Man könnte sogar Varianten kreieren, 1, 2, 4 Pixel auf einem Knochen, 
dann kann man sich bauen, was man möchte.

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Conny G. schrieb:
> Würde man LEDs mit eingebautem Treiber verwenden, fällt diese
> Beschränkung nämlich direkt weg.

Ach ja, von denen habe ich auch schon mal was gehört ;-)

Jetzt noch einen Ersatz für den 74165. So was wie ein D-FF mit 
Multiplexer am Eingang...

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Jetzt noch einen Ersatz für den 74165. So was wie ein D-FF mit
> Multiplexer am Eingang...

Eigentlich ist es aber auch egal. Selbst wenn nur ein einziges Bit von 
acht für ein einer Pixel genutzt würde. Platzprobleme dürfte es wohl 
keine geben und ob es billigere Lösungen (<20ct/St.) geben würde ist 
auch zweifelhaft...

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Also einfach den 74HC165 für jedes Pixel zu benutzen find ich eigentlich 
gar nicht so dumm, so braucht es keinen extra µC um das Signal vom IS471 
Busfähig zu machen.

Jetzt stellen sich da für mich zwei fragen:
1. Wieviel 74HC165 kann ich kaskadieren ohne Probleme zu bekommen?
   (Hardwaremäßig und Zykluszeit)
2. Ist bei z.B. 256 Pixeln (16x16) die Leitungslänge vom SPI-Bus kein
   Problem?
   Wenn ich jetzt mal davon ausgehe das der Tisch 6x6 cm Pixel hat sind
   das ca. 1,1m x 1,1m macht dann bei 16 Reihen auch 16m länge.

Ich hatte bei meinem Tisch Probleme mit dem SPI sobald die Leitung 
länger wie 80cm war.
Geschwindigkeit reduzieren hat zwar etwas geholfen aber man hat es am 
Tisch gesehen (hab allerdings auch die LEDs mit dem SPI gesteuert nicht 
den Multiplexer)

: Bearbeitet durch User
von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> Ist bei z.B. 256 Pixeln (16x16) die Leitungslänge vom SPI-Bus kein
>    Problem?

Wenn ich das Prinzip richtig verstanden habe sollte das für die LEDs 
kein Problem sein, da Takt und Daten ja quasi in jeder immer neu für die 
nächste erzeugt wird.

Wie das mit den Schieberegistern aussieht, da habe ich zu wenig 
Erfahrung.
Den Takt müsste man aber auch nicht unbedingt komplett durch schleifen.
Das könnte doch auch so Stichleitungs-artig funktionieren, oder?

von Conny G. (conny_g)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> 2. Ist bei z.B. 256 Pixeln (16x16) die Leitungslänge vom SPI-Bus kein
>    Problem?
>    Wenn ich jetzt mal davon ausgehe das der Tisch 6x6 cm Pixel hat sind
>    das ca. 1,1m x 1,1m macht dann bei 16 Reihen auch 16m länge.
>
> Ich hatte bei meinem Tisch Probleme mit dem SPI sobald die Leitung
> länger wie 80cm war.
> Geschwindigkeit reduzieren hat zwar etwas geholfen aber man hat es am
> Tisch gesehen (hab allerdings auch die LEDs mit dem SPI gesteuert nicht
> den Multiplexer)

Ja, das wäre ein Problem, so sollte man es nicht machen.
Ich habe mal ein "Fussballdisplay" gebaut mit 2 Meter Leitungslänge für 
SPI und es brauchte Terminierung plus Treiber, damit das noch 
funktioniert.
Man kann es hinbekommen (man kann auch noch aufrüsten mit geschirmtem 
Twisted-Pair etc.), aber es ist m.E. keine gute Architektur.

Lieber das Prinzip, das jeder Node das Signal neu generiert, damit sind 
diese Probleme erledigt.

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Conny G. schrieb:
> Lieber das Prinzip, das jeder Node das Signal neu generiert, damit sind
> diese Probleme erledigt.

Ja seh ich auch so, damit sind wir wieder bei der Frage wie bekommen wir 
das am einfachsten hin.

Doch für jedes Pixel ein Attiny der den IR einliest und an den das 
empfangene Bus signal anhängt. Nachteil ist das jeder Pixel alle Daten 
empfangen muss dann den Wert für den IR-Empfänger anhängen und zum 
nächsten senden.
Das braucht halt schon ne "Menge Zeit" je mehr Pixel das werden.
Irgendwie gefällt mir das noch nicht so richtig.

Andere Möglichkeit dann halt doch 8 o. 16-Pixel auf eine Platine und 
dann Multiplexen. Macht es sicherlich einfacher aber unflexibler.

von Sam .. (sam1994)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> Das braucht halt schon ne "Menge Zeit" je mehr Pixel das werden.
> Irgendwie gefällt mir das noch nicht so richtig.

Eigentlich ist die Zeit gar nicht relevant:

Die Verzögerung durch ein Knoten dauert mindestens so lange, wie ein 
Übertragung von einem Byte.

Bei 1 MBaud, 100 Hz Refreshrate und 3 Bytes/Knoten können maximal
 Knoten angeschlossen werden.

Wenn man eine Verzögerung von einem Frame (10 ms) akzeptiert, hat jeder 
µC 30 µs Zeit, um die Daten weiterzuleiten. Davon müssen 10µs für das 
Empfangen des Bytes abgezogen werden. Aber selbst 20 µs sind bei 8 MHz 
160 Takte und damit deutlich mehr als genug.

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Sam .. schrieb:
> Eigentlich ist die Zeit gar nicht relevant:
>
> Die Verzögerung durch ein Knoten dauert mindestens so lange, wie ein
> Übertragung von einem Byte.
>
> Bei 1 MBaud, 100 Hz Refreshrate und 3 Bytes/Knoten können maximal
>  Knoten angeschlossen werden.
>
> Wenn man eine Verzögerung von einem Frame (10 ms) akzeptiert, hat jeder
> µC 30 µs Zeit, um die Daten weiterzuleiten. Davon müssen 10µs für das
> Empfangen des Bytes abgezogen werden. Aber selbst 20 µs sind bei 8 MHz
> 160 Takte und damit deutlich mehr als genug.

Korrigier mich wenn ich jetzt falsch denke, aber ich stell mir das so 
vor:

Node 0 sendet sein bit --> node 1 empfängt es und hängt seins an sendet 
es --> node 2 empfängt es und hängt seins an....

je nach Bus natürlich auch ein Byte wenn das voll ist dann 2 Byte...

wenn ich jetzt mal bei dem 16x16 Beispiel bleibe wären das 256 Bit = 32 
Byte
macht dann grob überschlagen noch 33

Oder denk ich jetzt falsch?

von Sam .. (sam1994)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> Node 0 sendet sein bit --> node 1 empfängt es und hängt seins an sendet
> es --> node 2 empfängt es und hängt seins an....
>
> je nach Bus natürlich auch ein Byte wenn das voll ist dann 2 Byte...

Genau. Du wirst keinen µC mit Bus finden, der einzelne Bits sendet. Ohne 
Hardwareunstützung kommt man praktisch nicht mal in die Region von 100 
kByte/s.

> wenn ich jetzt mal bei dem 16x16 Beispiel bleibe wären das 256 Bit = 32
> Byte
> macht dann grob überschlagen noch 33
>
> Oder denk ich jetzt falsch?

Du redest von den Touch-Daten? Ich habe diese erst mal igoniert, da sie 
im Vergleich zu den Pixeldaten gering sind. Ich persönlich würde für pro 
Pixel mindestens 16 bit nehmen.

: Bearbeitet durch User
von Markus M. (adrock)


Bewertung
lesenswert
nicht lesenswert
Für die Rückgabewerte ist keine extra Zeit einzuplanen.

Während die neuen RGB-Daten praktisch "von vorne" in die Kette 
reingeschickt werden, senden die Nodes auf der anderen Seite ihr letzten 
Touch/Statusdaten "nach hinten" raus. Die Unterscheidung kann man durch 
ein Flag im Paket machen.

Wenn eine Node die Daten für sich selbst empfangen (und somit auch ihren 
letzten Status gesendet hat) leitet sie nur noch alles weiter.

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Sam .. schrieb:
> Du redest von den Touch-Daten? Ich habe diese erst mal igoniert, da sie
> im Vergleich zu den Pixeldaten gering sind. Ich persönlich würde für pro
> Pixel mindestens 16 bit nehmen.

Ja ich rede von den Touch Daten, die RGB Daten sind kein Problem LED mit 
Treiber und fertig ist die Sache.

Nur die Daten vom Touch machen mir sorgen, wenn man alles flexibel 
halten will und jede Pixel Platine als eine Einheit betrachtet. Wie 
bekomme ich einen Eingang schnell und einfach in einen Bus das ich in 
der Gestaltung flexibel bin. Brauchen eigentlich was wie der LED Treiber 
nur anders rum...

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Ich habe noch nie so eine lange SPI Leitung gehabt.
Wo genau liegt eigentlich das Problem?

Könnte man nicht den von den LEDs generierten Clock für die 
Schieberegister mit nutzen? (So wie ich das sehe, haben das unsere 
Studierenden mit dem LED Treiber auch so gemacht)

Wenn man 2 SPI Schnittstellen am Controller benutzt und mit der einen 
als Master nur die LEDs schreibt und mit der anderen als Slave die 
Schieberegister einliest, dann sollten auch Verzögerungen kein Problem 
darstellen. Egal wie viele sich da aufsummieren.

Sam .. schrieb:
> Ich persönlich würde für pro
> Pixel mindestens 16 bit nehmen.
Die LEDs die ich kenne haben 8 Bit für jede Farbe, also 24 Bit 
insgesamt.

: Bearbeitet durch User
von Chris F. (chfreund) Benutzerseite


Bewertung
lesenswert
nicht lesenswert
Ich sehe das so wie Samuel Kleiser. Der hat das doch super vorgerechnet.

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Chris F. schrieb:
> Ich sehe das so wie Samuel Kleiser. Der hat das doch super
> vorgerechnet.

Was genau meinst du? (kann gerade nicht folgen ;-)

von Chris F. (chfreund) Benutzerseite


Bewertung
lesenswert
nicht lesenswert
Ich meine das der dem TE doch schon alles vorgekaut hat.

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Chris F. schrieb:
> Ich meine das der dem TE doch schon alles vorgekaut hat.

Ich habe nicht alles gelesen, aber den Eindruck, dass der TE eben was 
anderes will. Also warum nicht einfach mal die Finger still halten und 
ihn machen lassen? Oder habe ich jetzt was falsch verstanden?

: Bearbeitet durch User
von Chris F. (chfreund) Benutzerseite


Bewertung
lesenswert
nicht lesenswert
Sehe ich so ähnlich wie Du, Volker. Ich würde aber gerne noch wissen was 
daraus geworden ist. ;-)

von Peter B. (shaphard)


Angehängte Dateien:

Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Ich habe noch nie so eine lange SPI Leitung gehabt.
> Wo genau liegt eigentlich das Problem?

SPI ist ein Platinen Bus der nicht für lange Leitungslängen ausgelegt 
ist.

Chris F. schrieb:
> Ich sehe das so wie Samuel Kleiser. Der hat das doch super vorgerechnet.

bin noch nicht ganz überzeugt ;-)

So würde mich mal auf ein paar Sachen festlegen:
Als RGB-LED Treiber würde ich mal den TLC5973 verwenden, Ansteuerung ist 
ja Analog zum WS2812 so bleibt in der Beziehung alles flexibel.
Der TLC5973 hat eine 12-Bit Auflösung pro Farbe was mir besser gefällt 
wie die oft nur 8-Bit

Für den Touch würde ich den Infarrot Empfänger IS471F verwenden, dieser 
generiert seinen Takt für das Pulsen selbst und hab da sehr gute 
Erfahrungen mit gemacht.
Als µC für das Pixel ist denk ich ein ATtiny das richtige über welchen 
genau bin ich mir noch nicht einig. Vorschläge?
Mit dem ATtiny will ich nur das Touch-Signal erfassen und dann per UART 
einsameln (von Pixel zu Pixel). Hier ist dann noch die Frage mit wie ich 
es am einfachsten schaffe, das die ATtiny Programme alle gleich sind und 
Trotzdem die einzelnen Pixel unterscheiden kann.
Evtl. könnte ich eine Pixelnummer mit senden die beim weitersenden immer 
erhöht wird...

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> Volker S. schrieb:
>> Ich habe noch nie so eine lange SPI Leitung gehabt.
>> Wo genau liegt eigentlich das Problem?
>
> SPI ist ein Platinen Bus der nicht für lange Leitungslängen ausgelegt
> ist.

Es wären ja praktisch viele SPI Busse die seriell hintereinander hängen. 
Also immer nur von einem Pixel zum nächsten.
Wenn möglich würde ich auf einen Controller verzichten. Das müsste doch 
mit den Schieberegistern gehen, wenn man einfach den Clock von den LEDs 
mitbenutzt. RGBs mit eingebautem Controller und 12bit/Farbe wüsste ich 
allerdings keine. Ich kauf mir wohl mal 100 APA102 beim Ali und spiel 
ein bisschen mit denen rum... (die Knochenform werde ich wohl auf Z 
ändern)

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Es wären ja praktisch viele SPI Busse die seriell hintereinander hängen.
> Also immer nur von einem Pixel zum nächsten.
> Wenn möglich würde ich auf einen Controller verzichten. Das müsste doch
> mit den Schieberegistern gehen, wenn man einfach den Clock von den LEDs
> mitbenutzt. RGBs mit eingebautem Controller und 12bit/Farbe wüsste ich
> allerdings keine. Ich kauf mir wohl mal 100 APA102 beim Ali und spiel
> ein bisschen mit denen rum... (die Knochenform werde ich wohl auf Z
> ändern)

also SPI von Pixel zu Pixel müsste eigentlich gehen, wüsste eigentlich 
kein Grund warum nicht. Benötigt nur mehr Adern wie UART. Aber man 
benötigt dann einen µC der das SPI Signal dann Empfängt und neu sendet.

Die Schieberegister bei einzel Pixelplatinen machen keinen Sinn man 
schaltet zwar das Schieberegister mit SPI aber den SPI müsste man dann 
wieder über alle Platinen schleifen um alle Eingangsdaten durch zu 
takten, was wieder Probleme macht.
Das Schieberegister macht dann nur bei Mehrpixel Platinen Sinn. Ich 
würde aber gerne einen Einzel Platine Entwickeln um flexibel zu bleiben 
für andere Projekte. (So kann ich mir 1000 bestellen und dann 
kombinieren wie auch immer)

Clock von den LEDs macht keinen sinn da Daten schicken und Takt ja 
synchron sein müssen, das geht bestimmt schief da die Signallaufzeiten 
von Daten und Takt zwangsläufig irgendwann auseinander laufen werden.

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> also SPI von Pixel zu Pixel müsste eigentlich gehen, wüsste eigentlich
> kein Grund warum nicht. Benötigt nur mehr Adern wie UART. Aber man
> benötigt dann einen µC der das SPI Signal dann Empfängt und neu sendet.
Aber das machen doch die LEDs/Treiber schon.

Peter B. schrieb:
> Die Schieberegister bei einzel Pixelplatinen machen keinen Sinn
Auch wenn man dann dafür keinen uC braucht?

Peter B. schrieb:
> Clock von den LEDs macht keinen sinn da Daten schicken und Takt ja
> synchron sein müssen,
Sind sie doch. Das sind hier ja wieder viele kleine SPIs und jeder hat 
sozusagen seinen eigenen (zum vorhergehenden leicht verzögerten) Clock.


Ich sollte mal einen Schaltplan zeichnen ;-)

: Bearbeitet durch User
von Peter B. (shaphard)


Angehängte Dateien:

Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Peter B. schrieb:
>> also SPI von Pixel zu Pixel müsste eigentlich gehen, wüsste eigentlich
>> kein Grund warum nicht. Benötigt nur mehr Adern wie UART. Aber man
>> benötigt dann einen µC der das SPI Signal dann Empfängt und neu sendet.

> Aber das machen doch die LEDs/Treiber schon.

Nein der LED Treiber macht kein SPI sondern ein 1-Draht Serial-Bus und 
er macht nur die LEDs nicht den Touch

> Peter B. schrieb:
>> Die Schieberegister bei einzel Pixelplatinen machen keinen Sinn
> Auch wenn man dann dafür keinen uC braucht?

Der 74HC165 wird kaskadiert das heißt er muss vom gleichen SPI gespeist 
werden taktet alle Daten durch alle Bausteine und geht dann am MISO in 
den Master. Das ist dann ein SPI-Bus
Hab mal das Bild vom Schieberegister angehängt hoffe das macht es 
klarer...

> Peter B. schrieb:
>> Clock von den LEDs macht keinen sinn da Daten schicken und Takt ja
>> synchron sein müssen,
> Sind sie doch. Das sind hier ja wieder viele kleine SPIs und jeder hat
> sozusagen seinen eigenen (zum vorhergehenden leicht verzögerten) Clock.

> Ich sollte mal einen Schaltplan Plan zeichnen ;-)

Ja solltest du ;-)

Für mich ist die LED Ansteuerung ein getrenntes System
und der Touch ein eigenes System

von Volker S. (vloki)


Angehängte Dateien:

Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> Nein der LED Treiber macht kein SPI sondern ein 1-Draht Serial-Bus und
> er macht nur die LEDs nicht den Touch

Ja, habe gerade mal ins Datenblatt geschaut, nachdem ich geelesen hatte, 
dass der gleich funktioniert wie eine WS2812. Hatte einen anderen (den 
vierfach von den Studies) im Kopf der wie die APA102 auch einen Clock 
braucht. Deshalb kam ich auf SPI und Clock-Sharing.

Dann geht alles andere natürlich auch nicht :-(

: Bearbeitet durch User
von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Ja, habe gerade mal ins Datenblatt geschaut, nachdem ich geelesen hatte,
> dass der gleich funktioniert wie eine WS2812. Hatte einen anderen im
> Kopf der wie die APA102 auch einen Clock braucht. (den vierfach von den
> Studies)
>
> Dann geht alles andere natürlich auch nicht :-(

Hab mir grade mal den APA102 angeschaut, auch ein nettes Teil :-)

Aber mal ne Frage interessehalber, wie wolltest du da das 
Schieberegister mit einbringen ohne die LED Daten durcheinander zu 
bringen?

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> Aber mal ne Frage interessehalber, wie wolltest du da das
> Schieberegister mit einbringen ohne die LED Daten durcheinander zu
> bringen?

Einfach zwei Stränge parallel laufen lassen. Die Daten sind vollkommen 
getrennt, nur der Clock wird gemeinsam genutzt.

Für die Sensoren bekommt man dann natürlich einen Haufen Müll mit.
Zunächst die 7 nutzlosen Bits bei einem Einer-Pixel und dann natürlich 
die ganzen Bits die hinterher noch ankommen, weil die LEDs ja 3x8 (oder 
3x12) Bits brauchen. Aber das kann man ja einfach ignorieren.

: Bearbeitet durch User
von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Einfach zwei Stränge parallel laufen lassen. Die Daten sind vollkommen
> getrennt, nur der Clock wird gemeinsam genutzt.

So langsam wird's klarer ;-)
Ok gemeinsamer Clock is klar die Daten laufen getrennt macht absolut 
Sinn, aber wie soll der Master dann das ganze empfangen? Als SPI geht ja 
eigentlich nicht da der Master von dem Clock ja nichts weiß und das 
Schieberegster muss über die SPI ja auch zum einlesen getriggert werden.
Oder hast du da auch schon eine Super Idee?

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Also der uC kann ja einen SPI Master und einen Slave haben.
Über den Master schickt er die Daten für die LEDs raus und über den 
Slave empfängt er die Daten von den Schieberegistern.

Wenn die Laufzeitverschiebung sehr gering wäre könnte der uC natürlich 
einfach die LED Daten auf dem MOSI raus schicken und gleichzeitig die 
Daten von den Sensoren am MISO empfangen.

Alternativ könnte sich durch Kodierung der unbenutzten Bits am 
Schieberegister auch ein spezielles Protokoll überlegen.

: Bearbeitet durch User
von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Stimmt, kommt wohl auf einen Versuch an.
SPI kann im Vollduplex gleichzeitig senden und empfangen, aber das muss 
ich dann auch erstmal nachlesen, weiß ich jetzt auch net aus dem Kopf

dann wäre das echt ne super Lösung

von Sam .. (sam1994)


Bewertung
lesenswert
nicht lesenswert
Naja, es bleibt der Drahtverhau. Ich sehe dort den Vorteil in der 
Uart-Ring-Topologie. Insgesamt braucht man da für die Kommunikation nur 
eine Leitung/Knoten. Dafür braucht man natürlich einen µC. Wenn man sich 
nicht auf Atmel beschränkt, bekommt man den auch für bis zu 20 Cent 
(STM8S003F3P6).

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Sam .. schrieb:
> Naja, es bleibt der Drahtverhau. Ich sehe dort den Vorteil in der
> Uart-Ring-Topologie. Insgesamt braucht man da für die Kommunikation nur
> eine Leitung/Knoten. Dafür braucht man natürlich einen µC. Wenn man sich
> nicht auf Atmel beschränkt, bekommt man den auch für bis zu 20 Cent
> (STM8S003F3P6).

Ja da will ich mal nicht widersprechen die Verdrahtung ist bei UART 
absolut einfacher. Vom µC her sind wir ja frei der vorgeschlagene 
STM8S003F3P6 kann ja schon viel zu viel... hast du da noch ne kleinere 
Variante im Kopf?
Brauchen ja nur einen Eingang und die UART Schnittstelle.

von Sam .. (sam1994)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> hast du da noch ne kleinere
> Variante im Kopf?

Nein, aber das ist der günstigste den ich kenne und den man auch in 
kleinen Stückzahlen aus China bekommt. Und wirklich viel kann er 
eigentlich nicht, wenn du ihn z.B. mit dem kleinsten M0 von ST 
vergleichst (STM32F030). Bei den kleinen Attinys und PICs ist die 
Peripherie halt extrem minimal. Der µC könnte auch die Led ansteuern, 
dann kann man auch die günstigeren RGB-Leds ohne "Intelligenz" nehmen.

: Bearbeitet durch User
von Volker S. (vloki)


Angehängte Dateien:

Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Ich sollte mal einen Schaltplan zeichnen ;-)

Ok, habe ich jetzt mal für ein 4er Modul gemacht. Wäre auch als 1er, 
2er, 8er möglich.
Das Layout müsste man natürlich noch entsprechend der Pixelgröße zurecht 
schieben.

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Sam .. schrieb:
> Naja, es bleibt der Drahtverhau. Ich sehe dort den Vorteil in der
> Uart-Ring-Topologie. Insgesamt braucht man da für die Kommunikation nur
> eine Leitung/Knoten. Dafür braucht man natürlich einen µC. Wenn man sich
> nicht auf Atmel beschränkt, bekommt man den auch für bis zu 20 Cent
> (STM8S003F3P6).

Genau das war der Gedanke dahinter ;-)
Zwischen den uC (einer pro Pixel) wird eine Leitung der UART gezogen und 
damit kann man wunderbar einen Ring vom Master durch alle Slaves ziehen. 
Als uC war ein kleiner ATTiny angedacht, man kann sicherlich auch andere 
verwenden.

Als Touch kann man einen IS471 Sensor verwenden, dieser ist aber relativ 
teuer. Deswegen war die Überlegung eines Fototransistors oder Ähnliches. 
Hier im Thread gibts dazu erste Versuche per Video. Mich persönlich 
hatten diese Überzeugt.

Um die Slave-Software variable zu halten, kann man die Nachrichten 
codieren oder die Slaves teachen.. irgendetwas in der Richtung.

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
@Volker: sehr gut :-)

@Ast Erix:
Also ich hab mir nochmal Gedanken über die Gestaltung des UART 
Protokolls gemacht.
Hab mir gedacht im ersten Byte steht die Pixelnummer 0-255 in den 
Restlichen Bytes werden dann die Daten geschrieben. Hab mir das dann so 
vorgestellt:
Master sendet Pixelnummer 0 an das erste Pixel das weis jetzt in Bit 0 
muss jetzt der Touch Status dann zählt das Pixel die Nummer um 1 hoch 
und schickt es an das nächste Pixel das trägt jetzt wieder den Touch 
Status ein aber im Bit 1 .... wenn der Ring wieder beim Master ankommt 
kann dieser alle Bytes auslesen außer das Byte für die Pixelnummer.
Wenn man das zyklisch macht hat man immer den aktuellen Touch Status.
Und das Programm kann für jedes Pixel gleich sein.

Welcher IR-Sensor verwendet wird ist ja eigendlich egal funktioniert ja 
Grundlegend mit allen. Hatte nur den ISF gewählt da ich mit diesem schon 
sehr gute Erfahrungen gemacht habe und man sich nicht ums Pulsen kümmern 
muss, aber das ist dann eher Faulheit ;-)

Kann jemand mal einen Testaufbau für den UART Ring machen zum Testen?
Bin im Moment Beruflich unterwegs und würde erst nächsten Monat dazu 
kommen.

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> Also ich hab mir nochmal Gedanken über die Gestaltung des UART
> Protokolls gemacht.

Jetzt muss ich auch nochmal nachfragen... ;-)

Also bei einer Lösung mit einem uC pro Pixel, könnte der dann nicht 
treiberlose LEDs per PWM steuern (edit- hat Sam ja auch schon...) und 
AUCH NOCH das Gedöns mit einem (günstigeren) IR-Sensor System managen?

: Bearbeitet durch User
von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Also bei einer Lösung mit einem uC pro Pixel, könnte der dann nicht
> treiberlose LEDs per PWM steuern (edit- hat Sam ja auch schon...) und
> AUCH NOCH das Gedöns mit einem (günstigeren) IR-Sensor System managen?

Also beim IR-Sensor gar kein Problem PWM für die IR Diode gemacht und 
dann eingelesen kein problem. Ist weiter oben auch schon Irgendwo mal 
beschrieben worden... Und dann über UART Ring die Daten Abholen.

Bei den LEDs halt ich es für schwieriger das das Timing passt. PWM Kein 
Problem aber die Daten von Pixel zu Pixel schicken im UART Ring geht 
zwar aber würde zulange dauern denk ich.
Mal ausgehend von 256 Pixel wären das für jedes Pixel 8 Bit Pixelnummer 
+ 1 Bit Touch Status + 12 Bit Farbcodierung sind dann 21 Bit, das macht 
zusammen für alles schon mal 5376 Bit (672 Byte), wenn ich jetzt mal von 
38.400 bits/s Übertragungsrate ausgehe sind das ca. 26 µs für ein Bit 
mit Start/stop-Bit, das sind für einmal übertragen 140 ms da wir das ja 
von pixel zu pixel schicken nacheinander sind das dann schon ganze 35 
Sekunden!
Also kurz gesagt keine gute Idee jedenfalls mit UART.
Wenn dann müsste das Serial durchgetaktet werden wie es die Treiber auch 
machen oder Parallel an alle gleichzeitig.
Denke Einlesen Touch über UART und Pixel einen extra Bus z.B. Uart 
Parallel an alle Pixel und dann ein Bit zum Datenübernehmen über einen 
normalen Ein/Ausgang oder SPI was alles serial durchschiebt.
Aber ich denke fasst da ist ein Treiber Baustein einfacher...

von Markus M. (adrock)


Bewertung
lesenswert
nicht lesenswert
Naja, man benötigt wenigstens einen Transistor oder Fet um die LEDs zu 
treiben. Die Ausgänge vieler Controller können nicht 3 (RGB) bzw. 4 
(+IR) LEDs mit dem entsprechenden Strom (wenigstens 20mA angenommen) 
treiben. Ein "dummer" 4-Kanal LED-Treiber wäre nett, aber ich habe 
nichts passendes/günstiges gefunden bis jetzt.

Der Vorteil es diskret aufzubauen wäre, man hat freie Wahl bei den LEDs 
und ist nicht auf ein bestimmtes Modell festgenagelt.

Unter 3-4 EUR wird man pro Pixel (inklusive Platine) wohl nicht kommen. 
Die Gesamtkosten für ein eingermaßen großen Aufbau machen das Ganze doch 
eher unattraktiv (für mich zumindest).

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Ja Markus es ist nicht einfach das optimale zu finden, bei einzelnen 
Platinen ist man hinterher in der Gestaltung für verschiedene Projekte 
flexibler (das wäre mein Wunsch) aber größer Platinen sind zwar 
unflexibler, aber haben sicherlich manchmal einen Kostenvorteil (Größer 
wird ja grad beim Ätzen lassen auch schnell mal teuerer)
die Idee war ja das wir am Ende ein flexible Platine haben und diese 
dann als Sammelbestellung gleich 1000x bestellen evtl. sogar bestückt. 
So das jeder sein Projekt verwirklichen kann.
Aber ich denke wir kommen der Endlösung langsam näher....

von Konrad S. (maybee)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> sind das dann schon ganze 35
> Sekunden!

???

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> Also kurz gesagt keine gute Idee jedenfalls mit UART.
> Wenn dann müsste das Serial durchgetaktet werden wie es die Treiber auch
> machen

Ja klar. Warum sollte das mit USART/SPI/... nicht gehen?

: Bearbeitet durch User
von Sam .. (sam1994)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> Mal ausgehend von 256 Pixel wären das für jedes Pixel 8 Bit Pixelnummer
> + 1 Bit Touch Status + 12 Bit Farbcodierung sind dann 21 Bit, das macht
> zusammen für alles schon mal 5376 Bit (672 Byte), wenn ich jetzt mal von
> 38.400 bits/s Übertragungsrate ausgehe sind das ca. 26 µs für ein Bit
> mit Start/stop-Bit, das sind für einmal übertragen 140 ms da wir das ja
> von pixel zu pixel schicken nacheinander sind das dann schon ganze 35
> Sekunden!

So wird das natürlich nichts. Es ist kein Problem, das ganze mit einem 
UART-Ring zu lösen. Aber man muss es richtig machen:

-Der Master sendet ein Paket mit allen Pixeldaten
-Jeder Knoten sendet ein empfangenes Byte sofort weiter
-Pixelnummern werden nicht übertragen. Die Knoten können selbst zählen 
und die entsprechenden Daten aus dem Stream herauspicken
-Wenn ein Knoten seine Daten empfängt, sendet er diese nicht weiter, 
sondern seine Touchdaten
-Wenn der Master das Paket wieder empfängt, enthält es die Touchdaten 
aller Pixel

Ich habe das weiter oben schon mal vorgerechnet. Die Latenz ist 
vernachläßigbar.

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Ja Sam da hast du recht, hätte vielleicht noch 5 Min nachdenken sollen 
vorm Posten ;-)

von Andreas (Gast)


Bewertung
lesenswert
nicht lesenswert
Ich finde das Projekt interessant, auch wenn ich selbst das nicht 
nachbauen werde :)

Ein paar Gedanken zum Protokoll:
- woher wissen die Pixel wann ein Datenpaket anfängt?
- Woher weiss der Master, wie_ _viele Pixel es sind? (Paketgröße)

Paketaufbau:
Variante 1
- Pixelnummer, wird von jedem Pixel um 1 erhöht weitergesendet, Master 
sendet 0
- Aus der empfangenen Pixelnummer weiss jeder Pixel, wo seine Daten im 
Paket liegen und kann an diese Stelle auch die Touchdaten legen und 
weiter versenden

Variante 2
- Anzahl Pixel ist allen Pixeln bekannt, oder ist der erste Datensatz im 
Paket
- der empfangende Pixel liest den ersten Datensatz (RGB) und sendet 
diesen nicht weiter
- am Ende des Datenpakets (die Länge ist ja bekannt) hängt der Pixel 
seine Touchdaten an

MfG,
Andreas

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Also das Protokoll der WS2812 oder APA102 ist doch gar nicht so 
schlecht. Wenn niemand mit einer besseren Idee kommt, warum das nicht 
übernehmen/erweitern?

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Konrad S. schrieb:
> Peter B. schrieb:
>> sind das dann schon ganze 35
>> Sekunden!
>
> ???

Ich hatte die selben gedanken. Die Rechnung ist etwas verwirrend.
Oben wurde es vorgerechnet, UART ist möglich. Zudem sind 38,4KBaud/s 
nicht wirklich schnell. Dort geht einiges mehr.

Das Protokoll muss entsprechend sehr gut überlegt sein. Sodass die 
Slaves selber zählen (wurde glaub ich auch schon diskutiert), denn dann 
ist das System sehr flexibel, was die Anzahl der Slaves angeht. Es muss 
zudem nicht extra etwas einprogramiert werden

Das WS2812 Protokoll ist ganz nett. Beinhaltet leider nur nicht das 
Rückführen vom Touch. Durch das genaue Timing sollte wahrscheinlich eine 
gut programmierte Lib genutzt werden.

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Ast E. schrieb:
> Das Protokoll muss entsprechend sehr gut überlegt sein. Sodass die
> Slaves selber zählen

Wieso zählen und nicht einfach wie die LEDs mit integriertem Controller 
die ersten Bytes nehmen und den Rest weiter schicken?

Die Touch-Info könnte doch einfach hinten angehängt werden. Immer 
2-Bit-Weise
Eines zum Signalisieren, dass das Bitpaar belegt ist und das Andere mit 
dem Zustand.
Also das erste Pixel hängt schon ein Byte an. Bit Null enthält den Touch 
Zustand und Bit-1 die Belegung. Bit 2..7 sind noch alle Null.
Das nächste Pixel setzt Bit-3 als Belegung und schreibt in Bit-2 seinen 
Touch Zustand. usw...

: Bearbeitet durch User
von Konrad S. (maybee)


Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Wieso

Dein Protokoll bietet keinen Vorteil und es ist komplizierter als nötig. 
Es hilft nichts, wenn jedes Pixel seine Bytes nicht auf den Ring 
weitergibt, denn das erste Pixel muss eh in der Lage sein, den gesamten 
Datenstrom zu transportieren. Also kann jedes Pixel den Datenstrom 
transportieren, da alle Pixel gleich aufgebaut sind. Ein Pixel kann 
durch Austausch seiner Bytes Daten zurückliefern.

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Ast E. schrieb:
>> Das Protokoll muss entsprechend sehr gut überlegt sein. Sodass die
>> Slaves selber zählen
>
> Wieso zählen und nicht einfach wie die LEDs mit integriertem Controller
> die ersten Bytes nehmen und den Rest weiter schicken?

Gar nicht so verkehrt die Idee! Ich hab den Wald vor lauter Bäumen nicht 
gesehen. Zum implementieren ist das super einfach.
Das einzige was man nicht vergessen sollte, wenn die Pixel mal ein 
Update bekommen sollten, wäre es schön dies über diese Verbindung zu 
tun. Wie löst man das? Ansonsten muss man bei 200 Pixeln per ISP ganz 
schön schuften :-)

Vorteil an dieser Variante ist natürlich, dass ohne extra Zähler der 
Master anhand der zurückkommenden Daten wüsste, wieviele Pixel sich 
aktuell im System befinden

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Konrad S. schrieb:
> Ein Pixel kann
> durch Austausch seiner Bytes Daten zurückliefern.
Dann müsste ja jedes Pixel seine Position wissen. Das ist doch völlig 
unnötig.

Ast E. schrieb:
> Das einzige was man nicht vergessen sollte, wenn die Pixel mal ein
> Update bekommen sollten, wäre es schön dies über diese Verbindung zu
> tun.
Ja auch wenn jetzt nur ein einziges Pixel ein Update bekommen sollte, 
muss man trotzdem den kompletten Datenstrom durchblasen. Bei den 
LED-Bändern mit den WS2812 oder AP102 ist das natürlich auch so. Bei der 
"Lichtbar" unserer Studierenden haben sich aber auch meistens viele/alle 
Pixel geändert.

Ast E. schrieb:
> Ansonsten muss man bei 200 Pixeln per ISP ganz
> schön schuften :-)
Man kann das ja aufteilen in 2x100 oder 4x50 ...

Ast E. schrieb:
> Vorteil an dieser Variante ist natürlich, dass ohne extra Zähler der
> Master anhand der zurückkommenden Daten wüsste, wie viele Pixel sich
> aktuell im System befinden
Na ja, der "Master" muss die Struktur der Matrix sowieso kennen, damit 
was Vernünftige angezeigt werden kann. Dann weiß er ja auch wie viele 
Pixel die Matrix hat.

: Bearbeitet durch User
von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Ich nehme anKonrad wollte damit andeuten, dass das austauschen der Bytes 
schon sinnvoll ist. Nur wozu extra das WS2812 Protokoll nutzen? Da ist 
die UART wahrscheinlich eine einfachere Variante.
Per UART kann ebenfalls problemlos ein Update an alle ausgelöst werden.

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Ast E. schrieb:
> Nur wozu extra das WS2812 Protokoll nutzen? Da ist
> die UART wahrscheinlich eine einfachere Variante.

Ahhh ok, ich dachte USART wäre gerade der Kontext ;-)
Mir ging es beim "Protokoll" nur darum die ersten (RGB)Daten einfach 
wegzunehmen und die Touch-Daten hinten anzuhängen. Wenn das ganze durch 
den Ring durch ist, sind nur noch die Touch-Daten enthalten.

von Nosnibor (Gast)


Bewertung
lesenswert
nicht lesenswert
Vom WS2812 kann man übernehmen, daß eine lange Pause als Framesync 
dient, und daß jeder Slave den ersten Datensatz für sich behält und dann 
alles folgende (bis zur nächsten Pause) weiterreicht.

Die Bitcodierung würde ich nicht vom WS2812 übernehmen, wenn schon ein 
Hardware-UART vorhanden ist. Mit UART hat die Software weniger 
Interruptlast durch die Kommunikation, und ein Master ist einfacher zu 
implementieren (PC + USB-UART). Allerdings müssen die Slave-Prozessoren 
dann einen hinreichend präzisen (max. 2%) Takt haben.

Um die Touch-Daten hinten anzuhängen, ist es aber nötig, daß jeder Slave 
das Ende des RGB-Datenframes sofort erkennt (nicht erst nach einer 
Pause). Also entweder durch eine Längenangabe am Anfang (die dann jeder 
Slave beim Weiterreichen entsprechend herunterzählt) oder durch eine 
eindeutige Kennung für das Ende.

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Ok Fassen wir mal kurz zusammen was wir brauchen:

für UART Protokoll
-RGB Daten für jedes Pixel
-Touch Daten anhängen für jedes Pixel
-Update Funktion für alles Slaves gleichzeitig
-Synchroner Takt für alle Slaves

Slave selbst
-Pulsen IR-Diode (1 PWM Kanal)
-Touch Auswertung
-PWM für RGB LED (3 PWM Kanäle)

so jetzt noch ein paar Gedanken zum Protokoll

Erste Byte Pixel Nummer - RGB Daten Pixel 0 (12Bit) - RGB Daten Pixel 1 
.... - Endmarkierung RGB Daten (z.B. XXX) - Bit 0 Touch Pixel 0 - Bit 1 
Touch Pixel ...

Pixel Nummer wird von jeden Salve eins hoch gezählt so ist immer klar wo 
der Touch hingeschrieben wird gezählt ab Trennzeichen, bei den RGB Daten 
kann sich jeder Slave seine nehmen und sendet nur den Rest weiter.

Man könnte ja auch noch ein Bit für Programmupdate über UART mit 
aufnehmen, wenn das gesetzt ist geht der Slave in den Programmiermodus. 
Aber da kommt es ja drauf an wie das genau funktioniert und wie man das 
machen muss (hab ich noch nie gemacht vielleicht kann ja mal einer 
erklären)

: Bearbeitet durch User
von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Das mit den Pixelnummern und dem Zählen verstehe ich nicht. Wozu soll 
das gut sein?

12 Bit RGB Daten sind mir auch nicht klar. 12 Bit pro Farbe oder 3 
Farben a 4 Bit?

Gleichzeitige Aktualisierung, braucht man meiner Meinung nach eine extra 
Leitung. Muss das sein? (falls der Transfer "aller" schnell genug gehen 
würde) Die "LED-Bänder aktuallisieren ja auch sequenziell.

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Das mit den Pixelnummern und dem Zählen verstehe ich nicht. Wozu soll
> das gut sein?

Die Pixelnummer soll dafür sorgen das die Touch Info an die richtige 
Stelle kommt und falls die Daten für die LEDs am ende der Diskussion 
doch nicht entnommen werden auch dafür

> 12 Bit RGB Daten sind mir auch nicht klar. 12 Bit pro Farbe oder 3
> Farben a 4 Bit?

12 Bit meine ich für jede Farbe sonst wäre es ja doch ein bisschen wenig

> Gleichzeitige Aktualisierung, braucht man meiner Meinung nach eine extra
> Leitung. Muss das sein? (falls der Transfer "aller" schnell genug gehen
> würde) Die "LED-Bänder aktuallisieren ja auch sequenziell.

Die Slaves Programm Aktualisierung macht man ja nur in der 
Programmierphase mal öfters und hängt natürlich dann auch stark davon ab 
was der ausgewählte MC dann auch kann, man kann natürlich auch in Serie 
aktualisieren oder halt auch Manuell alle einzel.... Ist ja nur für die 
Faulheit bei einer größeren Anzahl Pixel

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> Die Slaves Programm Aktualisierung macht man ja nur in der
> Programmierphase mal öfters
Sorry, da war ich komplett auf dem falschen Dampfer. Ich dachte an die 
gleichzeitige Aktualisierung der Farbe.


Noch mal zum USART(oder SPI...). Ein Pixel empfängt ein Byte und schickt 
es dann (gegebenenfalls) weiter. Es gibt somit ein Delay von ein 
bisschen was über einem Byte pro Pixel.
ODER, das Signal wird direkt durchgeleitet (gegebenenfalls die ersten 
RGB Daten nicht). Kein Delay.

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> Ok Fassen wir mal kurz zusammen was wir brauchen:
>
> für UART Protokoll
> -RGB Daten für jedes Pixel
> -Touch Daten anhängen für jedes Pixel
> -Update Funktion für alles Slaves gleichzeitig
> -Synchroner Takt für alle Slaves

synchroner Takt? Bei UART wird doch nur TxD und RxD bedient? Das ist der 
Vorteil, man spart nicht nur eine Leitung, sondern die Slaves arbeiten 
alle selbstständig/asnychron


> Erste Byte Pixel Nummer - RGB Daten Pixel 0 (12Bit) - RGB Daten Pixel 1
> .... - Endmarkierung RGB Daten (z.B. XXX) - Bit 0 Touch Pixel 0 - Bit 1
> Touch Pixel ...

warum 12 und nicht 8 oder gar 16? bei 12Bit werden bits verschenkt.

Ich würde vorschlagen ein Header oder etwas in der Art zu generieren. 
Dort kann drin stehen, wieviele Slaves es gibt, welches Commando (z.B. 
RGB an oder SW Update) ausgeführt wird oder Ähnliches... Dem Header 
könnt man auch einen Zähler einfügen

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Ast E. schrieb:
> warum 12 und nicht 8 oder gar 16? bei 12Bit werden bits verschenkt.

12 Bit geben 4096 Steps das sollte reichen. Wo verschenken 12 Bit den 
bits? einfach aneinander reihen und fertig, man kann doch beim 13 bit 
mit den nächsten daten anfangen.

Ast E. schrieb:
> Ich würde vorschlagen ein Header oder etwas in der Art zu generieren.

Gute Idee macht sicherlich Sinn so bleibt alles einfach und flexibel

Ach ja zum Synchronen Takt meinte ich eigentlich die Anmerkung von 
Nosibor...

Nosnibor schrieb:
> Allerdings müssen die Slave-Prozessoren
> dann einen hinreichend präzisen (max. 2%) Takt haben.

: Bearbeitet durch User
von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> Ast E. schrieb:
>> warum 12 und nicht 8 oder gar 16? bei 12Bit werden bits verschenkt.
>
> 12 Bit geben 4096 Steps das sollte reichen. Wo verschenken 12 Bit den
> bits? einfach aneinander reihen und fertig, man kann doch beim 13 bit
> mit den nächsten daten anfangen.

Für RGB sind es dann 3*12 = 36Bits. Das sind 4 volle Bytes und ein 
halbes Byte.
1.Es gibt vielleicht Anwender die wollen die vollen 16Bit. Was dann?
und 2. ihr wisst noch gar nicht wie das Protokoll letztendlich aussieht. 
Deshalb weiß man auch nicht was alles hinten dran kommt. Damit könnt ihr 
wohl kaum einfach bestimmen, dass es 12Bit sein sollen und "den Rest 
hängen wir hinten dran". Oder seh ich hier etwas nicht?! :-)


> Nosnibor schrieb:
>> Allerdings müssen die Slave-Prozessoren
>> dann einen hinreichend präzisen (max. 2%) Takt haben.

Die Diskussion über einen extra Quartz wurde auch schon geführt. Viele 
meinen dieser ist nicht nötig und kann aus kostengründen eingespart 
werden. Anderen ist es zu unsicher. Ich persönlich habe bisher ohne 
quartz leider noch nicht viel gemacht

von Nosnibor (Gast)


Bewertung
lesenswert
nicht lesenswert
Ast E. schrieb:
> Die Diskussion über einen extra Quartz wurde auch schon geführt. Viele
> meinen dieser ist nicht nötig und kann aus kostengründen eingespart
> werden. Anderen ist es zu unsicher. Ich persönlich habe bisher ohne
> quartz leider noch nicht viel gemacht

Das käme auf einen Versuch an. Notfalls ändert man das Protokoll auf 
weniger nutzbare Bits pro Byte, dann kommt es auch mit etwas größeren 
Taktabweichungen bzw. unscharfen Flanken klar.
Der Trend bei den Prozessoren geht ja dahin, daß die internen 
Oszillatoren ab Werk auf <=2% abgeglichen sind, damit man damit ohne 
Quarz UART/RS232 nutzen kann. Steht jedenfalls so in den Datenblättern. 
Ich habe aber auch noch kein konkretes Beispiel gesehen/gebaut, wo 
beide Seiten ohne Quarz arbeiten. Das mit den 2% sieht zwar im 
Datenblatt überzeugend aus, aber da sind auch immer perfekte 
Rechtecksignale abgebildet...

Eine explizite Taktleitung wäre eben zusätzlicher Hardwareaufwand und 
daher vermeidenswert, genau wie ein Quarz.

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Ast E. schrieb:
> Für RGB sind es dann 3*12 = 36Bits. Das sind 4 volle Bytes und ein
> halbes Byte.
> 1.Es gibt vielleicht Anwender die wollen die vollen 16Bit. Was dann?
> und 2. ihr wisst noch gar nicht wie das Protokoll letztendlich aussieht.
> Deshalb weiß man auch nicht was alles hinten dran kommt. Damit könnt ihr
> wohl kaum einfach bestimmen, dass es 12Bit sein sollen und "den Rest
> hängen wir hinten dran". Oder seh ich hier etwas nicht?! :-)

ob es am Ende 8, 12 oder 16 Bit sind ist völlig egal das ist eine 
Kleinigkeit
Kann doch am Ende jeder machen wie er will... außerdem diskutieren wir 
ja deswegen ;-)

Wichtig ist das wir das generelle Protokoll mal zusammen bekommen und 
alle evtl. Probleme beseitigen.

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:

> Wichtig ist das wir das generelle Protokoll mal zusammen bekommen und
> alle evtl. Probleme beseitigen.

Mein Vorschlag wäre wie gesagt ein Header. Dieser beinhaltet ein 
Kommando. Das Kommando kann für folgendes stehen:
- de-/aktiviere Bootloader
- neue Flash Daten (im bootmode)
- neue RGB Daten (im application mode)
- applikationsspezifische kommandos (ändern einer Blink Frequenz oder 
Ähnliches)
- Slave counter (wird einmalig am Anfang verwendet)

Der Slave counter ermöglicht dem Master zu ermitteln, wieviele Slaves 
denn tatsächlich in seinem System sind. Dies wird einmalig beim 
Programmstart ausgeführt. Denn ich sehe das Problem nicht gelöst, wenn 
ohne Zähler gearbeitet wird, wie soll der Slave wissen, wann seine Daten 
kommen und wieviele Daten danach auch noch kommen?!

Nach dem Kommando kann man einen Zähler anhängen. Der Zähler beinhaltet 
die tatsächliche Anzahl der Slaves und wird dekrementiert. Idealerweise 
dekrementiert der letzte Slave auf 0.
Mit Hilfe des Zählers weiß der Slave auch ganz genau wieviele RGB oder 
angehängte Touch Daten noch folgen.

Fazit: 1 Kommandobyte, 1-2 Counterbyte, Rest Daten. Oder Man kombiniert 
Kommando mit Counter.

Das wäre mein Vorschlag. Wenn jemand weiß wie man die "Zählvariante" 
umgehen kann, bin ich für alles offen

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Ast E. schrieb:
> Wenn jemand weiß wie man die "Zählvariante"
> umgehen kann, bin ich für alles offen
So wie es die WS2812 oder APA102 machen?

(Letztendlich kann man mit der gleichen Hardware sicher auch 
verschiedene Protokolle verwenden, falls es da verschiedene Strömungen 
gäbe)

: Bearbeitet durch User
von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Ast E. schrieb:
>> Wenn jemand weiß wie man die "Zählvariante"
>> umgehen kann, bin ich für alles offen
> So wie es die WS2812 oder APA102 machen?

Du meinst also die vordersten RGB Bytes entnehmen, Touch hinten anhängen 
(wo ist hinten?) und warten bis der Master Reset auslöst!?
Ich bin da momentan etwas auf dem Holzweg wie genau das funktionieren 
soll

: Bearbeitet durch User
von Nosnibor (Gast)


Bewertung
lesenswert
nicht lesenswert
Ast E. schrieb:

> Der Slave counter ermöglicht dem Master zu ermitteln, wieviele Slaves
> denn tatsächlich in seinem System sind. Dies wird einmalig beim
> Programmstart ausgeführt. Denn ich sehe das Problem nicht gelöst, wenn
> ohne Zähler gearbeitet wird, wie soll der Slave wissen, wann seine Daten
> kommen und wieviele Daten danach auch noch kommen?!

Eine berechtigte Frage.
WS2812 macht es sich einfach: jeder Slave weiß, daß der erste 
RGB-Datensatz für ihn selbst ist. Falls danach noch Daten kommen, reicht 
er die natürlich weiter, wobei es ihm egal ist, wieviele das sind. Kein 
Zähler nötig. Den ersten Datensatz erkennt ein Slave daran, daß vorher 
eine Pause war. Das Ende des Datenstroms erkennt der Slave daran, daß 
dahinter eine Pause kommt.

Wir können das nicht so einfach machen, weil unsere Slaves nicht nur 
RGB-Daten entnehmen, sondern auch Touch-Daten einfügen sollen. Da gibt 
es mehrere Möglichkeiten:

1. RGB-Daten gewissermaßen in-place durch Touch-Daten ersetzen. Dazu muß 
man jedem Datensatz ansehen können, ob es sich um RGB- oder Touchdaten 
handelt, z.B. an einem entsprechenden Bit im ersten Byte. Der Slave 
ersetzt dann den ersten RGB-Datensatz durch seine Touch-Daten, alle 
andere Datensätze (Touchdaten vorher, RGB hinterher) reicht er 
unverändert durch.

2. Touch-Daten hinten an den Datenstrom anfügen. Dazu muß der Slave 
wissen, wann das RGB-Telegramm zu Ende ist, damit er dann seine 
Touch-Daten anfügen und eventuelle Touch-Daten  der anderen Slaves 
weiterreichen kann. Dafür sehe ich zwei Möglichkeiten:

a) eine Markierung (also z.B. ein RGB-Datensatz mit einem speziellen 
Wert), die hinter dem letzten RGB-Datensatz gesendet wird, so daß die 
Slaves wissen, daß sie ab hier Touch-Daten einfügen können.

b) ein Zähler am Anfang des ganzen Datenstroms, der angibt, wieviele 
RGB-Datensätze folgen. Jeder Slave muß den natürlich herunterzählen und 
weitergeben, wenn er einen RGB-Datensatz entnimmt.

Mir sieht momentan 2b am besten aus. Einen einfachen Header am Anfang 
braucht man sowieso, wenn man Firmware-Update über den Bus ermöglichen 
will, was sicherlich in der Entwicklungsphase ganz angenehm ist.

Daß der Master die Slaves zählen kann, halte ich nicht für nötig und 
würde dafür keinen zusätzlichen Protkollaufwand treiben.
Das ist zwar in der Entwicklungsphase cool, aber bei einem fertigen 
Gerät muß der Master nicht nur wissen, wieviele Slaves vorhanden sind, 
sondern auch deren geometrische Anordnung und ggf. Bedeutung (vielleicht 
will der Benutzer ja mit dem Touch noch mehr bewirken als nur die 
Farbänderung eines Pixels). Da ist also im Master jede Menge 
Konfiguration nötig, wo die Anzahl der Slaves sowieso enthalten ist.

Slaves Zählen geht ohne expliziten Aufwand in den Slaves auch so:
Bei Variante 1 kann der Master versuchshalber unterschiedlich große 
Datenströme senden und beobachten, wieviele unbenutzte (d.h. nicht durch 
Touch-Daten ersetze) RGB-Datensätze zurückkommen. Bei Variante 2 kann 
man vorsehen, daß Slaves ihre Touch-Daten auch dann anfügen, wenn sie 
keinen RGB-Datensatz mehr abbekommen haben. Dann sieht der Master bei 
jeder Übertragung, wieviele Slaves in der Kette sind, egal ob er die 
richtige Anzahl RGB-Daten geschickt hat.

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Nosnibor schrieb:
> Das ist zwar in der Entwicklungsphase cool, aber bei einem fertigen
> Gerät muß der Master nicht nur wissen, wieviele Slaves vorhanden sind,
> sondern auch deren geometrische Anordnung und ggf. Bedeutung (vielleicht
> will der Benutzer ja mit dem Touch noch mehr bewirken als nur die
> Farbänderung eines Pixels). Da ist also im Master jede Menge
> Konfiguration nötig, wo die Anzahl der Slaves sowieso enthalten ist.

kommt darauf an. Wenn man den Master rein als Steuerungsobjekt 
betrachtet, dann bedient der Master das Protokoll RGB/Touch und stellt 
die Daten per Schnittstelle an die Applikation bereit. In der 
Applikation beginnt dann erst der richtige User-Spaß. Dort ist es 
unerheblich wo Pixel1,Pixel2 etc sich befinden, die Zuordnung findet 
einmal in der App statt. Der (hardware) Master bedient dann die Slaves 
immer gleich, somit sollte die SW des Masters eigtl immer gleich sein. 
Man brauch "nur" die Applikation sich entsprechend zu Recht frickeln. 
Kann aber auch sein das ich gerade wieder etwas zu weit gedacht habe ;-)

> Slaves Zählen geht ohne expliziten Aufwand in den Slaves auch so:

Grundsätzlicher Nachteil beim Zähler ist dann die Begrenztheit. Wenn man 
hier aber zwei Byte vorsieht, sollte das Ganze schon gelöst sein. 
Deshalb finde ich die Zählervariante ganz angenehm.

von Volker S. (vloki)


Angehängte Dateien:

Bewertung
lesenswert
nicht lesenswert
Also das vorne entnehmen ist ja einfach. Die ersten Bytes nach einer 
(längeren) Pause sind die RGB Infos für das jeweilige Pixel.

Beim hinten anhängen wird es schon etwas kniffliger.

Wenn man sich das Protokoll der APA102 anschaut, dann hat die auch einen 
Start-Frame (Header) und ein End-Frame. Die RGB-Frames sind durch die 
"111" gekennzeichnet. Das Ende durch 1*32. Wie man jetzt das von den RGB 
Daten unterscheiden kann, ist mir nicht so ganz klar, weil ich mich 
ehrlich gesagt noch nicht tiefer mit den Dingern beschäftigt habe.
Mit den drei (oder wie viel auch immer) Bits könnte man auf jeden Fall 
verschiedene Funktionen realisieren. (Bootloader...)

Das Anhängen ist aber ohne Zähler immer noch nicht so einfach. Man 
könnte vielleicht die Pixel initialisieren indem man auf ähnliche Weise 
wie die RGB-Daten eine Nummerierung durchschickt und auch die 
Gesammtanzahl.
Auf diese Weise bräuchte das Pixel nicht auf eine Pause am Ende der 
Übertragung warten, weil es berechnen kann, wann seine Touch-Daten 
angehängt werden können.

von Ast E. (vis)


Angehängte Dateien:

Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Das Anhängen ist aber ohne Zähler immer noch nicht so einfach. Man
> könnte vielleicht die Pixel initialisieren indem man auf ähnliche Weise
> wie die RGB-Daten eine Nummerierung durchschickt und auch die
> Gesammtanzahl.
> Auf diese Weise bräuchte das Pixel nicht auf eine Pause am Ende der
> Übertragung warten, weil es berechnen kann, wann seine Touch-Daten
> angehängt werden können.

Entspricht ja dann meiner Überlegung die ich hatte ;-)
Mit dem Zähler brauch kein Slave warten. Extra Delays würde ich auch 
vermeiden wollen, denn dann kann man nur schwierig die reale "Bildrate" 
berechnen

Beispiel:
gegeben:
100 Pixeln
(ganz fiktive Zahlen) 1 Byte Kommando, 2 Byte Zähler, je 3Byte RGB, je 
1Byte Touch (rangehängt)

ergibt für jeden Pixel eine Formel:
Summe(n bis 100) = 3Byte Header + (100-n)*3 RGB Bytes + n Touch Bytes

Hab mal eine schnelle Excel Datei erstellt die das runterbricht. Ich 
hoffe da ist kein Fehler drin, aber die Summe verstimmt mich etwas...

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Ast E. schrieb:
> Ich
> hoffe da ist kein Fehler drin, aber die Summe verstimmt mich etwas...

Ich verstehe das mit der Summe nicht so ganz ;-)
Es gibt doch gar keine Summe.
Der Master muss zunächst alle RGB Daten abschicken.

Das erste Pixel empfängt die ja praktisch zur gleichen Zeit.
Alle Bytes die es nicht benötigt schickt es sofort weiter.
Den Header und den Zähler kann es ja weiter schicken, während es seine 
RGB-Daten empfängt. Das gibt ein Delay von ca. einem Byte pro Pixel.
(Wenn die Daten einfach durchgeleitet werden können dann gar keines)
Am Ende muss das Pixel noch seine Touch-Daten anhängen. Nochmal ein Byte 
damit das schön einfach bleibt.

Die RGB-Daten gehen doch nur ein einziges mal in die Summe ein. Also 
wäre die Summe bei 100 Pixel
~ 1Header + 2*Zähler + 300RGB +100*2Delay ~ 503 Bytes?

von Andreas (Gast)


Bewertung
lesenswert
nicht lesenswert
Hallo Leute,
ich hatte schon vorher zu den zwei Möglichkeiten was geschrieben.
Es meiner Sicht ist der Zähler so oder ein Muss.

Und die Variante mit am Ende Anhängen hat nach einigem Überlegen einen 
Nachteil:
Wie hier schon gesagt wurde, verzögert ein Pixel die Daten um eine 
Byte-Zeit. Das Abschneiden vorne hat keinen zeitlichen Vorteil, da der 
nächste Pixel seine Daten ja nicht schneller bekommt - er muss genauso 
lange warten.
Die Angehängten Daten machen das Datenpaket aber länger, weil, wie 
gesagt, die abgeschnittene Werte machen die Übertragung nicht schneller!
So kommt eine zusätzliche Verzögerung pro Pixel um die Touch-Daten!

Ich hoffe, ich habe das verständlich erklärt :) es ist wie das Spiel 
Worm/Schlange oder wie auch immer das alte Spiel heißt, wo ein Wurm 
immer länger wird.

rgb rgb rgb rgb       <-- eingang 1. pixel
    rgb rgb rgb t     <-- eingang 2. pixel
        rgb rgb t t   <-- eingang 3. pixel

MfG,
Andreas

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Die RGB-Daten gehen doch nur ein einziges mal in die Summe ein. Also
> wäre die Summe bei 100 Pixel
> ~ 1Header + 2*Zähler + 300RGB +100*2Delay ~ 503 Bytes?

Du überträgst diese Bytes aber nicht einmal von Slave zu Slave sondern 
zwischen 100 oder mehr... Deshalb musst du die Zeiten addieren. Das 
meinte ich mit Summe.
Und Andreas hat auch Recht. Vorne wegnehmen bringt keinen Aufschub, denn 
hinten kommt wieder ein Byte ran. Man hat eher ein Delay wegen fehlenden 
RGB Bytes.
Und daraus wollte ich berechnen wie weit man mit der UART eigentlich 
kommt. In der Rechnung war der Delay noch nicht einmal drin. Wenn man 30 
oder besser 50 mal pro Sekunde (50fps) die Daten aktualisieren möchte um 
ein flüssiges Bild zu bekommen, dann muss die Refreshrate bei ungefähr 
20ms für 50fps liegen. Meine Berechnung zeigte (ohne Delay) knapp 150ms. 
Oder bin ich völlig auf dem Holzweg? :-D

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Andreas schrieb:
> Wie hier schon gesagt wurde, verzögert ein Pixel die Daten um eine
> Byte-Zeit. Das Abschneiden vorne hat keinen zeitlichen Vorteil, da der
> nächste Pixel seine Daten ja nicht schneller bekommt - er muss genauso
> lange warten.
> Die Angehängten Daten machen das Datenpaket aber länger,

Ok, langsam verstehe ich ;-)

Abschneiden bringt nur was wenn kein Zähler da ist, damit jedes Pixel 
trotzdem automatisch seine RGB-Daten bekommt.
Mit Zähler wäre Ersetzen sinnvoller als das Anhängen.

Wie kommt jetzt das Pixel zu seiner Position? Die wird man ja wohl kaum 
im Code hinterlegen wollen. Die könnte man mit der Abschneidetechnik 
durchgeben.


Ast E. schrieb:
> Meine Berechnung zeigte (ohne Delay) knapp 150ms.
> Oder bin ich völlig auf dem Holzweg? :-D
Das setzt aber voraus, dass immer der komplette Datensatz von jedem 
Pixel empfangen wird und erst nach dem Ende an das nächste Pixel 
weitergegeben wird. (wenn ich es richtig verstanden habe). Warum?

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Andreas schrieb:

> Ast E. schrieb:
>> Meine Berechnung zeigte (ohne Delay) knapp 150ms.
>> Oder bin ich völlig auf dem Holzweg? :-D
> Das setzt aber voraus, dass immer der komplette Datensatz von jedem
> Pixel empfangen wird und erst nach dem Ende an das nächste Pixel
> weitergegeben wird. (wenn ich es richtig verstanden habe). Warum?

Die Berechnung zeigt alle Pixel. Für jeden Pixel werden jeweils 3 RGB 
Bytes abgezogen und 1 Touch Byte angehängt. Deswegen sinkt die Summe der 
zu übertragenden Bytes von Slave zu Slave. Der Letzte Slave muss 
entsprechend nur noch alle Touch Bytes übertragen. Der erste muss 
hingegen AnzahlSlaves * 3 RGB + Header empfangen und fängt dann mit dem 
ersten Austausch an. Dadurch ergibt sich eine Übertragungszeit von Slave 
zu Slave, diese variiert aber entsprechend. Die Übertragung der letzten 
Slaves ist schneller, da dort deutlich weniger Bytes übertragen werden 
müssen. Mit der Summe der Übertragungsraten kann die komplette Bildrate 
berechnet werden. Hintergrund ist: ob der UART Ring für solch ein 
Protokoll schnell genug wäre

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Ast E. schrieb:
> Der erste muss
> hingegen AnzahlSlaves * 3 RGB + Header empfangen und fängt dann mit dem
> ersten Austausch an.

Meine Frage ist doch WARUM er erst ALLES empfangen muss. Er kann doch 
sofort weiter schicken. Dann gibt es nur ein vergleichbar kleines Delay.

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Wie kommt jetzt das Pixel zu seiner Position? Die wird man ja wohl kaum
> im Code hinterlegen wollen. Die könnte man mit der Abschneidetechnik
> durchgeben.

Ist natürlich Quatsch, weil viel zu kompliziert. Zähler durch schicken, 
der von den Pixeln incrementiert wird reicht ja auch.

von Nosnibor (Gast)


Bewertung
lesenswert
nicht lesenswert
Die meisten Daten werden vom Master zum ersten Pixel übertragen (danach 
werden es immer weniger, weil Touch kürzer ist als RGB). Aus Anzahl der 
Pixel, Größe des RGB-Datensatzes und Baudrate kann man berechnen, wie 
lange diese Sendung dauert. Wenn die Sendung raus ist, kann der Master 
sofort den nächsten Frame senden (ggf. mit 'ner ms Pause als Framesync 
dazwischen). Daraus ergibt sich die Framerate.

Für Animationen ist nur diese Framerate relevant. Wie lange das vorige 
Telegramm noch durch die Kette kriecht, während der Master schon das 
nächste sendet, ist dafür egal.

Interessant wird das für die Reaktionszeit. Also, wenn ich ein Pixel 
berühre, wie lange dauert es, bis das Pixel die Farbe wechselt? Dazu muß 
die Information praktisch eine komplette Runde drehen: die 
Touchinformation muß durch den Rest der Kette zum Master und dann dessen 
Antwort durch den ersten Teil der Kette zurück zum aktuellen Pixel. Und 
vorher kann noch Wartezeit hinzukommen, weil der Datenzug vielleicht 
gerade abgefahren ist (Framerate).

Um die Reaktionszeit kurz zu halten, ist es wichtig, daß jedes Pixel die 
Daten so schnell wie möglich weitergibt. Bei UART-Benutzung wäre das 
also ein Byte + Interruptlatenz, schneller geht es nicht. Das hatte ich 
bisher als selbstverständlich vorausgesetzt, denn alle Daten, die ein 
Pixel nicht sofort weitergibt, muß es zwischenspeichern. Das ist nur 
zusätzlicher Aufwand und hilft niemandem.

Ob ein Pixel seine Position kennt, ob man einen Zähler oder eine 
Markierung verwendet… das spielt alles für die Berechnung der Framerate 
und Reaktionszeit keine Rolle.

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Nosnibor schrieb:
> Bei UART-Benutzung wäre das
> also ein Byte + Interruptlatenz, schneller geht es nicht.

Habe ich selbst noch nicht verwendet, aber bei uC mit CLC müsste man die 
für das Pixel nicht interessanten Bytes einfach durch schleifen können. 
http://www.microchip.com/design-centers/8-bit/peripherals/core-independent/configurable-logic-cell-clc

Also das Pixel zählt z.B. bis zu seiner Position mit und ersetzt da die 
RGB durch seine Touch Daten. Ob sich das wegen ~1Byte pro Pixel aber 
lohnt...

von Andreas (Gast)


Bewertung
lesenswert
nicht lesenswert
Also, wenn die Daten nicht angehängt werden, dann ist die Berechnung 
einfach:
Paketgröße + 1Byte * Anzahl_Pixel, da Ein Pixel empfängt ein Byte 
komplett vor dem versenden.
Der nächste Frame kann sofort danach versendet werden.

Wenn man Daten anhängt, hat man zwei Probleme:
1. Wenn die angehängte Datenlänge ungleich der Abgeschnittenen ist, ist 
es schwieriger, das Ende des Paketes zu berechnen:
RGB_Länge * Anzahl_Pixel_Danach + Touch_Daten_Länge * Anzahl_Pixel_Davor

2. Man kann nicht sofort den nächsten Datenblock senden, da der erste 
Pixel zuerst seine Touchdaten loswerden muss, oder der Pixel muss die 
empfangene Daten zwischenspeichern, bevor die verarbeitet und weiter 
gesendet werden können. -- Ich hoffe bei diesem Punkt habe ich keinen 
Gehirnknoten und schreibe keinen Unsinn :)

MfG,
Andreas

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Andreas schrieb:
> Wenn man Daten anhängt, hat man zwei Probleme:
> 1. Wenn die angehängte Datenlänge ungleich der Abgeschnittenen ist, ist
> es schwieriger, das Ende des Paketes zu berechnen:
> RGB_Länge * Anzahl_Pixel_Danach + Touch_Daten_Länge * Anzahl_Pixel_Davor
Na ja, so schwierig jetzt auch wieder nicht, aber wenn das Anhängen 
sowieso keine Vorteile bringt... ;-)


Andreas schrieb:
> 2. Man kann nicht sofort den nächsten Datenblock senden, da der erste
> Pixel zuerst seine Touchdaten loswerden muss,
Sofort wäre eh schwierig, falls man die "Pause" zur Synchronisation 
nutzen wollte.




Man könnte sich die kompliziertesten Protokolle überlegen.
Wenn die Pixel ihre Position kennen, wie wäre es wenn die eigenen RGB 
Daten am Ende kämen? Dann wäre die Zeitverschiebung der Aktualisierungen 
von erstem und letztem Pixel viel geringer.

von Nosnibor (Gast)


Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Man könnte sich die kompliziertesten Protokolle überlegen.
Man sollte es aber bleiben lassen und stattdessen das einfachstmögliche 
Protokoll wählen. Das ist zwar zunächst schwieriger, hat am Ende aber 
mehr Aussicht auf erfolgreiche Realisierung.  ;)

> Wenn die Pixel ihre Position kennen, wie wäre es wenn die eigenen RGB
> Daten am Ende kämen? Dann wäre die Zeitverschiebung der Aktualisierungen
> von erstem und letztem Pixel viel geringer.
Dann wäre die Zeitverschiebung eben umgekehrt... aber eine gute Idee ist 
es trotzdem, jeweils den letzten RGB-Datensatz zu entnehmen (und durch 
Touchdaten zu ersetzen). Und damit nicht jedes Pixel seine Position erst 
lernen und sich dann merken muß, kommt als erstes ein Zähler.

Das Pixel schickt also zuerst den dekrementierten Zähler weiter, dann 
reicht es so viele RGB-Daten durch wie der Zähler angibt, dann nimmt es 
sich einen RGB-Datensatz und sendet seine Touch-Daten stattdessen, und 
schließlich reicht es alle weiteren (Touch-)Daten durch, bis… naja, ich 
favorisiere ja immernoch eine Pause von mehreren Bytezeiten als Trennung 
zwischen den Frames. Irgendwas braucht man jedenfalls, um zu erkennen, 
wann es wieder neu losgeht.

Für fünf Pixel sähe das dann z.B. so aus:
Master --> 1.Pixel:  5 RGB5 RGB4 RGB3 RGB2 RGB1
1.Pixel --> 2.Pixel:  4 RGB5 RGB4 RGB3 RGB2 T1
2.Pixel --> 3.Pixel:   3 RGB5 RGB4 RGB3 T2   T1
3.Pixel --> 4.Pixel:    2 RGB5 RGB4 T3   T2   T1
4.Pixel --> 5.Pixel:     1 RGB5 T4   T3   T2   T1
5.Pixel --> Master:       0 T5   T4   T3   T2   T1

Hmm, die Lücken zwischen den Touchdaten gefallen mir nicht. Da ist 
möglicherweise etwas Padding nötig.

Gleichzeitigkeit kommt auch hier nicht von alleine. Anhand des Zählers 
kann zwar jedes Pixel wissen, wann das letzte Pixel den Anfang des 
Datenpaketes sieht, aber zu dem Zeitpunkt haben die vorigen ihre Daten 
noch gar nicht. Man braucht dann noch eine Konvention (oder einen (für 
alle Pixel gleichen) Konfigurationswert), daß die neuen Daten eine 
bestimmte Zeit diesem Zeitpunkt gelten sollen, z.B. (200-Zähler) 
Bytezeiten nach dem Start des Datenframes.

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
eine Idee die mir eben kam:
unter der Annahme, dass jedes Pixel nur ein Bit für Touch 'aktiv' oder 
'nicht aktiv' kennzeichnen soll, kann man den Header auch soweit 
dynamisch aufbohren. Es wird  ein Kommando und ein Zähler für die Pixel 
implementiert ist. ZUSÄTZLICH wird der Header dynamisch gehalten und je 
nach Anzahl der Pixel um X Bits verlängert. In diese Bits schreibt jeder 
Pixel seinen Touch Zustand. Man kann bei unschöner Anzahl von Pixeln 
höchstens 7Bit eines Bytes verschenken.
Da der Header eh bei jedem Pixel als erstes durchrauscht, wird nichts 
entnommen oder weggelassen. Die RGB Daten werden in umgekehrter 
Reihenfolge der Pixel verschickt, sodass der erste Pixel den letzten RGB 
Datensatz nimmt (kann man anhand des Zählers berechnen) und diesen nicht 
weiter leitet. Der zweite Pixel entnimmt ebenfalls den letzte RGB 
Datensatz.

Somit entstehen keine Lücken und es werden Touch/RGB Daten in einem 
Rausch getauscht und die Bildrate ist ermittelbar :-)


unter der Annahme, dass jedes Pixel den ADC Wert (8Bit) für Touch 
bereitstellen soll, wird der Header um Faktor 8 größer. Das ist dann 
schon eine etwas andere Größenordnung

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
lesenswert
nicht lesenswert
Nosnibor schrieb:
> Hmm, die Lücken zwischen den Touchdaten gefallen mir nicht. Da ist
> möglicherweise etwas Padding nötig.

Zieh das Pferd mal von hinten auf. Wer braucht denn 256x256x256 = 
16777216 Farben?

Mach eine Tabelle mit 256 Farben und fertig. Dann passt der Farbwert in 
ein simples Byte.

2 Bytes pro Pixel gespart. Jedes Pixel frisst einen Farbwert (1 Byte) 
weg und hängt einen Touchwert (1 Byte) an. Das heisst: die Menge der 
übertragenen Bytes bleibt immer gleich.

: Bearbeitet durch Moderator
von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Frank M. schrieb:
> Nosnibor schrieb:
>> Hmm, die Lücken zwischen den Touchdaten gefallen mir nicht. Da ist
>> möglicherweise etwas Padding nötig.
>
> Zieh das Pferd mal von hinten auf. Wer braucht denn 256x256x256 =
> 16777216 Farben?

ich verstehe wenn man keine 16x16x16 Farben haben möchte. Das Ganze aber 
auf 256Farben begrenzen finde ich arg Knapp. Mit 8x8x8 Farben kann ich 
mich noch zufrieden geben :-)

Meine oben genannte Variante interessiert es nicht wieviele RGB Bytes es 
sind.

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Frank M. schrieb:
> Zieh das Pferd mal von hinten auf. Wer braucht denn 256x256x256 =
> 16777216 Farben?
>
> Mach eine Tabelle mit 256 Farben und fertig. Dann passt der Farbwert in
> ein simples Byte.

also nur 256 find ich auch etwas arg wenig...

ich finde Volkers Vorschlag die Touch Daten zuerst einzuschreiben und 
die RGB Daten zum Schluß eigentlich gut.
Vielleicht sollten wir langsam mal anfangen den Vorschlag in ein paar 
Zeilen Code zu fassen bevor wir uns zu sehr verzetteln.

Denke ja was wir hin und her schicken müssen ist uns mittlerweile klar.

Denke eine Header zum einstellen der Pixel Anzahl, Länge RGB Daten ist 
Sinnvoll, so bleib es für jeden flexibel und einfach.

Was meint Ihr?

von Nosnibor (Gast)


Bewertung
lesenswert
nicht lesenswert
Niemand braucht 16 Millionen Farben… gleichzeitig. Es werden nie mehr 
Farben gebraucht als Pixel vorhanden sind. Aber wenn man weniger an 
grellem Blinken interessiert ist als an fast unmerklich langsamen 
Farbübergängen, dann muß man sehr feine Farbunterschiede ausdrücken 
können. Da sind die 16 Millionen möglicherweise noch zu wenig, wenn man 
keine Gammakurve hat.

Außerdem hätte man mit dem Palettenprinzip das Problem, gelegentlich 
(mindestens einmal nach dem Einschalten) die Palette (also die Tabelle 
der 256 ausgewählten Farben) übertragen zu müssen. Das dauert auch, und 
vor allem macht es das Protokoll komplexer.

Ich denke, das ist eine Option für später, falls man mit der 
erreichbaren Framerate bei einer großen Pixelzahl nicht zufrieden ist. 
Vorher sollte aber überhaupt erst etwas funktionieren.

Die Touchdaten in den Header einzufügen halte ich für problematisch, 
wegen des Einfügens. Irgendwer (entweder jedes Pixel oder jedes achte) 
muß ein Byte einfügen und produziert ab dem Moment zwei Bytezeiten 
Verzögerung. Das ist zusätzliche Komplexität. Da wäre es besser, der 
Master schickt gleich die entsprechende Anzahl dummy-Bytes für die 
Touchdaten mit, gewissermaßen ein "Formular", das von den Pixeln dann 
ausgefüllt wird. Und das tut er ja schon: RGB-Daten, die die hinteren 
Pixel nicht mehr brauchen.  :)

Also mein Vorschlag: jedes Pixel ersetzt seine RGB-Daten (oder 
meinetwegen auch Farbindex) durch Touch (+Dummybytes), dann bleibt das 
ganze Telegramm immer gleichlang und das Timing überschaubar.

Nicht vergessen: wir gewinnen nichts, wenn das Datenpaket unterwegs 
kleiner wird. Die Framerate wird begrenzt durch die maximale Länge des 
Datenpaketes auf seiner Runde, also an der Stelle vom Master an das 
erste Pixel.

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> ich finde Volkers Vorschlag die Touch Daten zuerst einzuschreiben und
> die RGB Daten zum Schluß eigentlich gut.

Bin mir gar nicht so sicher, dass ich das genau so gesagt habe, aber 
gefällt mir auch ;-)
Eigentlich ist es gar nicht nötig einen Zähler mit zu schicken. Der wäre 
ja für das jeweilige Pixel sowieso immer gleich. Aus der Position und 
der Gesamtanzahl kann das Pixel anhand der komplizierten Formel von 
weiter oben doch das Ende des Datenstromes berechnen. Das sähe dann wohl 
so aus:

Master schickt:
HEADER_DATA RGB_n RGB_n-1 ... RGB_3 RGB_2 RGB_1

1. Pixel:
HEADER_DATA T_1 RGB_n RGB_n-1 ... RGB_3 RGB_2

2. Pixel:
HEADER_DATA T_2 T_1 RGB_n RGB_n-1 ... RGB_3

3. Pixel:
HEADER_DATA T_3 T_2 T_1 RGB_n RGB_n-1 ...

Gibt natürlich ein Delay von 2Byte bei jedem Pixel aber der Datenstrom 
würde dafür immer um 3Byte kürzer (Bei 3x8Bit RGB)
Hätte dann etwa das letzte Pixel seine Daten noch vor dem ersten?

von Nosnibor (Gast)


Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Eigentlich ist es gar nicht nötig einen Zähler mit zu schicken. Der wäre
> ja für das jeweilige Pixel sowieso immer gleich. Aus der Position und
> der Gesamtanzahl kann das Pixel anhand der komplizierten Formel von
> weiter oben doch das Ende des Datenstromes berechnen.

Dazu muß das Pixel aber seine Position und die Gesamtzahl kennen, d.h. 
es muß erstmal konfiguriert werden. Es wäre schön, wenn man ohne 
Konfiguration der einzelnen Pixel auskäme.

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Nosnibor schrieb:
> Dazu muß das Pixel aber seine Position und die Gesamtzahl kennen, d.h.
> es muß erstmal konfiguriert werden. Es wäre schön, wenn man ohne
> Konfiguration der einzelnen Pixel auskäme.

Und wie genau macht es das mit dem Zähler?
Es müsste doch völlig ausreichen den Zähler nur einmal durch die Kette 
zu schicken, anstelle bei jeder Aktualisierung. Das Pixel kann sich den 
Zähler merken und ist konfiguriert. (Seine Position wird es wohl nicht 
ändern)
Wenn ich das richtig interpretiere ist das doch wie einmal 
konfigurieren, oder ständig konfigurieren.

: Bearbeitet durch User
von Nosnibor (Gast)


Bewertung
lesenswert
nicht lesenswert
Das stimmt, der Zähler in jedem Datenpaket ist praktisch ein ständiges 
Konfigurieren. Das hat zur Folge, daß das Pixel sich keine Konfiguration 
merken muß, weder im RAM noch im Flash/EEPROM. Das Verhalten des Pixels 
ist damit weniger komplex; es hängt nur vom aktuellen und vorigen 
Datenpaket ab, nicht davon, ob sich das Pixel an den letzten 
Konfigurationsvorgang erinnern kann.

Komplexität vermeiden ist allgemein gut, das macht das System robuster.
Nötig ist das hier aber wahrscheinlich nicht.

Wenn es aber einen separaten Konfigurationsvorgang gibt, braucht der 
Master auch einen Algorithmus, wann er neu konfigurieren soll:
 - wenn der Benutzer die "Config"-Taste drückt (z.B. weil irgendwas 
nicht geht, oder weil er was umgebaut hat)?
 - wenn sich die Konfiguration im Master (Anzahl Pixel, geometrische 
Anordnung,...) geändert hat?
 - als erstes nach jedem Einschalten?
 - immer wenn es eines Störung gibt (kein korrektes Datenpaket 
zurückgekommen)?
 - präventiv einmal pro Minute?
  ...
 - präventiv bei jedem Frame?    :)

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Ast E. schrieb:
> Es wird  ein Kommando und ein Zähler für die Pixel
> implementiert ist. ZUSÄTZLICH wird der Header dynamisch gehalten und je
> nach Anzahl der Pixel um X Bits verlängert. In diese Bits schreibt jeder
> Pixel seinen Touch Zustand. Man kann bei unschöner Anzahl von Pixeln
> höchstens 7Bit eines Bytes verschenken.



Nosnibor schrieb:
> Also mein Vorschlag: jedes Pixel ersetzt seine RGB-Daten (oder
> meinetwegen auch Farbindex) durch Touch (+Dummybytes), dann bleibt das
> ganze Telegramm immer gleichlang und das Timing überschaubar.

Das versuche ich seit zwei Beiträgen mitzuteilen :-)
Der Header beinhaltet bereits die nötigen Bytes und diese müssen nur von 
den Slaves mit Touchdaten gefüllt werden.

Ich finde den Vorschlag mit einem einmaligen Zähler gut. Beim Hochfahren 
des Systems reicht eine einmalige Initialisierung und jeder Slave weiß 
wo er steht.

Tadaaa, wir haben das Protokoll ;-)

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Nosnibor schrieb:
> Nicht vergessen: wir gewinnen nichts, wenn das Datenpaket unterwegs
> kleiner wird. Die Framerate wird begrenzt durch die maximale Länge des
> Datenpaketes auf seiner Runde, also an der Stelle vom Master an das
> erste Pixel.

Wenn der Zug an Daten kürzer wird, desto schneller kann der Master um N 
"weggelassene" Bytes seine nächste Operation starten -> zum Beispiel den 
nächsten Datenzug starten. Das sollte eigentlich die Rate erhöhen
Das hatte ich versucht in der Excel darzustellen. Desto weniger Bytes 
hinten heraus, desto kürzer die Übertragungszeit zwischen den einzelnen 
Slaves zum Schluss.

: Bearbeitet durch User
von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Ast E. schrieb:
> Tadaaa, wir haben das Protokoll
Schön, die Hardware fände ich interessanter ;-)

Ast E. schrieb:
> Wenn der Zug an Daten kürzer wird, desto schneller kann der Master um N
> "weggelassene" Bytes seine nächste Operation starten -> zum Beispiel den
> nächsten Datenzug starten. Das sollte eigentlich die Rate erhöhen...
Da kann ich jetzt irgendwie nicht folgen, aber ich mache mir um die Rate 
auch nicht allzu große Sorgen.

: Bearbeitet durch User
von Nosnibor (Gast)


Bewertung
lesenswert
nicht lesenswert
Ast E. schrieb:
> Das versuche ich seit zwei Beiträgen mitzuteilen :-)

Entschuldigung, da hatte ich das Wort "dynamisch" mißverstanden.

Konfiguration beim Hochfahren widerstrebt mir noch immer, aber 
wahrscheinlich werde ich kein fertiges Gerät betreiben und deshalb die 
(zugegebenermaßen geringen) Nachteile nicht zu spüren bekommen.

> Wenn der Zug an Daten kürzer wird, desto schneller kann der Master um N
> "weggelassene" Bytes seine nächste Operation starten -> zum Beispiel den
> nächsten Datenzug starten. Das sollte eigentlich die Rate erhöhen
> Das hatte ich versucht in der Excel darzustellen. Desto weniger Bytes
> hinten heraus, desto kürzer die Übertragungszeit zwischen den einzelnen
> Slaves zum Schluss.

Wenn es nur um die Framerate geht, kann der Master den nächsten Datenzug 
sofort (bzw. nach einer Sync-Pause) starten, sobald der vorige 
abgefahren ist. Wieviele Züge da noch im Ring unterwegs sind und ob die 
kürzer werden, ist egal.

Relevant ist das nur für die Reaktionszeit. Da wäre es allerdings gut, 
wenn das Datenpaket auf dem Weg von den Pixeln zurück zum Master schön 
kurz ist, weil der Master möglicherweise alle Touchdaten sehen will, 
bevor er eine Reaktion erzeugt. Viel ist da aber nicht zu holen, fürchte 
ich.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
lesenswert
nicht lesenswert
Nosnibor schrieb:
> Relevant ist das nur für die Reaktionszeit. Da wäre es allerdings gut,
> wenn das Datenpaket auf dem Weg von den Pixeln zurück zum Master schön
> kurz ist, weil der Master möglicherweise alle Touchdaten sehen will,
> bevor er eine Reaktion erzeugt.

Mal eine Frage: Wieviele Finger tatschen da gleichzeitig drauf rum? Lass 
es meinetwegen 10 (von mehreren Personen) sein - und das ist schon 
hochgegriffen. Bei z.B. 100 Pixeln besteht dann die Übertragung der 
Touch-Daten aus 90% leerer Luft. Bei mehr Pixeln wird das Verhältnis 
sogar noch schlechter.

Wenn die die Pixel lediglich Ihre eigene Adressnr. mit Flag "ich wurde 
getatscht" bzw. "ich wurde losgelassen" übertragen, reduziert sich die 
Datenmenge auf weniger als 10%. In der Praxis wird das sogar noch 
erheblich  weniger sein. Die Pixel, bei denen keine Änderung eingetreten 
ist, schicken nur das Zeug im Ring weiter, geben aber sonst keinen 
eigenen Senf dazu.

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Frank M. schrieb:
> Wenn die die Pixel lediglich Ihre eigene Adressnr. mit Flag "ich wurde
> getatscht" bzw. "ich wurde losgelassen" übertragen, reduziert sich die
> Datenmenge auf weniger als 10%.

Um bei deinem Beispiel zu bleiben. Bei Hundert Pixeln bräuchte man 
entweder 100Bit ~ 13Byte oder die 10% also 10 * Adresse+Flag(passt noch 
in ein Byte) = 10Byte. (Bei mehr als 128 Pixeln passt es dann nicht mehr 
in ein Byte)

Unter 80(73) Pixel wäre die Datenmenge sogar größer, wenn die Touchdaten 
von vorne herein der Einfachheit halber im Protokoll vorgehalten wären. 
Darüber fällt die Ersparnis im Verhältnis zu den RGB-Daten meiner 
Meinung nach gering aus.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Um bei deinem Beispiel zu bleiben. Bei Hundert Pixeln bräuchte man
> entweder 100Bit ~ 13Byte

Ich wusste nicht, dass da jeder Touch als einzelnes Bit übertragen 
werden sollte. Ich bin immer davon ausgegangen, dass es sich um 
mindestens 1 Byte pro Pixel handelt, welches evtl. sogar noch auf insg. 
3 Bytes/Pixel "gepadded" wird, s.o.

Werden da tatsächlich nur Bits übertragen, ist mein Vorschlag natürlich 
hinfällig.

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich wusste nicht, dass da jeder Touch als einzelnes Bit übertragen
> werden sollte.
Ob das sicher festgelegt ist, weiß ich auch nicht. Ich finde die Idee 
aber wirklich nicht schlecht.


Ast E. schrieb:
> eine Idee die mir eben kam:
> unter der Annahme, dass jedes Pixel nur ein Bit für Touch 'aktiv' oder
> 'nicht aktiv' kennzeichnen soll, kann man den Header auch soweit
> dynamisch aufbohren...
Muss man natürlich alle von Anfang an übertragen, aber dafür gibt es 
keine zusätzlichen Delays durch späteres Einfügen von Bytes.

Ast E. schrieb:
> Das versuche ich seit zwei Beiträgen mitzuteilen :-)
> Der Header beinhaltet bereits die nötigen Bytes und diese müssen nur von
> den Slaves mit Touchdaten gefüllt werden.
Ich habe hier einfach mal angenommen, dass in einem Byte 8 Touch-Bits 
untergebracht sind.

: Bearbeitet durch User
von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Volker S. schrieb:
> Ast E. schrieb:
>> Das versuche ich seit zwei Beiträgen mitzuteilen :-)
>> Der Header beinhaltet bereits die nötigen Bytes und diese müssen nur von
>> den Slaves mit Touchdaten gefüllt werden.
> Ich habe hier einfach mal angenommen, dass in einem Byte 8 Touch-Bits
> untergebracht sind.

Kleiner Ergänzung noch:
Das Füllen ist sehr einfach. Das Pixel weiß ja seine Position und somit 
sein Bit in seinem Byte. Der Master schickt wohl einfach Nullen. Das 
Setzen für Touch kann dann einfach durch die Addition einer Variablen 
(Wert = 2^Bitposition) zum entsprechenden Byte erfolgen. Kein Touch, 
keine Addition.

von Andreas (Gast)


Bewertung
lesenswert
nicht lesenswert
Warum so kompliziert?
Die Mindestlaufzeit ist von der Datenpaketgröße an dem ersten Pixel 
abhängig - schneller senden kann man einfach nicht.
Alles Andere bringt nur noch zusätzliche Verzögerungen. Von denen hat 
man bereits 1 Byte pro Pixel und eine Bearbeitungs-"Gebühr" zwischen den 
einzelnen Bytes. Am letzten Pixel ist der Abstand zwischen den einzelnen 
Bytes etwas größer geworden ;) Jedes Anhängen und jede Berechnung kann 
zur zusätzlichen Verzögerung beitragen.

Und kompliziertere Vorgehensweisen fordern die Fehler geradezu aus. :)

Also:
1.Byte - Befehl: Durchzählen, Daten, Update, wasweisich
2.Byte - Zähler, am Besten nur eine Byte, bei 16 Bit muss der Übertrag 
berechnet werden --> zusätzliche Verzögerung
3.Byte - Rot1, wird durch Touchbyte ersetzt
4.Byte - Grün1
5.Byte - Blau1
usw.
Die Daten können natürlich auch anders aussehen.

Damit ist es einfach und schnell umzusetzen.

MfG,
Andreas

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Andreas schrieb:
> Warum so kompliziert?
> Die Mindestlaufzeit ist von der Datenpaketgröße an dem ersten Pixel
> abhängig - schneller senden kann man einfach nicht.
> Alles Andere bringt nur noch zusätzliche Verzögerungen. Von denen hat
> man bereits 1 Byte pro Pixel und eine Bearbeitungs-"Gebühr" zwischen den
> einzelnen Bytes. Am letzten Pixel ist der Abstand zwischen den einzelnen
> Bytes etwas größer geworden ;) Jedes Anhängen und jede Berechnung kann
> zur zusätzlichen Verzögerung beitragen.
>
> Und kompliziertere Vorgehensweisen fordern die Fehler geradezu aus. :)
>
> Also:
> 1.Byte - Befehl: Durchzählen, Daten, Update, wasweisich
> 2.Byte - Zähler, am Besten nur eine Byte, bei 16 Bit muss der Übertrag
> berechnet werden --> zusätzliche Verzögerung
> 3.Byte - Rot1, wird durch Touchbyte ersetzt
> 4.Byte - Grün1
> 5.Byte - Blau1
> usw.
> Die Daten können natürlich auch anders aussehen.
>
> Damit ist es einfach und schnell umzusetzen.
>
> MfG,
> Andreas

Ich würde wie beschrieben den Zähler nur einmalig beim Startup 
verwenden. Dadurch gewinnt man bei jeder Übertragung die Anzahl an X 
Bytes für den Zähler, da dieser nicht jedesmal mitgesendet wird (wozu 
auch?)

Die Touch Daten könnten in Dummybytes oder eben in den eh vorhandenen 
RGB Daten verpflanzt werden.

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Ast E. schrieb:
> Ich würde wie beschrieben den Zähler nur einmalig beim Startup
> verwenden. Dadurch gewinnt man bei jeder Übertragung die Anzahl an X
> Bytes für den Zähler, da dieser nicht jedesmal mitgesendet wird (wozu
> auch?)
>
> Die Touch Daten könnten in Dummybytes oder eben in den eh vorhandenen
> RGB Daten verpflanzt werden.

Also ich bin mittlerweile auch für nur einmal durchzählen...

Die Touch Daten würde ich in Dummybytes schreiben ist dann beim weiter 
verarbeiten einfacher und mann muss die Daten nicht so zusammen suchen.

Als nächstes steht dann wohl die Auswahl eins MC für´s Pixel an

Vorgeschlagen war ja schon einer der ATtiny oder ein  STM8S003F3P6

Hier wäre dann nach der Auswahl noch zu klären wie ein gemeinsames 
Programmieren über den Bus realisiert werden kann. Da dies ja stark vom 
verwendeten MC abhängt.

Ich persönlich wäre ja eher für einen ATtiny da ich mich mit den Atmel 
MC besser auskenne.

von Volker S. (vloki)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> Ich persönlich wäre ja eher für einen ATtiny da ich mich mit den Atmel
> MC besser auskenne

Ich wäre natürlich für einen PIC :-)
Eigentlich würde mich aber das Drumherum mehr interessieren...

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
ich hatte mal einen ULN gedacht aber da würden soviele Pins frei 
bleiben, sodass ich nicht Recht weiß wie die LEDs getrieben werden 
sollen
einzelner Transistoren?!

von Sam .. (sam1994)


Angehängte Dateien:

Bewertung
lesenswert
nicht lesenswert
Ich habe vor einer Woche eine Platine bestellt - vor allem um die 
Touch-Empfindlichkeit zu testen. Die Platine kostet mit Bauteilen schon 
weniger als 50cent.
Als Mikrocontroller habe ich den STM8S003 gewählt, da er einfach das 
beste Preis/Leistungs-Verhältnis hat. Ich kenne kaum andere µCs, die 
unter 20cent kommen, außer sehr spartanische. Der SN8P2501B gibt es für 
13cent, aber der hat fast gar nichts an Peripherie. Für die Photodiode 
ist eine Regelschaltung dabei, weil ich sonst die Befürchtung habe, dass 
Erkennung bei starkem Sonnenlicht gar nicht mehr funktioniert. Aber 
schaut es euch einfach selbst an.

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Sam .. schrieb:
> Ich habe vor einer Woche eine Platine bestellt - vor allem um die
> Touch-Empfindlichkeit zu testen. Die Platine kostet mit Bauteilen schon
> weniger als 50cent.

Das ist ja super Sam, wenn die Platine da ist kannst du ja mal von den 
ersten Versuchen berichten ist ja für alle interessant.

Welches Programm hast du zum Layout erstellen benutzt? Mit Eagle ging 
schon mal nicht auf bei mir...
Hast du die Platine bestückt oder umbestückt bestellt?
Und Wo wäre dann natürlich auch noch interessant.

von Sam .. (sam1994)


Bewertung
lesenswert
nicht lesenswert
Peter B. schrieb:
> Welches Programm hast du zum Layout erstellen benutzt? Mit Eagle ging
> schon mal nicht auf bei mir...
KiCad.

> Hast du die Platine bestückt oder umbestückt bestellt?
Unbestückt bei oshpark.com (3 Stück für 4€).

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Sam .. schrieb:
> Ich habe vor einer Woche eine Platine bestellt -

Sehr schön. Dein "Tatendrang" gefällt mir.

Sam .. schrieb:
> Für die Photodiode
> ist eine Regelschaltung dabei, weil ich sonst die Befürchtung habe, dass
> Erkennung bei starkem Sonnenlicht gar nicht mehr funktioniert.

Könntest du dies näher erläutern?
Ich hab den Beitrag nicht finden können. Aber Jemand hatte glaube ich 
eine Photodiode ohne weitere Regelung getestet und dies sah eigentlich 
recht viel versprechend aus

von Sam .. (sam1994)


Bewertung
lesenswert
nicht lesenswert
Ast E. schrieb:
> Aber Jemand hatte glaube ich
> eine Photodiode ohne weitere Regelung getestet und dies sah eigentlich
> recht viel versprechend aus

Bei normalen Lichtverhältnissen mag das gehen. Bei meinen Tests habe ich 
gemerkt, dass durch die IR-Photodiode bis zu 1mA fließen wenn sie im 
Sonnenlicht ist. Die Stromänderung durch Reflektion lag eher bei ~1µA. 
Dazwischen liegen schon 3 Dekaden, d.h. ein 10-Bit-ADC geht schon mal 
nicht. Durch die Regelung verspreche ich mir eine verbesserte 
Empfindlichkeit im Dunklen sowie im Hellen. Die Tests habe ich übrigens 
nicht draußen gemacht. Es war ein heller Sommertag und die Sonne schien 
nur durch das Fenster.

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
mal eine Frage nebenbei: Die Pins des STM8 können doch auch "nur" 20mA 
maximal vertragen oder? Deswegen war die Überlegung generell einen 
Treiber für die LEDs zu verwenden.

Sam .. schrieb:
> Durch die Regelung verspreche ich mir eine verbesserte
> Empfindlichkeit im Dunklen sowie im Hellen. Die Tests habe ich übrigens
> nicht draußen gemacht. Es war ein heller Sommertag und die Sonne schien
> nur durch das Fenster.

ich bin gespannt welches Ergebnis du erzielst

von Ast E. (vis)


Bewertung
lesenswert
nicht lesenswert
Sam .. schrieb:
> Ich habe vor einer Woche eine Platine bestellt

gibt es schon Erkenntnisse? :-)

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Hey Sam gib uns doch mal einen kurzen Zwischenstand zu deinen Tests

von Sam .. (sam1994)


Bewertung
lesenswert
nicht lesenswert
Ich hab die Platine schon länger aufgebaut und getestet. Für mehr hat 
mir irgendwie dann die Zeit gefehlt. Mit kleinen Modifikationen 
funktioniert auch die Regelung, aber sie scheint tatsächlich nicht 
nötig. Die IR-Diode wird bei mir mit 150mA gepulst, was mehrere 100µA 
auf der Photodiode erzeugt. Das größte Problem war eher die Reflexion 
durch die Glasplatte. Die Erkennung einer weiteren Reflexion wird 
dadurch ein gutes Stück erschwert.

Ich könnte mir vorstellen, dass evtl ein niederohmiger Widerstand 
(~5kOhm) für die Erkennung ausreicht. Bei 5kOhm sollte auch genügend 
Reserve bei Sonnenlicht vorhanden sein. Da wird man aber wohl kaum um 
Messungen herumkommen. Gescheite Daten über die Photodioden bekommt man 
von den Chinesen ja nicht.
Auf der anderen Seite könnte man auch noch mit dem IR-Dioden Strom etwas 
nach oben gehen.

Ast E. schrieb:
> Die Pins des STM8 können doch auch "nur" 20mA
> maximal vertragen oder? Deswegen war die Überlegung generell einen
> Treiber für die LEDs zu verwenden.

Mehr als 20mA Dauerstrom würde ich auch nicht auf die Leds geben. Bei 
der Platine hab ich sie eher auf 15mA dimensioniert.

von Peter B. (shaphard)


Bewertung
lesenswert
nicht lesenswert
Sam das sind ja schon mal gute Erkenntnisse. Gut das du dafür schon mal 
Zeit hattest.

Noch ein paar kurze fragen:

Wie groß war der Abstand von Photodiode zum Glas?
Was für eine Lichtdurchlässigkeit hatte das Glas?
Macht die Leuchtend Pixel LED einen Unterschied bei der Erkennung?

so und noch zwei Fragen zu dem was vermutlich noch nich passiert ist:

Die auswerte Daten hast du noch nicht über UART abgeholt?
hast du nur 1 Pixel getestet oder auch schon mehrere im Verbund?

evtl. könntest du ja mal ein Foto machen.

Danke

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.