Ich arbeite an einer LED-Laufschrift, bestehend aus mehreren 16x32-RGB-Panelen und je einem Arduino Namo pro Panel. Der Code beruht auf der bekannten Adafruit-Lib und den dazugehörigen Beispielen. Meine besondere Anforderung ist die, dass ich nicht irgend eine "Show" vorher speichern und dann abspielen möchte, sondern Daten vom PC müssen live angezeigt werden. Das klappt für sich alleine mit jedem Modul per USB/Serial wunderbar - ich erreiche bei 115000 bit/s ca. 22 Frames/s. Nun dachte ich, ich nehme quasi als Hub einen Arduino Uno mit Ethernet-Shield (also mind. 10Mbit), der dann seinerseits die MCs an den Modulen per SoftSerial versorgt. Es gibt einen Sync-Code, der alle Zähler zurücksetzt und ansonsten geht das erste Byte zu Serial-1 hinaus, das zweite zu Serial-2 usw., bis die 512 Bytes pro Modul (16x32) voll sind, dann gehts von Vorne wieder los. Aber das klappt nun wiederum nichtmal mit einem einzelnen Clienten. Auch nicht mit reduzierter Baudrate von 57000. Die Ausgabe ist extrem ruckelig, oft bleibt das System einfach ganz stehen. Die Daten kommen zwar ruckelig aber sauber (vollständig) am Hub-Arduino an, das kann ich mir per Serial-Monitor ansehen ... Könnte es sein, dass ein TCP-Paket immer erst "voll" sein muss, bevor es abgesendet wird? Das würde die Ruckelei erklären, aber nicht die Aussetzter und Hänger ... was habe ich übersehen? Tips? Danke!
Es ist die Aufgabe von TCP dafür zu sorgen, dass die Daten vollständig sind, daher regelt die Flusssteuerung von TCP die Übertragungsrate runter, falls die Daten schneller ankommen, als sie verarbeitet werden können. Das vermute ich als Ursache für das Ruckeln. Damit es nicht ruckelt, könntest du versuchen, einen Puffer zu programmieren, der die Daten in ausreichender Menge aufnimmt und sammelt, bevor sie an die Anzeigen weitergegeben werden - ähnlich dem Buffering beim Video-Streaming (z.B. YouTube), denn im Grunde versucht du ja ein Streaming zu implementieren.
:
Bearbeitet durch User
Frank schrieb: > Könnte es sein, dass ein TCP-Paket immer erst "voll" sein muss, bevor es > abgesendet wird? Das würde die Ruckelei erklären, aber nicht die > Aussetzter und Hänger ... was habe ich übersehen? Tips? Danke! Nimm UDP. Das belastet den AVR weniger, und Du machst die Flusskontrolle, nicht der TCP-Stack. Auch bei Internettelefonie laufen die Daten über UDP, und das hat seine Gründe. fchk
Die Ursache scheint gefunden: SoftSerial nutzt Interrupts, die auch die Ethernet-Lib nutzt, das beisst sich. Die vorhandene Hardware-UART bleibt davon ungestört - allerdings hat der UNO ja leier nur eine, der Mega dagegen drei, ich brauche aber fünf :-( Ich werde es nun damit versuchen, dass alle Modulrechner an der einen Hardware-Serial "horchen" und ich den Datenblöcken eine Kennung voranstelle, die das jeweilige Modul adressiert. Damit die Module aber ihren neuen Inhalt nicht nacheinander aktualisieren (sieht doof aus), gibts einen extra-Code zum Planeswapping, den dann alle gemeinsam ausführen ... Damit muss ich wohl auf Animationen verzichten, aber damit kann man bei einem Info-Display vermutlich leben.
So, Problem gelöst: UDP war die Lösung - Danke für den Tip. In meiner Steuersoftware kann ich die Pakete genau so groß machen wie nötig und auf dem Hub-Arduino dazu passend den Empfangspuffer. Somit erreiche ich nun über 5 Panele (160 x 16) immerhin eine Datenrate von beinahe "butterweichen" 14 Frames/s - absolut ausreichend.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.