SEDU-Board + tpm2 + WS2801: nur die ersten fünf Pixel leuchten

Nee, das "Problem" liegt hier, in der Datei "Settings.inc":

.equ PIX_COUNT			= 5				; WS2801-Pixel-Anzahl (logische Pixel)

- war so eingestellt, da ich zum testen auch nur 5 Pixel dran hatte...

einfach die Zahl erhöhen, also Deine tatsächliche Pixel-Zahl hin schreiben, und neu assemblieren... es gehen hier aber nur 255 Pixel max., weil da die alte Ausgaberoutine drin ist (vom Ambilight), die nicht mehr kann, das muss ich erst noch umbauen.

wo war das noch mal her...? - hatte ich irgendwo "inoffiziell" gepostet, kann ich mich erinnern, aber nicht, in welchem Thread - und ob ich das ganze AVR-Studio-Projekt gepostet habe, oder nur die .hex-Datei...?

das ist eben nur die Version, um mal zu testen, ob das überhaupt geht, die offizielle Version wird dann in dem SW-Thread in der Lobby veröffentlicht - die holt sich die Pixel-Zahl dann gleich aus dem tpm2-Header (da steht ja drin, wie viele Bytes kommen) und passt die Ausgaberoutine automatisch dran an... und kann dann eben auch bis zu 1.024 Pixel

hab's mal nach TTT verschoben, weil's ja nicht direkt was mit LEDs zu tun hat...

ach, vorsichtshalber hier anbei mal das ganze Projekt - da kannst Du auch das tauschen der Farben einstellen, die .hex ist nun schon für 255 Kanäle assembliert - wie gesagt, mehr kommt noch, die Empfangsroutine muss ich auch noch umbauen, da soll noch einstellbar sein, ab welchem Byte und wie viele sie tatsächlich empfängt (also abspeichert)... also das hier ist als "Beta-Version" zu betrachten...

die endgültige soll dann auch noch über DIP o.ä. konfigurierbar sein, evtl. auch wieder mit so nem Config-Tool vom PC aus, eben ob/wie Farben tauschen, welche Baudrate, etc. - deswegen dauert das noch etwas...

weil ich's gerade für jemanden gemacht habe, hier nun ne Version mit 16-Bit-Zähler in der Ausgaberoutine, also max. 65.335 Pixel möglich

natürlich nur in der Theorie - da reicht die Datenrate ja nicht...

diese lässt sich nun auch auf 500 k einstellen, einfach in der Datei "Settings.inc", andere Baudraten als 250000 oder 500000 führen zu ner Fehlermeldung...

1 Mbit kommt dann auch noch, sowie die Einstellbarkeit der Startadresse, wobei das bei ner größeren Matrix eigentlich eh' uninteressant ist...

die .hex ist fertig für 660 Pixel und 500k Baud... so brauchte der User das, der dann seine Matrix hoffentlich auch hier im Forum vorstellt...

Hört sich super an, Pesi. Jetzt noch ein anderes Ausgabe-Protokoll dazu und ich habe direkt eine 22x22 Matrix zum Test mit Glediator da .

Du meinst für die APA101-LEDs...? - da bin ich gerade dabei...

Es wird immer besser ... aber Psst! mehr wird noch nicht verraten

APA101-Leds sind doch die flexiblen Ledscreens.
Da bin ich kürzlich mal drüber gestolpert... Hab aer kein Plan was die so kosten.

Gruß Flo

APA101 ist der LED-Controller-Chip, also so wie TM1804, WS2810... siehe hier und Datenblatt.

es gibt dann eben PLCC6-LEDs mit diesem Chip bereits drin, da schließt man nur 5V, GND, SDO, SDI, CKO und CKI an, und jagt das serielle Signal durch, nix weiter. Ich habe sowohl die "nackten" LEDs da wie auch fertige Stripes damit, turi hat noch diese "Matten":

was die kosten, kannst Du dann ihn mal fragen - der Ansteuer-Code (gleich mit tpm2-Empfang für Glediator) ist fertig, stelle ich später in nem eigenen Thread vor...

