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