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
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
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.
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
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...
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.
> 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.
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
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...
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
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
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.
@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.
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
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
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...
Experte schrieb: > Die Idee ist vielleicht Murks, Ist sie, zumindest in dieser Situation. Karol Babiochs Versuche haben kein Übersprechen zwischen Pixel-Zellen ergeben.
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.
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
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
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
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.
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
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. :-)
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 :-(
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.
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? ;-)
okay dann kann der Thread auch gelöscht werden oder so... ich mach mein eigenes Ding ;-) :-P
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...
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 :-(
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.. ;-)
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
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...
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 :-)
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.
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
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.
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?
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
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.
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
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
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.
Kann so eine platine herstellen. 8 io Pins. Zwei sind für Kommunikation reserviert. VerWendung: IR beacon. Charliplex 6way borg led oder rgb led
...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.
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 :-)
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.
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.
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
Hier mal ein Schaltplan zur Diskussionsgrundlage. Es sind hier mehrere Bestueckungsmöglichkeiten vorhanden, ohne Transistoren, ohne current limiters, ... .
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?!
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
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.
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.
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.
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?
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
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
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...
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?
Nein. RGB LEDs, bedrahtet, ohne gemeinsame Anode/Katode sind sehr speziell und somit teuer. Du wirst Dein Design ändern müssen oder SMD verwenden.
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
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
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?
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.
...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.
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 :-)
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
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
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.
Wäre es möglich, dazu auch die Schaltpläne und Layouts zu posten? Danke Christian
@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 ;-)
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)
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.
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...
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...
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
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?
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.
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.
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.
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?
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
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.
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...
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
Ich sehe das so wie Samuel Kleiser. Der hat das doch super vorgerechnet.
Chris F. schrieb: > Ich sehe das so wie Samuel Kleiser. Der hat das doch super > vorgerechnet. Was genau meinst du? (kann gerade nicht folgen ;-)
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
Sehe ich so ähnlich wie Du, Volker. Ich würde aber gerne noch wissen was daraus geworden ist. ;-)
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...
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)
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.
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
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
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
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?
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
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?
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
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
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).
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.
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
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.
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.
@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.
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
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...
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).
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....
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
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.
Ja Sam da hast du recht, hätte vielleicht noch 5 Min nachdenken sollen vorm Posten ;-)
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
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?
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.
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
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.
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
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
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.
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.
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.
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
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.
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
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.
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
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
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
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.
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.
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
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
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
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.
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.
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.
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...
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?
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
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
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?
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
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.
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.
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.
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...
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
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.
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.
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
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
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.
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?
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.
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?
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.
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
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? :)
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 ;-)
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
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
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.
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.
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.
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.
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
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.
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
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.
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.
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...
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?!
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.
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.
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€).
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
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.
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
Hey Sam gib uns doch mal einen kurzen Zwischenstand zu deinen Tests
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.
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.