Fragen zum tpm2-Protokoll

  • 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.

    Da gebe ich dir vollkommen recht! Bereue es nur, dass ich mich Jahre zuvor von programmiersprachen (wegen der liebe zur musik) verabschiedet habe. Da war mir auf der bühne mit der e-gitarre bisschen rumrocken lustiger. Deshalb finde ich Arduino i.M für mich echt cool, weil man da nicht unbedingt wie du schon sagst sich mit tausenden registern beschaftigen muss.


    Ich muss auch ehrlich zugeben, dass ich für meine videowall projekte nur noch FPGA's von china bevorzuge, weil i.M es wirklich unmöglich ist, den preis-leistung effekt was die da anbieten hier mit 8bit MC zu realisieren. Aber wie schon vorher erwaehnt, find ich den lernprozess und spass hier nicht bei einem fertigprodukt, mit dem man auch nix weiter experimentieren kann. Steckst halt in die steckdose und es funktioniert, fast schon zu langweilig für mich :) Diesen "mal selber machen" effekt hat man auch wirklich nur wenn mann selber mal was lötet. Also "Hör mal wer da lötet!!!" wie Tim Allen :)


    Vielleicht aendert sich die lage ja bald, da es ja jetzt den Arduino Due gibt, der nen ARM cortex M3 drauf hat, und wie ich gelesen habe soll der ja die Arduino libs komplett unterstützen, und auch sogar den wiz5100, oder war es der wiz5200? Dann könnte man natürlich mehr rausholen.

    Zitat

    Die Anzahl der Pakete hat doch nix mit deren Headergröße zu tun!?

    Sorry! Hab es falsch verstanden, meinst also die paketnummer/universe. Das erklaert natürlich auch die 3 dahinter.
    Ich habe auch mittlerweile die Paketnummer von der tpm2net routine komplett rausgenommen (von meiner sendesoftware auch), da ich es ja auch besser finde alles in einem paket zu senden.



    Ich habe mal letzte nacht wieder bissl rumgewurschtelt und einen lustigen test gemacht, und bin auf 768 pixel mit 2304 bytes gekommen. Die grenze mit den 256 pixel ist also erstmal wech. Edit: Ich hab das alles erstmal mit USART TX mit 1mbit baudrate out getestet. Also noch nicht mit ws2801 pixeln.


    also
    #define NR_OF_PANELS 1
    #define PIXELS_PER_PANEL 768
    #define UDP_PACKET_SIZE 2304


    Was ich gemacht habe ist:
    Ich habe TPM2NET_HEADER_SIZE auf 2 gestellt.
    Ich check in der firmware nur noch Header ID und Dataframe bytes ob die stimmen. Ganz am ende im code natürlich noch blockende byte.
    Das heisst die framesize wird nicht mehr in der header size benannt.
    Paketnummer byte wie gesagt komplett raus, auch von der sende software.


    Und siehe da, geht locker mit 768pixel und 25fps. Hab jetzt zwar nur 100 pixel angeschlossen an der HW. gehe aber davon aus, dass über 100 pixel auch in ordnung sind.


    Ich weiss jetzt natürlich nicht ob das hier in euren augen jetzt total bescheuert oder doch ein bisschen hilfreich ist. :rolleyes:


    Das hat aber noch ein haken: Nach ca. 1 minute haengt der MC. Wenn ich beim MC reset mache, dann gehts wieder eine naechste minute weiter.
    Hab erstmal nen delay mit 500us im main loop angegeben. Trotzdem haengts nach 1 minute. Hat jemand da ne idee was mann noch dabei aendern könnte? Mit PixelController konnte ich das noch nicht testen, weil ich in eclipse noch nix kompilieren kann. Michu, haettest du mal zeit und lust, die tpm2net routine in PixelController so zu aendern und vielleicht mir zum testen mal nen link geben?


    gruss

  • Hallo leddie,


    na geht doch voran! Es ist immer nützlich sich ein paar States über ein UART ausgeben zu lassen... hilft sehr gut beim Debuggen...



    Ich check in der firmware nur noch Header ID und Dataframe bytes ob die stimmen. Ganz am ende im code natürlich noch blockende byte.
    Das heisst die framesize wird nicht mehr in der header size benannt.


    Das musst du mir näher erklären. Wie findest du denn das Abschlussbyte, wenn du ohne die Paketlänge arbeitest? Hast du in Software erstmal eine fixe länge eingestellt? Willste nochmal den Source hochladen?
    Also liegt ja dein alter Fehler bei dem Auslesen der Länge!?


    Wenn der MC sich aufhängt, bleibt er ja irgendwo im Source stehen. Wäre jetzt sinnvoll hinter jeder relevanten Zeile ein laufende Zahl auf UART auszugeben... dann wissen wir auch alle wo er hängen bleibt ;)


    Grüße


    Basti

  • Naja, mit solche Aussagen wie: es unterstützen nicht alle Router und Switches man sollte da speziell nachgucken, wäre ich Vorsichtig, wenn die Info von 2004 kommt. Das ist ja PC technisch gesehen uralt..


    Also, eigentlich kann es doch jeder selbst mit nem Ping ganz leicht ausprobieren... am besten vorher Wireshark anschalten:


    Windows:


    cmd aufrufen und mal in japan anpingen (wird dann hoffentlich oft genug rumgeroutet ;) :(



    Dann mal mit dem -f flag -> gibt warnung aus wenn es fragmentiert werden soll:



    und jetzt noch mal das selbe ohne -f




    Man sieht nichts von der Formatierung, aber im Wireshark steht folgendes:



    Naja, alles nix neues.


    Wie Pepe schon sagt, wenn dann muss man den IP Stack so auslegen... Ansonsten ist die Option mit den TMP2.net Paketnummern ne schicke Lösung. Zwar etwas mehr Protokolloverhead, aber wen störts


    Grüße


    Basti

  • Ahem, ich denke mal dass die Kommunikation mit dem TPM2.NET Protokoll in den meisten Fällen innerhalb eines LANs stattfinden wird. Da hängt dann idr auch kein Router zwischen. Daher ist mir nicht ganz klar, was du uns mit dem Beispiel sagen willst?!
    Und ja, im Jahre 2013 kannst du davon Ausgehen, dass halbwegs aktuelle NICs und Switches JF unterstützen.
    Das wäre eben eine "einfache" Möglichkeit das Fragmentierungsproblem zu umgehen.

  • Nein, ich verstehe leider nicht.
    Oben schreibst du

    Zitat

    l in japan anpingen (wird dann hoffentlich oft genug rumgeroutet ;) :(

    Danach schreibst du

    Zitat

    das nach außen Routen war jetzt nicht nötig

    Warum gehst du dann nach Japan? So testest du nicht deine Hardware, sondern die komplette Route nach Japan. Das hat dann leider nicht mehr viel mit deinem LAN bzw. deiner Ethernethardware zu tun.


    Und was heisst bei dir geht aller Verkehr durch die Fritzbox? Hast du nur einen Laptop im Subnet und die Fritzbox routet zu weiteren lokalen Geräten? Oder hast du garkeine weiteren ethernet Geräte?
    Dein nächster Pingserver (ich denke du meinst einen normalen Ethernetteilnehmer, der Ping replys ausgibt?) ist deine Fritzbox.
    Und Jumboframing ist nur was fürs LAN. Daher kann ich nicht erkennen was du uns mit dem Test sagen wolltest.


    Die zwei wichtigen Fragen wären:
    - Wäre Pepe bereit in seinem Glediator eine Checkbox einzubauen, die Jumboframes bei TMP.NET ermöglicht? Bietet die Java Net Class diese Funktionalität?
    - Der Ethernetstack auf der Empfängerplatine muss dann genug Speicher haben um das große Paket zu puffern und dieses eben auch verarbeiten können.


    VG


    Mode

  • Hallo,


    es ist in der Tat sinnlos bis nach Japan zu pingen, bis zur Fritzbox ist völlig ausreichend (ist mir in dem Moment auch gar nicht in den Sinn gekommen). Geb ich dir vollkommen recht. Aber mit beiden Methoden kann man seine locale Hardware testen (zwischen client PC und server)... fands halt witzig die Latenz bis Japan zu testen ;)


    Nö, hab leider nur noch den Lappi meiner Freundin, da geh ich net ran und der war aus... ;) Wenn ich also mein switch testen wollte, ob es das IP Fragmentieren beherrscht, dann würde ich den einfach zwischen meinem Rechner und Fritzbox hängen. Man kann natürlich auch eine Hardware hinter dem switch booten das das ICMP Protokoll drauf hat. Ich denke das wird die Ethernet lib bei arduino aber nicht drauf haben...


    Sooo, ich hoffe mein Visualisierungsversuch ist hier etwas deutlicher geworden ;)


    Grüße


    Basti


    P.S. Hier mal ergoogelt... ICMP Ping lib für arduino: http://arduino.cc/forum/index.php/topic,8701.0.html



    *edit* Mich würde interessieren ob das WLAN Modul von Pesi die fragmentierten Pakete wirklich verarbeiten kann oder ob der von Pesi beschriebene Fehler durch einen interen Bufferüberlauf zustande kam. Kennt jemand eine Möglichkeit ein IP Paket fragmentieren zu lassen, obwohl es erst zB. 1300 Byte beinhaltet? Dann könnte man das ja nochmal testen... ^^

  • Habe über ethercard ne wichtige info gefunden. Das erklaert einiges :/
    Der jeniger der diesen lib gemacht hat, meint dass nur 1 paket (max.1536 bytes) von diesem lib bearbeitet werden kann. Und dass allein schon zu gross für nen mega328 waere...


    http://forum.jeelabs.net/comment/7052#comment-7052


    Der test mit meinem header size auf 2 schrinken funktioniert komischerweise nur bis 256 pixel. Die ersten 128 sind flüssig, zweite 128 pixel zu lahm, und dritter bekommt sehr selten daten, wenn dann nur noch müll daten was noch übrig bleibt.


    Also switch ich erstmal wieder um auf orginal tpm2net headern, und versuche mit den 256 pixeln zufrieden zu bleiben.


    Mit orginalem tpm2net protokoll (mega644p & enc) & Glediator: 3 paketen (128px pro paket) und 1152 udp buffer ist die framerate schon bei ca 5-10 fps.


    Die wiz5100 lib ist denke ich ajf besser als ethercard lib gemacht (und der wiz5100 chip ist ajf besser als der Enc).


    Ausserdem, warum Pepe mit ner reinen ARP, UDP stack (denke hast nicht die ethercard lib komplett benutzt?), mit ner mega1280 locker auf 32x16 pix kommt ist glaube ich wegen SRAM im MC. Ich schaffe 16x16 mit mega644p der 4kb sram hat , Pepe's 1280 hat ja 8kb und schafft 32x16. Und weil Michu ja 2 kb hat, kann er nur 16x8 pix kontrollieren.


    Das wars nun... Wie Pesi schon meinte "schade" eigentlich, aber jetzt weiss ichs ajf bescheid. Falls noch jemand glaubt, dass man vom MC irgendiwe mehr rausholen kann, dann kanns wie Weinachten werden :)


    Gruss & danke


    EDIT: Anbei noch die Serial-OUT version. Ist das so ok mit dem Serial.writes? Oder kann man das noch besser bzw richtig machen?

  • Mich würde interessieren ob das WLAN Modul von Pesi die fragmentierten Pakete wirklich verarbeiten kann

    Du meinst, *nicht* verarbeiten kann, oder...?


    ich könnte mal den Test machen (bei Gelegenheit, liege gerade auf dem Sofa, habe mir schon wieder so ne doofe Erkältung eingefangen, Schädel brummt total...), dass ich halt nen tpm2.net-Frame mit 1.500 Bytes oder sowas schicke - der müsste dann ja schon fragmentiert werden (da über 1.472), sollte aber inkl. Overhead in den 1.600-Byte-Puffer des RN-171 passen...(?)


    gibt's dann wieder die Meldung, dann kann er wohl das fragmentierte nicht - ansonsten sollte der Frame dann ja richtig rauskommen...


    nur so aus Neugier - hilft mir dann nicht wirklich was, weil größere Frames (also z.B. 1.000 Pixel in einem Block) kann ich ja deswegen auch nicht schicken...

    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!

  • Ach, hier noch:

    Ne meinte eher Leddie und michu, da die ja die Arduino lib benutzten. Wäre mal ganz interessant wie schnell die ist...
    Denn 1 MBit empfangen und dann als serielle Aufgabe mit 1 MBit senden, macht auch nur ein Datendurchsatz von 0,5 MBit...
    Der ENC läuft bei nem 16 MHz Quarz mit 8 MHz, aber son TCP/IP ist ja von nem kleinen 8 Bitter auch nicht sofort abgehandelt...

    klar, stimmt - da werden ja erst mal die Daten komplett aus dem ENC in den µC geholt, und dann ausgegeben, richtig..?


    da hatte ich nicht dran gedacht, weil bei mir ja während der Ausgabe schon wieder "gleichzeitig" empfangen werden kann... ich komme also tatsächlich auf 1 Mbit Durchsatz...


    hier, das kommt mit den Zahlen dann schon hin... noch Zeit für den Stack, dann noch die 500 µs zusätzliche Pause, da kann's schon sein, dass es nur noch 300 kBit/s netto sind, und damit dann eben um die 300 Pixel...

    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!

  • Also, ich hab's jetzt mal getestet: Von Pixelcontroller 500 Pixel (= 1.500 Byte) auf's Modul gesendet - im Netzwerkmonitor zeigt er mir ein UDP-Paket mit 1.518 Byte an (insg., inkl. Ethernet-Header) und dann noch ein Fragment mit 72 Byte...


    sind zusammen 1.590, sollte also in den Puffer des RN-171 passen...


    trotzdem kommt vom Modul wieder die Fehlermeldung:


    Zitat

    *CLOS*
    Unrecoverable failure (7) Misaligned address at PC=00039a84
    The system will be reset

    gehe mal davon aus, dass das an diesem Fragment liegt, er damit nix anfangen kann...


    lange Rede/Versuche kurzer Sinn: ich würde das also generell so machen, dass ein tpm2.net-Frame dann auch nicht größer als 1.466 Byte sein soll (^= 488 Pixel), sind dann inkl. tpm2.net-Header 1.472 Byte, da tritt noch keine Fragmentierung auf... sollte dann also mit jeder HW (natürlich vorausgesetzt, sie kann überhaupt so viele Pixel) funktionieren...


    werde ich dann im Protokoll-Thread auch noch ergänzen

    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 Pesi,


    gestern Abend hat es mich auch noch in den Fingern gejuckt und hab das mal selbst getestet... Also RN-171 angepingt und den selben Fehler bei fragmentierten Paketen bekommen. Bissel gegoogelt und da gibts einige Foren wo gesagt wird: "Auf die 2.30 updaten und dann kommts nicht mehr"...
    Hab dann gestern ewig versucht up zu daten... ohne Erfolg... obwohl es schon eine neue 2013er Version gibt: 2.36 (oder so)... vielleicht bekommst du es ja hin...


    Grüße


    Basti

  • Hallo in der Produktbeschreibung steht folgendes:



    Ich hab gerade mal auf meinem Renesas Dev. Board, auf dem meine Webbasierende Heizungsteuersoftware läuft, getestet ob Adam Dunkels uIP Stack Fragmentierung erlaubt. Aber auch da Fehlanzeige... X(


    Wüsste aber nicht warum die hier auf ARM wechseln solltest. Ich denke der ATMega ist dazu in der Lage nen paar LEDs anzusteuern. Würde mal einen ATMega versuchen der zwei Hardware SPI Interface hat.
    Zur IP - Fragmentierung muss man man wohl die lib etwas abändern...

  • Danke Basti, die info ist hilfreich. Steht ajf schwarz auf weiss : Not support IP Fragmentation :/


    Dass viele oder fast alle uC stacks ohne IP fragm. sind verstehe ich nicht. Ist es vielleicht zu schwer zu programmieren oder reicht den meisten leuten einfach 1500 MTU?


    Ich sehe im tpm2net halt sehr viel potenzial, aber dass man da nicht alles wg. IP Fragmentation rausholen kann nervt halt ;) Wie du schon sagst, da waere sicher ein eigener stack die ultimative lösung wenns nicht zu viel arbeit ist...

  • Irgendwie fehlt noch nen Byte das sagt, wieviele Packete denn jetzt eigentlich abgewartet werden müssen... Klar kann man immer bis Packet 0 warten und die höchste Packetzahl als Maximalpackete speichern, aber das könnte auch mal zu komischen Erscheinungen führen, wenn man das so adaptiv umsetzt...


    *edit* nagut, man kann es ja anhand der Gesamtdatenbytes bestimmen, aber irgendwie...

  • Das ist so gedacht, dass praktisch der Empfänger vorgibt, wie viele Pakete er "erwartet"...


    Beispiel: Du hast ne RGB-Matrix mit 32x32 = 3.072 Bytes, dann würde ich das so aufteilen, dass man 3 Pakete á 1.024 Bytes schickt - das muss man dann so im Sender einstellen...


    das ist ja hauptsächlich für so Sachen wie Matrix, Pixelstripes, etc. gedacht - da ändert sich ja nix an den Paketgrößen und -Anzahl, so lange man an der HW nix ändert... muss also auch nix adaptiv angepasst werden


    also es ist ja irgendwie sinnlos, dass man dann auf diese Matrix, die 3.072 Bytes erwartet und "braucht" mal 2.000 Byte schickt und mal 4.000... ;)

    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!

  • Ja, dass ist halt wieder Ansichtssache. So muss der Empfänger wieder etwas smarter sein (Schnittstelle wo man was einstellen kann), obwohl ja der Sender eh schon was größeres wie nen PC mit Glediator ist....


    Benutzerfreundlich ist es halt dem User so wenig Einstellung wie möglich zu bieten. So hält man die Fehler klein... Werd das dann irgendwie ausrechnen lassen... entweder über die Gesamtpixel oder das Maxpacket halten...


    Grüße basti

  • So muss der Empfänger wieder etwas smarter sein (Schnittstelle wo man was einstellen kann)

    Nee, die braucht's nicht, das ist ja fest eingestellt, das gibt die HW vor...


    so ähnlich wie, Du hast nen Movinghead, da ist's ja auch fest, der hat soundsoviel Kanäle, Pan, Tilt, Dimmer, RGB, Gobo, ... und Du stellst am Sender ein, was was ist.


    ich versteh' ehrlich gesagt nicht ganz, wie Du das meinst, kannst Du ein konkretes Beispiel geben...?


    Beispiel bei mir: Ich bau' ne Matrix mit nem Xmega mit Ethernet, der tpm2.net empfängt - dort lege ich fest, dass die Matrix 3 Pakete á 1.024 Bytes erwartet - und das bleibt fest, *da* muss ich ja nix mehr dran ändern, da muss ich an der Matrix selbst *gar nix* einstellen - nur im Glediator dann mit der GUI das richtig patchen...


    sind ja dann so wenig Einstellungen wie möglich - und die Matrix "weiß" ja, dass sie 3 Pakete "will", da muss ich ja nicht noch mal im Protokoll mitschicken, dass sie auch 3 Pakete bekommt... ;)


    es wäre übrigens auch möglich, das komplett ohne Benutzer-Einstellungen zu machen, wir haben auch Steuerbefehle festgelegt, es wäre also durchaus möglich, dass beim Verbindungsaufbau die Matrix dem Glediator mitteilt "ich bin ne RGB-Matrix mit 32 x 16 Pixeln, Verkabelung snakeline von oben links, Farbreihenfolge BGR" und Glediator erstellt dann anhand der Angabe die Patchtabelle selbst - aber k.A., ob Pepe den Aufwand machen will...

    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!