Glediator - Freeware LED Matrix Steuerung - Software

    Glediator - Freeware LED Matrix Steuerung - Software

    EDIT Pesi: Thread wurde neu erstellt aus Posts zur SW Glediator im Thread "Universelle RGB-Matrix-Platine"
    Es geht hier um eine kostenlose SW, mit der man - ähnlich wie mit Madrix - RGBLED-Matritzen steuern kann.
    Habe mir mal erlaubt, Das Video der mit dieser SW gesteuerten Matrix rein zu posten, ist irgendwie schöner/interessanter, als wenn hier nur Text steht:




    So,

    die Software steht auf unserer Seite zum Download bereit!

    Damit die Software läuft müsst ihr euch kostenlos bei Oracle die aktuelle Version der JAVA JDK für euer Betriebssystem runterladen und installieren.

    Wer Daten rausschicken will muss zudem die RXTX library für sein System herunterladen und entsprechend der beliegenden Anleitung die Dateien an die richtige Stelle kopieren.

    Wir bitte ausdrücklich um reichlich Feedback denn ein solches Software-Projekt kann nur davon leben das möglichst viele Verbesserungsvorschläge einbringen!

    Eine ausführliche Anleitung zu Installation und Gebrauch der Software wird in den nächsten Tagen auf unserer Projektseite erscheinen.

    Einen schönen Abend noch,


    Pepe

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „Pepe_1981“ ()

    DMX als Protokoll zu implementieren ist sicher kein Problem. Wenn hardwareseitig eine ensprechende Umsetztung von RS232 bzw. UART auf DMX (488?) vohanden ist, dann geht das ohne Probleme!

    Ich schreibs mal auf die ToDo-Liste ganz oben hin. Wird aber nicht mehr heute ;)

    Beste Grüße,

    Pepe
    Ich hab's jetzt mal getestet, macht wirklich nen guten Eindruck, ja, ist ähnlich wie Madrix... zuerst wollte es nicht laufen, musste erst RXTX Library installieren, das wird wohl grundsätzlich gebraucht, damit die SW überhaupt läuft...

    ich weiß nicht, ob Du die andere Matrix-Freeware ("Pixelcontroller") hier im Forum kennst..?

    das sind unterschiedliche Ansätze, bei Euch ist ein schön kompaktes GUI, ne überschaubare Anzahl Effekte (die aber wirklich gut!), dort ist das Ganze modular und erweiterbar, dafür auch ein bisschen "zusammengestöpselt" und man muss doch hier & da etwas konfigurieren....

    schön an Eurer SW ist auch, dass sie sehr wenig CPU-Last erzeugt - Pixelcontroller geht auf meiner Kiste gar nicht mit 32x16, auch mit 20x10 ist die CPU schon ständig bei 90-98%... Eure SW zwischen 1% und 14%

    seltsam ist nur, dass die Auslagerungsdatei und die Zahl der aktiven Handles ständig wächst:



    k.A., ob das irgendwas zu bedeuten hat...? ich habe es noch nicht so lange laufen lassen, bis der Balken links am Anschlag ist, k.A. ob es dann abkackt...? :D

    wegen DMX: Kleines Problem ist da ja, dass man damit max. 170 Pixel ansteuern kann in einem Universe - Ihr müsstet das dann also auf mehrere Interfaces verteilen...

    cool finde ich persönlich (naja, warum wohl..? :D) die modifizierte (mehr Kanäle) Version von Mini-DMX - weil sie echt simpel ist: Es werden auch nur die Kanäle als Bytes raus geschickt, davor halt ein Start- und danach ein Endcode... wie wird bei Euch eigentlich ein neuer Block angezeigt, eben durch ne 1 ms Pause, wie bei WS2801...?

    wenn Ihr ne "Mini-DMX"-Ausgabe noch mit dazu machen könntet, dann wäre auch die Umsetzung auf DMX zumindest für ein Universe schon fertig... ;) - und, nein, man muss dafür nicht das SEDU-Board kaufen, das kann man auch auf eigene HW drauf machen, Quellcode ist auch dabei...

    wenn Ihr noch die Mini-DMX-Ausgabe dazu machen könntet, oder zumindest die 250k Baud Ausgabe, dann würde ich Eure SW gerne am Freitag mal live ausprobieren... wenn meine Matrix bis dahin fertig wird, ich verbringe schon wieder zu viel Zeit im Frum und mit anderen Sachen... ;)
    It's only light - but we like it!

    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!
    wird es die platine auch in naher zukunft ( ca 6 monaten) auch noch geben? oder muss ich mich gleich auf die liste setzen lassen?

    habe derzeit ein paar projekte noch am laufen und habe eigentlich nur angst mir noch ein projekt aufzuhalsen... da ich eh nich weis wann mir die zeit was neues erlaubt...?

    weil auf deutsch... eigentlich haben will ;)
    Ach, vergessen:

    Pepe_1981 schrieb:

    Ich hatte auch erst überlegt hier ein paar Bilder in meinen ersten Post einzubauen. Das ist aber von technischer Seite her gescheitert. Anscheinend kann man Bilder nur als Link einfügen.
    Nein, Du kannst die Bilder direkt hier hochladen, unten bei dem Reiter "Dateianhänge" - die hochgeladenen Bilder kannst Du dann mit dem Button daneben direkt in den Beitrag einfügen.

    Das ist auch besser so, weil dann bleiben sie drin, wenn die extern irgendwo liegen und dort mal gelöscht werden, dann sind sie hier auch wieder weg...

    ebenso kann man Youtube-Videos hier direkt einbinden (mit dem Button "Youtube" oben in der Leiste, da einfach den Link rein), das sieht dann auch gleich interessanter aus, als wenn da nur ein Link ist... ;)
    It's only light - but we like it!

    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!
    Hallo,

    schön das die Software doch relativ problemlos bei euch läuft! Die RXTX muss man tatsächlich IMMER installieren egal ob man Datentransfer nutzt oder nicht. Das hatte ich oben falsch gepostet!

    Ich habe mich jetzt mal (nur ganz kurz) zu DMX belesen und folgendes gefunden:

    Ein DMX-Paket beginnt mit mindestens 88 µs (22 Bitlängen) niedrigem Pegel (logisch 0) - dieser Abschnitt wird „Break“ genannt. Dies ermöglicht eine einfache Erkennung des Paketanfangs, da quasi jeder handelsübliche UART den Break als ungültiges Datenbyte mit fehlenden Stoppbits meldet. Darauf folgt „Mark after Break“ mit mindestens 8 µs (2 Bitlängen) hohem Pegel / Ruhezustand des Busses (logisch 1). In dieser Mark-Zeit können sich langsamer getaktete Controller auf ein neues DMX-Paket einstellen. Dann wird das Startbyte mit dem Wert 0 übertragen. Anschließend werden die Kanalbytes gesendet, beginnend mit dem Wert des Kanals 1 (DMX-Kanalzählung beginnt bei 1, nicht bei 0). Es können, müssen aber nicht alle 512 Kanalbytes übertragen werden. Eine Adressierung der Kanalbytes ist jedoch nicht möglich - das erste gesendete Kanalbyte ist für den ersten Kanal, das zweite Kanalbyte für den zweiten Kanal etc.. Sollte die Übertragung zu einem beliebigen Zeitpunkt unterbrochen werden, kann sie durch das Senden eines neuen DMX-Paketes wiederaufgenommen werden. Die Break-Sequenz führt automatisch zu einem Zurücksetzen aller noch offenen Übertragungen.


    So wie es mir scheint liegt die Übersetzung auf das Protokoll ja in der Schnittstelle und nicht bei der Software! Denn irgendein Controller muss die Daten ja seriell vom PC empfangen und dann ein DMX-Paket daraus erzeugen und mit 485-Pegel wegschicken! Wie die Daten dabei vom PC kommen sollte ja nur vom Controller abhängen!? Also vielleicht ein paar Startbytes dann alle Pixel hintereinander und evtl. ein paar Bytes als Abschluss hinten dran!

    Von daher also genau das was die Software auch jetzt schon macht! Wenn mir also jemand sagt was genau an Bytes für einen solchen Controller vorangestellt und angehängt werden muss, dann hack ich das in 5 min in die Software rein.

    Dann gehen natürlich immer noch "nur" 512 Kanäle also ca. 170 RGB - LED's. Die einfachste Lösung die ich da sehe wäre ein DMX-Modul mit mehreren DMX-Ausgängen. Das würde seine Daten genau wie oben beschrieben seriell empfangen und dann an den entsprechenden Ausgängen Pakete generieren. Wenn da Interesse besteht könnten wir so etwas gern in Angriff nehmen! Ich sehe da keine größeren Probleme. Oder gibt es da fertige Sachen?

    Zu dem gegenwärtigen Protokoll der Software noch zwei Dinge:

    Ich habe gesehen, das ich in der aktuell hoch geladenen Version doch noch nicht wie fälschlich geschrieben die WS2801-Pixel in Schlangen-Anordnung drin habe. Die sind momentan nur in der Experimentierversion auf meinem Rechner eingepflegt.

    Ein Latchen der Daten ist bei unseren Treiber-Platinen nicht notwendig. Jede Platine hat intern einen Graphik-Buffer von 128x3 Bytes = 384 Bytes. Das was in diesem Buffer steht wird permanent mit 250Hz Wiederholrate auf den LEDs ausgegeben. Kommen nun Daten an so wird parallel (genauer: in einem Interrupt) Byte für Byte in dem Graphik-Buffer ersetzt! Da die Darstellung weiter läuft wird das Bild demzufolge pixelweise neu aufgebaut! Wenn der Buffer komplett ersetzt ist, also nach 384 bytes, werden alle folgenden Daten an das nächste Modul weitergeleitet!

    Und wie weiß nun das erste Modul in der Reihe wann ein neues Paket losgeht wenn es doch gar nicht weiß, wie viele Module hinter ihm sitzen?

    An dieser Stelle kommt ein kleiner Kunstgriff, der aus der eigentlich asynchronen seriellen Datenübertragung eine synchrone macht! Das ganze funktioniert so: Der Rechner schiebt ein Paket raus das so aussieht: "Startbyte --- Byte_R1 --- Byte_G1 --- Byte_B_1 --- Byte_R2 --- Byte_G_2 --- Byte_B2 --- ... --- Byte_G512 --- Byte_G512 --- Byte_B512" Das erste Board sieht nun, ah da kommt ein Startbyte und schiebt dieses SOFORT zum nächsten Board weiter! Das zweite Board seinerseits sieht das empfangene Startbyte, erkennt dieses als solches und schiebt es seinerseits zum Dritten weiter und so weiter! Jedes mal wenn ein Board ein Startbyte empfängt setzt es automatisch die Schreibposition innerhalb des Graphik-Buffers auf NULL = ANFANG, schreibt die nächsten ankommenden 384 bytes in den Buffer und schiebt den Rest einfach solange durch bis das nächste Start-Byte empfangen wird.

    So gut so schön nur gibt es noch ein kleines Problem:

    WIE sieht das Startbyte aus? Da ja unsere Farbtiefe 8bit pro Farbe beträgt kann jede Farbe eines Pixels die Werte 0-255 annehmen. Nun könnte es ja sein das eine Farbe irgend eines Pixels zufällig gerade dem Wert des Startbytes entspricht!!!?? Nun, das würde die ganze Kommunikation durcheinander werfen! Und genau an der Stelle kommt nun der kleine Kunstgriff zum tragen: In der internen Umrechnung von 8bit (EIngang) auf 12 bit (Ausgang) zeigen sich natürlich in der hinterlegten Gammakorrektur Rundungen!!! (Das liegt in der Natur der Dinge - Es gibt nur ganzzahlige Bytes :-)!) Das kann dann (ja nach GAMMA-Faktor) in etwa so aussehen: 0 --> 0 ; 1-->1; 2 --> 1; 3 --> 2 ; 4 --> 2; 5 --> 3 ; 6 --> 4 ; .... ;255 --> 4095

    Und genau diese Rundung machen wir uns nun zu Nutze indem wir (am Rechner in der Software) alle Farbwerte die =1 sind auf 2 setzen da sie ja ohnehin zu identischen Farbwerten am Ausgang führen! Damit ist die "1" komplett frei und kann als Start-Byte genutzt werden da sie mit 100%iger Sicherheit niemals in einer Farbe vorkommen wird!

    Die ganze Vorgehensweise mag ein wenig kompliziert klingen ist aber dafür Benutzer-seitig extrem einfach zu implementieren da dieser nur eine "1" gefolgt von seinen Pixel-Daten rausschicken muss! Jegliche Addressierung der Board entfällt! Das Prokoll ist extrem ausfallsicher, da nach jedem Frame über das Start-Byte neu synchronisiert wird! Und das Beste ist. Man kann die Boards zusammenstöpseln wie man will.

    Möchte zum Bespiel jemand eine Matrix in der ungewöhnlichen Dimension 8 * 64, dann nimmt er sich 4 Boards legt sie in einer Reihe nebeneinander hin und fertig! In der Software stellt er ein: Num_Boards_X = 4 und Num_Boards_Y = 1. Mit der selben Anzahl an Boards könnte er aber auch eine Matrix 32x16 zusammelegen indem er 2 nebeneinander legt und danach nochmal 2 darunter. In der Software Num_Boards_X = 2 und Num_Boards_Y = 2 einstellen und los geht's.

    Was ich mit dem vielen Text eigentlich sagen will ist, dass wir von Beginn an sehr großen Wert auf Universalität unserer Module und auch der Software gelegt haben.

    Ich freue mich schon in den nächsten Tagen eure "Wunsch-Formate" einzupflegen!

    @Pesi: Sagst du mir bitte ganau wie deine WS2801 - Daten raus geschoben werden sollen, was vor den Daten kommen soll und was danach und du hast morgen Abend die neue Software!


    Noch ein paare Wort bezüglich Artnet:

    Wenn mir jemand die Form des Protokolls erklärt kann ich das Ganze gern einpflegen. TCP und / oder UDP Pakete zu verschicken ist kein Problem in Java! Nur muss ich schon wissen wie die Pakete auszusehen haben!

    Aber mal ganz unter uns: In unserer Suppenküche brodelt da etwas, das m.M. sowohl DMX als auch Artnet in den Schatten stellen könnte, aber das in einem anderen Thread, lasst euch überraschen ... 8) Obwohl ein kleiner Vorgeschmack ....



    Bis die Tage,

    Pepe

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Pepe_1981“ ()

    Pepe_1981 schrieb:

    Von daher also genau das was die Software auch jetzt schon macht! Wenn mir also jemand sagt was genau an Bytes für einen solchen Controller vorangestellt und angehängt werden muss, dann hack ich das in 5 min in die Software rein.
    Guckst Du dazu hier und hier... ;)

    es muss halt vorne ran als Startbyte 0x5A - dann kommt das Header-Byte, das angibt, wie groß der Frame ist:

    A0 = 96 Bytes
    A1 = 256 Bytes
    A2 = 512 Bytes

    inoffizielle Größen (verwende ich, dazu ja diesen oben verlinkten Thread aufgemacht):

    B0 = 768 Bytes
    B1 = 1.536 Bytes
    B2 = 3.072 Bytes

    danach kommen dann eben die Nutzdaten - hier beachten: es muss eben die im Header angegebene Anzahl geschickt werden, werden weniger Bytes gebraucht, dann auf die Framegröße auffüllen...

    danach kommt dann das Blockende-Byte 0xA5, danach der nächste Frame...

    das ist von dem her natürlich bisschen komplizierter, weil man eben nicht einfach nur Startbyte und dann die Daten in beliebiger Menge schicken kann - schau' Dir doch mal diese Pixelcontroller-SW an, da ist der Quellcode ja dabei, da ist ein Ausgabemodul mit drin, das das so macht...

    klar, da hast Du natürlich recht, einfacher ist es, ein reserviertes Startbyte zu haben, und dann halt nur noch 255 Helligkeitswerte (inkl. "aus") statt 256 - reicht ja auch dicke, da sieht kein Mensch nen Unterschied... das hatte ich mir anfangs auch schon so überlegt, da wäre halt "255" der Framestart gewesen, Daten von 0-254, wird 254 empfangen, dann wird die Helligkeit auf 255 gesetzt (oder halt bei ner Tabelle entsprechend verteilt)...

    ich habe dann halt doch auf Mini-DMX gesetzt, einfach, weil es dafür schon einiges an fertiger SW gibt (Freestyler, PCdimmer, DMXcontrol, ...), und dann eben auf weitere Framegrößen erweitert, damit man mehr als ein DMX-Universe ansteuern kann...

    dieses Daisy-Chain-Prinzip geht übrigens mit DMX auch, da habe ich für jemanden im Forum hier z.B. ne SW gemacht, die auch immer die ersten X Byte (waren glaubich 24 für 8x RGB auf so Streifenplatinen) "raus nimmt" und den Rest weiter schickt, da kann man auch einfach die Platinen mit "automatischer Adressierung" hintereinander hängen...

    EDIT: Hier z.B. werden die Empfänger auch nach dem selben Prinzip "automatisch adressiert"
    - noch mal EDIT: Nee, sorry, da ist das Prinzip etwas anders, da wird ne Adresse mitgeschickt und die raufgezählt, das lässt sich also nicht beliebig fortsetzen...

    und:

    Pepe_1981 schrieb:

    An dieser Stelle kommt ein kleiner Kunstgriff, der aus der eigentlich asynchronen seriellen Datenübertragung eine synchrone macht!
    das ist so nicht ganz richtig: asynchron = nur eine Leitung, ohne extra Takt, synchron = mit extra Taktleitung... ;)

    bei Mini-DMX geht das leider nicht so einfach, eben wegen der festgelegten Framegrößen...

    übrigens könnte man auch mit dem FT232 direkt DMX ausgeben, das muss dann die SW am PC steuern: zum erzeugen des Break einfach die Baudrate auf die Hälfte setzen und ein Nullbyte schicken, das ergibt dann Break-Pegel für die Länge von 2 Bytes, wie gefordert - dann wieder die Baudrate auf normal, ein Nullbyte schicken (das Startbyte), dann die Daten...

    gibt auch fertige Interfaces, die das so machen, ist nur ein FT232 mit RS485-Bustreiber dran... mehr HW wäre da also gar nicht nötig

    DMX macht aber m.M. nach *nur* dann Sinn, wenn man schon fertige, gekaufte Matrix-Module hat, die halt DMX brauchen - wenn man da was selbst baut, dann ist es auf jeden Fall sinnvoller, ein eigenes Protokoll zu verwenden, wie eben Eueres, oder das modifizierte "Mini-DMX"...

    EDIT: man könnte natürlich auch das DMX-Protokoll entsprechend "erweitern": einfach bei größeren Matrixen dann halt mehr als 512 Kanäle schicken :D - auch den FrameError als Blockstart benutzen, dann hat man für die Nutzdaten weiter 256 Werte... ist aber natürlich ein bisschen aufwändiger - dafür bleibt man (bei gleicher Baudrate) "abwärtskompatibel" zu normalen DMX-Geräten, weil denen ist es ja wurscht, ob nach "ihren" nun noch 100 oder 1.000 weitere Kanäle kommen...
    It's only light - but we like it!

    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „Pesi“ ()

    Ach, noch was:

    Pepe_1981 schrieb:

    Weiter arbeitet das Steuermodul hinsichtlich der Datenfütterung wie 128 hintereinander geschaltete WS2801 !!! Auf deutsch heißt das, dass man einfach die Daten für seine Matrix pixelweise seriell auf das Board schiebt, dieses sich die Daten für 128 Pixel abgreift und alles was sonst noch an Daten kommt einfach durchreicht zum nächsten Modul! Man kann also quasi unbegrenzt die Größe seiner Matrix erweitern!! Zudem kann man seinen vohandenen Controller für WS2801-Pixel weiterhin benutzen!
    Das oben von Dir beschriebene ist dann aber nicht das selbe Protokoll wie beim WS2801 - da gibt es kein Startbyte, die Übertragung erfolgt synchron (eben mit extra Taktleitung), und es gibt daher also auch kein Start- und Stoppbit...

    "vorhandene Controller" wie Onumen, LEDwalker, SEDU-Board, fertiger DMX/WS2801-Umsetzer, ... geben das natürlich auch so aus - dabei ist die Taktrate auch nicht festgelegt, alles in allem, wenn Du das "Data"-Signal von nem WS2801-Controller an nen UART hängst, kann der nie und nimmer auch nur irgendwie gültige Bytes erkennen... ;) - also kann man diese Controller mit Eurem Board nicht benutzen

    oder habt Ihr da nen speziellen Eingang zusätzlich, an den man das WS2801-Signal (Data und Clock) einspeisen kann...? - würde ja im Prinzip gehen, mit dem HW-SPI z.B. - und eben 1 ms Pause zum anzeigen eines neuen Frames, Startbyte geben diese Controller ja auch keins aus...
    It's only light - but we like it!

    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!
    Hallo noch einmal,

    @Pesi

    Ja da habe ich mich mal wieder missverständlich ausgedrückt! Die Software ansich oder ein PC kann WS2801 nicht ohne zusätzliche HW antreiben!

    Ich bin es halt so gewöhnt das ich an meinem USB-Kabel ein Arduino-Board dran habe! Wenn man also WS2801-Pixel mit der Software nutzen will dann nur mit einem kleinen ATmega dazwischen! Die Firmware für den ATMEGA habe ich fertig, kommt auch auf die Projektseite zum Download! Ach, ja und eben diese Firmware empfängt aus Kompatibilitäsgründen (wer hätte es gedacht :-)) auch ein Startbyte, daher kam meine leicht vereinfachte Aussage bezüglich der einfachen Nutzung mit unserer SW.


    Das Mini-DMX Protokoll werde ich morgen implementieren!


    @all

    Noch eine kleine Schae die ich vergaß:

    Wenn ihr die Software am laufen habt und mit der linken Maustaste in das mittler Ausgabefenster klickt so öffnet sich ein separates Ausgabefenster, welches in seiner Größe frei skalierbar ist! Ein weiterer Klick in eben dieses Fenster wechselt in den Vollbild-Modus! Und das Tolle: Das klappt auch bei mehreren Monitoren oder mit Laptop und BEAMER! Für die ganz Geizigen oder wenn's mal schnell gehen soll also quasi die billigste RGB-LED-Matrix der Welt :) Und die Größe kann man selbst wählen! :) Ab 200x100 könnten aber alle PCs die keine Zockermaschinen sind leichte Probleme bekommen :)

    So long,

    Pepe

    Pepe_1981 schrieb:

    daher kam meine leicht vereinfachte Aussage bezüglich der einfachen Nutzung mit unserer SW.
    neenee - in der Richtung ist's klar, dass man mit Eurer SW (und nem kleinen simplen Umsetzer) eine WS2801-Matrix ansteuern kann - habe übrigens auch schon angefangen eine "Euer-Protokoll" (Gibt's da nen Namen...? - wie wäre es mit "PepePixelStream"...?) auf WS2801-Umsetzung zu machen...

    es geht um die *andere Richtung*: Die Aussage war ja:
    Zudem kann man seinen vohandenen Controller für WS2801-Pixel weiterhin benutzen!
    Also *Eure Module* mit nem Onumen, LEDwalker, o.ä. ansteuern, und das geht eben nicht so einfach wie sich das liest, "einfach Eure Boards an den Controller ran und fertig", da muss dann auch ein Umsetzer hin, der eben das WS2801-Protokoll empfängt (2 Leitungen) und Euer Protokoll über USART ausgibt...

    und da diese Kisten mit bis zu 25 MHz Takt raushauen, wird's evtl. auch mit dem HW-SPI schon schwierig, die Daten da rein zu bekommen... diese Richtung ist also nicht so ganz trivial
    It's only light - but we like it!

    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!
    Verdammt, da hast Du natürlich vollkommen recht!

    Da habe ich mich ja ordentlich vertan :cursing:

    Die eigentliche Aussage sollte natürlich sein, das man für WS2801 - Installationen gar keinen extra Controller mehr braucht sondern nur Software und nen kleinen Atmega als UART-SPI-Umsetzer!

    Man man man, manchmal frage ich mich wo ich beim Schreiben meine Gedanken habe! Aber dafür gibt es ja Gott sei Dank aufmerksame User hier!

    Cheers,

    Pepe
    Moin Leute,

    ich habe eure SW runtergeladen, aber kann sie nicht ausführen :S

    System: Windows 7 64Bit

    Habe mir auch das Java runtergeladen und Installiert

    Wenn ich auf die Datei klicke, kommt für 1 Sekunde das Ladesymbol und dann nichts mehr...

    Der Blick in den Installationsordner brachte folgendes zu Tage:

    C:\Program Files (x86)\Oracle\JavaFX 2.0 Runtime

    C:\Program Files (x86)\Oracle\JavaFX 2.0 SDK

    in beiden Verzeichnissen sind mehrere Ausführbare .exe Dateien bin irgendwie überfragt ^^

    zur Zeit will der PC die Datei "Glediator.jar" mit: "Java(TM) Platform SE binary" öffnen, was ja nicht funktioniert ;)


    Jemand eine Idee bzw. den Namen der .exe die ich zum Ausführen nehmen muss ?

    Danke

    und mfg

    Nils

    youtube/hamburgtechDE <- LED Tutorials!
    :thumbsup:
    Facebook/hamburgtech
    hamburgtech.de


    Keep calm and watch LEDs!
    Hallo,

    sieht ganz danach aus, als hättest du die JAVA FX installiert und nicht das JAVA JDK!!!

    oracle.com/technetwork/java/ja…7u2-download-1377129.html

    Da findest du den richtigen download für dein System!

    Und nicht vergessen danach auch die RXTX für dein System installieren! Das findet sich in deinem Fall über eine einfache Google-Suche nach "RXTX 64bit" --> Auf der Seite auf die Du dann gelangst findet sich auch eine super Anleitung, wie Du die RXTX aus der ZIP-Datei auf dein System bekommst, d.h. welche Dateien wohin kopiert werden müssen!

    Falls es dann immer noch nicht klappen sollte einfach nochmal melden!

    Schönen Abend noch und viel Spaß beim Probieren!

    Bitte lass uns danach dein Feedback zuteil werden! :)
    Also ich habe diese Seite gefunden cloudhopper.com/opensource/rxtx/ und mir die Zip-Datei ch-rxtx-2.2-20081207-win-x64.zip geladen.
    Werde die Dateien gleich mal nach Anleitung (Install.txt) in die Ordner packen.

    Muss aber erstmal schnell Einkaufen gehen ;)


    Habe nochmal JDK geladen, unter dem von dir angegebenen Link und installiert.

    Problem in folgendem Verzeichnis: "C:\Program Files\Java\jdk1.7.0_02\bin" sind 47 .exe Dateien.. ich habe einfach mal alle durchgeklickt, bei den meisten ist nichts passiert und die anderen waren auch nicht das Richtige. Wo versteckt sich denn die .exe die ich brauche ;) Ich muss Windows ja sagen mit welchem Programm es die Glediator.jar öffnen soll ;)



    mfg

    Nils

    youtube/hamburgtechDE <- LED Tutorials!
    :thumbsup:
    Facebook/hamburgtech
    hamburgtech.de


    Keep calm and watch LEDs!
    Irgendwie ist der Wurm drin ;)

    Doppelklick erzeugt ein Eingabeaufforderung Fenster, das für weniger als eine Sekunde zu sehen ist, habe durch wildes auf die Tastatur hacken einen Screenshot machen können ;)



    Also ich lese da:

    Fehler Hauptklasse Pfad/.....Glediator.jar konnte nicht gefunden oder geladen werden.

    An ein Lesen ohne den Screenshot war nicht zu denken ;) zack und weg

    Sorry ich komme mir selber schon wie der letzte Noob vor

    youtube/hamburgtechDE <- LED Tutorials!
    :thumbsup:
    Facebook/hamburgtech
    hamburgtech.de


    Keep calm and watch LEDs!

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „Unreal87“ ()