Beiträge von Pepe_1981

    Für alle die, die ein Andoid Gerät ihr Eigen nennen:


    http://widar.nu/GlediatorRemote.apk


    Ist aber nicht auf meinem Mist gewachsen, daher ohne Gewähr.


    Wer (wie ich) eher auf Äpfel steht 8) muss sich noch ein bisschen gedulden bis die App (die schon fertig und getestet ist) von Apple offiziell freigegeben wird und dann KOSTENLOS aus dem app store geladen werden kann.



    Prost!



    PS: Auch für die bald erscheinenden Umsetzer-Boards wird es Andoid/Apple apps geben sodass man z.B. die Szenen die Glediator Light abspielt oder das was man von SD-Karte wiedergibt ändern kann via WLAN / BT (ohne PC).

    Der µC ist ein 1284P mit 16 kB RAM.


    Die MAC kann man jederzeit selber konfigurieren, nur ist es halt so, das man ein 'Netzwerkgerät' nur mit gültiger (heißt gekaufter) MAC unter Leute bringen darf. Was nun aber ein 'Netzwerkgerät' ist und was 'nur' eine Platine ohne Funktion, das ist recht schwammig ;(


    Prinzpiell kann das Board alles was physikalisch möglich ist und was die Firmware erlaubt. Also auch 800 Pixel im TPM2.net-Betrieb. Dennoch muss man irgendwo "künstlich" 'ne Linie ziehen wenn man, wie wir, den Anspruch hat alles in einer FW zu vereinen. Denn da muss man halt für ALLES mögliche Vorkehrungen treffen und auch irgendwo einen MAXIMALEN Buffer vorhalten, usw.


    Daher haben wir einfach fest gelegt das _unsere_ FW max. 512 Pixel unterstüzen wird. Wer größere Matrizen baut, der hat zwei Möglichkeiten:


    a.) Die FW selbst ändern
    b.) Mehrere UIBs nutzen, das ist das schöne an Ethernet :D



    Beste Grüße,


    Pepe

    Einen Preis können wir sicher erst nennen wenn wir ein konkretes Angebot vom Bestücker haben. Zudem ist auch noch nicht ganz klar in welcher Menge wir fertigen lassen.


    Bei diesem Board wird sich auch noch die Frage stellen ob man (wir) Lizenzgebühren für MAC-Adressen bezahlen müssen oder nicht. Das wiederum hängt davon ab, in welchem 'Ausbauzustand' wir die Boards später anbieten.


    Es sind also noch viele Fragen zu klären. Die Bauteilkosten an sich sind da mit ca. 25 EUR der überschaubarerer Posten :)


    Eine Vorbestellung wird sicher nicht notwendig sein.


    Für unsere Tests hatten wir 'ne Kleinserie über 10 Stück fertigen lassen. Wenn alle Programmierarbeiten abgeschlossen sind können wir ein paar davon die sicher entbehren, in Deinem Fall würden zwei ja reichen :P


    Hier übrigens mal zwei Bilder von den 'Winzlingen' 8)




    Beste Grüße,


    Pepe

    Hi leddie,


    Zitat

    mann mann, ihr gibt ja auch nicht nach was?
    Ich bin doch kein FW/SW entwickler,


    Hehe, war auch nicht bös gemeint :D Bin selbst auch 'nur' Hobbybastler und 'Try_and_Error' ist auch bei mir z.T. gängige Praxis. Dennoch habe ich immer wieder festgestellt, das das Leben oft um so einiges einfacher wird wenn man sich das ein oder andere Datenblatt bis zum Schluss durchliest und in die ein oder andere Thematik etwas tiefer hineinguckt. :P


    Das allerwischtigst beim Basteln ist für mich aber auch immer der Lerneffekt, da darf es am Anfang auch erst mal _nicht_ funktionieren wenn man bei der Fehlversuch dafür viele neue Sachen lernt. Wie bei Dir eben.


    Es gibt aber auch wirklich Leute denen Fehlerursache und Lerneffekt total egal sind, hauptsache es läuft irgendwie (aber zu denen zähle ich Dich nicht).


    Zitat

    Ja, ethercard lib ist ja auch n mod von Guido Socher.


    Ja, in der Tat sind 70% aller Stacks die so im Netz rumgeistern wohl von ihm abgeleitet. Ich denke das liegt im Wesentlichen nicht daran das ein Stack so wahnsinnig kompliziert wäre, im Gegenteil der eigentliche Stack ist recht überschaubar, aber es gibt zwei Punkte die sehr mühsam sind wenn man sie selbst noch einmal machen will und die man auch nicht wirklich anderes machen kann/will: Zum Einen sind das die Definitionen (Makros) der 'tausend' Register / Bänke auf dem ENC und zum anderen die Ganzen Makros für die verschiedenen Positionen in den Headern der unterschiedlichen Netzwerk-Layer (alles das was in der net.h so definiert ist).


    Zitat

    Verstehe ich das richtig: Du schickst 4 pakete insgesamt, obwohl header size bei tpm2 =5 ist? Oder laesst du dataframe oder was weg?


    Hmm, diese Frage verstehe ich irgendwie nicht ganz!? Die Anzahl der Pakete hat doch nix mit deren Headergröße zu tun!?


    Zitat

    Was meinst du mit der 3? Dritter byte?


    Damit meine ich die Paketnummer im TPM2-Header. Bei meinen 4 Paketen sind das 0,1,2,3. Wenn also die '3' kommt weiß ich das war das letzte Paket.


    LG,


    Pepe

    Zitat

    -> SEND FRAME 2
    -> uP bearbeitet das FRAME 1 immer noch


    Und genau das darf eigentlich nicht sein!


    Ich habe hier selbst unser neues UIB vor mir liegen. Das ist ein Atmega1284P gepaart mit dem ENC. Der Atmega läuft mit 16MHz. In der Verarbeitungsgeschwindigkeit ist das System also äquivalent zu Arduino bzw. zum System von leddie.


    Nun kann ich hier ohne jegliche Probleme unsere 32x16 Matrix (512 Pixel) mit 25 FPS via Glediator mit Artnet oder TMP2 füttern und dabei noch aus dem Terminal 'nen Dauer-Ping auf das Board abfeuern. Paketverlust = NULL. Die Vorgehensweise sieht so aus:


    • Der Stack ist ein selbst abgeleiteter der nur ARP, ICMP und UDP macht. Abgeleitet aus einem Stack von Guido Socher.
    • Pro Frame werden 4 (!!!) Pakete ohne Delay auf PC-Seite an das Board geschickt.
    • In der FW wird der Inhalt eines Paketes nach Empfang einfach nur in einen Speicher an die Stelle [PACKETNUMMER*128] kopiert. Erst wenn das letzte Packet (3) empfangen wurde und in den Speicher kopiert ist startet die Ausgabe-Routine. Denn dann hat man ja bis zum nächsten Packet ca. 40ms Zeit :D
    • Die SPI zwischen µC und ENC läuft mit 4MHz.


    Vielleicht hilft das ja!


    leddie: Was mir noch eingefallen ist. Hast Du in deinem Heimnetzwerk evtl. 'nen Netzwerkdrucker oder ein NAS Gerät sitzen? Die sind nämlich beide bekannt dafür wild mit Broad-Casts um sich zu werfen. Und wenn der entsprechende Filter am ENC nicht gesetzt ist könnte das schon zu 'guter Auslastung' führen.


    Beste Grüße,


    Pepe

    So, nun wieder zurück in Deutschland kann ich mich wieder zu Wort melden.


    Der ENC28J60 macht physkalisch 'nur' PHY und MAC! IP muss der µC und der darauf laufende Stack abhandeln. Mir ist derzeit kein Stack für µC/ENC-Kombination bekannt der IP-Fragmentation behandeln würde. Auch die Ethercard Lib macht das nicht.


    Zitat

    In IPv4, hosts must make a best-effort attempt to reassemble fragmented IP datagrams with a total reassembled size of up to 576 bytes - equal to the minimum MTU for IPv4. They may also attempt to reassemble fragmented IP datagrams larger than 576 bytes, but they are also permitted to silently discard such larger datagrams. In IPv6, this minimum capability is increased to 1280 bytes [6] - larger than the minimum MTU for IPv4.


    Auch der W5100 der ja den completten TCP/IP Stack schon an Board hat ist 'nur' IPv4 konform und so steht in seinem DB auf S.5 u.a.:


    Zitat

    Not support IP Fragmentation


    Das DB vom RN hab ich jetzt nicht im Kopf, aber ich kann mir gut vorstellen das es schon IPv6 konform sein sollte, ist ja nicht so alt. Daher ist es wohl wahrscheinlich das folgender Satz zutrifft:


    Zitat

    In IPv4, routers perform fragmentation, whereas in IPv6, routers do not fragment, but drop the packets that are larger than the MTU


    Viele Information dazu finden sich im Übrigen in RFC791, RFC815, RFC1191, RFC2460.


    Ok, nach diesem kleinen Exkurs nun zum eigentlichen Problem von Dir, leddie:


    Ich bin mir sicher das nicht Dein EtherCard stack Deinen µC langsam macht. Vielmehr denke ich das es entweder Probleme bei der Aufarbeitung des TPM2.net Paketes gibt und/oder Du ein Problem in deinem Netztwerk bezüglich MTU hast.


    Der von Dir beschriebene Test mit der 8x8 Matrix auf zwei Pakete verteilt hat eigentlich alles richtig aufgezeigt! Denn mit


    Code
    #define UDP_PACKET_SIZE 96


    kann es nicht funktionieren. Wie Du aber richtig vermutet hast


    Zitat

    das heisst packtenummer arbeitet nur dann wenn ich auch den gesamten UDP paket in der FW eingebe.


    arbeitet Deine FW nur wenn du auch das ganze Paket (im Übrigen nicht nur den UDP-Teil) aus dem ENC abholst. Denn nur so werden dann auch entsprechenden Zeiger im ENC auch wieder richtig zurückgesetzt. Das alles steht im DB des ENC und im Quell-Code der EtherCard Lib. Und ohne Dir zu nahe treten zu wollen schließe ich mich damit der Meinung von Basti an, das Dein "Rumwurschteln" hier eher nicht zielführend ist. :D


    Ich denke hier wäre es sinnvoll sich etwas eingehender mit der Materie zu beschäftigen anstatt verschieden Code-Fragmente zusammzufügen, auf andere HW zu protieren, hier und da was anzupassen ohne wirklich zu verstehen was da passiert.


    Ich hoffe natürlich dennoch das Du Deine Matrix zum laufen bekommst und werde auch weiter mit (hoffentlich) sachdienlichen Hinweisen zur Seite stehen.


    Eins noch: Besten Dank für Deine Info bezüglich der Patch-Eingabe von TPM2.net in Glediator. Das ist in der Tat ein BUG dass man da max. bis ch 511 gehen kann! War halt ein Relikt das aus DMX übrig geblieben war. Das passiert eben wenn man seinen eigenen Code an andere Stelle kopiert und nicht _alles_ anpasst. :P Werde ich bei der nächsten Version fixen.



    In diesem Sinne beste Grüße,


    Pepe

    Die 1500 Byte sind nicht wirklich bindend!


    Was ALLE ETH-Geräte können MÜSSEN steht in der RFC1122 (http://www.ietf.org/rfc/rfc1122.txt:(



    Dennoch ist es sehr wahrscheinlich, das in der heutigen Zeit (fast) alle Geräte 1500 können :P Aber den Versuch mit der Paketaufteilung würde ich Dir dennoch mal empfehlen!


    Was auch interessant wäre, wäre zu wissen ob die 'magische Grenze' nun wirklich genau bei 300 Pixeln ist oder ob das fließen kommt und immer langsamer wird oder ab einer gewissen Anzahl dann plötzlich ... Damit könnte man sicher noch einiges an Infos gewinnen und die Fehlersuche eingrenzen.


    LG,


    Pepe

    Kleiner Nachtrag:


    Versuch doch mal:


    Code
    #define NR_OF_PANELS 		3
    #define PIXELS_PER_PANEL 	100
    #define UDP_PACKET_SIZE 	500


    Und von Glediator schickst die Daten als 3 Pakete mit den Paketnummern 0,1 und 2.


    Würde mich interessieren wie es dann aussieht!


    LG,



    Pepe

    Zitat

    Alles über 300 Pixel ergibt dann ziemlich kleinen framerate. Hab schon mit 3 verschiedenen software die tpm2net-ausgabe getestet. Normal schafft der 644p ja 2 dmx universen mit artnet protokoll (mit 2 RX ausgaengen), was 340 pixel ergibt, und dazu noch halt ziemlich flüssig bei der Wiedergabe(framerate) bleibt.


    Zwei DMX-Universen werden da als zwei UDP-Pakete verschickt. Mit max. 512Byte Nutzdaten + Artnet-Header + UDP-Heeader bleibt man dabei sicher unter dem MTU-Wert bei dem Pakete geteilt werden!


    Bei TPM2.Net mit 300 Pixeln sieht das schon anders aus! Das sind mit TMP2-Header + UDP-Header reichlich 900 Byte!! Und ob die als _EIN_ Paket ankommen ... ?


    Die müssten dann von der EtherCard.lib wieder zusammengebastelt und erst dann prozessiert werden! Das könnte ein Grund dafür sein das es dann langsam wird.


    Zu Deinen Anmerkungen bzgl. Closed-Source: Es gibt ja für TPM2 (genau wie für jedes andere Protokoll) eine Protokollvereinbarung. Und wenn eine SW TPM2.Net ausgibt, dann eben in diesem Format, ganz egal ob die Open oder Closed Source ist :D


    Beste Grüße,


    Pepe

    Das Board wird Ende Februar/Anfang März offiziell released. Es hat sich ein ganzes Stück verändert, ist kleiner geworden und kann noch mehr als ursprünglich geplant. Die erste Kleinserie von 10 Stück tut was sie soll und wir schreiben fleißig an der FW.


    Ich bin grad dienstlich unterwegs und kann daher keine Photos reinstellen, hole ich aber am Do. nach. Nur soviel vorab:


    • Das UIB 3.0 (Universal Interface Board) kann nun auch WLAN + BlueTooth.
    • Es ist auf 100mm x 60mm geschrumpft.
    • In der Firmware ist ein Stand-Alone-SD-Player integriert der Szenen von SD-Karte abspielt welche man zuvor mit (der neuen Version von) Glediator hochgeladen hat. Welche Szene gerade gespielt wird kann man bequem via PC / iPHONE / ANDROID / BLUETOOTH / DMX-PULT wählen.
    • In der FW ist nun 'Glediator Light' (GL) integriert! D.h. ihr braucht keinen Rechner mehr für Glediator :P GL läuft entweder im Random Mode ODER man kann über PC / iPHONE / ANDROID / BLUETOOTH / DMX-PULT Szenen wechseln / Szenenparameter einstellen.
    • Mit dem UIB und einem DMX-Pult kann man Glediator auf dem PC fernbedienen
    • Zur Konfiguration des UIB 3.0 gibt es ein winziges JAVA-Progrämmchen in dem man alle Parameter und die gewünschte Funktion des UIB bequem per GUI einstellen kann.


    Ach, ja wer das gute Stück schon mal vorab in Aktion sehen will dem möchte ich unseren OpenSpace am 02.02. ans Herz legen :P


    Beste Grüße,


    Pepe

    Dreas99


    Den Eingang den Glediator benutzt muss Dein Betriebssytem bereitstellen, das hat nix mit Glediator zu tun. Es gab füher unter Windows die Möglichkeit in der Systemsteuerung einen Eingang namens "Was sie hören" zu definieren. Damit gab es einen Eingang auf dem alles lag was auch raus ging, so z.B. auch dein Winamp.


    Mit Win7 wurde das aber irgendwie 'versteckt' wenn man danach googelt findet man aber work-arounds (geht aber galube ich nicht mehr bei den Realtek Chipsätzen).


    Glediator listet im Optionsfenster immer alle Eingänge auf die das BS zu bieten hat.


    mirko
    Besten Dank für den Sketch! Wir hatten schon des öfteren Anfragen zwecks LPD-Unterstützung auf Arduino! Jetzt können wir den Leuten endlich 'nen Link geben :thumbup:


    @Uhrmacher
    Ja, in der nächsten Glediator Version werden die letzten Einstellungen beim nächsten Start geladen, versprochen! :rolleyes:



    Beste Grüße und Prost!


    Pepe

    MaddinB


    Schön zu hören das Dir unsere Boards gefallen.


    An einer Standanlone Lösung arbeiten wir gerade fieberhaft :) Die erste Version von "Glediator Light" für µC steht soweit und die Animationen werden nach und nach eingepflegt. Dazu wird es aber zu gegebener Zeit hier noch ausführlicherer Infos geben.


    Das alles wird mit dem offiziellen Erscheinen der nun 3. und finalen Generation unserer Umsetzer-Boards gegen Ende Februar / Anfang März relseased.


    Wer schon einen Vorgeschmack haben will der kann am 2.2. gern zum OpenSpace kommen ... :P


    gibsonuser
    Nun das geht bestimmt "irgendwie", die Frage ist halt ob da das Aufwand/Nutzen Verhältnis gewahrt wäre, wenn man da an jede Zeile und jede Spalt noch ne extra Tanssitor/Mosfet - Kombi dranhängt die aus 'ner KSQ nen Schalter macht! Da würde ich lieber andere Wege gehen.



    Beste Grüße,


    Pepe

    Hallo,


    dieses mal möchten wir den dritten Arduino OpenSpace in Dresden etwas eher ankündigen als die beiden Male zuvor. Dann kommen nämlich (hoffentlich) nicht nur die kurzentschlossenen unter euch auf ihre Kosten :P


    http://www.agile-hardware.de/0…no-open-space-in-dresden/


    Lasst euch nicht vom "Arduino" abschrecken. Jeder der etwas in Richtung µController, Elektronik oder LEDs sehen / hören oder zeigen will ist herzlich willkommen!


    Mittlerweile hat sich auch schon der ein oder andere aus dem Forum hier angemeldet und wir freuen uns schon sehr endlich mal die Personen hinter den Namen kennenzulernen!


    Beste Grüße,


    Pepe

    Unregistered|Guest


    Nun können tut der Programmer das schon, ein Teil der ganzen Flash-Prozedur ist ja auch das Verifizieren. Da lädt er sich nach dem Brennen nochmal den ganzen Flash vom µC und vergleicht ihn mit dem file auf der SD-Karte. Und nur wenn beide zu 100% identisch sind wird der Brennvorgang als erfolgreich gemeldet.


    Es wäre also kein Problem das so zu modifizieren das man 'nen AVR auch auslesen kann (Es sei denn natürlich der AVR ist "verriegelt*).


    LG,


    Pepe

    Lochraster
    Ja der Sockel ist den 8ern vorbehalten, das ist aus ganz "egoistischen" Gründen so entstanden :rolleyes: Aber wie Dein Nachredner schon schreibt, kann man sich ganz leicht (auch auf Lochraster) nen Adapter machen der dann auf ISP geht, Wir selbst haben aber nicht geplant solche Adapter zu entwickeln.


    dgoersch
    Ich muss gestehen das ich mit mit dem PDI interface nicht auskenne. Aber eines ist sicher, es ist ne digitale Datenübertragung die man sicher auch von 'nem AVR aus machen kann. Nur müsste man sich da etwas einlesen und das kostet sicher Zeit ... Will sagen, das es sicher physikalisch geht und wenn mal viel Zeit ist könnte ich mir vorstellen da was zu machen ...



    LG,


    Pepe