Obwohl ich schon so lange im Forum gesucht habe, wurde ich leider nicht fündig.

Für meinen 2500 Pixel Project würde ich nicht so gern Artnet, sondern den TPM2-Protokoll einsetzen. Artnet Nodes selber zu bauen nimmt viel Zeit und so viele kommerzielle Nodes zu kaufen ist für mein geldbeutel zu teuer.

Pesi meint ja, dass TPM2 ca 1000 Pixel schafft. Könnte man vielleicht die Sedu-Boards im TPM2-Modus auch kaskadieren, also Multi-Sedo-Boards für mehr Pixel benutzen?
Müsste ich dann für jeden Sedu-Board einen USB port verschenken oder geht das auch irgendwie mit nur 1 USB port?

Oder gibts es vielleicht schon ne Ethernet-Lösung fürs Sedo, die kaskadierungen erlaubt?

Oder vielleicht ein Atmega der mehr Pixel schafft als der 644P? Wenn, dann was für ein Atmega sollte man da benutzen?

Danke schonmal im voraus für jede Info.

Ich denke mal bei mehr als 1000 Pixeln wird auch mit dem Timing Schwer werden, und ich denke nicht das ein größerer ATMega das ändern würde.

Aber wegen dem USB Port könnte man ja auch ein USB Hub Nehmen, sowas bekommt man schon für eine paar Euronen.

Ok, USB-Hub ist mir schon klar. Frage ist dann ob und wie die mehreren Sedu-Boards sich im USB-Hub vertragen.

Das beste waere, wenn man die Daten per einen USB-Port an den ersten Sedu-Board schickt und der erste dann die Daten den anderen Sedus weiter schickt (Latch-Modus?).

Ich habe hier auch etwas über "tpm2.net" gelesen aber konnte keine weitere infos finden. Gehts da um Ethernet und Sedu?

Wenn ich das SEDU richtig verstanden habe, dann arbeitet es mit 500kBaud und damit sind bei 25 Bilder die Sekunde max. 666 RGB LEDs drin!

Wird das denn eine RGB Matrix?

Mal aus Interesse, welches PC Programm soll deine Matrix "befeuern"?

MfG basti

Ja, es wird eine RGB Matrix. Da ich hier ja schon über den artnet->tpm2 möglichkeit gelesen habe, denke ich, dass ich bei der PC-Software auswahl recht flexibel sein kann. Womit ich mich in letzter Zeit beschaftigt habe ist die MagicQ von Chamsys wo man viele Einstellungen flexible aendern kann. Aber ich könnte auch andere programme benutzen, die in der Lage sind, mehr als 8 Universen mit Artnet-protokoll senden können. (madrix, glediator etc.)

Zitat von leddie

Pesi meint ja, dass TPM2 ca 1000 Pixel schafft.

Hab' ich nirgendwo behauptet...

bei tpm2 kann man bis zu 65.535 Bytes Nutzdaten haben, das wären 21.845 RGB-Pixel...

Das Problem ist die Übertragungsgeschwindigkeit, also über welchen Kanal mit welcher Baudrate die Daten geschickt werden... und wie schnell der µC sie verarbeiten kann, wie viel er ggfs. speichern kann, wenn das nötig ist...

beim SEDU sind's eben *max* (noch nicht in der Praxis getestet) 2 MBit, das würde zwar für 2.500 Pixel reichen, aber man kann die mit 4 k RAM nicht puffern...

Zitat von leddie

Ok, USB-Hub ist mir schon klar. Frage ist dann ob und wie die mehreren Sedu-Boards sich im USB-Hub vertragen.

Das *sollte* kein Problem sein, müsste man mal ausprobieren - wären da ja 12 MBit (wenn ich richtig liege, sollte low-Speed-USB sein), also sollte man über ein Hub an einem USB schon mehrere SEDUS versorgen können...

das allein hilft aber noch nix, die SW muss die Daten dann ja auch auf mehrere COM-Ports aufteilen können - Glediator kann das nicht, wäre (k.A., Pepe, wie aufwändig das wäre?) aber theoretisch möglich, dass es die Daten Portionsweise á 1.024 Pixel an mehrere SEDUs schickt...

