Canon-EOS-Protokoll

[jplatte]

Das Protokoll ist deutlich interessanter. Einen Atmel programmieren kann ja jeder, so ein Protokoll analysieren und verstehen kann nicht jeder.

Hoffe, dass das motiviert!

 

[_MAG_]

i sink need do atmel fist becouse you can use him to test eos protocol.

i dont undertand general target of this progect, sory. I use translate-google to read this forum.

1. you can create system to control lens without body (adapter to video camera or microscope)
2. you can create lens simulator and create confirmation chip
3. maybe you can reprogram AF-adjust values in lens
i dont know....
in patent you can read sequence of commands and algoritm how eos system works in different situation.

 

[Nightshot]

i dont undertand general target of this progect, sory.

It's just fun. I had to program a FPGA for my astronomy project and was missing a signal source. The next thing I could grab was a camera and I connected the signal lines to my hardware. Now I had the protocol in my PC and could analyze it.
The rest is fun again. There are so many myths regarding this protocol and nobody ever looked on to it. I have no idea where the road goes and what will be the final result.

 

[maui]

Nun die Frage was mach ich zuerst? Den AF Algorithmus zu Ende verstehen oder Atmel proggen?

Ich würde beides parallel machen. Den Atmel zu proggen ist nicht die Welt und mit deinem technischen Verständnis hast du in 1-2 Tagen dort eigene Programme drauf. Ich finde es immer sehr motivierend, wenn die kleine Spinne schon nach wenigen Schritten Regung zeigt.

Ich denke, die kleine Einstiegshürde ist der Ablauf des ersten Flashens des Mikrokontrollers. Sobald dies einmal durchgespielt ist, begeistert son Krabbler durchaus.

 

[_MAG_]

i sink it is not AF adjustment value
"
248: 5.6 AF adjustment value he (int8)
250: 2.8 AF adjustment value he (int8)
"
read pages 9,10 if service manual

lens model 1 coefficient
zoom lens - zoom rage divided intro 32 parts. 1 coefficient for each
...
and ets
i sink it is difference of front or rear blur (2 coefficients)

or -
2.8 - lens apperture data. 5.6 coefficient
try to search lens name

 

[buyman]

Erst einmal Hut ab vor deiner Arbeit


Eine kleine Frage zum Protokoll (das habe ich aus deinen 2 angehängten Bildern leider nicht rauslesen können) wieviel Pause ist zwischen 2 Nachrichten?

Ich habe selbst noch ein altes (halb defektes - die Blende ist verharzt) Sigma Objektiv mit dem Fehler daheim. Damit würde ich gerne etwas spielen und den Protokollfehler beheben - die benötigte Ausrüstung dafür habe ich zum Teil zu Hause und den Rest in der Firma.

 

[pinkdots]

Also ich würde gleich zwei Chips für alte Sigma's abnehmen wollen. Vielleicht sogar drei. Wenn das deine Entscheidung zugunsten der Chip-Programmierung begünstigt

 

[MasterFX]

Ich glaube wir haben einen Gewinner, der passt wirklich sehr gut und kann eigentlich schon fast zu viel. Das wird eh auf Soft-SPI raus laufen, das andere ist nicht flexibel genug. Ist jetzt auch nicht der Mega Aufwand ein Shiftregister zu setzen und die Flanken zu scannen.

Eins noch. Wenn du später noch mehr machen willst, als nur das Protokoll zu "übersetzten", also z.B. auch die Schrittmotoren anzusteuern etc. dann reicht der ATtiny45 natürlich nicht aus. Denn durch den Quarz verlierst du auch noch 2 Pins, wodurch du dann nur noch 4 Pins hast, von denen 3 Stück aber schon weg sind (SDI, SDI, SCK)

Nun die Frage was mach ich zuerst? Den AF Algorithmus zu Ende verstehen oder Atmel proggen?

Erst Algo, das Proggen ist schnell gemacht.

 

[Nightshot]

Eine kleine Frage zum Protokoll (das habe ich aus deinen 2 angehängten Bildern leider nicht rauslesen können) wieviel Pause ist zwischen 2 Nachrichten?

