Home
Download: Arduino-Shutter.ino


Canon EOS 1100D Shutter-Emulation mit Arduino

Erwin Lotter, 25.1.2017                                    

Vor einiger Zeit hat Hendrik Beijeman eine Schaltung vorgestellt, die den Shutter einer Canon EOS 1100D emuliert. Um die von der Kamera erwarteten Signale zu simulieren, hat er einen Mikrocontroller-Chip eingesetzt, was leider einen hohen Einarbeitungsaufwand für Nichteingeweihte wie mich voraussetzen würde. Deshalb habe ich nach einer alternativen Lösung gesucht und bin dabei auf den Arduino gestoßen, von dem ich zwar schon mal gehört hatte, den ich aber bisher noch nicht kannte. Umso erfreuter war ich, als ich fand, dass alles, was man benötigt, um einen solchen Controller zu programmieren, die komfortable, super dokumentierte und freie Arduino IDE ist, die mit ein paar Mausklicks installiert war und mich fast im ersten Anlauf ein Testprogramm starten ließ.

Ebenso erfreulich fand ich das große Angebot an preisgünstigen Arduino-Boards, das in den kompatiblen China-Nachbauten gipfelt, die schon für ca. 2 Euros zu haben sind.

Grundsätzlich können wohl fast alle der verschiedenen Arduino-Boards, die recht unterschiedliche Ausstattung besitzen, verwendet werden. Für die einfache Integration in die Kamera ist jedoch ein kleines Board günstig, das mit 3.3V betrieben werden kann. Zum Testen wäre dagegen ein Board mit integrierter USB-Schnittstelle vorteilhaft. Das sind zwei Anforderungen, die sich schlecht miteinander vertragen. Zum Glück machen es die günstigen Preise der Boards einfach: Man kauft einfach zwei verschiedene Boards.

Tatsächlich hat sich herausgestellt, dass dies sogar die ideale Lösung ist. Es ist nämlich notwendig, auf einem in die Kamera integrierten Board den Arduino Bootloader zu überschreiben, weil der nach dem Einschalten zu lange braucht, das Nutzprogramm – den Shutter-Emulator – zu starten. Stattdessen wird der Emulator direkt als Startcode in das Board geschrieben. Und dazu eignet sich ein zweiter Arduino mit einer USB-Schnittstelle ganz hervorragend. (Zusätzlich lässt sich dessen USB-Schnittstelle auch noch für den seriellen Zugang zu einem USB-losen Arduino verwenden, während man umgekehrt mit einem USB-Adapter allein kein Bootprogramm installieren kann.)

Das sind die Boards, die ich mir dazu beschafft habe:

1.)   „MINI USB Nano V3.0 ATmega328P CH340G 5V 16M - Compat. Arduino Nano V3.0”
(Bezeichnung des Anbieters)

 2.)  “‘Pro Mini’ atmega328 3.3V Replace ATmega128 Arduino Compatible Nano“
(Bezeichnung des Anbieters)

 

 

Beide kamen per Direktimport aus Hongkong zum Preis von ca. 2,50 € bzw. 1,80 € (versandkostenfrei !). Zoll ist dank der geringen Preise kein Thema, die Lieferzeiten können allerdings schon mal 2-3 Wochen betragen. Einziges kleines Problem war der CH340G USB-Kontroller des ersten Boards, für den die Arduino-IDE keinen Treiber installiert hat, so dass ich erst einen besorgen und manuell nachinstallieren musste (CH341SER.zip).

Die 3.3V-Variante des ‘Pro Mini’ läuft aufgrund der Prozessorspezifikationen nur mit 8 MHz statt der verbreiteten 16 MHz. Man muss deshalb bei der Programmierung genau darauf achten, nicht nur den korrekten Board-Typ, sondern auch die passende Taktfrequenz auszuwählen! Die verbreitete 5V/16MHz-Variante des ‘Pro Mini’ läuft zwar auch mit 3.3V, es ist aber nicht garantiert, dass dies unter allen Betriebsbedingungen zuverlässig funktioniert. Bei mir hat es zwar geklappt, aber ich habe z.B. noch nicht getestet, ob es auch in einer kalten Nacht funktioniert. (Nein, ich habe keine drei Boards gekauft, es waren bisher fünf. Ein herrliches Spielzeug, die Dinger.)

Die Beschaltung

Abweichend von Hendriks Lösung verwende ich das P5 Signal der Kamera nicht, und zwar weil es sich nicht dazu eignet, den Live-View Modus nachzubilden. Man kann aber aus dem P7-Signal allein die benötigten Informationen ziehen und mit einer kleinen Modifikation von Hendriks Timing alle Modi nachbilden. Damit erübrigt es sich auch, P5 direkt auf dem Mainboard der EOS abzugreifen, was nicht ganz trivial ist. Lediglich für die 3.3V muss man noch direkt auf dem EOS-Board löten, aber das geht recht einfach. (Leider lässt sich die Versorgung der ‚coil‘ auf P6 nicht zur Versorgung des Arduino verwenden, weil sie nicht permanent anliegt.)

Ein anderer kleiner Unterschied zu Hendriks Design besteht darin, dass ich anstelle der MOSFETs an den Ausgängen simple Dioden verwende, die ich noch rumliegen hatte. Evtl. könnte man darauf auch ganz verzichten, aber ich wollte kein Mainboard riskieren und habe es deshalb nicht ausprobiert. Außerdem ist mit den Dioden (oder MOSFETs) auch ein 5V Testbetrieb des Arduino problemlos möglich.

