Beiträge von leddie

Ich finde es übrigens auch gut, dass Ihr den Byte für die Gesamtpaketanzahl ins protokoll einfügt...

Eine Zeile mehr code in meinem "Ghost tpm2net Code" die ich einfügen muss, macht das Kraut dann auch nicht mehr Fett

Zitat von Counterfeiter

Aber was ist, wenn mal ein UDP Paket "lost" ist?

Ich erinnere mich dass Pesi dazu schon was mitgeteilt hatte, dass dieses Paket dann gar nicht zu sehen ist, weil das irgenwo im milisekunden bereich liegt...

Zitat von Pesi

Neujahr bei den Chinesen...

Ehehe, ja geht eigentlich gar nicht. So lange hat kein Volk auf der Erde auf einmal Urlaub

uiui, der preis ist echt unschlagbar und dann noch 2.4ghz!! pesi: könntest du hier bitte berichten ob die auch was taugen? dann nehm ich mir auch gleich ein paar davon

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

Hi,

waere es möglich den tlc5940 als ganz normalen constant current driver zu benutzen? Habe im DB nachgeguckt, man kann zwischen GSCLK und Dot correction umschalten aber irgendwie nicht mehr. Vielleicht hat jemand ja ein Trick?

Super idee michu!

Kurze frage:
Könnte mann nen Arduino DUE mit ARM & wiz5100 ethernet shield nehmen und dann dieses UDP paket limit übergehen? Oder würde trotz schnellem uP und 96kb sram nicht mehr als 1500 bytes wegen MTU size geschichte gehen? (mit tpm2net)

Die SD Card slot ist ja wie ich sehe horizontal zum board. Geht die karte dann einfach rein? kann mir schon vorstellen dass du das so gemahct hast wegen platz sparen, hoffe nur dass ich nicht immer meinen neffen holen muss um die karte da reinzuplatzieren Aber allgemein sieht das board lecker aus, fast wie zum reinbeisen

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?

Zitat von Pepe_1981

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.

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

Zitat von Pepe_1981

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.

mann mann, ihr gibt ja auch nicht nach was?
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
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 ) 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.

Zitat von Pepe_1981

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.

Zitat von Pepe_1981

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.

Zitat von Pepe_1981

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. Werde ich bei der nächsten Version fixen.

Siehst de? Bin also doch nicht der einziger der hier rum copy & pastet
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.

Zitat von Pepe_1981

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
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?
Das mit dem speichern nach dem alle pakete da sind find ich erstmal ne super idee. Werd mal demnaechst irgendwas probieren aeeeh rumwurschteln

Zitat von Pepe_1981

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

Nö, hab ich nicht. Waer aber cool

gruss

EDIT:

Zitat

Erst wenn das letzte Packet (3) empfangen wurde

Was meinst du mit der 3? Dritter byte?

Zitat von Pesi

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

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

Zitat von Counterfeiter

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

Zitat von michuNeo

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

Zitat von Pesi

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

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

Zitat von Pesi

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

Zitat von Pesi

also die Daten auf 2 Pakete mit Paketnummern aufteilen

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

Zitat von Pepe_1981

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:

// max frame length which the conroller will accept:
// (note: maximum ethernet frame length would be 1518)
#define MAX_FRAMELEN  	1500

Ja, da MTU-wert ja sowieso max 1500 bzw 1518 ist, wie soll mann denn dann noch 3072 bytes in einem packet empfangen?? 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!!

Also wenn keine Ethernet daten empfangen werden laueft es ja gar nicht weiter. Geht ja erst los wenn empfangene bytes mehr als das Header_size ist.

Meinst du mit dem 500us den latch delay für die ws2801 ? Die ist ja in der library ws2801.h schon drin.

Hab mal dein framesize getestet, leider blinkt jetzt die ganze matrix alle 100 milisekunden