Hallo, Ich würde gerne wissen ob es sinnvoll bzw besser wäre einen eigenen uController für eine Anzeige die im Multiplex betrieb läuft zu haben? Wenn ich zb von einem Sensor einen Wert einlese und davon den Mittelwert bilde dauert das alles ja eine gewisse Zeit und diese Zeit wird dann an der Anzeige sichtbar, so dass sie flackert bzw ein Element kurz gar nicht leuchtet. Da ich gerade am lernen bin weiss ich nicht ob mein Gedanke richtig bzw sinnvoll ist einen Controller für die Anzeige und einen separaten Controller für die Auswertung zu haben? Danke euch
Robert I. schrieb: > Hallo, > > Ich würde gerne wissen ob es sinnvoll bzw besser wäre einen eigenen > uController für eine Anzeige die im Multiplex betrieb läuft zu haben? Kommt drauf an. Mit einem eigene Controller handelt man sich eine weitere Software-Schicht ein, die man ansonsten nicht bräuchte. Denn dieser eigene Cotroller ist ja kein Hellseher. D.h man braucht eine Kommunikationsschicht vom Hauptprozessor zum Controller. > Wenn ich zb von einem Sensor einen Wert einlese und davon den Mittelwert > bilde dauert das alles ja eine gewisse Zeit und diese Zeit wird dann an > der Anzeige sichtbar, so dass sie flackert bzw ein Element kurz gar > nicht leuchtet. Dann machst du etwas falsch. Multiplexing macht man mit Interrupt. D.h. die Mittelwertrechnerei etc. wird von einem regelmässigen INterrupt unterbrochen, die Anzeige auf den neuen Stand gebracht und erst wenn dann die nächsten Segmente leuchten, darf die Mittelwertrechnerei zu Ende rechnen. Sensorauslesen könnte zu einem kleinen Problem werden, wenn das Protokoll dergestalt ist, dass es zeitkritisch wird. Ein naives Auslesen eines DS1820 durch Protokollimplementierung mittels delays könnte da zb darunterfallen, wenn sich die Zeitfehler im Laufe der Übertragung eines Bytes zu sehr akkumulieren, wenn die Multiplexfrequenz sehr hoch ist. > sinnvoll ist einen Controller für die Anzeige und einen separaten > Controller für die Auswertung zu haben? Es ist NIE sinnvoll, mehrere Controller für eine Arbeit einzusetzen, die einer alleine problemlos schaffen kann. Ehe man diese Option ins Auge fasst, sollte man erst mal in sich gehen und sich fragen, ob man tatsächlich ein reales technologisches Problem hat oder ob nur die eigenen Fähigkeiten in der Programmierung nicht ausreichen. Leider überschätzen sich gerade Neulinge bzw. Anfänger gerne in letzterem Punkt. Und so kommt es dann, dass sie Mehrprozessorsysteme planen, die erstens unnötig sind und zweitens ihre Fähigkeiten immer noch übersteigen, weil sie es komplett unterschätzen, was nötig ist, damit die Prozessoren untereinander geordnet kommunizieren können. Krassestes Beispiel aus der letzten Zeit war wohl ein Schüler, der eine LED Matrix auf 2 µC aufgeteilt hat, weil er nicht wusste, wie er die ganzen Anschlüsse der Matrix auf einem µC bedienen solle. Das sieht auf den ersten Blick einfach aus, womit er aber nicht gerechnet hat war die Kommunikation und das sich seine Spiellogik jetzt extrem verkompliziert, weil er unterscheiden muss, auf welchem µC jetzt eigentlich welche LED (die den Ball anzeigen soll) leuchten soll, bzw. wie Bewegungen des Tennisschlägers je nachdem auf die unterschiedlichen Matrixteile verteilt werden müssen. Was bei lediglich einem µC trivial ist, artete sich für ihn zum Albtraum aus. Dabei wäre sein eigentliches Problem mit nur 1 µC und ein paar Schieberegister leicht zu lösen gewesen. interrupt-getriebenes Multiplexing für ca. 4 bis 6 Anzeigen, zwackt weniger als 0.1% der Rechenzeit ab (hängt natürlich auch von der Multiplexfrequenz ab), so dass in einem normalen Programm (mit Ausnahme von zeitkritischen delays, deren Fehler sich akkumulieren können) ein Multiplexing für den Rest des Programms keinerlei großartige Bedeutung hat.
:
Bearbeitet durch User
Solch eine Auftrennung in Bausteine wäre ein Luxus für kommerzielle Anwendung. Da ist jeder zusätzliche Baustein ein erheblicher Kostenfaktor. Schön für den Bastler ist jedoch, dass durch die Auftrennung einzelne, besser beherrschbare Einheiten entstehen. Warum soll man eine Display-Software mit mit passender LED- oder LCD-Hardware in jedes Projekt neu integrieren oder sich Gedanken drüber machen, obs beim neuen Projekt am Display oder am neuen Programm liegt? Ich selbst habe z.B. mehrere LED-Einheiten herumliegen: 4-stellig, rot 3stellig grün, LCD zweistellig, die bei verschiedenen Projekten entstanden sind und auch mehrfach eingesetzt werden. Die Einheiten sind mit I2C- Schnittstelle ausgestattet und wie ein I2C-Baustein anwendbar. Das Timing der I2C-Schnittstelle belastet den Ablauf im "Projektkontroller" kaum, sodass die Software einfacher strukturiert ist. So gemacht wird es ja eigentlich bei den Punktmatrix-LCDs: Der LCD-Baustein ist getrennt vom eigentlichen Projekt und hat seinen eigenen Kontroller.
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.