Was meinst du mit 2 Nachrichten? Der Abstand zwischen zwei Bytes? Das ist variabel und vom Objektiv abhängig. Sollte bei einem Sigma so um die 150µs sein.

 

[MasterFX]

Was meinst du mit 2 Nachrichten? Der Abstand zwischen zwei Bytes? Das ist variabel und vom Objektiv abhängig. Sollte bei einem Sigma so um die 150µs sein.

Oh, bedeutet das, dass das Objektiv der SPI-Master ist?

 

[Nightshot]

Master, Slave das ist hier alles etwas verworren. Die Kommunikation läuft noch etwa 2s nach dem letzten Befehl nach (ungefähr so lange wie auch der IS nach läuft) und dann steht die Clock. Wird jetzt am Objektiv der AF/MF Schalter betätigt muss das die Kamera ja irgendwie mit bekommen, so zieht das Objektiv seine Datenleitung auf 0 und das bedeutet für die Kamera da will mir einer was sagen, ich lass mal die Clock laufen. Ebenso kann anscheinend auch das Objektiv einen Stopp einlegen lassen so lange es noch Daten verarbeitet und erst wenn es die Leitung wieder hoch setzt bedeutet das, bin bereit für neue Daten. Während sich die Blende bewegt wird die Clock auch aktiv auf 0 gezogen, so nach dem Motto jetzt musst ruhig sein, ich arbeite.

 

[buyman]

Was meinst du mit 2 Nachrichten? Der Abstand zwischen zwei Bytes? Das ist variabel und vom Objektiv abhängig. Sollte bei einem Sigma so um die 150µs sein.

Nein, mit Nachricht meine ich nicht den Abstand zwischen 2 Bytes. Eine Nachricht besteht wahrscheinlich aus einem Byte für den Befehl und mehreren Byte für die Daten. Irgendwie muss das Objektiv erkennen wo eine neue Nachricht beginnt. Obwohl, ich glaube gerade nicht dass die Kommunikation zwischen Objektiv und Kamera großartig gestört werden könnte ...

Eine Nachricht müsste das sein was du jeweils in eine Zeile geschrieben hast vermute ich mal.

 

[Nightshot]

Es gibt Befehle die bestehen nur aus einem Byte (Anforderung von Objektivparametern) und andere aus einem Byte gefolgt von ein bis zwei Byte an Werten (move aperture, move USM XY stepps). Die Antwort kommt schon im nächsten Byte das das Objektiv sendet.

 

[Nightshot]

Zweierkomplement: Höchstwertiges Bit hat den Wert -32768, die anderen Bits dann +16384, +8192, ..., +2, +1.

Also die Anzahl der zu fahrenden Motorschritte wird dann offensichtlich als Zweierkomplement gesendet.

 

[buyman]

Es gibt Befehle die bestehen nur aus einem Byte (Anforderung von Objektivparametern) und andere aus einem Byte gefolgt von ein bis zwei Byte an Werten (move aperture, move USM XY stepps). Die Antwort kommt schon im nächsten Byte das das Objektiv sendet.

Genau da setzt meine Frage an: wie erkennt das Objektiv ob das Byte das es gerade empfangen hat Daten oder ein Befehl ist? Es gibt eigentlich 2 Möglichkeiten:

• entweder es wird quasi ab dem 1. Befehl "mitgeloggt" und davon ausgegangen dass nichts bei der Übertragung schief geht (halte ich persönlich für unwahrscheinlich - alle Fremdhersteller müssten so das gesamte Protokoll genau analysiert haben, sonst würde nichts funktionieren)
• oder es wird irgendwie "mitgeteilt" dass als nächstes ein Befehlsbyte kommt - sei es durch eine längere Pause zwischen 2 Clocks oder definierte Pegel auf den Leitungen. Das gilt es rauszufinden. Hätte ich die Möglichkeit mir das ganze selbst anzusehen hätte ich das ganze heute schon gemacht.

Wenn ich weiß wie ich ein Befehlsbyte vorab erkenne kann ich dann mit einem 2. µC aus einer 19 eine 18 machen (und wenns ganz genau sein soll auch wieder aus der 18 eine 19 bei der Antwort).

 