Zitat von leddie

Das beste waere, wenn man die Daten per einen USB-Port an den ersten Sedu-Board schickt und der erste dann die Daten den anderen Sedus weiter schickt (Latch-Modus?).

Das geht nicht, weil die Begrenzung eben schon beim empfangen und verarbeiten liegt - wie soll der also noch mehr empfangen und dann das auch noch an andere SEDUS weiterleiten, das wäre ja Quatsch, weil dann könnte gleich ein SEDU alles empfangen und an die Pixel weitergeben...

Zitat von leddie

Ich habe hier auch etwas über "tpm2.net" gelesen aber konnte keine weitere infos finden. Gehts da um Ethernet und Sedu?

Nee, da geht's um Ethernet und tpm2, tpm2 hat ja wie gesagt nix mit SEDU zu tun, das ist nur ein Protokoll, völlig von irgendeiner HW unabhängig...

tpm2.net bedeutet schicht und einfach, dass man Datenframes nach diesem Protokoll über Ethernet verschickt, am einfachsten wohl per UDP - das soll in der neuen Glediator-Version drin sein, mit so nem Ethernet-Bridge-Chip (z.B. dem, den Pepe auf seiner universellen Umsetzer-Platine hat, oder dem Wifly RN-171, mit dem Basti und ich gerade rumspielen) kann man das dann transparent empfangen und weiter verarbeiten...

auch hier wieder der Flaschenhals: der Ethernet/Wifly-Chip kann mit max. 1,1 Mbit Daten raus geben, der AVR auch nicht deutlich mehr verarbeiten bzw. (zumindest der M644p) 2.500 Pixel zwischenspeichern... da hilft's auch nix, dass über Ethernet 100 MBit gehen bzw. über Wlan 54 MBit...

Zitat von Counterfeiter

Wenn ich das SEDU richtig verstanden habe, dann arbeitet es mit 500kBaud und damit sind bei 25 Bilder die Sekunde max. 666 RGB LEDs drin!

Nee, der SEDU ist nur ne Platine mit nem M644p und nem FT232R drauf, nix weiter... - wie der arbeitet, hängt von der SW ab... die tpm2-auf-WS2801-SW, die ich hier mal gepostet habe, ist zwar auf 500 k eingestellt, kann man aber auch auf 1 Mbit einstellen, dann gehen (getestet) 1.024 Pixel, also ne 32x32-RGB-Matrix... viel mehr ist wegen Baudrate und Speicher dann aber auch nicht drin...

Zitat von leddie

Ja, es wird eine RGB Matrix. Da ich hier ja schon über den artnet->tpm2 möglichkeit gelesen habe, denke ich, dass ich bei der PC-Software auswahl recht flexibel sein kann.

naja, dann kannst Du aber auch gleich Artnet nehmen und auf WS2801 umsetzen, Dir den Zwischenschritt mit tpm2 sparen...

tpm2 ist ein tolles Protokoll für sowas, eben weil man sich da bei "haushaltsüblichen" (eben bis knapp 22.000 RGB-Pixel) Matrix-Größen dieses rumgewurschtel mit den "DMX-Universes" wie bei Artnet sparen kann - es ist einfach ein Datrenframe pro Bild, nicht in Portionen á 170 Pixel aufgeteilt, was man der SW wieder irgendwie beibringen muss etc.

nur, es gibt halt ausser Glediator noch keine SW, die tpm2 ausgeben kann, und auf der anderen Seite hapert's i.M. noch an der HW, die solche Datenmengen verarbeiten kann...

Lösung wäre hier ein schnellerer und größerer µC, z.B. der XMega, mit dem Basti ja arbeitet - da hast Du nicht mehr diesen FT232-Flaschenhals, der kann die Daten deutlich schneller per USB empfangen - und dann unabhängig davon per DMA an die Pixel ausgeben... fehlt nur noch genug Speicher, da muss man mal gucken, was es so gibt...

