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