Fragen zum tpm2-Protokoll

    Fragen zum tpm2-Protokoll

    Hier können allgemeine Fragen zum in diesem Forum entwickelten Protokoll tpm2 gepostet werden, Antworten von allgemeinem Interesse werden dann auch dort bei den FAQs gepostet.

    Bitte keine Fragen in der Art, was das ganze überhaupt ist und soll, was man damit machen kann etc., das ist alles in dem verlinkten Thread erklärt.
    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!
    Supi! kann ja gleich mal was fragen :)

    Habe zwar schon tpm2net mit einem Arduino laufen, allerdings habe ich die Paketnummer (universe) Funktion noch nicht so im Griff. Ich verstehe es noch nicht so ganz...

    Wenn ich also eine 8x8 matrix in Glediator über tpm2net patche, waehle ich z.b IP 192.168.10.100 - 0/0/0 fürs erste Paket.
    Bei der zweiten 8x8 matrix die auch im gleichen node laufen soll waehle ich dann 192.168.10.100 - 0/0/1 fürs zweite paket. Für die 3. 8x8 dann halt 192.168.10.100 - 0/0/2 u.s.w

    Wie schick ich denn diese pakete von einer einzigen arduino raus? Muss ich dann mehrere tx/uarts pro paket benutzen? Oder geht nur 1 paket pro empfaenger? Oder wie geht das? Hab glaube im moment blackout :)

    danke schonmal
    gruss

    EDIT: Übrigens, der Arduino akzeptiert keine andere Paketnummern ausser der 0 (erster paket/universe in glediator). Das heisst, arduino empfaengt nur Daten und gibts sie nur dann raus, wenn sie von dem ersten Paket kommen. also in glediator praktisch 192.168.10.100 - 0/0/0. Sobald ich 192.168.10.100 - 0/0/1 patche, kommt da bei arduino nix mehr an.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „leddie“ ()

    Wie meinst Du das "kommt da nix mehr an...?"

    Dem Arduino, und dieser Ethernet-Lib (die benutzt Du doch...?) sollte das eigentlich wurscht sein, was Du da einstellst, weil für ihn sind das nur irgendwelche Bytes in nem UDP-Paket, haben für ihn (und die Lib) keinerlei Bedeutung, ob das Byte Nr. 5 (Paketnummer) nun Null oder Eins ist, interessiert den nicht...

    oder meinst Du, die tpm2.net-Empfangsroutine empfängt nix mehr...? - wie sieht die denn aus, wertest Du das Paketnummer-Byte aus..? - wenn das irgendwie so gemacht ist, dass der Nur Pakete mit Nr. 0 nimmt, dann kommen da natürlich keine Daten mehr an...

    Muss ich dann mehrere tx/uarts pro paket benutzen?
    Das kapiere ich nicht - die Pakete werden ja alle über Ethernet geschickt, also über einen Port - da sind dann wie gesagt nur versch. Nummern drin, dazu braucht man ja nicht mehrere Leitungen...

    oder meinst Du bei der Ausgabe an die Pixel..? - die geht ja per SPI, nicht UART...

    das kannst Du hier machen wie Du willst, wenn Du mehrere 8x8 Matritzen an einem Arduino hängen hast, musst Du deswegen nicht die Daten über mehrere Leitungen ausgeben, kannst sie auch einfach in Reihe verdrahten - und Du musst auch nicht versch. Paketnummern benutzen, Du kannst das Ganze ja als eine große Matrix betrachten, und alle Daten dafür in einem Paket schicken...

    das ist reine SW-Sache, wie Du das haben/machen willst - Du emfpängst auf der einen Seite Daten über Ethernet, und gibst sie auf der anderen Seite über SPI aus - Ob Du die Daten auf mehrere Pakete mit unterschiedlichen Nummern verteilst (aufwändiger) oder einfach alle in einem Paket schickst (einfacher), ist dabei im Prinzip egal, Du musst halt die Empfangsroutine anders benutzen...

    z.B., wenn Du mehrere Paketnummern empfangen willst, dann würde ich mehrere Empfangsbuffer anlegen, je nach Paketnummer landen die Bytes dann in diesem oder jenen Puffer

    das hat dann mit der Ausgabe wiederum auch nix zu tun - da kannst Du dann auch den Inhalt jedes Buffers extra an einem Pin ausgeben, oder einfach die Inhalte der ganzen Buffer an einem Pin nacheinander...
    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!

    Pesi schrieb:

    z.B., wenn Du mehrere Paketnummern empfangen willst, dann würde ich mehrere Empfangsbuffer anlegen, je nach Paketnummer landen die Bytes dann in diesem oder jenen Puffer

    das hat dann mit der Ausgabe wiederum auch nix zu tun - da kannst Du dann auch den Inhalt jedes Buffers extra an einem Pin ausgeben, oder einfach die Inhalte der ganzen Buffer an einem Pin nacheinander...
    Genau diese Logik hat mir gefehlt! Also müsste ich (wenn ich es genau so haben will wie ich es mir gedacht habe), einfach mehrere Empfangsbuffer anlegen.
    Da ich ja nicht HW SPI sondern soft SPI benutze, könnte ich halt schon an mehreren pins ausgeben, um kabelsalat zu verhinden.
    Das mit ws pixeln hat natürlich nix mit tx/uart zu tun, habe aber hier einiges schon durchgetestet, und da habe ich als versehen uart/tx geschrieben :) hab ja schon gesagt - Blackout :)))

    Danke dir vielmals :)
    hallo ich nochmal :)

    also mittlerweile bekomme ich von nem 644p und tpm2net mit 25fps nicht mehr als 300 Pixel. 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.
    Verstehe nicht warum das mit tpm2net so ist. ?(
    Könnte mal bitte jemand auch testen und die Ergbnisse hier berichten oder mir nen tipp geben?

    PS: Wenn das alles wirklich wegen dem 644p ist, ungefaehr wieviel pixel würde ich denn mit nem mega2560 und nem ARM kommen?

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

    leddie schrieb:

    Könnte mal bitte jemand auch testen
    Na, da müsstest Du Deine SW hier rein stellen, sonst kann die ja keiner testen.... ;)
    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!
    Welche Software meinst du ? Die von 644p oder die vom PC?

    Die vom 644p ist die von michu's arduino code, den ich auf einem Netino mit nem Enc28j60 zum laufen gebracht habe. Die benutzt die ethercard library. Werd ich dann mal hier posten wenns für Michu auch ok ist.

    Als PC test software hab ich Pixelcontroller, Glediator und den von mir entwickelte tpm2net sender für vvvv benutzt.

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

    Ich hatte die vom 644p gemeint...

    kann mich erinnern, wir hatten da doch schon per PN geredet - ich kann's z.B. leider nicht ausprobieren, weil ich keinen Netino und auch keinen ENC28J60 da habe...

    und wie da auch schon geschrieben, es weiß halt keiner (also ausser dem Entwickler natürlich :D) was diese ethercard library so alles macht, also wie viel "Rechenleistung" die braucht, ich vermute dort den Flaschenhals...

    bzw., wenn's mit Artnet geht (also 340 Pixel flüssig) aber dann tpm2.net nicht, k.A., kann am Sender liegen oder an Deiner Empfangsroutine... bei mir ist's da so, ich benutze ja so nen RN171, der die Daten über Usart ausgibt, bei tpm2 benutze ich nen FT232, der ebenfalls die Daten per USART ausgibt - Empfangsroutine ist bei mir also fast die selbe, nur bei tpm2.net wird halt noch das Paketnummer-Byte empfangen (aktuell aber nicht ausgewertet).

    und da macht's auch keinen Unterschied, läuft beides flüssig, ist ja immer das selbe, es kommt halt ein Byte rein und wird verarbeitet, ich muss keinen Ethernet-Stack abarbeiten oder sowas... also, will damit sagen, an der eigentlichen Empfangsroutine ändert sich praktisch nix...

    ich kann mich gerade nicht erinnern, mit wie vielen Pixeln ich das getestet habe, probier's aber später noch mal aus und sag' Dir dann Bescheid...
    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!
    Netino mit ethercard ist ja nix anderes als ein pollin board mit nem 644p und nem enc28j60 drauf.

    Mittlerweile denke ich aber auch, dass der 8bit MC einfach nicht in der lage ist, den ganzen ethernet stack zu berechnen, dann zu puffern und dann noch via soft spi daten rauszugeben. Wenn ,ch weiterhin keine lösung finden sollte, werd ich wohl demnaechst richtung ARM gehen. Leider ist dann die enc library dann auch schon raus aus dem thema. Der enc ist halt sehr günstig und praktisch, und das war der grund warum ich so lange jetzt an dem zeug rumgebastelt habe. ARM und wiz5100 sollen aber im moment schon gut zusammen laufen.

    Ausserdem war es für mich noch schwieriger, als ich das ganze mit closed source led control software testen musste. Da musste ich halt hoffen, dass sie die richtigen tpm2net daten rausschicken. Da war es mit PixelController von Michu doch noch übersichtlicher, weil man wenigstens den tpm2net sieht und kontrollieren kann, was in der software überhaupt passiert :) Noch besser war es, als ich dann meinen eigenen tpm2net sender software gebastelt habe, nun weiss ich ganz genau was raus oder reinkommt :D

    Mich hat es halt gewundert, dass ja artnet auch den ganzen ethernet-stack kram rechnen muss um daten rauszuschicken. Würd mich freuen, wenn jemand mit C kentnissen mal den code durchchecken kann (synvox?). Vielleicht kann man ja noch was rausholen. Die framesize berechnung die michu gemacht hat sieht ja gut aus. Haette jetzt keine ahnung wo man sonst noch reinschauen müsste.

    Habe das ganze auch mit USART ausgabe getestet. Kein unterschied :/ Bei bedarf kann ich die Usart-out version auch posten.
    ich kann mich gerade nicht erinnern, mit wie vielen Pixeln ich das getestet habe, probier's aber später noch mal aus und sag' Dir dann Bescheid...
    Da bin ich mal gespannt...

    Gruss
    Dateien
    • code.zip

      (1,32 kB, 39 mal heruntergeladen, zuletzt: )

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „leddie“ ()

    Habs mal überflogen... bin aber kein arduino mensch...

    aber diese Zeile sieht komisch aus und da scheinst du ja selbst dran zu zweifeln:

    Quellcode

    1. uint16_t frameSize = ((ptr[3] << 0) & 0xFF) + ((ptr[2] << 8) & 0xFF00); // is this correct?


    also der erste Ausdruck ist sinnlos aber wird sicher vom Compiler in sinnvolles umgewandelt... aber bei dem nächsten Ausdruck wäre ich vorsichtig... du schiebst ein 8 Bit von Rechts in ein Byte und and'st es mit nem word...
    Also ich denke der Compiler macht bei diesem "unsauberen" C folgendes:

    Quellcode

    1. uint16_t frameSize = prt[3];


    Aber genaueres wird dir das ASm Listing sagen

    *edit* ach da is noch einiges mehr... ich würde das nochmal genau anschauen... da gibts noch nen paar ungereimtheiten! Wenn das zu viele Pixel werden, dann erreicht deine for Schleife auch nie ihre Wert und hängt dann fest:

    Quellcode

    1. for (byte i=0; i < frameSize; i++) {


    Wenn Framesize 256, dann wird das Byte das wohl nie erreichen...

    Grüße

    Basti

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

    Hi Basti,

    Die Zeile hab ich von Michu direkt übernommen und bin in sachen framesize berechnungen gar nicht gut. Das ist auch die einzige Zeile die ich nicht verstehe was da passiert. Deshalb auch die verzweiflung. Wie würdest DU denn die framesize berechnen lassen damit da was sinvollen rauskommt. Laut tpm2 protokoll muss ja erst high dann low byte kommen.

    Edit: Hab dein edit grad gesehen und AHA! Tatsaechlich haengt der MC wenn ich mehrere pixel zahl angebe. Also wohl damit was zu tun. Echt super dass wir da naeher kommen. Hatte immer gedacht UDp schickt die daten zu schnell raus deshalb "freeze" am MC :P
    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
    Also lt. Wikipedia (ja, ich weiß, gefährliches Halbwissen :D) kann ein Ethernet-Frame bis zu 1.500 Byte Nutzdaten haben, das sollte in einem Rutsch durchgehen...

    aber schon möglich, dass da das Problem liegt - k.A., ob der ENC so viel Puffer hat, dass er das komplette Paket speichern und auf einmal ausgeben kann...?

    die Diskussion mit dieser Ethernet-Beschränkung hatten wir schon mal irgendwo, deswegen wurde dann bei tpm2.net dieses Paketnummer-Byte eingeführt, damit man größere Bild-Frames auf mehrere UDP-Pakete aufteilen kann...

    irgendwer meinte da zwar, das macht die unterliegende Schicht ja automatisch, also ich kann auch 1.000 Pixel in einem tpm2-Frame schicken, das kommt dann letztlich wieder als ein kompletter an, aber evtl. funktioniert das hier ja doch nicht so wirklich....?

    ich kann's leider grad mit dem RN-171 nicht testen, hatte den auf 1,1 Mbit umgestellt zum gucken, ob das mit AVR auf 1,125 Mbit zusammen arbeitet, aber jetzt komm' ich nicht mehr drauf.... :(

    ggfs. müsstest Du das dann so machen wie weiter oben erklärt, also die Daten auf 2 Pakete mit Paketnummern aufteilen, und die wieder zusammen setzen... wobei dann ein Vorteil von tpm2.net wieder dahin wäre, nämlich der, dass man sich das eigentlich sparen können sollte...
    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!
    Kleiner Nachtrag:

    Versuch doch mal:

    Quellcode

    1. #define NR_OF_PANELS 3
    2. #define PIXELS_PER_PANEL 100
    3. #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
    Ja, da MTU-wert ja sowieso max 1500 bzw 1518 ist, wie soll mann denn dann noch 3072 bytes in einem packet empfangen?? 8) Da muss man ajf das ganze mehrere an packete verteilen und das am bestem wie im artnet halt dann mehrere TX usart's.

    Meine Anmerkung mit Open source etc. war deshalb, weil ich einfach eine bessere Übersicht haben möchte wenn mal was nicht so funktioniert wie ich es mir vorstelle, und ich dann halt bei der fehlersuche flexibler sein kann.
    Solange man nur deine hardware und deine software benutzt ist das ja ok mit closed source. Da muss man sich auch keine gedanken mehr machen und denkt halt, gut, das kommt alles von einem entwickler, also muss ja auch alles funktionieren.
    Da ich aber eher der bastler typ bin, stehe ich persönlich mehr auf open source, um manchmal einfach mehr in den code reingehen zu können um verschiedene konfigurationen zu testen, und falls da mal in der sende software was geaendert werden muss, kann ich das dann auch gleich selber machen. Vielleicht kommt ja dann auch nach soviel experimenten irgednwann tpm3net raus ;)
    Wenn die neugier nicht da ware etwas selber mal zu basteln und zu entwickeln, haette ich sowieso gleich nen fpga mit altera4 vom chinesen für 50 dollar (inkl ethernet) die eh 65000 pixel ohne rummeckern kontrollieren können und mbi5026 für 0.10 cent statt tlc5940 für 2 dollar gekauft, installiert und basta!! :D
    Die 1500 Byte sind nicht wirklich bindend!

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


    3.3.2 Reassembly

    The IP layer MUST implement reassembly of IP datagrams.

    We designate the largest datagram size that can be reassembled
    by EMTU_R ("Effective MTU to receive"); this is sometimes
    called the "reassembly buffer size". EMTU_R MUST be greater
    than or equal to 576, SHOULD be either configurable or
    indefinite, and SHOULD be greater than or equal to the MTU of
    the connected network(s).

    DISCUSSION:
    A fixed EMTU_R limit should not be built into the code
    because some application layer protocols require EMTU_R
    values larger than 576.

    IMPLEMENTATION:
    An implementation may use a contiguous reassembly buffer
    for each datagram, or it may use a more complex data
    structure that places no definite limit on the reassembled
    datagram size; in the latter case, EMTU_R is said to be



    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