Änderungen
**Bugfixes in der flash.tcl, Blinken konnte niedrige Beleuchtung zurück lassen
**Neues Feature: Priorität
==Funktionsweise der zukünftigen Version==
Entwicklungsbasis von MustangRocks und DocZoid für die weitere Entwicklung
===Komponenten===
Es gibt folgende Software-Komponenten:
*'''hss_lcd.ko''': Kernel-Treiber, basierend auf OpenSource, von MustangRocks weiterentwickelt, zur Ansteuerung des CCU-Displays und der LEDs und Tasten. Weiterentwickelte Version enthält zwei Kanäle, einen zur Kommunikation mit hss_lcd, und einen zur Kommunikation mit dem API.
*'''hss_lcd''': Programm von eq-3, welches die HTML-Interpretation der Menüdateien enthält. Ruft die Menüdateien über den Webserver auf, so dass cgi-Scripte ausgeführt werden. Kann keine LEDs ansteuern, nur Text anzeigen.
*'''hss_index.cgi''': Haupt-Menüdatei, welche bisher direkt den anzuzeigenden Text und einen autoswitch-timeout zurückgegeben haben, um ein refresh der angezeigten Daten zu erreichen. Die zukünftige Verwendung wird weiter unten beschrieben.
*'''API''': Das API wird von MustangRocks als tcl-Datei (Name) bereitgestellt, um eine einfachere Kommunikation zwischen TCL-Programmen und der hss_lcd.ko zu ermöglichen.
*'''ccu_lcd''': Daemon, welcher die Nachrichtenverwaltung übernimmt.
===Initialisierung===
*hss_lcd wird gestartet und ruft hss_index.cgi auf.
*in hss_index.cgi wird zunächst der ccu_lcd daemon Prozess gestartet, und ein default-String (ccu_lcd Va.b) zur Anzeige an der CCU zurückgegeben, ohne refresh-timeout.
*in ccu_lcd wird die init-Routine des API aufgerufen, und ein TCP-Listener-Socket geöffnet (Nachrichtenannahme)
*im API wird die initialisierung von hss_lcd.ko weitergeführt
*hss_lcd.ko schaltet auf den zweiten Kanal zur Anzeige der eigenen Nachrichten
*ccu_lcd zeigt ggf. bestehende Nachrichten an
===Ereignisse===
*Neue Nachrichten werden durch Übertragung von TCP-Daten (Warum nicht UDP?) an ccu_lcd gemeldet. ccu_lcd verarbeitet daraufhin die Daten und hält sie für eine weitere Übermittlung an das API vor (vermutlich in Dateien).
*Nachdem eine "showtime" von Nachrichten abgelaufen ist meldet sich hss_lcd.ko über das API beim ccu_lcd-Daemon. Dort können dann weitere Nachrichten übermittelt werden.
===Fragen===
#warum nicht UDP statt TCP
#Nachrichten in Dateien vorhalten hat den Vorteil, dass bei einem Neustart des Anzeigesystems alte Nachrichten wieder angezeigt werden können. Scheint mir (DocZoid) jedoch mehr Aufwand in der Programmierung, zumal ein Neustart des Anzeigesystem nicht notwendig sein sollte. Bei einem CCU-Neustart sind eh alle Nachrichten weg. Mal schauen inwieweit sich das alte Dateien-System übernehmen lässt.
#Wie werden neue Nachrichten an hss_lcd.ko gesendet? Wenn nur eine Nachricht angezeigt wird sollte hss_lcd.ko nicht ständig pollen, ob es neue Nachrichten gibt: man hätte nicht viel zum alten System gewonnen. Grundsätzlich sollten neue Nachrichten immer ''sofort'' angezeigt werden (wenn die Priorität dies zulässt), und das Pollen muss minimiert werden, sprich ccu_lcd darf dem API nur eine showtime übergeben, wenn weitere Nachrichten angezeigt werden müssen.
#Wer prüft auf den timeout einer Nachricht, insbesondere wenn es nur eine gibt und es kein Polling gibt?
===Timeout-Überwachung===
#LED- und Hintergrundbeleuchtungs-Timeouts werden von hss_lcd.ko überwacht
#Bei Nachrichten-Timeouts muss die Datei / der Datensatz in ccu_lcd gelöscht werden. Wird ccu_lcd hier extern von hss_lcd.ko getriggert?
===API-Beschreibung===