nicht nur aus dem Grund ist auch in Planung, den nächsten SEDU (wenn er mal kommt, wurden gerade erst wieder 250 Stück vom aktuellen bestellt) mit einem XMega auszustatten, ideal einer mit 8 k RAM, kommt unter'm Strich dann auch nicht teurer als der alte, aber kann dann auch Deine 2.500 Pixel mit einem Board über USB versorgen...

ich persönlich spiele ja nach längerer Lektüre bei µC.net mit dem Gedanken, für sowas auf ARM umzusteigen - da hast Du dann Rechenleistung (168 MHz statt 20/32 wie beim AVR) und RAM satt, es gibt von Texas Instruments so ein Board mit USB und Debugger drauf, braucht man also keine weitere HW wie Programmierer o.ä. zum sofort loslegen, das Teil kostet bei Farnell 4,70 Euro... - also für solche Projekte dann gleich komplett so ein Board irgendwo einlöten statt nem AVR zum selben Preis...

da ist für mich persönlich nur die Hürde, mich endlcih mal mit C anzufreunden, bei solchen Teilen ist Assembler dann wohl doch zu umständlich...

Zitat

beim SEDU sind's eben *max* (noch nicht in der Praxis getestet) 2 MBit, das würde zwar für 2.500 Pixel reichen, aber man kann die mit 4 k RAM nicht puffern...

Ja und genau da sehe ich das Problem (Du gehst ja weiter unten in Deinem Post auch darauf ein). Die Pufferung braucht eben RAM. Ich weiß garnicht bei den WS2801 könnte es doch auch ohne Pufferung gehen!? Die Zeit zum latchen ergibt sich ja zwischen zwei Frames ohnehin. Der µC müsste einfach nur jedes, über UART empfangene Byte (am besten in einer ISR), in die SPI legen (3-4 CPU Zyklen). Natürlich muss die Zeit zwischen zwei Bytes länger sein als die Latchzeit Ich bin so früh am Morgen zu faul da was nachzurechnen, aber rein aus dem Bauch heraus sollte das doch bei 1 MBit passen, oder? WIe ist das bei der aktuellen SEDU-Implemenierung, pufferst Du da? Und wenn ja, an welcher Stelle legst Du die Puffergröße fest? Oder wird die dynamisch angepasst an die Paketgröße des jeweiligen tpm2-frames?

Zitat

das allein hilft aber noch nix, die SW muss die Daten dann ja auch auf mehrere COM-Ports aufteilen können - Glediator kann das nicht, wäre (k.A., Pepe, wie aufwändig das wäre?) aber theoretisch möglich, dass es die Daten Portionsweise á 1.024 Pixel an mehrere SEDUs schickt...

Ich muss ganz erhlich gestehen das ich von dieser Lösung nicht viel halte. Klar das wäre rein technisch machbar, aber schon EINE Com-Schnittstelle ist mir zuviel. Für verteilte Lösungen ist Ethernet m.M.n. einfach viel besser geeignet und auch ein Stück eleganter!

Zitat

Lösung wäre hier ein schnellerer und größerer µC, z.B. der XMega, mit dem Basti ja arbeitet - da hast Du nicht mehr diesen FT232-Flaschenhals, der kann die Daten deutlich schneller per USB empfangen

Er kann sich als USB2.0 device ausgeben und Daten unheimlich schnell empfangen! ABER: dann nicht mehr als virtueller COM-Port. Dann müsste die SW wirklich die Daten direkt an das "USB-Device" senden und das macht m.M.n. keine SW im Moment! Und sowie man auf virtuell COM-Port geht ist man wieder bei 1 MBit Der DMA ist aber ein ganz entscheidender Punkt, denn der sorgt zumindest dafür das man vom RAM unabhängig wird.

Zitat

auf ARM umzusteigen - da hast Du dann Rechenleistung (168 MHz statt 20/32 wie beim AVR)

Hier muss man aber ein bisschen aufpassen. Beim AVR (das weißt Du als ASM-Freak besten) hat man bei fast allen Befehlen eine Zykluslänge von 1 oder 2, d.h. 20MHz sind dann auch knapp 20 MIPS. Das kann je nach Anwendung beim ARM doch erheblich abweichen! Aber RAM-Argument ist natürlich unschlagbar, wobei man beim XMega wohl auch über DMA externen RAM anbinden kann ...

