Hey, Ich hab mir vor einiger Zeit ein Paar ATtiny85 zugelegt. Nun möchte ich diese als Daten weiche verwenden. Ich möchte den ATtiny verwenden um bspw. an PB0 einen Dateneingang von einem LED Controller zu haben (Wahrscheinlich wird das in dem Fall WLED sein). Dann würde ich den ATtiny gerne verwenden um diese Daten aufzusplitten und bspw. die Daten (24Bit pro LED) für die ersten 3 LEDs an PB1 leiten und die restlichen 3 an PB2. Mein Problem ist nun das ich noch nicht wirklich einen passenden Ansatz gefunden habe um das ganze umzusetzen. Ich habe mich jetzt mal in Timer und Interrupts eingelesen, aber habe nicht das Gefühl dass ich damit weiter komme... Hat jemand eine Idee oder ein ähnliches Projekt schonmal gehabt LG
Lennart schrieb: > WLED Das ist doch OpenSource, dort zwei Ausgänge einzubauen und die Daten aufzuteilen dürfte viel einfacher sein als die Daten einzulesen, aufzuteilen und wieder rauszusenden. PS: WLED kann bis zu 10 Ausgänge - wozu noch aufteilen?
:
Bearbeitet durch User
Lennart schrieb: > Ich möchte den ATtiny verwenden um bspw. an PB0 einen Dateneingang von > einem LED Controller zu haben (Wahrscheinlich wird das in dem Fall WLED > sein). Dann würde ich den ATtiny gerne verwenden um diese Daten > aufzusplitten und bspw. die Daten (24Bit pro LED) für die ersten 3 LEDs > an PB1 leiten und die restlichen 3 an PB2. Wozu soll das denn gut sein? Warum nicht einfach die 6 LEDs als eine Kette verschalten? > Mein Problem ist nun das ich noch nicht wirklich einen passenden Ansatz > gefunden habe um das ganze umzusetzen. Der Tiny müsste dazu das WS28xx-Protokoll "verstehen". Nur so kann er die korrekten Zeitpunkte zum Umschalten der Weiche ermitteln. Der Rest wäre hingegen relativ simpel: so rausschreiben, wie es reinkommt, mal dahin und mal dorthin, je nach aktueller Weichenstellung. Wenn der Tiny sonst nichts zu tun hat, ist die Sache recht simpel zu lösen. C oder Assembler ist hier weitgehend egal, in beiden Fällen werden das schätzungsweise so 20..30 Zeilen Code. > Ich habe mich jetzt mal in Timer > und Interrupts eingelesen Interrupts brauchst du hier nicht, weil der Tiny ja sonst nix zu tun hat. Einen Timer schon, als Referenz zur Zeitmessung. Die brauchst du, um das Resetsignal zu finden. Damit synchronisierst du deine Weiche mit dem Datenstrom der Quelle. Start: Bei Erkennung des Reset schaltest du auf Weichenstellung eins. Ab hier: Eingangssignal zum Ausgang 1 kopieren und dabei High-Pulse zählen. Hast du 96 davon gezählt, umschalten auf Weichenstellung zwei. Ab hier: Eingangssignal zum Ausgang 2 kopieren und nebenbei die Länge der Low-Phasen des Signals messen, bis du wieder auf einen Reset triffst. Hast du einen: GOTO Start.
Angehängte Dateien:
-
Bild_2024-05-31_172742689.png
230 KB -
Bild_2024-05-31_175325415.png
230 KB
Niklas G. schrieb : > PS: WLED kann bis zu 10 Ausgänge - wozu noch aufteilen? Da ich gerne ein Nanoleaf-Lines ähnliche LED Struktur bauen würde und wenn man 2 Streifen an einen Datenkanal anschließt diese sich sonst Spiegeln.. Hier noch ein Bild zur Veranschaulichung
Ob S. schrieb: > Wozu soll das denn gut sein? Warum nicht einfach die 6 LEDs als eine > Kette verschalten? Ich möchte eine Nanoleaf-Lines ähnliche LED Struktur und wenn ich an einem Knoten-Punkt 2 LED Streifen anschließe, diese sich dann spiegeln. Habe es anfänglich nicht wirklich gut erklärt > Der Tiny müsste dazu das WS28xx-Protokoll "verstehen". Klar, das WS28xx-Protokoll lässt sich mit bloßem Auge auslesen, die Logik hinterm Programmieren ist auch nicht das Problem. > Wenn der Tiny sonst nichts zu tun hat, ist die Sache recht simpel zu > lösen. C oder Assembler ist hier weitgehend egal, in beiden Fällen > werden das schätzungsweise so 20..30 Zeilen Code. Das Problem ist das ich das Timing bis jetzt nicht hinbekomme. Ich habe auch mit Portmanipulation eine viel zu hohe Reaktionszeit, wodurch die daten nicht richtig ausgelesen werden können. > Start: > Bei Erkennung des Reset schaltest du auf Weichenstellung eins. Ab hier: > Eingangssignal zum Ausgang 1 kopieren und dabei High-Pulse zählen. Hast > du 96 davon gezählt, umschalten auf Weichenstellung zwei. Ab hier: > Eingangssignal zum Ausgang 2 kopieren und nebenbei die Länge der > Low-Phasen des Signals messen, bis du wieder auf einen Reset triffst. > Hast du einen: GOTO Start. Okay danke, das ist ein Anfang nachdem das auslesen von den Quell Daten erfolgreich ist..
:
Bearbeitet durch User
Sowas in der Art hat hier (?) schon mal jemand realisiert - allerdings mit einem Pico Pi. (würde ich wissen, wo ich das gelesen habe, würde ich den Link posten). Es ging darum, selber einen Decoder zu bauen, der einerseits LEDs ansteuert, andererseit den Datenstream weiterleitet. Dein Tiny wird dafür einfach zu langsam sein.
Ich kann mir vorstellen das es mit den low cost WCH Controllern auch geht. Sowas müsste in den T-Stücken der Lichtvorhänge mit adressierbaren LED drin sein, die zweigen auch die Daten für die vertikalen Ketten ab.
Lennart schrieb: > Okay danke, das ist ein Anfang nachdem das auslesen von den Quell Daten > erfolgreich ist.. Ja, das ist tatsächlich eng, selbst bei den 16MHz, die ein Tiny85 dank PLL kann. Aber noch machbar. Abfrage mit Verzweigung kostet 3 Takte, also wird mit ca. 5,3Mhz gesampelt, der Jitter liegt also bei 190ns. Reicht normalerweise. Wenn allerdings auch die Quelle schon das WS28xx-Timing bis an die Grenzen der Spec ausreizt, dann könnte es durchaus auch daneben gehen.
Ob S. schrieb: > der Jitter liegt also bei 190ns Wird das durch gereichte Signal dann auch so stark verzerrt?
Ob S. schrieb: > Aber noch machbar. Abfrage mit Verzweigung kostet 3 Takte, also wird mit > ca. 5,3Mhz gesampelt, der Jitter liegt also bei 190ns. Reicht > normalerweise. Wenn allerdings auch die Quelle schon das WS28xx-Timing > bis an die Grenzen der Spec ausreizt, dann könnte es durchaus auch > daneben gehen. Wenn ich die Quelle "Langsamer" mache müsste das machbar sein oder ?
Beitrag #7675738 wurde vom Autor gelöscht.
Lennart schrieb: > Wenn ich die Quelle "Langsamer" mache müsste das machbar sein oder ? Die Übertragungsrate ist durch die LEDs festgelegt, die kannst du nicht ändern.
Steve van de Grens schrieb: > Die Übertragungsrate ist durch die LEDs festgelegt, die kannst du nicht > ändern. Klar, aber wenn ich die Daten eh auslesen muss kann ich auch die Quelle langsamer machen und damit Resourcen sparen.. Ein Tiny müsste somit nur 50 LEDS auf 5 Ports verteilen und danach die übrigen verlangsamten Quell daten an einen andern "Kotenpunkt" weiterleiten
Lennart schrieb: > Klar, aber wenn ich die Daten eh auslesen muss kann ich auch die Quelle > langsamer machen und damit Resourcen sparen.. > > Ein Tiny müsste somit nur 50 LEDS auf 5 Ports verteilen und danach die > übrigen verlangsamten Quell daten an einen andern "Kotenpunkt" > weiterleiten Super Idee! Wenn du die LEDs an der Stelle nur "kopieren" / verfielfältigen willst, solltest du mal ausprobieren, ob du nicht einfach die DIN-Leitungen der Stränge "zusammenlötest".
Also ich hab jetzt mal den WLED Controller (also die Quelle) runter auf 400khz. Damit sollte es für den Tiny möglich sein die Daten auszulesen, zwischenzeitig zu Speicher, an die LEDs zu verteilen und am ende die überbleibenden Daten weiterzuleiten... Jetzt schonmal ein danke für eure Hilfe, ich melde mich sobald ich fortschritte gemacht habe und wenn nicht frag ich einfach wieder in die Runde.
Steve van de Grens schrieb: > Ob S. schrieb: >> der Jitter liegt also bei 190ns > > Wird das durch gereichte Signal dann auch so stark verzerrt? Im ungünstigsten Fall: ja klar. Aber mir ist noch was eingefallen: Der Tiny85 hat ja eine recht großzügige Menge Flash, die man nutzen kann. Man muss also nicht unbedingt per Schleife pollen, sondern kann Abfragekaskaden bauen. Damit steigt die effektive Samplefrequenz auf 8MHz, der Jitter fällt entsprechend auf 125ns. Schon deutlich besser. Und dann kann man noch etwas mit OSCCAL spielen, so bis ca. 10Mhz Samplefrequenz sollte man damit kommen können. 100ns.
Steve van de Grens schrieb: > Lennart schrieb: >> Wenn ich die Quelle "Langsamer" mache müsste das machbar sein oder ? > > Die Übertragungsrate ist durch die LEDs festgelegt, die kannst du nicht > ändern. Doch, die Dauer der Low-Phasen kann man schon recht deutlich gegenüber der Herstellervorgabe erhöhen und damit die Übertragungsrate erheblich absenken. Nützt nur nix, das eigentliche Signal steckt ja in den unterschiedlichen Zeiten der High-Phasen und der Unterschied zwischen den beiden ist nicht sehr groß. Der Spielraum, der für ungewollte Verkürzungen/Verlängerungen durch den Jitter der Abtastung bleibt, ist also recht gering.
Ob S. schrieb: > Aber mir ist noch was eingefallen: Der Tiny85 hat ja eine recht > großzügige Menge Flash, die man nutzen kann. Man muss also nicht > unbedingt per Schleife pollen, sondern kann Abfragekaskaden bauen. Damit > steigt die effektive Samplefrequenz auf 8MHz, der Jitter fällt > entsprechend auf 125ns. Schon deutlich besser. Und dann kann man noch > etwas mit OSCCAL spielen, so bis ca. 10Mhz Samplefrequenz sollte man > damit kommen können. 100ns. Was genau meinst du mit Abfragekaskaden ? 100ns hören sich ja schonmal super an. Möglicherweise könnte ich ein "Plugin" in WLED programmieren womit ich die Quelldaten dann mit meinem gewünschtem Timing erhalten kann. Aber das will ich möglichst vermeiden..
Ob S. schrieb: > Nützt nur nix, das eigentliche Signal steckt ja in den unterschiedlichen > Zeiten der High-Phasen und der Unterschied zwischen den beiden ist nicht > sehr groß. Der Spielraum, der für ungewollte Verkürzungen/Verlängerungen > durch den Jitter der Abtastung bleibt, ist also recht gering. Stimmt, daran hab ich nicht wirklich gedacht...
Ein alternativer Ansatz: In jedem Gerät/Teil/Leaf/Node/Whatever steckt ein eigener µC, der sich um die in seinem Gerät befindlichen LEDs kümmert, d.h. auf dem WLED o.ä. läuft. Alle diese µCs wiederum sind über einen (unidirektionalen) Datenbus mit einem zentralen µC verbunden, der mit einem einfach zu decodierenden Protokoll den angeschlossenen Geräten/Teilen/Leaves/Nodes/Whatevers mitteile, was sie anzuzeigen haben. Dieses einfach zu decodierende Protokoll kann eine stinknormale UART-Übertragung sein, dann ist nämlich nur eine Datenleitung nötig. Die Geräten/Teilen/Leaves/Nodes/Whatevers müssen dafür halt eindeutig adressierbar sein. Wenn die alle in Reihe geschaltet werden, könnte man natürlich auch eine Art Daisy-Chain-Protokoll verewnden, bei dem nicht alle Geräten/Teilen/Leaves/Nodes/Whatevers an einer Datenleitung hängen, sondern jeweils der Eingang eines Geräten/Teilen/Leaves/Nodes/Whatevers am Ausgang des vorangehenden Geräten/Teilen/Leaves/Nodes/Whatevers hängt. Das Telegramm, das der zentrale Steuerer verschickt, muss dann so konzipiert sein, daß sein Beginn immer eindeutig erkennbar ist, jedes Gerät/Teil/Leaf/Node/Whatever entfernt einen Teil des Telegramms als seine Steuerinformationen und reicht den Rest weiter. So machens die WS2812-LEDs ja auch, nur daß deren serielles Protokoll extrem schlecht mit einem µC decodiert werden kann.
Lennart schrieb: > Was genau meinst du mit Abfragekaskaden ? 100ns hören sich ja schonmal > super an. Ein Beispiel für sowas kannst du dir in den Quelltexten von V-USB anschauen. Die benutzen denselben Trick, um sich möglichst schnell und exakt auf das USB-Signal zu synchronisieren. Trotz der nominell höheren Frequenz (USB low speed: 1,5Mhz, WS28xx: 800kHz) ist WS28xx deutlich kritischer. Bei USB genügt es, sich einmal zu synchronisieren, um ein ganzes Datenpaket ohne weitere Verfolgung des Taktes empfangen zu können, bei WS28xx leider i.d.R. nicht. Das liegt daran, dass diese Signale oft mit mehr oder weniger ungeeigneten Methoden erzeugt werden. Diese genügen zwar den Anforderungen, die die WS28xx-Controller stellen, machen aber ein Sampling schwierig. Wenn schon die Quelle die Toleranzen der Specs fast ausnutzt, wird es schwierig bis unmöglich. Da hilft dann leider nur ein höherer Takt, um höhere Samplingraten zu erreichen. Das von dir benutzte WLED kenne ich nicht, deswegen kann ich die Qualität der damit erzeugten Signale nicht einschätzen.
Harald K. schrieb: > In jedem Gerät/Teil/Leaf/Node/Whatever steckt ein eigener µC, der sich > um die in seinem Gerät befindlichen LEDs kümmert, d.h. auf dem WLED o.ä. > läuft. > > Alle diese µCs wiederum sind über einen (unidirektionalen) Datenbus mit > einem zentralen µC verbunden, der mit einem /einfach zu decodierenden/ > Protokoll den angeschlossenen Geräten/Teilen/Leaves/Nodes/Whatevers > mitteile, was sie anzuzeigen haben. Jepp, das wäre ein sehr viel sinnvollerer Ansatz.
Ob S. schrieb: > Ein Beispiel für sowas kannst du dir in den Quelltexten von V-USB > anschauen. Die benutzen denselben Trick, um sich möglichst schnell und > exakt auf das USB-Signal zu synchronisieren. Das wär auch noch eine recht einfach umsetzbare Lösung. > Das von dir benutzte WLED kenne ich nicht, deswegen kann ich die > Qualität der damit erzeugten Signale nicht einschätzen. WLED hat ein sehr genaues Timing, das sollte keine Probleme darstellen. Ich werde es mal so ausprobieren.
Harald K. schrieb: > Alle diese µCs wiederum sind über einen (unidirektionalen) Datenbus mit > einem zentralen µC verbunden, der mit einem /einfach zu decodierenden/ > Protokoll den angeschlossenen Geräten/Teilen/Leaves/Nodes/Whatevers > mitteile, was sie anzuzeigen haben. Dieses /einfach zu decodierende/ > Protokoll kann eine stinknormale UART-Übertragung sein, dann ist nämlich > nur eine Datenleitung nötig. > > Die Geräten/Teilen/Leaves/Nodes/Whatevers müssen dafür halt eindeutig > adressierbar sein. > > Wenn die alle in Reihe geschaltet werden, könnte man natürlich auch eine > Art Daisy-Chain-Protokoll verewnden, bei dem nicht alle > Geräten/Teilen/Leaves/Nodes/Whatevers an einer Datenleitung hängen, > sondern jeweils der Eingang eines Geräten/Teilen/Leaves/Nodes/Whatevers > am Ausgang des vorangehenden Geräten/Teilen/Leaves/Nodes/Whatevers > hängt. Das war auch der Anfangsplan aber lässt sich ja wie du erwähnt hast gut in das UART Protokoll umwandeln. > Das Telegramm, das der zentrale Steuerer verschickt, muss dann so > konzipiert sein, daß sein Beginn immer eindeutig erkennbar ist, jedes > Gerät/Teil/Leaf/Node/Whatever entfernt einen Teil des Telegramms als > seine Steuerinformationen und reicht den Rest weiter. Das ist ein sehr guter Ansatz.. Ich schau mal was ich programmiert bekomm mit meinem Wissen.
:
Bearbeitet durch User
Lennart schrieb: > Das war auch der Anfangsplan aber lässt sich ja wie du erwähnt hast gut > in das UART Protokoll umwandeln. Nunja, der Tiny85 hat leider keine UART und auch keinen Takt, der hinreichend genau für den zuverlässigen Betrieb einer UART wäre. Wennschon, liefe das auf SPI oder I2C hinaus und als einzig brauchbare Hardwareunterstützung für beides käme nur das USI in Frage.
Ob S. schrieb: > Nunja, der Tiny85 hat leider keine UART und auch keinen Takt, der > hinreichend genau für den zuverlässigen Betrieb einer UART wäre. Hmm, okay heißt wenn ich einen Tiny85 verwende muss ich die Taktrate von der Quelle runter bekommen... Ich hab mich nochmal etwas umgesehen, bin mir aber nicht sicher ob die stm32f0 (tm32f030c8t6) Serie sinn macht.. Diese wären billiger und haben (wenn ichs richtig gelesen habe) eine Taktrate von 48Mhz Einen St-Link zum Programmieren habe ich schon. Gibt es bei diesen Controllern etwas spezielles zu beachten ? Bestimmte Programmiersprachen oder Einschränkungen ?
:
Bearbeitet durch User
Lennart schrieb: > Mein Problem ist nun das ich noch nicht wirklich einen passenden Ansatz > gefunden habe um das ganze umzusetzen. Ich habe mich jetzt mal in Timer > und Interrupts eingelesen, aber habe nicht das Gefühl dass ich damit > weiter komme... Hast Du mal ins Datenblatt geschaut? Die Pulse dürfen eine Toleranz von max 150ns haben, das sind bei 16MHz gerade mal 2 CPU-Zyklen. Vergiß es. Ein µC jenseits der 200..300MHz schafft es vielleicht in handoptimiertem Assembler.
Wie schnell folgen denn die einzelnen Telegramme aufeinander? Das heißt, wie lang ist der Reset Puls? Wenn das lange genug ist, kann man vielleicht erst mal nur die Daten einlesen und dann zeitunkritisch verarbeiten und wieder neu an die beiden Stränge aussenden.
Der Resetpuls von ws2812x variiert immer je nach wie viele LEDs angesteuert werden.. Wenn ich Zeit hab kann ich mal einen ungefähren Zeitwert nennen
Peter D. schrieb: > Hast Du mal ins Datenblatt geschaut? > Die Pulse dürfen eine Toleranz von max 150ns haben, das sind bei 16MHz > gerade mal 2 CPU-Zyklen. Ja. Und zufällig braucht das Codekonstrukt, was man zur Abfrage eines Pegelwechsels benötigt, auch gerade zwei Takte. > Ein µC jenseits der 200..300MHz schafft es vielleicht in handoptimiertem > Assembler. Nö, bei 200MHz braucht man sicher keinen handoptimierten Assemblercode mehr. Bei 16 bis knapp unter 20MHz, die mit einem Tiny85 möglich sind, hingegen natürlich. Daran bestand von Anfang an keinerlei Zweifel. Inzwischen ist mir übrigens auch noch klar geworden, dass genug Rechenzeit und Flash da ist, damit sich der Code selbst zur Laufzeit bezüglich des Timing optimieren kann. Das Timing des Senders muss nur halbwegs konstant sein. Wenn die Pulslängen schon senderseitig über die gesamte Breite des Toleranzfelds wackeln, dann klappt es nicht. Und natürlich: Mindestens das erste Paket wird die LEDs nicht erreichen. Das wird zum "Kalibrieren" gebraucht. Eventuell noch weitere, so lange nämlich nur Lowbits oder nur Highbits im Paket vorkommen, funktioniert die Kalibrierung nicht und merkt das selber auch.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.