[Nightshot]

Genau da setzt meine Frage an: wie erkennt das Objektiv ob das Byte das es gerade empfangen hat Daten oder ein Befehl ist?

Im Prinzip sind einfach alles Befehle. Mir fallen im Moment nur drei Befehle ein die ein Argument erfordern. Wird so ein Befehl geschickt wartet das Objektiv noch ein oder zwei Byte ab bis alles vollständig ist und führt ihn dann aus. So gesehen loggt das Objektiv alles mit, was nicht verwunderlich ist, denn die Kamera schickt keine NOP. Alles ist wichtig und alles erfordert eine Antwort.

Wenn ich weiß wie ich ein Befehlsbyte vorab erkenne kann ich dann mit einem 2. µC aus einer 19 eine 18 machen (und wenns ganz genau sein soll auch wieder aus der 18 eine 19 bei der Antwort).

Tja, es gibt leider keine Vorwarnzeit.

 

[nipponichi]

Nightshot, kannst Du mal einen Screenshot vom Oszi/LA einstellen und vielleicht kommentieren. Das würde mehr als tausend Worte sagen und wäre sehr interessant

 

[buyman]

Im Prinzip sind einfach alles Befehle. Mir fallen im Moment nur drei Befehle ein die ein Argument erfordern. Wird so ein Befehl geschickt wartet das Objektiv noch ein oder zwei Byte ab bis alles vollständig ist und führt ihn dann aus. So gesehen loggt das Objektiv alles mit, was nicht verwunderlich ist, denn die Kamera schickt keine NOP. Alles ist wichtig und alles erfordert eine Antwort.

Das ist natürlich blöd - da müsste man schon (fast) die ganze Kommunikation verstehen. Ich würd aber sagen dass die Kamera schon NOPs schickt. Und zwar die 0-Bytes zwischen 2 Anfragen interpretiere ich als solche (ich nehme an die werden vom Objektiv ignoriert). Der Master clockt so einfach noch etwas weiter damit das Objektiv auch die Antwort/Daten komplett zurück senden kann.

Tja, es gibt leider keine Vorwarnzeit.

Blöd, aber das ganze sollte trotzdem noch schaffbar sein.

Ist der Dump aus Beitrag #24 vollständig, also vom Start weg aufgezeichnet? (Mit Start meine ich den Zeitpunkt wo die Kamera eingeschaltet wird bzw. das Objektiv auf die Kamera kommt - ka. ob die Kamera im ausgeschalteten Zustand auch kurz mit dem Objektiv kommuniziert). Falls nein, könntest du einen entsprechenden Dump einstellen?

Nightshot, kannst Du mal einen Screenshot vom Oszi/LA einstellen und vielleicht kommentieren. Das würde mehr als tausend Worte sagen und wäre sehr interessant

Schau mal hier: https://www.dslr-forum.de/showpost.php?p=6458130&postcount=43
Sowas meintest du doch, oder?

 

[nipponichi]

Schau mal hier: https://www.dslr-forum.de/showpost.php?p=6458130&postcount=43
Sowas meintest du doch, oder?

Ups, stimmt . Ich dachte nur, bei der letzten Diskussion wäre ein Bildchen hilfreich gewesen.

 

[Nightshot]

Ich würd aber sagen dass die Kamera schon NOPs schickt. Und zwar die 0-Bytes zwischen 2 Anfragen interpretiere ich als solche (ich nehme an die werden vom Objektiv ignoriert).

Na gut, die Kamera wartet natürlich schon so lange bis alle Bytes der erwarteten Antwort da sind. Wenn sie nichts erwartet schickt sie aber auch keine 0 Bytes durch die Gegend.

Ist der Dump aus Beitrag #24 vollständig, also vom Start weg aufgezeichnet?

Nein ist er nicht. Der hier ist mit Kamera im Standby und dann wird der Abblendknopf gedrückt. Der Dump ist vollständig, bis die Kamera die Kommunikation selbständig wieder einstellt.