Zitat

da ist für mich persönlich nur die Hürde, mich endlcih mal mit C anzufreunden, bei solchen Teilen ist Assembler dann wohl doch zu umständlich...

Für den klassischen EINSTIEG in C wäre der AVR m.M.n. besser geeignet. Denn bei den ARMs wird schon sehr viel abstrahiert, und Du hattest Dich ja slebst in nem andeen Thread mal als "Kontrollfreak" geoutet

Einen schönen Tag wünscht,

Pepe

Danke Dir Pesi wieder mal, weil du Dir wieder so viel Zeit genommen hast.

Zitat von Pesi

Hab' ich nirgendwo behauptet...

bei tpm2 kann man bis zu 65.535 Bytes Nutzdaten haben, das wären 21.845 RGB-Pixel...

Ja, also ist es nicht tpm2, sondern der Sedu-Board selbst der bis ca 1000 pixel schafft. Habe ich jetzt verstanden

Zitat von Pesi

naja, dann kannst Du aber auch gleich Artnet nehmen und auf WS2801 umsetzen, Dir den Zwischenschritt mit tpm2 sparen...

Auf jedenfall ist es besser.

Ich sehe es eben so, dass ich dann für max 1000 Pixel dann lieber den Sedu nehmen sollte, aber halt für mehrere Pixels dann Artnet. Mich nervts nur, dass ich mit einem Sedu doch schon 1000 pixels schicken kann, aber mit artnet, der viel aufwaendiger zum bauen ist nur 340 pixel ( 2 DMX Universen). Oder liege ich da falsch? Könnte ich dann mit einem artnet interface mit nem 644p vielleicht doch noch 2000 pixel empfangen & senden, wenn ich die DMX geschichte rauslasse und ein protokoll direkt zum ws2801 reinbastle?

Zitat von Pepe_1981

Ich weiß garnicht bei den WS2801 könnte es doch auch ohne Pufferung gehen!? Die Zeit zum latchen ergibt sich ja zwischen zwei Frames ohnehin.

Ja, das hatte ich auch mal so gemacht, hängt halt von den "Umständen" (Framegröße, fps, Baudrate) ab.

Für den konkreten Fall hier, Du hast bei 2.500 Pixeln also 7.505 Bytes pro Frame, bei 2 Mbit/s braucht der also ca. 38 ms - Glediator sendet ja mit 21 fps, also alle 47 ms einen neuen, also hätte man zwischen 2 Frames 9 ms Pause, die ja für die WS2801 locker reichen...

in der Theorie, k.A., ob sich da auch mal was "verschluckt" am FT232, und dann evtl. mal die Pause zu kurz ist - praktisch testen kann ich das leider nicht, weil ich in Glediator ja keine 2 Mbit einstellen kann... könnte natürlich probieren, wieder den FT232-Treiber zu "bescheissen", so wie bei dieser 115k/250k-Sache auch...

wenn das ginge, dann würde hier also ein SEDU reichen, mit direkt weiter schicken und modifiziertem FT232-Treiber...

Zitat von Pepe_1981

WIe ist das bei der aktuellen SEDU-Implemenierung, pufferst Du da? Und wenn ja, an welcher Stelle legst Du die Puffergröße fest? Oder wird die dynamisch angepasst an die Paketgröße des jeweiligen tpm2-frames?

Ja, da wird gepuffert - ich muss in asm ja keine Größe festlegen, da gibt's einfach ne Startadresse im RAM, und der Pointer wird bei jedem empfangenen Byte eins rauf gesetzt - den RAM brauche ich ja sonst für nix (OK, oben ein bisschen für den Stack), aber natürlich wird drauf geachtet, dass der nicht überläuft, also wenn mehr als 3.072 Bytes empfangen werden, wird der Rest einfach nicht mehr gespeichert...

Zitat von Pepe_1981

