Canon EF lens mount - Communication protocol

Started by jplxpto, December 08, 2012, 02:42:44 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jplxpto


"
The communication protocol between the camera is 8-data-bit, 1-stop-bit SPI (mode 3). The pins, from right to left on the lens, are:

Canon EF mount pins[2][17]
Name   Function   Notes
VBat   +6 volts to power internal lens focus motors   
Present on all EOS bodies and lenses

P-Gnd   Power ground
P-Gnd
VDD   +5.5 volts Digital logic power
DCL   Data from camera to the lens (MOSI)
DLC   Data from the lens to the camera (MISO)
LCLK   Camera body generated clock signal (SCLK, CPOL=1)
D-GND   Digital logic ground
COM1   Teleconverter common[18][19][20]   
Only on most L-series and some macro lenses

EXT0   Short to COM1 for 'Life Size Converter' and x1.4 teleconverter
EXT1   Short to COM1 for x2 and x1.4 teleconverter
"

http://en.wikipedia.org/wiki/Canon_EF_lens_mount#Stepping_motor




eos-dacious

Is there a way to intercept the raw data that is sent or received over the electrical connection pins in the EF-Mount from within ML ?
Are there any adressess that are constantly changing while there is communication going on with lens?

Btw.: the probably currently best compilation of the Canon EOS EF-mount protocol can be found in this post: www.dslr-forum.de/showpost.php?p=12221153&postcount=554

a1ex

This happens on another processor, which we don't really understand yet.

To get the code running on that processor, see https://bitbucket.org/hudson/magic-lantern/branch/mpu

If you have about 1-2 years of spare time, and some low-level programming knowledge, you could try to modify a Tx19A emulator (such as NikonHacker's) and have fun understanding that code.

Looking inside an EOS M3 might be interesting: from strings, it appears to have 3 secondary CPUs: MechaCpuA, MechaCpuB, SubCPU. I have no idea what's there yet, but at least the implementation seems different than on current DSLRs.

In other words, I think it's much easier to intercept it at hardware level.

nikfreak

You could modify the following setup and treat it as PoC for debugging the cam hardware if you extend it:

http://web.media.mit.edu/~bandy/invariant/move_lens.pdf

What I was planning to do is:


  • Get my hands onto a small body (pref. EOS-M)
  • Add JTAG hardware / software to my equipment (UART is known to provide access to DryShell) but JTAG with OpenOCD would be preferrable.
  • Dismantle the body to gain access to the pins (RX / TX / GND ...)
  • Start debugging. I assume this would also help in terms of Digic6/7 development if a newer cam is used - not only extend private knowledge by a steady learning curve. Got only experience with flashing OpenWRT routers so far via serial console and cheapo FTDI cables / adapters
[size=8pt]70D.112 & 100D.101[/size]