I2C Daisy-Chain Module (“Zauberkästchen”)

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.

CIMG1366

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.

IMG_20130904_141701

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.

IMG_20130403_140229

 

IMG_20130319_235518

IMG_20130406_181210

Analog dazu enstand relativ schnell der Schaltplan und das Platinenlayout, sodass die ersten Platinen erstaunlich fix in Auftrag gegeben werden konnten.

CIMG0997

 

Zweifellos eine Meisterleistung der Integration.

IMG_20130701_175927

IMG_20130701_175840

 

Die Bestellungen bei RS-Online waren ab dem Zeitpunkt ausnahmslos kostenfrei (weil: viel)

IMG_20130709_172623

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.

CIMG1359

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.

CIMG1361

 

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.

IMG_20130706_130819

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.

CIMG1001

 

Die Protokolldokumentation füllt mittlerweile einen kleinen Ordner

CIMG0999

 

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).

IMG_20140228_125625 IMG_20140228_125617  IMG_20140211_230620

IMG_20130706_150022

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.

CIMG1003

CIMG1002

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.

Tagged , , , , , , .Speichere in deinen Favoriten diesen permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert