Hallo, um einem unbedarften Benutzer den Zustande eines Gerätes sichtbar zu machen habe ich eine kleine Routine geschrieben die verschiedene vorgegebene Muster per RGB LED darstellen kann. Gedacht ist jeder Farbe einem Modul oder einem Status zuzuweisen (rot = Fehler, Blau = Funkmodul, ...) und je nach Muster den Status dieses Moduls zu signalisieren. Es gibt vier Slots, die verschiedene Muster/Farb-Kombinationen darstellen und nacheinander abgearbeitet werden. Hierbei können die einzelnen Slots 1, 2 oder unendlich mal wiederholt werden. Auf eine PWM Modulation einzelner Grundfarben bzw PWM Dimmung der ganzen LED habe ich gezielt verzichtet, da die Unterscheidung der Farben bei den sieben darstellbaren schon teilweise schwer fällt (Blau <=> Türkies) und Timer gespart werden sollen. Das einzig benötigte Zeitsignal, ist ein gesetztes Flag alle x Herz. (Und der restliche Code darf nicht all zu lange den uC blockieren, um eine Verzerrung des Blinkmusters zu verhindern.) Die acht Muster sind 32 Bit lang und liegen im Flash. Zur einfacheren Lesbarkeit ist Byte 1 das niederwertisgte Byte und Bit 7 das niederwertigste Bit. Was kann noch effizienter/besser gestaltet werden? Allgemeine Kritik an der Idee oder dem Aufbau? Immer her damit... Gruß --Daniel
Gast
#3732940
Ich will es Dir nicht vermiesen, aber lese das hier mal: http://de.wikipedia.org/wiki/Rot-Gr%C3%BCn-Sehschw%C3%A4che 9% aller Männer haben also eine R/G-Sehschwäche. Das bestätigt auch meine Erfahrungen mit simplen R/G-LEDs im Service, die Benutzer bekommen es einfach nicht hin. Bedenke auch, dass Du als Entwickler eine andere (optimistische) Sichtweise hast. Fremdlicht-Einfluss (insbesondere Sonne) kann einem die Sache dann auch gar unmöglich machen. Dedizierte LEDs oder eine einzelne 7-Segment-Anzeige sind dagegen sehr viel besser im Service-Alltag. Zum ASM-Code: Bedenke, dass hier nur noch einzelne Spezialisten Lust haben, sich durch Assembler durchzudenken. C ist in der embedded-Szene nun einmal der Standard, auch wenn sich gleich eben diese Spezialisten dazu zu Wort melden werden.
Gast
#3732991
Daniel Steffen schrieb: > Allgemeine Kritik an der Idee oder dem Aufbau? Also ich bekomme es bei Blinkcodes von Auto-Elektroniken nicht hin. Ich bin mir nie sicher, welcher Blinkcode es denn nun war. Entweder zu schnell zum zählen, oder Abstände nicht unterscheidbar.
Danke für das Feedback! Farbprobleme sind insofern eher unwichtig, da Rot als Warnung schnell blitzen wird was grün niemals wird. Allgemein sind die Codes sehr simpel, ein langes Leuchten und dann 0-5 kurze Blinker, wobei kurz 2Hz bedeutet. Testpersonen von 15 bis 55 haben es bisher als klar unterscheidbar und nicht zu schnell beschrieben. Warum RGB? Das ganze wandert am Ende in ein wasserfestes Gehäuse und der eine Durchbruch für den Lichtleiter ist mir eigentlich schon zu viel. Mehrere für jede einzelne Status-LED oder ganze Fenster für 7-Segment Anzeigen ... da bekomme ich 's kalte grausen. Ich werde mal weitere Tester drauf los lassen (wenn ich finde auch explizit welche mit Farbschwächen) und schauen was die mir sagen. PS: Schade das ASM so stiefmütterlich behandelt wird. Da sieht man direkt was der Controller macht und kann schön kompakten Code schreiben.
Gast
#3733060
Daniel Steffen schrieb: > Warum RGB? Das ganze wandert am Ende in ein wasserfestes Gehäuse und der > eine Durchbruch für den Lichtleiter ist mir eigentlich schon zu viel. > Mehrere für jede einzelne Status-LED oder ganze Fenster für 7-Segment > Anzeigen ... da bekomme ich 's kalte grausen. Warum? Machen wir auch. Ist ganz simpel, gibt Normteile dafür. Wir nutzen z.B. dieses hier für ein Gerät mit Schutzgrad IP66 http://www.ganter-griff.de/?cmd=normblatt&guid=5a56bdcc-0983-4d3f-9086-04a6763ec4ef&LCID=1031&pageID=14
Gast
#3733086
Daniel Steffen schrieb: > PS: Schade das ASM so stiefmütterlich behandelt wird. Da sieht man > direkt was der Controller macht und kann schön kompakten Code schreiben. Den Output von C-Compilern generell(!) in Frage zu stellen war vor 10 Jahren, heute ist man im Zeitalter von automatischer C-Code-Generierung aus dem Modell nicht einmal mehr am C-Code interessiert. Was der Controller macht kann man mit einem gescheiten Debugger sehen, kompakter Code ist in Zeiten von passenden potenten Controllern für nahezu jeden Zweck eine überflüssige Liebesmüh'
Gast
#3733391
Daniel Steffen schrieb: > um einem unbedarften Benutzer den Zustande eines Gerätes sichtbar zu > machen In der Praxis gibt es zahlreiche Anwendungen für die optische Kommunikation durch – teils verschiedenfarbige - Blinkmuster. Meist sind daran aber keine 'unbedarften Benutzer' beteiligt. - Die Kennung von unbekannten Leuchtfeuern in der Seefahrt lässt sich zusätzlich durch geeignetes Kartenmaterial verifizieren. - Das Lichtmorsen zwischen Schiffen wird durch Fachpersonal routiniert abgewickelt. - Fluglotsen senden vom Tower auf optischem Wege Weisungen an Luftfahrzeugführer am Boden oder in der Luft. Da hier auch mit rotem oder grünem Licht gearbeitet wird, dürfen Piloten keine R/G-Sehschwäche besitzen.
Gast
#3733508
Grün-Blau-Schwäche ist bei Männern sehr viel häufiger als Grün-Rot. Blackbird
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.