Hallöchen, ich suche einen Chip, der Bits parallel einlesen, zwischenspeichern und seriell ausgeben kann und dabei ein genaues Timing einhält. Ein Bit hat dabei eine genau definierte Zeitspanne, wobei die Einschaltdauer der Leitung den Zustand angibt. Wer zu faul zum Lesen ist, kann nach dem folgenden Abschnitt fortfahren. <tl:dr> Konkret soll jedes Bit 1250ns lang sein. Wenn die Leitung 250ns lang ein- und die restlichen 1000ns ausgeschaltet ist, wird das Signal als "0" gewertet. Ist die Leitung 600ns ein- und 650ns ausgeschaltet, wird es als "1" gewertet. Die Toleranz beträgt 75ns. Vielleicht hat schon der eine oder andere gemerkt, dass es sich um das Protokoll der WS2811-Chips geht. Es gibt natürlich bereits eine Lösung, indem ein Arduino (bzw. AVR) so programmiert wird, dass er die Bits dem Timing entsprechend ausgibt. Bei 16 MHz Taktfrequenz dauert die Übertragung eines einzelnen Bits also 20 Takte. Herzlichen Glückwunsch! Habe selten so ein effizientes System gesehen! Meiner Meinung nach ist dieser Ansatz der letzte Dreck. 20 Takte pro Bit, also wirklich! Das Protokoll erlaubt eine Übertragung von 1024x24 Bit 30 mal pro Sekunde, ich kann also 1024 LEDs mit 30 FPS ansteuern. Nehmen wir an, wir hätten 1024 LEDs und fahren volle 30 FPS. Der Arduino wäre also während einer Sekunde 1024*24*30 = 921.600.000ns = 0,922 Sekunden ausschließlich damit beschäftigt, Bits auszugeben. Mein Ansatz ist folgender: Die Bits parallel über einen Port ausgeben. Es können 8 Bits in einem Takt statt 1 Bit in 20 Takten ausgegeben werden. Theoretische Geschwindigkeitssteigerung um das 160-fache. Natürlich kommen noch ein paar wenige Takte zum Adressieren etc. hinzu. Die Bytes werden in einem FIFO-Speicher abgelegt. Der Mikrocontroller kann nun alle Farbwerte für ein Frame innerhalb kürzester Zeit rausrotzen und sich dann auf andere Dinge (Die Berechnung des nächsten Frames) konzentrieren, während das Timing extern geregelt wird. </tl:dr> Ich habe bereits einen FIFO-Chip gefunden, der die Daten seriell ausgibt. Leider kann man dort scheinbar kein Timing für die Ausgabe oder ähnliches einstellen. Wie könnte man das Problem am geschicktesten lösen? Mit nem FPGA wird es sicherlich gehen, aber vielleicht kennt jemand etwas einfacheres?
Und was hinder dich daran, eben genau dafür einen eigenen kleinen uC einzusetzen?
Oder gleich SPI verwenden, bei 3.2Mbit/sec werden die 800khz erreicht.
Marlon S. schrieb: > Suche Mikrochip für serielles Bit-Timing > [...] > Protokoll der WS2811-Chips Microchip hat den PIC16F1509 und eine schöne Appnote dazu. Da geht das senden eines Bytes mehr oder weniger komplett in Hardware: http://ww1.microchip.com/downloads/en/AppNotes/00001606A.pdf
:
Bearbeitet durch User
> Der Mikrocontroller kann nun alle Farbwerte für ein Frame innerhalb > kürzester Zeit rausrotzen und sich dann auf andere Dinge konzentrieren Der Microcontroller? Genau deswegen besteht ein Microcontroler aus Prozessor und eigenständig laufender Peripherie. Und wenn das SPI Modul deines Controllers dafür nicht geeignet ist, nimm halt einen anderen.
Nobby Nic schrieb: > Und was hinder dich daran, eben genau dafür einen eigenen kleinen uC > einzusetzen? Ich stelle es mir schwierig vor, die Daten mit einem 2. µC rechtzeitig alle abzuspeichern und wieder im richtigen Timing auszugeben. 92% der Zykluszeit werden nämlich bereits durch die Ausgabe belegt. Dazu kommt, dass eine Kommunikation mit dem Haupt-µC notwendig ist, damit die Daten zwischen ihnen sicher übertragen werden. Ne Möglichkeit wäre natürlich noch ein FIFO-Buffer mit mind. 3 kByte zwischen den beiden. Wäre das eine gute Idee?
Marlon S. schrieb: > 92% der > Zykluszeit werden nämlich bereits durch die Ausgabe belegt. Dann hast du den falschen µC. Mit der oben verlinkten Appnote braucht die Ausgabe des Bytes nur so viel Rechenzeit wie du brauchst das Byte in das SSP1BUF Register zu schreiben. Wenn man das Byte über einen 8bit Bus einliest, könnte man das in einer PIN-Interrupt (Enable Signal) in <15 Befehlszyklen erledigen.
:
Bearbeitet durch User
Marlon S. schrieb: > Ich stelle es mir schwierig vor, die Daten mit einem 2. µC rechtzeitig > alle abzuspeichern und wieder im richtigen Timing auszugeben. Obiges Bitmuster läßt sich leicht über SPI oder Timer realisieren. Zumindest letzteres hat m.W. jeder uC an Bord. In der arbeitslosen Zeit dazwischen kannst Du ja noch Fraktale berechnen lassen oder so...
Marlon S. schrieb: > Der Arduino > wäre also während einer Sekunde 1024*24*30 = 921.600.000ns = 0,922 > Sekunden ausschließlich damit beschäftigt, Bits auszugeben. Nimm einen Arduino, der mit 84MHz Takt läuft. Dann hast du genug Takte frei für andere Aufgaben.
Marlon S. schrieb: > Bei > 16 MHz Taktfrequenz Mach dir deine eigene Platine, schmeiß n AVR 1284P mit einem 20MHz quarz rauf, lass den Arduino scheiß weg, und programmier es selbst. Oder nimm n stm32F4-discovery-Board (cortex-m4, 168MHz) für 15€ und freu dich, dass dein mC mehr mit daumendrehen beschäftigt ist, als mit sonst irgend was...
Das WS8211 Protokoll liest sich aber ein bisschen anders als das Timing des TE. Nichtsdestotrotz muß ich mir mal bei der nächsten Bestellung den PIC mit den CLCs zulegen. Vielleicht fällt mir mal eine Anwendung dafür ein.
Noch ne Anmerkung zu den PRUs: However, the TI AM335x ARM Cortex-A8 in the BeagleBone Black has two programmable "microcontrollers" built into the CPU that can handle realtime tasks and also access the ARM's memory. This allows things that might have been delegated to external devices to be handled without any additional hardware, and without the overhead of clocking data out the USB port. BTW: 2x200MHz MCUs - wie gemacht für solche Zwecke ...
Vielleicht einfach mal nachschauen wie Andere das Problem gelöst haben? http://www.mikrocontroller.net/articles/WS2812_Ansteuerung
Danke für die Antworten! Das mit dem BeagleBone Black hört sich ja mal richtig gut an! Den könnte ich dann auch gleich für die ganzen anderen Aufgaben verwenden. Die Farben der WS2812-LEDs sollen nämlich von Audio-Signalen, Lüfterdrehzahlen, Temperaturen und/oder auch anderen Events abhängig sein. Zudem sollen auch vordefinierte Animationen auf einigen LEDs laufen. Ursprünglich wollte ich die Daten vom Raspberry Pi an den Arduino weiterleiten, damit der seine Berechnung macht und dann das Signal über noch mehr aufwändige Schaltungen ausgibt. Der Raspberry Pi sollte das Hauptsystem darstellen (Datenbank, Webserver, Bildausgabe, Relais-Steuerung etc.) und der Arduino sich um die Beleuchtung kümmern. Jetzt hätte ich doch eigentlich alles in einem, oder? Hauptrechner mit Netzwerkanschluss, HDMI und USB, Messung von Daten, deren schnelle Aufzeichnung und Verarbeitung und gleichzeitige Realtime-Ausgabe des WS281x-Signals über die PRUs.
cpld nehmen, z.B. XC9572XL oder XC9536XL. Gibts beide für wenig Geld bei Reichelt. Takt kann man von nem AVR nehmen, am besten einen mit OSCOUT nehmen.
Marlon S. schrieb: > Ursprünglich wollte ich die Daten vom Raspberry Pi an den Arduino > weiterleiten, damit der seine Berechnung macht und dann das Signal über > noch mehr aufwändige Schaltungen ausgibt. Der Raspberry Pi sollte das > Hauptsystem darstellen (Datenbank, Webserver, Bildausgabe, > Relais-Steuerung etc.) und der Arduino sich um die Beleuchtung kümmern. > Jetzt hätte ich doch eigentlich alles in einem, oder? > Hauptrechner mit Netzwerkanschluss, HDMI und USB, Messung von Daten, > deren schnelle Aufzeichnung und Verarbeitung und gleichzeitige > Realtime-Ausgabe des WS281x-Signals über die PRUs. Kannst auch den UDOO nehmen: dual oder quadcore mit 1GHz und ein arduino due zusammen auf einer platine, und nur minimal größer als der raspi. Und kompatibilität zu den arduino-shields ist auch gegeben, falls du es brauchst. http://www.udoo.org/
der RPI hat meines Wissens auch ein DMA auf einen IO-Port dort sollte man auch ein genaues Timing hinbekommen.
Marlon S. schrieb: > ich suche einen Chip, der Bits parallel einlesen, zwischenspeichern und > seriell ausgeben kann und dabei ein genaues Timing einhält. Nein, suchst du nicht. Du willst einfach bloß mal richtig programmieren lernen. Das ist halt verdammt nochmal was anderes, als den Code anderer Leute per Copy&Paste zu importieren. > Konkret soll jedes Bit 1250ns lang sein. Eine kleine Ewigkeit also. > Wenn die Leitung 250ns lang > ein- und die restlichen 1000ns ausgeschaltet ist, wird das Signal als > "0" gewertet. Ist die Leitung 600ns ein- und 650ns ausgeschaltet, wird > es als "1" gewertet. Die Toleranz beträgt 75ns. Häh? Was ist denn das für eine bescheuerte Definition eines Timings? Das ist doch sicher nicht das, was im Datenblatt steht, sondern nur das, was du davon zu verstehen geglaubt hast, oder? Aber tun wir einfach mal so, als wüßtest du, wovon du redest: Dann wäre also die Aufgabe, ein Signal zu erzeugen, welches alle 1250ns toggelt und zusätzlich in der Zwischenzeit entweder irgendwo zwischen 175 und 325ns oder 525ns und 675ns. Bei 16MHz dauert in Tick 62,5ns. Also teilen wir einfach mal die Optimalzeiten dadurch: 1250/62.5=20 ;oops, ganze Zahl, Zykluszeit also schonmal exakt erreichbar 250/62.5=4 ;und schon wieder eine ganze Zahl 600/62.5=9.6 ;naja, mit 10 kommen wir auf 625ns, das ist weit innerhalb ;der angegebenen Toleranz Es besteht also eigentlich die Aufgabe, ein PWM-Signal mit 1250ns Zykluszeit und einem Duty-Factor von entweder 1:4 oder 1:1 abzusondern. Kinderkacke. Jeder AVR hat mindestens zwei Hardwarefeatures, die dafür in Frage kommen aus der Auswahl folgender vier: 1) Timer (FastPWM) 2) USART (im SPI-Mode) 3) SPI 4) USI Am effizientesten wäre es mit einer USART im SPI-Mode hinzubekommen. Die kann nicht nur das oben umrissende Timing exakt reproduzieren, sondern ist obendrein DoubleBuffered, was die Anforderungen an die Exaktheit des Timings der Datenzuführung soweit senkt, daß es auch in C für einen halbwegs fähigen Programmierer kein Problem mehr sein sollte. Aber leider bist du wohl keiner, sondern nur Copy&Paster... Nunja, richtige Programmierer jedenfalls rattern das in ein bis zwei Stunden runter und brauchen am Ende ca. 1..2 Takte/Bit dafür, erreichen also nicht nur die maximal mögliche Ausgaberate (also nur durch die Zykluszeit des Protokolls limitiert), sondern haben dann obendrein immer noch 90..95% der Rechenzeit für andere Zwecke über. Und ja: richtige Programmierer benutzen kein C. Und schon garnicht den Arduino-Bloat...
Kaj schrieb: > Kannst auch den UDOO nehmen: dual oder quadcore mit 1GHz und ein arduino > due zusammen auf einer platine, und nur minimal größer als der raspi. > Und kompatibilität zu den arduino-shields ist auch gegeben, falls du es > brauchst. Hört sich ja fast NOCH besser an! Hat der Due denn auch Zugriff auf den Speicher wie beim BBB?
c-hater schrieb: > Das ist halt verdammt nochmal was anderes, als den Code anderer > Leute per Copy&Paste zu importieren. Was erwartest du von einem Case-Modder :D
c-hater schrieb: > Nunja, richtige Programmierer jedenfalls rattern das in ein bis zwei > Stunden runter und brauchen am Ende ca. 1..2 Takte/Bit dafür, erreichen > also nicht nur die maximal mögliche Ausgaberate (also nur durch die Das musst Du jetzt aber beweisen.
Marlon S. schrieb: > Die Farben der WS2812-LEDs sollen nämlich von Audio-Signalen, > Lüfterdrehzahlen, Temperaturen und/oder auch anderen Events abhängig > sein. Zudem sollen auch vordefinierte Animationen auf einigen LEDs > laufen. Wollen wir Wetten? Das Projekt wird nie fertig. Du kaufst irgendwelche Bauteile und stellst Dann fest, dass es doch etwas komplizierter ist, als Du Dir gedacht hast.
c-hater schrieb: > Nein, suchst du nicht. Du willst einfach bloß mal richtig programmieren > lernen. Das ist halt verdammt nochmal was anderes, als den Code anderer > Leute per Copy&Paste zu importieren. In der Tat, ich möchte programmieren lernen. Deshalb beschäftige ich mich mit solchen Themen. Die Lösungen, die ich bisher gefunden hatte, fand ich ja schließlich auch so ineffizient, dass ich es selbst besser machen wollte. Kopieren wollte ich gar nichts. An der Nutzung von bereits vorhandenen und guten Libraries sehe ich allerdings grundsätzlich nichts verwerfliches. Wenn dur dir ALLES selbst programmierst, bittesehr. Andere Leute haben auch noch andere Dinge zu tun. c-hater schrieb: >> Konkret soll jedes Bit 1250ns lang sein. > > Eine kleine Ewigkeit also. Richtig, deshalb finde ich die Adafruit-Library auch so beschissen. In dieser Ewigkeit kann der AVR nämlich kaum etwas anderes tun. Vielleicht mit irgendwelchen Tricks von Super-Programmierern wie dir, aber ich kann das nicht. c-hater schrieb: > Häh? Was ist denn das für eine bescheuerte Definition eines Timings? Das > ist doch sicher nicht das, was im Datenblatt steht, sondern nur das, was > du davon zu verstehen geglaubt hast, oder? Das ist so ziemlich das, was im Datenblatt steht. Dort ist es tabellarisch für 400 KHz dargestellt. Mit dem eigentlich überflüssigen Vermerk, dass die Timings für 800 KHz jeweils die Hälfte betragen. c-hater schrieb: > Bei 16MHz dauert in Tick 62,5ns. Also teilen wir einfach mal die > Optimalzeiten dadurch: > > 1250/62.5=20 ;oops, ganze Zahl, Zykluszeit also schonmal exakt > erreichbar > 250/62.5=4 ;und schon wieder eine ganze Zahl > 600/62.5=9.6 ;naja, mit 10 kommen wir auf 625ns, das ist weit innerhalb > ;der angegebenen Toleranz Ich habe auch nie gesagt, dass die Zeiten mit den Prozessor-Clocks nicht möglich wären, da ich mir das alles bereits vorher ausgerechnet hatte. Trotzdem danke für die Mühe. Für das Problem ist das jedoch irrelevant, da ich die Daten ja zwecks Geschwindigkeit parallel ausgeben wollte. c-hater schrieb: > Nunja, richtige Programmierer jedenfalls rattern das in ein bis zwei > Stunden runter und brauchen am Ende ca. 1..2 Takte/Bit dafür, erreichen > also nicht nur die maximal mögliche Ausgaberate (also nur durch die > Zykluszeit des Protokolls limitiert), sondern haben dann obendrein immer > noch 90..95% der Rechenzeit für andere Zwecke über. Über SPI ist das sicherlich möglich, aber das war mir nunmal bis heute nicht so richtig klar. Ich finde es schade, dass deine guten fachlichen Kenntnisse leider mit außerordentlicher Arroganz und sozialer Inkompetenz gepaart sind.
Info schrieb: > Marlon S. schrieb: >> Die Farben der WS2812-LEDs sollen nämlich von Audio-Signalen, >> Lüfterdrehzahlen, Temperaturen und/oder auch anderen Events abhängig >> sein. Zudem sollen auch vordefinierte Animationen auf einigen LEDs >> laufen. > > Wollen wir Wetten? Das Projekt wird nie fertig. Du kaufst irgendwelche > Bauteile und stellst Dann fest, dass es doch etwas komplizierter ist, > als Du Dir gedacht hast. Es wird sicher noch einige Zeit dauern, aber ich werde das ganz bestimmt durchziehen. Ich habe sehr lange geplant und werde es noch eine ganze Weile tun müssen. Das Ergebnis wird dafür aber umso besser. Wenn du möchtest, kann ich dich informieren, sobald es fertig ist.
Info schrieb: > Das musst Du jetzt aber beweisen. Wenn du mich für die angegebenen 1..2h Entwicklungszeit bezahlst: sofort. Sämtliche Nutzungsrechte am Quelltext sind dann dein Eigentum, über die Veröffentlichung kannst dann du allein entscheiden.
Marlon S. schrieb: > Es wird sicher noch einige Zeit dauern, aber ich werde das ganz bestimmt > durchziehen. Ich habe sehr lange geplant und werde es noch eine ganze > Weile tun müssen. Das Ergebnis wird dafür aber umso besser. Kleiner Tipp: Bevor du einen Gipfel erklimmen willst lerne erstmal das Laufen. Oder anders formuliert: Lasse deine LEDs mit einem Billig-uC auf durchdachte Weise blinken. Sonst wird die Nachwelt nie von deinem fertigen Projekt erfahren.
Nobby Nic schrieb: > Kleiner Tipp: Bevor du einen Gipfel erklimmen willst lerne erstmal das > Laufen. Oder anders formuliert: Lasse deine LEDs mit einem Billig-uC auf > durchdachte Weise blinken. Sonst wird die Nachwelt nie von deinem > fertigen Projekt erfahren. Bin ich ja schon fleißig bei. Habe auch schon meine Relaiskarten und HD44780-Displays erfolgreich zum Laufen gebracht. Auch die Steuerung übers Web-Interface funktioniert in den Grundzügen. Allerdings will ich insgesamt von html auf php und von python auf c++ umsteigen, dafür muss ich einiges neu schreiben. C++ kann ich auch wesentlich besser als Python. Das Kompilieren finde ich unter Linux aber etwas umständlich und auf dem RPi auch langsam. Ist halt doch was anderes als VisualStudio. Ich weiß, RICHTIGE Programmierer verachten wahrscheinlich VS und schwören auf Konsole, aber ich bin nunmal kein "richtiger" Programmierer und mag es lieber komfortabel.
Marlon S. schrieb: > Ich finde es schade, dass deine guten fachlichen Kenntnisse leider mit > außerordentlicher Arroganz und sozialer Inkompetenz gepaart sind. Nöm, das sehe ich nicht unbedingt so. Das kommt i.A. nur so aus mir raus, wenn schon es im OP vor Faulheit und/oder Dummheit nur so strotzt. In deinem konkreten Fall wurde dieser üblicher Trigger allerdings durch eine gewisse, nicht durch fachliche Kompetenz abgesicherte Arroganz der Darstellung befeuert, die die eigene (also deine) Unfähigkeit auf andere delegiert hat, nämlich die Leute, deren Code du benutzt hast und mit dem du dann nicht zufrieden warst. Diese Leute haben ihn dir für lau zur Verfügung gestellt. Wenn er dir nicht reicht: kein Thema, dann mußt du es halt selbst besser schreiben. Aber es gehört sich nicht, die Geschenke zu verleumden. Soviel zu deiner sozialen Kompetenz.
Marlon S. schrieb: > In der Tat, ich möchte programmieren lernen. Deshalb beschäftige ich > mich mit solchen Themen. Die Lösungen, die ich bisher gefunden hatte, > fand ich ja schließlich auch so ineffizient, dass ich es selbst besser > machen wollte. Kopieren wollte ich gar nichts. An der Nutzung von Und Du bist Dir sicher, dass es nicht daran liegt, dass Du die Probleme nur noch nicht verstanden hast?
c-hater schrieb: > Wenn du mich für die angegebenen 1..2h Entwicklungszeit bezahlst: > sofort. > > Sämtliche Nutzungsrechte am Quelltext sind dann dein Eigentum, über > die Veröffentlichung kannst dann du allein entscheiden. Ok, Du bekommst 0.01 BTC von mir. Bitte gib mir eine Addresse.
Marlon S. schrieb: > Allerdings will ich > insgesamt von html auf php und von python auf c++ umsteigen, dafür muss > ich einiges neu schreiben. ...
Info schrieb: > Ok, Du bekommst 0.01 BTC von mir. Bitcoins? Die kannst du dir gern als Tapete ausdrucken.
c-hater schrieb: > Info schrieb: > >> Ok, Du bekommst 0.01 BTC von mir. > > Bitcoins? Die kannst du dir gern als Tapete ausdrucken. Dann bekommst Du eben 0.00 BTC von mir. Also, wo ist der Code, der die Ansteuerung in 1-2 Taktzyklen pro Bit erledigt und auch einen Kontext-Switch implementiert, so dass die restliche CPU-Zeit genutzt werden kann?
Info schrieb: > Also, wo ist der Code, der die > Ansteuerung in 1-2 Taktzyklen pro Bit erledigt Seite 5: http://ww1.microchip.com/downloads/en/AppNotes/00001606A.pdf Abhängig davon, woher du die Daten nimmst ist es mit 2 Befehlszyklen pro Byte möglich. Z.B. mit indirekter Adressierung:
1 | moviw FSR0++ |
2 | movwf SSP1BUF |
:
Bearbeitet durch User
RPI, 273 Leds kann man mit einem Buffer machen, und bei 30fps kann/muss man 1083 Leds ansteuern. Die 273 Leds (spi vorteiler auf 64) sind dann ca alle 8.33ms. Man braucht aber trotzdem normalerweise noch ein Pegelwandler Vorteiler von SPI wird dabei auf 64 gesetzt. Code gibt es fertigen von Inet runterzuladen, such nach dem CHIP und SPI . Für di 30fps musst du halt 1083 Leds raussenden (3*5byte je Led) sowie 31 leere bytes.
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.