Ich hab es an anderer Stelle schon einmal erwähnt: Seit mehreren Jahren arbeite ich mit Leuten an einer Lösung zur Steuerung von Geräten. Der ganze Bimmbamm hat sehr wenig bis ganz viel mit Automatisierung zu tun, geht aber an manchen Stellen darüber hinaus und ist an an verschiedenen Stellen sowieso ganz etwas anderes. Das Ding nennt sich BetaTouch.
Einer der Wege, die wir mal verfolgt haben, waren die ‘Zauberkästchen’. Daraus ist kein fertiges Produkt geworden, aber es gibt ein paar Bilder und ein wenig was zu erzählen. Hervorragend also für die Webseite.
Die Idee hinter den Zauberkästchen ist es, mehrere einfache Module zu haben, die man quasi beliebig kombinieren kann, um damit unterschiedliche Geräte anzusprechen. Die Module basieren alle auf einer identischen Platine, die abhängig von den jeweiligen Anforderungen bestückt werden kann. Dadurch sind alle Module leicht zu fertigen, kostengünstig und einfach zu warten.
Hier mal ein Beispiel dafür. Von links nach rechts sind hier verbunden ein MIDI IN-Modul, ein Master-Modul, ein MIDI OUT- und ein Audac-Out-Modul. Die Funktionsweise ist denkbar einfach: Das Master-Modul verwaltet alles, klaro. Bei Eingang definierter MIDI Daten wird dann je nach Konfiguration das MIDI OUT Modul angesprochen, oder das Audac-Modul sendet serielle Daten, um ein angeschlossenes Gerät (in diesem Fall eine Audac-Endstufe) fernzusteuern. Welche Eingangsdaten für welche Aktion sorgen, welche Module beteiligt sind, welche Daten ausgesendet werden, etc. etc. wird per Konfiguration geregelt.
Im unteren Bild sieht man Speichermodul, das derzeit immer noch nur als Prototyp existiert. Hier sind die Konfigurationsdaten abgelegt und es enthält die konkreten Befehle, die an die angeschlossenen Geräte gesendet werden. die Konfiguration kann durch ein ‘Seriell IN’-Modul (basierend auf der Standardplatine) über einen Computer in den Speicher geschrieben werden.
Die Entwicklung der Platinen gestaltete sich wie so oft bei mir … äußerst iterativ. Angefangen bei ersten Krickeleien und Überlegungen ging es weiter über Steckbrettmodule hin zu den ersten ‘echten’ Versionen, die auf Lochrasterplatine aufgebaut wurden.
Analog dazu enstand relativ schnell der Schaltplan und das Platinenlayout, sodass die ersten Platinen erstaunlich fix in Auftrag gegeben werden konnten.
Zweifellos eine Meisterleistung der Integration.
Die Bestellungen bei RS-Online waren ab dem Zeitpunkt ausnahmslos kostenfrei (weil: viel)
Auch in Großaufnahme haben die Module ihren Charme. Sie verfügen über MIDI In und -Out, RS232- und RS485- Schnittstellen. Jedes Modul beherbergt einen ATmega328p als Gehirn und hat zusätzlich eine serielle Debug-Schnittstelle, sowie einen Hardware-Reset. Alle Module kommunizieren per I2C-Bus miteinenander. Dieser kommt über ein Flachbandkabel am Modul an und versorgt es darüberhinaus mit Bestriebsspannung.
Die Module sind so konzipiert, dass sie jeweils nur eine Schnittstelle aktiv betreiben können. Das ist teilweise dem UART des ATmega geschuldet. Um trotzdem alle gewünschten Funktionen mit derselben Platine abbilden zu können, müssen ggf. Lötbrücken gesetzt werden. Bei der linken Platine kann man das schön erkennen: Die zwei Lötpunkte ungefähr auf Höhe von Pin 5 des ATmega.
Die Architektur des Systems ist dahingehend ausgelegt, dass die Module über relativ wenig Intelligenz verfügen. Kommunikation mit dem Bus, Auslesen der konkreten Befehle vom Speichermodul, Kommunikation mit dem angeschlossenen Gerät. Alles eher programmiertechnische Fingerübungen. Das Master-Modul hat dadurch auch nicht all zu viel zu tun. Wesentliches Feature des Masters ist die Verwaltung einer Input-Queue: Wenn z.B. ein per Midi angeschlossener Fader die Lautstärke an einer Endstufe regeln soll, dann kommen die Daten schneller an, als sie abgearbeitet werden. Schlau ist, das abfangen und verarbeiten zu können, damit es nicht zu Chaos auf dem I2C Bus kommt und gleichzeitig eine gewisse Schwupddizität erhalten bleibt.
Es ist tatsächlich so: Rein technisch ist es oft einfach, irgendeine Funktionalität zu programmieren – die ganze Sache so zu parametrisieren, dass es richtig gut funktioniert, ist etwas ganz anderes.
Natürlich funktioniert das alles nur, wenn die Kommmunikation auf dem I2C Bus halbwegs koordiniert abläuft. Um das sicherzustellen habe ich ein entsprechendes Protokoll entwickelt. Das Protokoll erlaubt eine beliebige Länge der zu übertragenden Befehle an die jeweiligen Module. es bietet darüberhinaus die Möglichkeit, Rückmeldungen der Geräte zu verarbeiten, die an die Module angeschlossen sind. Zusätzlich kann der Ausfall eines Moduls am Bus festgestellt werden. Dynamische Daten wie z.B. die Werte von Fadern, etc. können natürlich ebenfalls je nach Bedarf über den Bus transportiert werden.
Die Protokolldokumentation füllt mittlerweile einen kleinen Ordner
Ein paar Sachen wurden damit realisiert und haben sehr gut funktioniert. Letztlich gibt es Gründe, weswegen wir uns gegen diese Lösung entschieden haben. Ausschlaggebend ist wesentlich, dass eventuelle Fehler im Code der Micrcontroller nicht ohne weiteres zu fixen sind, wenn man keinen physikalischen Zugang zu den Geräten hat. Bei einer rein software-basierten Lösung ist das eine andere Sache (mit anderen störenden Aspekten, klar. Das muss man abwägen).
Der Aufwand, der hier drin steckt, hat sich nur bedingt gelohnt. Ich habe es eingangs bereits erwähnt, letztlich ist daraus kein kommerzielles Produkt geworden. Nun gut. Trotzdem sind die übrig gebliebenen Module ein echtes Nice-to-have. Wenn es jetzt darum geht, ein Midi-auf-Irgendwas-Modul fix in Hardware zu realisieren: Check. Ein Hardware Midi-Translator: Check. DMX-auf-Seriell-Wandler: Check. Na immerhin.
Ein Aspekt der mich an dieser Sache verstärkt nervt, ist die dummdreiste Kaltschnäuzigkeit, mit der ich mich in letzter Zeit herumschlagen muss. Ganz zu Beginn steht “ich arbeite mit Leuten an einer Lösung…”. Das ist absolut okay. So etwas funktioniert nicht im Alleingang. Da gibt es mehrere Leute und jeder bringt sich ein. Der eine mit Wissen darüber, wie man an Kunden herantritt, wie man Preise gestaltet, etc. Der nächste arbeitet im Bereich Veranstaltungstechnik und bringt realistische Kundenwünsche ein…. Meinetwegen.
Trotzdem ist es so, dass ich an dieser Stelle die komplette Entwicklung mache. Ich entwerfe Platinen, schreibe Code für Mikrocontroller, erarbeite Protokollspezifikationen etc. Allein das, was ich für die Protokollspezifikation geschrieben (nicht programmiert) habe ist mehr, als manch ‘anderer’ von uns in den letzten 5 Jahren zu Papier gebracht hat. Inclusive Einkaufszetteln. Außerdem bezahle ich den ganzen Kram. Guess what: Ich bin der Urheber. Guess noch what: Da gehen richtig Stunden bei drauf. Diese Stunden könnte ich dazu verwenden, Geld zu verdienen, mich mit Freunden zu treffen, Bier zu trinken, etc. Tu’ ich aber nicht. Ich gehe damit in Vorleistung und das nicht zu knapp. Wir reden hier von locker 4-stelligen Stundenzahlen.
Wenn sich ein Meister für Veranstaltungstechnik jemand jetzt vor mir aufbaut und meint, über das hier nach Gutdünken verfügen zu können, weil “er die Idee hatte” und “sich das alles ausgedacht hat” (Klartext: Im gemeinsamen Gespräch darüber zwei Kästchen auf einen Zettel gekrickelt), dann kann ich nur sagen: f*ck Dich, Homie. Aber mit ganz viel Anlauf. existiert hier ein nicht unerheblicher Interessenskonflikt, dem ich derzeit nicht gewillt bin, mit Sanftmut zu begegnen. Eher im Gegenteil. Stress, Digger? Bekommst’e.
