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.
