Hi, ich möchte mit einer 32x64 RGB LED Matrix (Sport) Ereignisse anzeigen die über Funk reinkommen. Aufbau: 32x64 LED <-- Arduino Mega 2560 <-- Atmel Mega <-- mehrere Funksensoren Meine Überlegungen: - da es einfach ist die Matrix mit Arduino zu steuern würde ich den als Display Prozessor einsetzen - der 2te Prozessor deshalb weil das Projekt schon fertig ist (außerdem ist alles in Assembler geschrieben das kann ich besser ;) - da es auch ohne dieses Diplay geht möchte ich nicht mit einem Prozessor arbeiten Also ich habe 2 fertige Bausteine, das Display mit Arduino und meinen Funkauswerter. Jetzt zur Frage - wie würdest Du die Datenübergabe zwischen beiden machen, so das das Display smooth weiterläuft und der Funkauswerter das Display scheibt ohne einen Funkevent zu verpassen? Datenmenge ca. 32-64 Byte. Ich steh echt auf dem Schlauch, ich habe Angst das entweder das Display ruckelt oder der Auswerter ein Event verpasst. Grüße, Frank
Du kannst ja mal ausprobieren, ob es wirklich Probleme macht, wenn zwischendrin mal Daten per UART oder I2C empfangen werden. Ich hatte mal eine Großanzeige aus diesen P5-Panels und nem Teensy aufgebaut. Der Teensy hat das heavy lifting der Panel-Ansteuerung und der Grafikerzeugung gemacht und fungierte als I2C-Slave und bekam so seine Daten. Wobei der Teensy natürlich etwas mehr Bums hat.
Also am liebsten wärh mit ein IC zwischen beiden auf dem der eine liest und der andere schreibt - notfalls auch gleichzeitig. Also ein Speicher IC mit 2 Schnittstellen?
Woher bekommt der Display Prozessor (Arduino Mega 2560) momentan seine Daten? Wie zeigt der Sensor Prozessor (Atmel Mega) momentan die empfangene Daten? Ich würde die beide enfach über eine serielle Schnittstelle ((Soft) UART) mit einander verbinden. Würde mich wundern wenn das bei der kleine Datenmenge anfängt zu rückeln.
@Eric B Arduino zeigt Daten aus eigenen Programm an. Der Sensor Prozessor hat ein paar Leds ;) @Sebastian R. & Eric B JA ich würde gerne auf Uart verzichten, würde das gerne entkoppeln und save machen.
Frank schrieb: > Also am liebsten wärh mit ein IC zwischen beiden auf dem der eine liest > und der andere schreibt - notfalls auch gleichzeitig. > > Also ein Speicher IC mit 2 Schnittstellen? Ob du X Bytes an Daten in deinen Display-Controller schreibst und der dadurch blockiert oder ob du X Bytes von deinem Display-Controller aus einem Speicher lesen lässt und es ihn blockiert - Die benötigte Zeit dafür wird annähernd identisch sein. DMA würde einiges schneller machen, aber das kann der M2560 nicht.
Frank schrieb: > ich möchte mit einer 32x64 RGB LED Matrix (Sport) Ereignisse anzeigen > die über Funk reinkommen. Nicht weiter dramatisch. > Aufbau: > 32x64 LED <-- Arduino Mega 2560 <-- Atmel Mega <-- mehrere Funksensoren Warum 2 CPUs? Eine reicht locker und langweilt sich immer noch. > - da es einfach ist die Matrix mit Arduino zu steuern würde ich den als > Display Prozessor einsetzen OK. > - der 2te Prozessor deshalb weil das Projekt schon fertig ist > (außerdem ist alles in Assembler geschrieben das kann ich besser ;) Ohje. > - da es auch ohne dieses Diplay geht möchte ich nicht mit einem > Prozessor arbeiten OK. > Also ich habe 2 fertige Bausteine, das Display mit Arduino und meinen > Funkauswerter. > > Jetzt zur Frage - wie würdest Du die Datenübergabe zwischen beiden > machen, so das das Display smooth weiterläuft und der Funkauswerter das > Display scheibt ohne einen Funkevent zu verpassen? Such dir was aus. UART, I2C, whatever. Ich würde UART nehmen, geht kaum einfacher. > Datenmenge ca. 32-64 Byte. Also quasi nix. Aber in welcher Zeit? 1 mal pro Sekunde? > Ich steh echt auf dem Schlauch, ich habe Angst das entweder das Display > ruckelt oder der Auswerter ein Event verpasst. Ach herje, Mal wieder Generation Snowflake am Start? Und das bei DEM Wetter?
Frank schrieb: > Also am liebsten wärh mit ein IC zwischen beiden auf dem der eine liest > und der andere schreibt - notfalls auch gleichzeitig. OMG!!! Das ist ja Snowflake^2!!!! > Also ein Speicher IC mit 2 Schnittstellen? Nennt sich Dual Portet RAM, ist heute eher exotisch und hier totaler Overkill. Aber mach mal, wenn du dadurch deine Angst eindämmen kannst . . .
Ah ja, Snowflake und Troll wa? Kinder ;) Aber Dual-Port RAM finde ich spannend und lustig. Da es um Zeit- und Zielauswertung im Sportschießen geht, gibt es viele zeitkritische Events innerhalb von einigen Sekunden. Denke das wird eine saubere Lösung die Daten im Speicher bereitzustellen und dann frei mit unterscheidlichen Displays/Rasberry+TV darauf zuzugreifen.
Frank schrieb: > Da es um Zeit- und Zielauswertung im Sportschießen geht, gibt es viele > zeitkritische Events innerhalb von einigen Sekunden. Zeitauswertung läuft ja auf dem anderen Controller, der dafür alle Zeit der Welt hat, oder? Wenn er die Zeit gemessen hat, kann er seelenruhig die Werte zum Displaycontroller schicken. "Einige Sekunden" sind in Mikrocontroller-Welten eine halbe Ewigkeit. Messwert berechnen, zum anderen Controller schicken, dort einlesen und auf die Anzeige bringen dürfte in ein paar Millisekunden erledigt sein.
Sebastian R. schrieb: > Zeitauswertung läuft ja auf dem anderen Controller, der dafür alle Zeit > der Welt hat, oder? 2 Controller - Display und Funk-/Zeit-/Zielauswertung Er muss 10 Funksensoren auf Treffer überwachen, die Ziele zuordnen, die Zeiten der 2 Schützen zwischen den Treffern errechnen, im Duellmodus geht's um ne hunderstel die ich schneller war als mein Gegner ;) Der Dual Speicher ist eigentlich genau das was ich gesucht habe, wann immer ein Ereigniss eintritt schiebe ich das rüber. Der Displaycontroller kann 10 mal in der Sekunde nackucken was er anzeigen soll. Hauptsache ist ich muss mich nicht ums Timing kümmern und nix interferiert...
Frank schrieb: > Der Displaycontroller kann 10 mal in der Sekunde nackucken was er > anzeigen soll. > Hauptsache ist ich muss mich nicht ums Timing kümmern und nix > interferiert... da brauchst du nen Dual port RAM mit eingebauter arbitration. höchst wahrscheilich musst du dich um ein Busy Flag kümmern wenn du die gleiche Adresse gleichzeitig ließt und schreibst (wenn nicht kommt auf einer seite Müll raus/rein). Was machst du wenn Daten aus mehreren Byte (bzw. mehr bit als der Datenbus hat) hast und nur ein Teil davon aktualisiert ist => da kommt wieder Müll raus. nimm nen UART, mach auf das Display nen interrupt wenn ein Byte empfangen wurde, schreib im interrupt das Byte in nen Buffer (Array + Variable für schreib Index reicht), setz nen Flag wenn alle Daten neu sind und wenn das Flag gesetzt ist aktualisier in der Hauptschleife, damit schaffst du auch 100mal in der sekunde. oder schreib in nen Ringbuffer, dann hast du aber wieder das Problem teil neu/teil alt = Müll. wenn du immer noch bedenken hast limitier das senden neuer daten auf eine gewisse Rate oder warte auf ein "display aktualisiert" Signal dass du zurück sendest. wenn du Assembler programmierst schläft der µC dann immer noch die meiste Zeit, wenn du wirklich was zeitkritisches hast im Bereich von wenigen takten vorher Interrupts aus und beim UART halt 20 Takte warten zwischen jedem gesendeten Byte.
K. S. schrieb: > nimm nen UART, mach auf das Display nen interrupt wenn ein Byte > empfangen wurde, schreib im interrupt das Byte in nen Buffer Hmmm hast Recht, ich werde den Display interrupt anschieben ein paar Bytes schnell rüberschieben und kucken ob das das Display flackern lässt... Stimmt schon, den DuoRam muss ich dennoch mal versuchen ist einfach zu intressant ;)
Das war die erste Antwort hier. Probier es aus, ob es wirklich Probleme macht. Meist hat man eine falsche Vorstellung davon, wie lange etwas dauer. Wie gesagt "einige Sekunden" sind Welten für einen Controller, der ein paar Millionen Befehle pro Sekunde ausführen kann. Dementsprechend ist das Empfangen und Verwursten von ein paar Bytes schnell gemacht, bevor der Mensch etwas davon mitbekommt. Das Display.. Alles über 25Hz ist dem Auge eh wurscht. Und da du da ja keine HFR-Filme in 3D drauf gucken willst, hast du zwischen den Frames in µC-relation echt eine Ewigkeit Zeit, die Daten zu bekommen.
Frank schrieb: > Der Dual Speicher ist eigentlich genau das was ich gesucht habe, wann > immer ein Ereigniss eintritt schiebe ich das rüber. > Der Displaycontroller kann 10 mal in der Sekunde nackucken was er > anzeigen soll. Das ist Unsinn und löst auch das Problem nicht - wenn Display-Ausgabe und Daten Einschreiben nebeneinander her laufen ruckelt das Bild ziemlich wahrscheinlich. Es geht genau umgekehrt: der Ausgabespeicher wird doppelt vorgesehen, das sind ja ganz wenig Daten, und die Anzeige multiplext sich entweder durch den einen oder den anderen Speicher. Neue Daten werden in den jeweils anderen reingeschrieben, Timing egal, und wenn sie vollständig sind wird die Anzeige umgeschaltet. So wird entweder der alte oder der neue Inhalt konsistent angezeigt. Georg
Äh ja hat sich erledigt. Also beim Adafruit 32x64 LED Display anteuern mit Arduino herrscht eine Menge Leerlauf - es ist überhaupt kein Thema den Arduino per INT ein Bytes zuzuführen ;)
Der TO sollte - bevor hier spekuliert wird - exakt die Anforderungen spezifizieren. Ansonsten: nächstes Thema.
Frank schrieb: > Also beim Adafruit 32x64 LED Display anteuern mit Arduino herrscht eine > Menge Leerlauf - es ist überhaupt kein Thema den Arduino per INT ein > Bytes zuzuführen Das ist aber nicht die Frage. Wenn die Anzeige mitten im Mux-Durchlauf geändert wird, so wird in der oberen Bildhälfte der alte und in der unteren der neue Bildinhalt angezeigt, natürlich sieht man das als Zucken und Ruckeln. Beim Fernseher löst man das so dass der Bildinhalt nur während des vertikalen Rücklaufs geändert wird, sowas ähnliches hat aber hier noch niemand vorgeschlagen. Wahrscheinlich hört sich Dual Ported Ram einfach zu geil an, da kann man nicht widerstehen. Georg
Die entsprechenden Libraries für die Matrix betreiben eigentlich schon Double-Buffering. Und der Ablauf ist ja diskret. Werte im Interrupt empfangen, in der Main verwursten, in den Anzeigebuffer, Buffer ausgeben. Also da sollte es keine Probleme geben, wenn man es richtig macht.
Das Zauberwort lautet Synchronisation. Also die Daten nicht irgendwann in den Datenpuffer reinschreiben sondern im richtigen Augenblick.
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.