Zum Testen kann vor Vcc des Arduino noch ein Schutzwiderstand von z.B. 47 Ohm eingefügt werden, für den Fall, dass die 3.3 V der Kamera nicht kurzschlussfest sind.

Weil der Shutter den Ausbau seines Anschlusskabels selten überlebt, habe ich auch versucht, die Kamera direkt an den Anschlüssen des Steckers zu kontaktieren. Davon kann ich aber nur abraten, das Raster ist doch ziemlich eng und Lötbrücken lassen sich nur schwer wieder entfernen. Als bessere Option hat sich die Verwendung eines ausgemusterten Flachbandkabels im 0.5 mm Raster erwiesen, das in einzelne Leiterbahnen gesplittet wird.

Software

Ein Arduino-Programm – Sketch genannt – wird i.A. per serielle (USB-) Schnittstelle an die Arduino Basissoftware – Bootloader genannt – übergeben, die es permanent speichert und nach einem Reset oder dem Einschalten des Arduino ausführt. Das dauert aber ca. eine halbe Sekunde, und das ist zu lange für die Kamera, die offenbar gleich mal überprüft, ob mit dem Shutter alles in Ordnung ist. Zumindest wenn die Kamera mit dem "EOS Utiliy" über ihre USB Schnittstelle angesprochen wird (anders habe ich es nicht getestet), hängt sie sich dabei auf. Für Testzwecke kann der Arduino natürlich mit einer externen Quelle (z.B. seinem USB Anschluss) versorgt werden, so dass die Versorgung schon anliegt, wenn die Kamera eingeschaltet wird – dann ist alles ok.

Für den Echtbetrieb muss das Steuerprogramm („Arduino-Shutter V1.0“) aber so in den Arduino übertragen werden, dass es den Bootloader überschreibt und beim Einschalten sofort startet. Wie das geht, wird z.B. auf Adafruit Learning System oder Shelvin – Elektronik ausprobiert und erläutert sehr schön gezeigt. Eine stichwortartige Kurzfassung findet sich unten im Abschnitt „Boot-Programme laden“.

Ablauf der Emulation

Im ersten Anlauf habe ich versucht, die Emulation mit P5 als alleinigem Triggersignal zu realisieren. Dabei habe ich vorausgesetzt, dass das Timing der beiden Modi, die Hendrik beschrieben hat, abgesehen von der Pause im ‚long mode‘ identisch sein darf – schließlich liegt ja der gleiche mechanische Ablauf zugrunde. Tatsächlich war die einzig nötige Anpassung die Verlängerung des Delays ab der zweiten Triggerflanke um mindestens 2 ms.

Leider klappt das aber nicht im Live-View Mode: Hier wird nämlich P5 (also die LED) nicht deaktiviert, so dass der Emulator nicht mehr weiss, wann Schluss ist.

Erfreulicherweise stellt sich aber heraus, dass die Lichtschrankensignale aktiv bleiben dürfen, auch wenn ihre LED via P5 deaktiviert wird. Dadurch wird die ganze Sache wirklich einfach: P5 wird komplett ignoriert, das Start-Timing auf die erste Flanke von P7 bezogen und das Schluss-Timing auf die zweite. Lediglich die Verlängerung des Delays um 2 ms wie oben muss in Hendriks Timing noch eingefügt werden.

Nun vereinfacht sich das ganze Programm zu einer Liste von Delays, nach denen die Signale, bezogen auf die P7-Flanken, generiert werden. Dazwischen geht der Prozessor in den Ruhezustand und verbraucht dann nur noch wenige Mikroampere. (Um das wirklich nutzen zu können, muss aber noch die Power-LED des Arduino ausgelötet oder –gebrochen werden, die ansonsten ca. 1 mA verbrät.

Boot-Programme laden

(Kurzfassung der Anleitung von Shelvin – Elektronik ausprobiert und erläutert.)

EIn Arduino-Sketch soll so geladen werden, dass er den Bootloader überschreibt und ohne dessen Hilfe ausgeführt wird. Dazu wird ein zweiter Arduino als ISP (In-System-Programmer) verwendet. Es sind 3 Schritte notwendig.

1. Einen Arduino zum ISP Programmer umfunktionieren

Als erstes wird der zweite Arduino – im Folgenden ISP genannt – an den PC angeschlossen und mit der Programmer Software geladen.
Hier darf das Ziel-Board noch nicht angeschlossen sein!

Unter Tools > Board wird der Typ des ISP Arduino eingestellt und die richtige COMx Schnittstelle wird ausgewählt.
In der Arduino IDE wird unter Datei > Beispiele > ArduinoISP das Programm ArduinoISP ausgewählt und dann als Sketch hochgeladen.

Dann wird der Arduino als Programmer gekennzeichnet mit
    Tools > Programmer > Arduino as ISP (nicht ArduinoISP!).

2. Beschaltung

Als nächstes wird der ISP abgehängt und der Ziel-Arduino an ihn angeschlossen: Gnd und Vcc werden verbunden, ebenso wie D11-D13 (MOSI, MISO und SCK). D10 des ISP geht an RST des Ziels.

Dann den ISP wieder an den PC anschließen.

3. Programm auf das Ziel laden

Als Board muss jetzt das Ziel-Board angegeben werden – ggf. einschließlich des korrekten Prozessors und der richtigen Taktfrequenz (wird nicht automatisch erkannt)!
Dann muss das gewünschte Programm ganz normal als Sketch geöffnet werden. Das Hochladen erfolgt jetzt aber nicht mit der HochladenHH Funktion, sondern mit Sketch > Upload mit Programmer (oder Shift-Hochladen Button). Damit lädt der ISP das Programm als Boot-Code in das Ziel.