Fragen zum tpm2-Protokoll

  • deswegen wurde dann bei tpm2.net dieses Paketnummer-Byte eingeführt,

    Irgendwie achtet die packetnummer funktion auf keine aenderung die ich hier vornehme.



    also ich kann auch 1.000 Pixel in einem tpm2-Frame schicken, das kommt dann letztlich wieder als ein kompletter an,

    Tjai bei mir schon mit 300 pix ist schluss :/



    also die Daten auf 2 Pakete mit Paketnummern aufteilen

    Habe ich schon vor 2 wochen versucht. Empfanger will irgendwie nicht auf packetnummern reagieren.



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


    Würde mich interessieren wie es dann aussieht!

    Wie gesagt, hab schon vor einige wochen ausprobiert mit glediator. Aber es macht einfach kein unterschied.
    Hatte dich mal vor einpaar tagen gefragt, dass man in Glediator tpm2net patchfenster nicht mehr als 512 bytes geben kann. ıst das absicht von dir? oder warum kann ich z.b keine 1024 bytes angeben pro IP? Also dass der Patchfenster dann nicht schliesst wenn ich auf die OK taste klicke.



    Zitat

    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.

    also die "magische grenze" bei Seriellen daten ausgabe (Serial.write) mit 1mbit baudrate ist: 256 pixel mit 768 packet_size. Auch wenn ich nur 3 framesmehr definiere, also z.b 771 eingebe klappt gar nix mehr.
    Bei ws2801 soft spi ausgabe ist dann der framerate bei 300 pixel schon ganz langweilig :( Trotzdem kann ich bei ws2801 ausgabe mit den puffern bisschen rumspielen.



    EDIT:
    Der enc kann 1500 frames auf einmal empfangen, zumindest ist es so in der enc28j60.cpp datei definiert:

    Code
    // max frame length which the conroller will accept:
    // (note: maximum ethernet frame length would be 1518)
    #define MAX_FRAMELEN  	1500
  • melde mich auch kurz dazu


    diese firmware war mal so ein 2h hack, ich habe das ohne pixel getestet, darum ist aktuell noch kein bitbanging drinn und darum auch noch kein delay von 500us. in anderen worten, nicht fertig. aber leddie hat ja da schon begonnen zu arbeiten.


    ein arduino hat 2kb ram, neben dem buffer für die led pixel (3 bytes pro pixel) muss noch das udp frame platz haben - darum habe ich den udb buffer auf 500bytes beschränken müssen.


    und leddie: 300 pixel * 3 = 900 bytes ram für den pixel buffer, 500 bytes für den udp buffer + arduino ram (mindestens 200 bytes) bedarf bedeutet, dass da nicht mehr viel geht. da bräuchtest du schon einen arduino mega (8kb) / teensy++ 2.0 (8kb).


    ich hoffe ich komme in nächster zeit dazu, die firmware zu testen.


    gruss
    michu

  • und leddie: 300 pixel * 3 = 900 bytes ram für den pixel buffer, 500 bytes für den udp buffer + arduino ram (mindestens 200 bytes) bedarf bedeutet, dass da nicht mehr viel geht. da bräuchtest du schon einen arduino mega (8kb) / teensy++ 2.0 (8kb).

    Hi Michu,


    Weil Uno 328P 2kb hat, habe ich ja absichtlich den 644P mit 4kb ram benutzt. Bei 4kb vom 644p bleibt ja schon ein bisschen was von ram übrig. hmm....

  • Dann lass dir doch mal Serial nen paar Daten ausgeben... Nur wurschteln bis es läuft geht nun mal nicht immer...


    Code
    uint16_t frameSize = ((ptr[3] << 0) & 0xFF) + ((ptr[2] << 8) & 0xFF00); // is this correct?
    
    
    uint8_t packetNumber = ptr[4];
    
    
    uint16_t currentLed = packetNumber*PIXELS_PER_PANEL;


    Wichtig wäre was hier drinen steht und im Receive buffer...


    Es bringt keinen Sinn hier an Glediator zu zweifeln... das Protokoll kann man sich auch mal schnell selbst an den Client schicken... das sollte ja kein Problem sein... Ansonsten gibt es tolle Software wie Wireshark, da kannst du dir die ausgehenden Pakete anschauen...


    Zu meinem Post davor: Ja stimmt, das steht alles in der IF... ich hab das hier mit DevC++ geöffnet, da ist die Formatierung hinüber

  • Es bringt keinen Sinn hier an Glediator zu zweifeln

    Hat ja auch keiner behauptet! Hab zwar oben schon genug beschrieben warum, aber ging / geht nur darum "um zu sehen" was da alles rauskommt und an edit möglichkeiten. Aber danke für dein tip mit Wireshark, werd ich mich mal damit demnaechst beschaeftigen.


    Was heisst denn hier mit wurschteln geht nix? :D Manchmal muss ich hunderte mal testen bis was ordentlich funzt. Diese bastlerei geht in meinen augen nun mal nur mit wurschtelei.


    Zitat

    #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!

    pepe: Probier ich heute abend nochmal in ruhe. Werde dann berichten.

  • Ich habe noch ein wenig mit der firmware rumgespielt, dabei ist mir noch ein potentielles problem aufgefallen.


    ich kann "kleine" udp packete versende (zb. wenn ich 4 panels habe sende ich 4x ein 8x8x3 packet) - oder aber ich sende ein "grosses" packet mit dem inhalt aller 4 panels.


    der vorteil der "kleinen" variante ist, dass der uP weniger ram braucht, der nachteil ist, dass pakete verloren gehen können bei höheren frameraten. nicht das dies bei udp eine überraschung wäre, aber mir ist aufgefallen das z.b. bei einer framerate von 5 alle 4 panels aktualisiert werden. wenn ich die framerate auf 50 erhöhe, wird zu 90% nur noch panel 0 aktualisiert und zu 10% noch panel 1 - panel 2 und 3 werden sozusagen nicht mehr aktualisiert.


    hat da jemand etwas ähnliches festgestellt?


    gruss
    michu

  • pepe:
    Hab mal patching in glediator getestet so wie du es vorgeschlagen hast. Allerdings mit weniger pixel.
    Hab ne 8x8 matrix mit 2 paketen gepatcht. Und zwar die ersten 8x4 mit 192.168.100.222-0/0/0 (96ch.) und die zweite 8x4 mit 192.168.100.222-0/0/1 (96ch.)


    wenn ich in der FW:
    #define NR_OF_PANELS 2
    #define PIXELS_PER_PANEL 32
    #define UDP_PACKET_SIZE 96


    eingebe leuchten nur die ersten 8x4 pixels.


    wenn ich
    #define NR_OF_PANELS 2
    #define PIXELS_PER_PANEL 32
    #define UDP_PACKET_SIZE 192


    eingebe dann alle 8x8.


    das heisst packtenummer arbeitet nur dann wenn ich auch den gesamten UDP paket in der FW eingebe. Also geht nicht mit geizigem buffer einstellung.


    Mal ne dumme idee: Diesen "buffer-cheat" könnte man aber vielleicht realisieren, in dem man trotzdem in der FW erst 96 UDP buffer eingibt, und dann spaeter bei der ausgabe irgendwo für den 2. paket +96,+97 u.s.w addiert, damit die matrix dann die ganzen 192 bekommt. Könnte sowas klappen? Hab leider k.a wie man sowas realisieren könnte.


    michu, das ist genau was mir auch passiert mit der gesamten grossen buffer eingabe :/

  • Ich kenn' mich ja mit dem Ethernet/IP-Zeug nicht so wirklich aus, manches verstehe ich da wohl auch einfach falsch....


    ich hatte das hier:

    3.3.2 Reassembly


    The IP layer MUST implement reassembly of IP datagrams.

    aber schon so verstanden, dass praktisch die IP-Schicht sich drum kümmern muss, Pakete zu zerlegen und wieder zusammen zu basteln, wenn sie für die Ethernet-Übertragung zu groß sind...?


    mal spaßeshalber getestet (RN-171 geht wieder ;)), ich habe 600 Pixel eingestellt und per tpm2.net raus geschickt - da gibt's dann so "IP-Fragmente":



    d.h. also für mich, der Sender macht das schon "richtig", er "zerlegt" das, schickt so viel wie in einem Ethernet-Frame geht, und den Rest dann noch "hinterher" - das UDP-Paket hat 1.472 Bytes:



    und fängt mit $C9 $DA an, also der tpm2.net-Frame - danach kommt dann eben immer so ein Fragment mit 334 Bytes:



    was dann insgesamt genau die 1.806 Byte macht, die bei 600 Pixel + Header anfallen - dieses Paket hört auch richtig mit $36 auf...


    nur, die Matrix macht nix, der RN-171 kann das wohl nicht zusammen setzen, dieses Teil-Paket und dann noch das Fragment dran... ?(


    anscheinend geht das nicht bei jeder HW/FW, evtl. bei diesem ENC-Stack auch nicht...?


    bei 400 Pixel, das sind dann 1.206 Bytes inkl. Header, läuft alles problemlos - aber bei mir muss sich ja auch nicht der µC um den ganzen Ethernet/IP/UDP-Stack kümmern, das macht hier ja der RN-171...


    was ich noch testen muss (erst wieder Netz umstellen, bin immer noch beim Nachbarn im Wlan, mein DSL wird erst Sa repariert, ist ja auch erst ne Woche kaputt... :D X( :( Ob der RN-171 bei diesen fragmentierten Dingern dann überhaupt was ausgibt, kann ja sein, dass er das Fragment einfach weg lässt, oder Durcheinander entsteht, oder er dann gar nix macht...

    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!

  • was dann insgesamt genau die 1.806 Byte macht, die bei 600 Pixel + Header anfallen - dieses Paket hört auch richtig mit $36 auf...


    nur, die Matrix macht nix

    Ich denk halt, dass wir die ganze zeit auf diesen 1500 mtu limit stolpern. Bei 400 pix lauefts ja bei dr. Hast wahrscheinlich 100 pixel mehr, weil mein MC noch den stack rechnen muss und dein RN-171 aber nichts weiter.


    Da müsste denke ich, in der empfaenger FW noch irgend etwas sein, die grossen UDP pakete im empfanger zu teilen. Vielleicht wie du schon vorher gesagt hast mit verschiedenen buffern für jede 8x8 matrix u.s.w


    Oder es ist nun wirklich nichts mehr vom mega 8bit rauszuholen... ;(

  • Nee, das hat nix mit dem 8 Bit µC zu tun, sondern das ist ne SW-Sache, der Stack müsste das können, dass er diese Pakete und Fragmente wieder *zusammen setzt* (geteilt werden sie ja im Sender), kann er aber wohl nicht...


    der RN-171 kann's anscheinend auch nicht, habe mal den Output über USB auf's Terminal ausgeben lassen - schicke ich so Frames mit 600 Pixeln (also dann fragmentierte Pakete), kommt irgendne Meldung mit "Critical Command Error at PC=0xbvlabla, System will be Reset" (oder so ähnlich, hatte es eigentlich kopiert, aber nicht mehr in der Zwischenablage drin..?() und das Teil hängt sich auf...


    schade - also muss man sich wohl an diese max. 1.500 Byte halten, und auch bei tpm2.net ggfs. auf mehrere Pakete aufteilen - das sollte da ja eigentlich vermieden werden... zum damaligen Zeitpunkt war mir diese Beschränkung noch nicht bekannt, aber wir haben dann ja "vorsichtshalber" hier eben noch dieses Paketnummer-Byte eingeführt...


    ich schreib' dann bei Gelegenheit meine Empfangsroutine mal so um, dass sie auch das Paketnummer-Byte auswertet und die Pakete wieder zusammen setzt, und schau' mal, wie das bei mir läuft - muss nur erst noch was anderes fertig machen...

    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!

  • Die meisten dieser Wifi-Module von beispielsweise Roving Networks, Wiznet oder Gainspan haben Einschränkungen dieser Art (unter anderem). Bei einem dieser Hersteller stand es explizit dabei, ich finde die Stelle aber gerade nicht mehr. Will man auf Nummer sicher gehen, empfiehlt sich imho ein Chip wie der HDG104 von HD Wireless, bei dem man den Stack selbst in der Hand hat und beispielsweise lwIP einsetzen kann. Abgesehen davon ist der sogar noch etwas günstiger.

  • der RN-171 kann das wohl nicht zusammen setzen, dieses Teil-Paket und dann noch das Fragment dran...


    Der reiht eh bloß alle UDP Pakete in einen FIFO ein und sendet dir das über UART raus... das Modul hat aber nur einen Buffer von 1600 Byte, meine ich gelesen zu haben... bei zwei kleinen Paketen hintereinander ist der schon voll.


    Wenn du die Daten nur mit 1 MBit rausholen kannst, die aber mit 24 MBit ankommen können, ist das irgendwie schon nen Problem =)


    Ohne noch mal nachzugucken, ich denke der ENC IC hat 8 kb RAM. Da müsste das schon ganz gut klappen...


    Messt doch mal die Zeit die es dauert bis die Pixel mit Software SPI versorgt sind. Vielleicht ist der Flaschenhals schon da...


    Grüße


    Basti

  • 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

  • besten dank zum thema fragmentation und wie das die embedded stacks implementieren. dann ist meiner meinung nach das problem mit den verschiedenen frames nicht gelöst, nochmals ein beispiel:


    -> SEND FRAME 1
    -> uP bearbeitet das FRAME 1
    -> SEND FRAME 2
    -> uP bearbeitet das FRAME 1 immer noch
    -> SEND FRAME 3
    -> uP bearbeitet das FRAME 1 immer noch
    -> SEND FRAME 4
    -> uP zeigt Frame 1 nun an


    -> SEND FRAME 1
    ....


    ich nehme an, nachdem die daten vom netzwerk stack kopiert wurden, werden sie 3 mal überschrieben oder komplett verworfen. die einzige idee, wie man das verhindern könnte wäre eine ack meldung vom uP, der sender wartet max. N ms bis ein ACK kommt (zb 30ms). oder hat da jemand eine bessere idee?


    gruss
    michu

  • 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

  • Ja, wegen der Fragmentierung, das wurde ja hier schon besprochen...


    da bin ich einfach davon ausgegegangen, dass das eben "automatisch" wieder zusammen gesetzt wird (wegen der Buffer-Größe vom RN-171 hatte ich da nicht geschaut), das wär' halt cool gewesen, wenn man einfach größere Pakete schicken könnte (also den kompletten Frame in einem)... aber so wie's aussieht, wird das von kaum einer HW unterstützt....?


    daher halt dann auch hier (so wie bei Artnet auch) die Daten schon von der Sende-SW selbst in mehrere Pakete aufteilen, ist wohl einfacher, als da noch selbst am IP-Stack rumzubasteln, damit der die Fragmente auch verarbeitet...


    wie gesagt, schade, damit geht einer der angedachten Vorteile von tpm2.net verloren (dass man theoretisch nicht in mehrere Pakte aufteilen müsste), aber mir immer noch lieber als Artnet, weil zumindest diese Festlegung auf "Universes" mit einer (für RGB) unpraktischen Größe wegfällt...


    Messt doch mal die Zeit die es dauert bis die Pixel mit Software SPI versorgt sind. Vielleicht ist der Flaschenhals schon da...

    Bin ich da auch gemeint, weil Du in der Mehrzahl schreibst..? - bei mir gibt's da ja keine Probleme, SW-SPI macht knapp 2 MBit, die Daten kommen mit max. 1,1 MBit rein...


    mit tpm2 über USB gehen da auch 1.000 Pixel flackerfrei, bin mir sicher, dass das dann mit tpm2.net über den RN-171 auch geht, für mich (also auf dem µC) ist das beides mal ja nur Daten über den USART empfangen, bei tpm2.net dann halt noch den Zeiger für's Speichern auf Paketnummer*Blockgröße setzen, das kann auch nicht mehr den Riesen-Unterschied machen... ;)

    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!

  • Bin ich da auch gemeint


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


    Wenn die Grenze bei leddie bei 256 LEDs liegt, dann scheint es aber eher noch wo anders Probleme zu geben...


    Grüße


    Basti

  • 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

    mann mann, ihr gibt ja auch nicht nach was? 8|
    Ich bin doch kein FW/SW entwickler, alles was ich machen kann ist halt rumwurschteln, FW's/SW's testen von den wahren entwicklern wie euch, und kann dann halt sagen was funzt und nicht funzt. Ich mein, ihr solltet froh sein, dass ich mich hier für euch als freiwilligen tester gemeldet habe :D
    Ich bin selber von mir überrascht, wieviel ich von pesi, michu und dir gelernt habe (mittlerweile auch von basti) wie das alles funktioniert und bin für eure hilfe wirklich sehr dankbar. Bin halt schon auch nicht mehr der jüngste hier aber freu mich trotzdem wenn ich jeden tag was dazu zu lernen darf. (will jetzt aber trotzdem nicht öffentlich hier mein alter public machen, nicht dass ihr noch n herzinfarkt bekommt 8) ) glaubt mir, ich habe in diesem alter noch andere sachen zu erledigen... Trotz wurschtelei habe ich es dennoch geschafft michus code mit seinen tips auf einem 644p mit nem enc zum laufen zu bringen, was für mich schon sehr zufriedenstellend ist.

    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.

    Also ich bitte dich, soooo wenig ahnung hab ich nun doch wieder nicht, Du kannst halt viel mehr. Ich versuch doch nur mich weiter zu entwickeln.

    und werde auch weiter mit (hoffentlich) sachdienlichen Hinweisen zur Seite stehen.

    Das schaetze ich sehr. Danke dafür. An dieser stelle danke an alle die mir tips & tricks geben.

    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.

    Siehst de? Bin also doch nicht der einziger der hier rum copy & pastet :P
    Nee aber mal ehrlich, mit deinem fix kann ich dann mehr tests machen, dann haben wir noch eine SW alternative für grössere UDP pakets.

    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.

    Ja, ethercard lib ist ja auch n mod von Guido Socher. Also:
    // Author: Pascal Stang
    // Modified by: Guido Socher
    // DHCP code: Andrew Lindsay


    Verstehe ich das richtig: Du schickst 4 pakete insgesamt, obwohl header size bei tpm2 =5 ist? Oder laesst du dataframe oder was weg? 8|
    Das mit dem speichern nach dem alle pakete da sind find ich erstmal ne super idee. Werd mal demnaechst irgendwas probieren aeeeh rumwurschteln :)

    Hast Du in deinem Heimnetzwerk evtl. 'nen Netzwerkdrucker oder ein NAS Gerät sitzen?

    Nö, hab ich nicht. Waer aber cool :P


    gruss


    EDIT:

    Zitat

    Erst wenn das letzte Packet (3) empfangen wurde

    Was meinst du mit der 3? Dritter byte?

  • 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