Canon EOS 1100D Shutter-Emulation with Arduino
Erwin Lotter, 25.1.2017
Recently, Hendrik Beijeman presented a Canon EOS 1100D shutter emulation in which he utilized a mikrocontroller chip to simulate the signals expected by the camera. Since I do not have experience with modern microcontrollers I was looking for an alternative solution and came to the Arduino. Although I didn’t have hands on such a system before, I found it very easy to get started with it due to the comfortable, free and very well documented Arduino IDE. I got the IDE installed with a few mouse clicks and succeeded to run one of the example programs almost on the first try.
Likewise, I enjoyed the broad offer of low-priced Arduino boards, which culminates in the compatible China clones, which are already available for about 2 euros.
Basically, almost all of the different Arduino boards, which have quite different equipment, should be usable. For easy integration into the camera a small board is favorable, which can be operated at 3.3V. For testing, however, a board with an integrated USB interface would be advantageous. These are two requirements that are not fully compatible with each other. Fortunately, the low prices of the boards make it easy: you simply buy two different boards.
In fact, this turned out to be the ideal solution because it is necessary to overwrite the Arduino bootloader on a board to be integrated into a camera. Otherwise, if the shutter emulator is started as a utility program, it takes too long to come up after switching it on. Instead, the emulator is written to the board as start code. And for this purpose, a second Arduino with a USB interface is perfectly suited. (In addition, its USB interface can also be used for serial access to a USB-less Arduino, while it is not possible to install a boot program through a USB adapter.)
These are the boards that I ordered:
1.) „MINI USB Nano V3.0 ATmega328P CH340G 5V 16M - Compat. Arduino
2.) “‘Pro Mini’ atmega328 3.3V Replace ATmega128 Arduino
Both came by direct import from Hong Kong for the price of about 2.50 € and 1.80 € (shipping free!). Tax was not an issue here in Germany due to the low prices, but delivery times can be 2-3 weeks. The only little problem was the CH340G USB controller on the first board, for which the Arduino-IDE had no driver installed, so I had to get one and install manually (CH341SER.zip).
Due to the controller specifications, the 3.3V model of the 'Pro Mini' runs only at 8 MHz instead of the more common 16 MHz. It is therefore important to pay attention not only to selecting the correct board type, but also the correct clock frequency during programming! The popular 5V / 16MHz version of the 'Pro Mini' often also runs fine at 3.3V, but it is not guaranteed to work reliably under all operating conditions. With me it worked, but I have not tested yet whether it works also in a cold night.
Unlike Hendrik's solution, I do not use the P5 signal of the camera, because it is not suitable to simulate the Live-View mode. One can, however, draw the required information from the P7 signal alone and simulate all modes with a small modification of Hendrik's timing. Then, it is also avoidable to tap P5 directly on the mainboard of the EOS, which is not quite trivial. Only for the 3.3V you have to solder directly on the EOS board, but this is less difficult. (Unfortunately, the supply of the 'coil' on P6 can not be used to supply the Arduino because it is not permanently present.)
Another small difference to Hendrik's design is that I use simple diodes instead of the MOSFETs at the outputs, which I had still lying around. Possibly they can be omitted completely, but I didn’t want to risk a mainboard to check this. In addition, a 5V test operation of the Arduino is possible without problems with the diodes (or MOSFETs) present.
For testing, a protective resistor of e.g. 47 ohms may be put into the supply line to protect the 3.3 V of the camera in case it is not short circuit proof.
Because the shutter rarely survives the extraction of its connecting cable, I also tried to contact the camera directly at the wires of the connector. But I can only advise against this, the pattern is rather tight and solder bridges are difficult to remove. A better option is the use of a spare flat-ribbon cable with a 0.5 mm pitch, which is split into individual conductor tracks.
An Arduino program – also called sketch –
usually is passed via a serial (USB) interface to the Arduino bootloader, which
permanently stores and executes the program after a reset or power-up of the
Arduino. This takes about half a second, however, and that’s too long for the
camera, which apparently checkes on start-up, whether the shutter is all right.
At least if the camera is addressed via USB and EOS-Utiliy (other
configurations I have not tested), it hangs.
For real-time operation, however, the control program („Arduino-Shutter V1.0“) must be transferred to the Arduino in such a way that it overwrites the bootloader and starts immediately when the Arduino is switched on. How this is done is shown very nicely on e.g. Adafruit Learning System. A short summary is given below in the section "Uploading a Boot Program".
In the first attempt I tried to realize the emulation with P5 as the sole trigger signal. Since the mechanical sequence is the same in all cases, I assumed that the timing of the two modes Hendrik described can be identical except for the pause in the 'long mode'. In fact, the only necessary adjustment was the extension of the delay from the second trigger edge by at least 2 ms.
Unfortunately, this approach does not work in Live-View mode: Here, P5 (ie the LED) is not deactivated, so the emulator cannot conclude from P5 when the shutter is closed.
Fortunately, however, it turns out that the light sensor signals may remain active, even if their LED is deactivated via P5. This makes the whole thing really easy: P5 can be ignored completely, the open timing is related to the first edge of P7 and the final timing to the second. Only the extension of the delay by 2 ms must be inserted in Hendrik's timing as above.
Now, the entire program is simplified to a list of delays, according to which the signals are generated with respect to the P7 slopes. In between, the processor goes into the idle state and then consumes only a few microampers. (In order to really use this, the Arduino's power LED, which otherwise consumes about 1 mA, must be unsoldered or broken off, however.
Uploading a Boot Program
An Arduino sketch can be uploaded in a way that it
overwrites the bootloader and runs without it. For this purpose, a second
Arduino is used as an ISP (In-System-Programmer).
1. Convert an Arduino into an ISP Programmer
First, the second Arduino - the ISP - is connected to the PC
and loaded with the Programmer software.
In the Arduino IDE, select „Tools > Board“ and enter the type of the ISP Arduino. Ensure that the correct COMx interface is selected.
Select „File > Examples > ArduinoISP > ArduinoISP“ and then upload as a sketch.
Next, the Arduino is marked as a programmer by selecting
Tools> Programmer> Arduino as ISP (not ArduinoISP!).
2. Connecting the Boards
Now the ISP is disconnected from the USB and connected to the target arduino: Gnd-Gnd and Vcc-Vcc are connected, as are D11, D12, D13 (MOSI, MISO and SCK). D10 of the ISP goes to RST of the target.
Then connect the ISP to the PC again.
3. Upload to Target
Now, the target board must be indicated as the connected board - including the correct processor and the correct clock frequency (this will not be detected automatically)!
Then the desired program is opened as a sketch. The upload, however, is not done with the upload function, but with „Sketch > Upload with Programmer“ (or Shift Upload Button). With this command, the ISP loads the program as boot code into the target.