Ich muss ganz erhlich gestehen das ich von dieser Lösung nicht viel halte. Klar das wäre rein technisch machbar, aber schon EINE Com-Schnittstelle ist mir zuviel. Für verteilte Lösungen ist Ethernet m.M.n. einfach viel besser geeignet und auch ein Stück eleganter!

Was hast Du denn gegen den COM, ist das auf PC-Seite schwieriger zu programmieren, fehleranfälliger, oder sowas...?

ich finde das halt schon cool, also bei meinen Anwendungen, und für so Pixel-Tische o.ä. auch leicht ausreichend, einfach ein USB-Dings und fertig, kein starres Netzwerkkabel, und halt auch billiger, (für den Fall hier) 3x ein µC + FT232 (oder gleich einer mit USB drin) ist halt doch günstiger als 3x µC mit Ethernet-Chip und Übertrager... bzw., OK, geht für ähnlichen Preis, aber dann braucht man wieder nen Switch, bei USB halt nur so'n HUB für 5 Euro...

das ist mir wieder eingefallen, als ich mit dem Schulterklopfer zusammen da rum gespielt habe, da haben wir auch mal 2 SEDUS über ein HUB an einen USB angestöpselt, und auf beide je 1 MBit simultan gesendet, das ging ohne Probleme... sollte mit 3 dann wohl auch gehen...

Zitat von Pepe_1981

ABER: dann nicht mehr als virtueller COM-Port. Dann müsste die SW wirklich die Daten direkt an das "USB-Device" senden und das macht m.M.n. keine SW im Moment!

Hm, da müsste man mal den Basti fragen, der benutzt das ja schon, und wenn ich das richtig verstanden habe, ist das bei ihm auf PC-Seite auch nur ein normaler VCP...

Zitat von Pepe_1981

Hier muss man aber ein bisschen aufpassen. Beim AVR (das weißt Du als ASM-Freak besten) hat man bei fast allen Befehlen eine Zykluslänge von 1 oder 2, d.h. 20MHz sind dann auch knapp 20 MIPS.

Ja, ist mir schon klar - aber unter'm Strich kann er halt trotzdem mehr Daten verarbeiten, wobei der Hauptvorteil wohl eher dann kommt, wenn man 32 Bit hat, hier ja nicht...

Zitat von Pepe_1981

Für den klassischen EINSTIEG in C wäre der AVR m.M.n. besser geeignet. Denn bei den ARMs wird schon sehr viel abstrahiert, und Du hattest Dich ja slebst in nem andeen Thread mal als "Kontrollfreak" geoutet

Ja, deswegen liegt mein Billig-ARM-Board mit Touchscreen immer noch in der Ecke - ich werde wohl erst mal mit C auf dem XMega anfangen, gewohnte Umgebung (AVR Studio), und wenn ich das dann mal alles kann, also andere IDE für C einrichten usw., sind die "kleinen" AVR wohl eh' schon so veraltet, dass ich nur noch XMega und ARM mache...

Zitat von leddie

aber mit artnet, der viel aufwaendiger zum bauen ist nur 340 pixel ( 2 DMX Universen). Oder liege ich da falsch? Könnte ich dann mit einem artnet interface mit nem 644p vielleicht doch noch 2000 pixel empfangen & senden, wenn ich die DMX geschichte rauslasse und ein protokoll direkt zum ws2801 reinbastle?

Naja, soo viel aufwändiger ist das Dings auch nicht zu bauen, siehe hier...

da ist die SW dabei, kann man dann auch so modifizieren, dass er die per Artnet empfangenen Daten halt nicht über DMX ausgibt, sondern gleich an WS2801 - hier ist halt auch der Flaschenhals die Kommunikation zwischen dem Ethernet-Chip und dem µC, und wie schnell der die Daten weiter schaufeln kann...

EDIT: Und ob alle 2.500 Pixel über ein Board gehen, weiß ich nun auch nicht, wenn ich mich richtig erinnere, ist das bei Artnet irgendwie so, dass nur 4 (?) Universes über eine IP-Adresse gehen, Du bräuchtest dann also 4 solcher Boards, aber dann würde es gehen, von Glediator über Artnet die Daten an die 4 Boards, und von jedem dann direkt an die WS2801...