Re: LED-Matrix für Computer - Anzeigeprobleme (Flimmern)

[LED-Matrix am PC]

Gerald und Harald haben dich ja schon auf die µC Lösung hingewiesen. Das geht auch wunderbar (habe selber eine 32x32 Matrix auf diese Art gebaut) braucht aber erstmal etwas Einarbeitung. Wenn du dir dir sparen willst und etwas mehr Geld ausgeben willst schau dir mal den MAX7219 an. Das ist ein IC wie du es suchst. Du schiebst deinen Displayinhalt seriell rein und der MAX macht den Rest.

-- Matthias Weißer snipped-for-privacy@matwei.de

Michael B. Simon schrieb im Beitrag ...

a) Deine Matrix ist 'falschrum'. Die Treiber (ULN) muessen an den Decoder (138), die Schieberegister treiben weniger Strom. Siehe de.sci.electronics FAQ:

b) Das Betriebssystem hat im Prinzip keine Auswirkungen, wenn du richtig programmierst. Natuerlich ist das programmieren unter NT schwieriger, als unter einem richtigen Betriebssystem, aber das ist deine Entscheidung. Unter NT bedeutet das, das du einen Kernel- Treiber fuer die Multiplexanzeige schreiben musst, der auf hoher Prioritaet läuft, am besten durch den Zeitgeber-Interrupt aufgerufen.

Einfach mal so ein (Basic?)Anwendungsprogramm taugt unter NT zum Ansrechen von Hardware natuerlich nicht.

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx.net
homepage: http://www.geocities.com/mwinterhoff/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Hallo!

er bracht keinen kerneltreiber schreiben sondern seinem programm nur höhere priorität zuordnen (siehe win32-api)

oder er verwendet LABVIEW wenn er nicht tipsen will

SERVUS

Hallo nochmal!

Gut, das du das bemerkst. Wahrscheinlich hätte dann irgendwann der Demultiplexer den Geist aufgegeben, wenn er soviel Strom geben muss.

Die Frage ist nur, ob dieser Umstand wirklich für eine (doch recht einfach aussehende) Multiplexanzeige sinnvoll ist. Auch, wenn es andere Verfahren geben sollte, die zum Ziel führen- der Computer wird ständig mit der Ausgabe belastet. Das macht den Computern heute vielleicht nicht mehr soviel aus wie vor einigen Jahren. Aber trotzdem irgendwie belastend für ein nicht-Echtzeit Betriebssystem, das es plötzlich auf Echtzeit ankommt. Die Routine ist übrigens in C geschrieben und die Portansteuerung in Assembler, was man aber vergessen kann, denn NT läßt den direkten Zugriff in Asm nicht zu. Aber von NT komme ich leider nicht weg. Auch, weil XP nur eine andere Aufmachung von NT ist.

Ich denke ich werde mich mal mit den µC beschäftigen. Das wollte ich schon seit langem. Nur hatte ich bis jetzt noch keine Mut dazu, weil die so aufwendig zu programmieren sind. Habe gehört, das es auch welche gibt, die direkt am Parallelport beschrieben werden können. Wäre natürlich gut. Dann schaue ich mir mal die Atmel-Reihe an. Wird eine neue Lernphase bedeuten, bevor es weitergeht. Aber ist denke ich auch die preiswerteste Lösung.

Vielen Dank schonmal! Michael

Das halte ich für einen schlechten Tipp. Die kostbare CPU-Leistung für die Ansteuerung einer LED-Matrix zu opfern ist nicht gerechtfertigt. Ehrlichgesagt halte ich das für Pfusch. Und einen Kerneltreiber zu empfehlen ist wirklich aus nicht das gelbe vom Ei - am Ende macht der OP das noch und benutzt schön viele CLIs und STIs, da ist dann der PC wirklich ein schöner "Dedicated LED Matrix Driver". Das kanns ja wohl net sein. Kernelprogrammierung sollte nur gewagt werden wenn absolut notwendig. Wer jemals schonmal ein Modul schreiben musste weiß wie schnell so ein PC sich aufhängen kann.

Ausserdem verlangsamt sich dann die RTC, weil Tasks mit hoher Priorität (also CLI/STI) diese komplett _stoppen_ (IMHO auch Pfusch in den IBM PCs). Wenn die Maus noch sehenbleibt ist das ja ok. Aber vielleicht verpasst das System sogar noch ein Paar schöne IDE-Zugriffe, dann wird alles nichtmehr so lustig.

Also: Lieber eine gescheite Hardware designen als den PC so übel zu vergewaltigen.

Viele Grüße Johannes

Das kommt halt auf die Anforderungen an - s.u..

Dann brauchst Du für diese Anwendung ein Realtime-Betriebssystem, ansonsten passiert genau das, was der Ursprungsposter beobachtet hat: es flimmert.

Ich sehe folgende Möglichkeiten: - Hardwareunterstützung - Microcontroller oder fest verdrahtet, mit eigenem Bildspeicher -> Timing unkritisch, Ansteuerung im Userspace, aufwendige Hardware

- Realtime-Kernel nehmen

- Oder ein "normales" Betriebssystem und ein Kerneltreiber. Wenn die anderen Treiber im System ihm nicht zu lange die Interrupts sperren, dürfte das für die LED-Ansteuerung dicke reichen. Wenn er das Interruptgesteuert macht, ist die CPU-Last auch nicht besonders hoch[1]. Klar erfordert das besondere Sorgfalt bei der Programmierung, andererseits ist das Problem sehr überschaubar, und dafür wird die Hardware einfacher - kommt halt drauf an, worauf man mehr Wert legt.

[1] wahrscheinlich deutlich weniger als das, was moderne Billighardware vom Typ Winmodem / Soundkarte / ... verbrät.

cu Michael

Wenn man das sauber programmiert, muß das kein Fehler sein. Es kommt halt auf die Anwendung und die verfügbaren Ressourcen an - wenn der Rechner primär nur das Display ansteuern soll, wozu dann aufwendige externe Hardware bauen, wenn es mit geeigneter Software (sprich: kerneltreiber) auch ohne geht?

Das geht genauso gut wir unter Windows: nämlich nur so lange, wie niemand mit höherer Priorität (user oder kernel) dazwischenfunkt.

ACK.

In dem Szenario würde auch ein Kerneltreiber für das DIsplay nicht reichen, dann braucht es einen RT-Kernel (der dem Rest dann das CLI/STI verbietet).

Aber: bloß, weil andere Leute nicht programmieren können, ist das kein Grund, selber solche Mechanismen generell nicht benutzen zu wollen.

cu Michael