Canon-EOS-Protokoll

[MasterFX]

Nein, ein ganzer Befehl geht gar nicht.
Na dann viel Spaß, Bild ist anbei.

war klar. Ist mit Sicherheit umgelabelt oder evtl. doch ein ASIC. Da würde man erstmal anfangen müssen um die VCC, GND sowie die Oszillator-Pins zu finden, dann kann man schonmal eine reihe von µCs ausschließen (zumindest wenns kein ASIC ist)
Könnte z.B. ein Toshiba TLCS-870 µC im SSOP30 sein. Kannst ja mal gucken ob da was übereinstimmt

EDIT: Nee der passt nicht, GND scheint PIN9 zu sein. Naja wenigstens die Motortreiber haben sie nicht umgelabelt

 

[some12]

Ach nein ASIC oder relabeled, schade, wär zu schön gewesen...Wenn man den Typ hat, wird es nochmals fast unmöglich das Flash auszulesen. Aber vielen Dank für das Bild =)

Hardcore Lösung, neuer Chip rein und selber Code schreiben, man müsste einfach ein halbes Labor haben um die Dinger zu justieren...Hmm da könnte ich doch glatt mal unsere Physiker fragen

 

[Nightshot]

Hab mein Programm etwas überarbeitet und nun kann ich auch das erweiterte schnelle Protokoll vollautomatisch auslesen. Etliche neue Befehle, aber auch viele alte Bekannte. Spannend finde ich, dass die Statusabfrage vom Objektiv nicht mehr 144 sondern 145 ist. Könnte sein, dass Canon da noch eine weitere tickende Bombe im Keller hat.

Ich lese jetzt mal einen ganzen Satz AF Parameterdaten aus, denn ich möchte endlich die Funktion dahinter erkennen. In einem weiteren Schritt will ich dann aktiv mit Objektiv und Kamera reden können.

 

[Nightshot]

So langsam bekomme ich den Durchblick bei den AF Parametern. Einige Werte machen nur Vorzeichen behaftet einen Sinn, sind also signed int16. Was ist denn dafür die geläufigste Umsetzung? Das erste Bit als Vorzeichen und die restlichen 15 Bit als normalen int Wert oder sortiert man um von klein nach groß?

Wir werden übrigens auch in fern Ost gelesen, da kommen schon die ersten Anfragen.

 

[jplatte]

So langsam bekomme ich den Durchblick bei den AF Parametern. Einige Werte machen nur Vorzeichen behaftet einen Sinn, sind also signed int16. Was ist denn dafür die geläufigste Umsetzung? Das erste Bit als Vorzeichen und die restlichen 15 Bit als normalen int Wert oder sortiert man um von klein nach groß?

Ich kenne nur Umsetzungen mit dem ersten Bit als Vorzeichenbit und dem Zweierkomplement als Kodierung ( http://de.wikipedia.org/wiki/Zweierkomplement ), da damit sehr einfach gerechnet werden kann.

Was meinst Du mir umsortieren? Die Bytes in der Reihenfolge vertauschen?

Könnte es auch sein, dass Fließkommazahlen gesendet werden? Die passen ja auch ganz gut in 16 Bit und haben dann wieder eine andere Darstellung.

 

[Keksdose]

So langsam bekomme ich den Durchblick bei den AF Parametern. Einige Werte machen nur Vorzeichen behaftet einen Sinn, sind also signed int16. Was ist denn dafür die geläufigste Umsetzung? Das erste Bit als Vorzeichen und die restlichen 15 Bit als normalen int Wert oder sortiert man um von klein nach groß?

Das ist dummerweise vom Prozessor abhängig - da gibt es Big Endian und Little Endian. Bei Big Endian kommt das höchstwertige Byte zuerst, bei Little Endian das niederwertigste. Innerhalb eines Bytes gibt es dann aber Einigkeit, dort wird mit dem höchstwertigen Bit begonnen.
Ansonsten werden negative Zahlen üblicherweise im Zweierkomplement dargestellt.

Wir werden übrigens auch in fern Ost gelesen, da kommen schon die ersten Anfragen.

Interessant. Größeres Interesse von "Firmen" oder eher Privatpersonen?

Klaus

 

[Keksdose]

Könnte es auch sein, dass Fließkommazahlen gesendet werden? Die passen ja auch ganz gut in 16 Bit und haben dann wieder eine andere Darstellung.

Glaube ich nicht. Die kleinste mir bekannte allgemeingültige Fließkommadefinition hat 32 bit (float) - ich würde eher auf Festkommarithmetik tippen.

Klaus

 

[jplatte]

Das ist dummerweise vom Prozessor abhängig - da gibt es Big Endian und Little Endian. Bei Big Endian kommt das höchstwertige Byte zuerst, bei Little Endian das niederwertigste. Innerhalb eines Bytes gibt es dann aber Einigkeit, dort wird mit dem höchstwertigen Bit begonnen.
Ansonsten werden negative Zahlen üblicherweise im Zweierkomplement dargestellt.

Wenn man annimmt, dass bei verschiedenen Objektiven die Zahlenwerte nicht zu weit auseinander liegen, kann man recht schnell feststellen, ob Little- oder Big-Endian verwendet wird. Einfach die Zahlen in beiden Varianten umwandeln und schauen, was näher beieinander liegt. Allerdings hatten wir ja vorher erfahren, dass bei positiven Zahlen Big-Endian verwendet wird. Dann sollte es bei negativen Zahlen nicht anders sein.

Glaube ich nicht. Die kleinste mir bekannte allgemeingültige Fließkommadefinition hat 32 bit (float) - ich würde eher auf Festkommarithmetik tippen.

In freier Wildbahn sind mir auch nur 32-Bit floats begegnet, aber es gibt auch 16-Bit floats Da das Protokoll ja schon recht alt ist, wäre es durchaus möglich, dass ein sehr platzsparendes Format gewählt wurde. Möglicherweise auch was ganz anderes: Es würde ja nichts dagegen sprechen, wenn Canon hier was eigenes definiert hat. Jedes Bit könnte eine andere Funktion haben. Wirklich helfen würden vermutlich nur Objektive vor und nach der Justage bei Canon. Dann könnte man vergleichen, was sich verändert hat.

Jörg

 

[Nightshot]

Den meisten Sinn ergeben die Werte, wenn das erste Bit das Vorzeichen ist und die restlichen 15 einen normalen Wert ergeben. Hier mal ein Beispiel:

35 174
33 138
29 86
157 243
163 215

was dann folgende Übersetzung wäre:

9134
8586
7510
-7667
-9175

An der Stelle erwarte ich eine halbwegs glatte Zahlenreihe, da es ähnlich der ersten Ableitung einer Funktion ist. Leider springt das Teil beim Nulldurchgang.

 

[nipponichi]

-7667
-9175

Ich komme da auf -25101 und -23593, zumindest bei üblichem Zweierkomplement.
(-32768 ist 0x8000 und -1 ist 0xFFFF)
Vielleicht ist das MSB d.c. oder hat andere Bedeutung?

 

[MasterFX]

Vielleicht ist das MSB d.c. oder hat andere Bedeutung?

War HIER auch schon ein verdacht von mir (allerdings bei anderen Werten). Ich denke auch, dass es sich nicht um ein Vorzeichen handelt. Denn negative Werte ergeben eigentlich keinen Sinn, der Betrag des Wertes jedoch schon.
@Nightshot
Was sollen Zahlenfolgen denn sein bzw. was stellen sie ein? Brennweite, Blende etc?

 

[Nightshot]

Ok, dann gibt es hier mal einen größeren Brocken. Ausgelesen hab ich das 100/2,8 IS Makro. Das hab ich aus mehreren Gründen gewählt. Beim Fokussieren verschieben sich 3 Linsengruppen gegeneinander (das machen nur Makros) und die Werte sind extrem fein gestuft hinterlegt.

Im zip File sind die AF relevanten Daten abgelegt. Wie früher auch in jeweils Zweierzeilen. Zur Erklärung die Befehle:
12: Schaltet irgendein Register im Objektiv an
15: Macht auch irgendetwas (beide Befehle werden vom Objektiv als bestätigende Antwort zurück geschickt, das passiert nur bei Befehlen)
148 9: Etwas Neues bei EOS2.0 keine Ahnung
196: Könnte so etwas wie der Zeileneintrag im Register sein, der gerade abgefragt wird.
194: Entfernungsdaten vom Objektiv (zweimal int16)
248: 5,6er AF Justagewert (int8)
250: 2,8er AF Justagewert (int8)
148 48: Auch was Neues in EOS2.0
224: Lens extension sensitivity (int16). Ein ganz wichtiger Wert. Der macht die Übersetzung Phasendifferenz -> Motorschritte

Der Wert ist abhängig von der aktuellen Fokusposition vom Objektiv. Muss das Objektiv weit fahren, ändert sich ja dieser Wert auf der Strecke und der berechnete Wert an Motorschritten stimmt nicht so ganz. Daher gibt es noch die Lens extension correction Werte: 234 und 232. Einmal wenn das Richtung Unendlich fahren soll und einmal für die Richtung Nachbereich. In der Antwort vom Objektiv stecken drei int16 Werte. Der dritte Wert ist bisher immer 0 0, das war wohl mal als future upgrade gedacht.
Plotet man nun die LES (224) über den ganzen Fokusbereich, so sieht man schön wie sich die Linsen im Inneren gegeneinander verschieben und dadurch den Wert verändern. Den ersten der drei Werte aus dem LEC interpretiere ich als erste Ableitung aus oben gemachten Plot und der zweite Wert könnte die zweite Ableitung sein. Somit kann die Kamera zumindest im näheren Bereich abschätzen wie sich der LES während dem Fokusieren ändern wird und diese Änderung in die Berechnung der Motorschritte einfließen lassen.

Bis auf die Sprünge beim Nulldurchgang passt diese Theorie nicht schlecht, wenn jemand die Werte besser interpretieren kann, nur her damit.

Rechts nach jeder Zeile habe ich meine bisher beste Übersetzung noch hin gesetzt. Die Reihenfolge wäre:
224 234 (erster Wert) (zweiter Wert) 232 (erster Wert) (zweiter Wert)

Und sorry, ich verwende immer noch keine Hex Darstellung, auch wenn es in dem Fall sicher besser wäre.

 

[Nightshot]

So, ich hab den Abend jetzt mal genutzt um meine Elektronik umzubauen. Bisher war sie nur das stille Mäuslein das auf den Leitungen lauscht und nun werden alle Signale aktiv durch den Rechner geleitet, so dass ich direkten Einfluss auf den Datenfluss habe. Klingt jetzt einfach, hat aber etwas gedauert bis ich merkte, dass alle Ausgänge open collector sind und ich einen pull up Widerstand brauche.

Und dann hab ich auch gleich mal ausgetestet ob ich einen Übersetzer für das alte Sigma Objektiv schreiben kann und was soll ich sagen, hat auf den ersten Versuch geklappt. Kein Fehler mehr, Blende schließt und öffnet wie eh und je. Jetzt muss man das "nur" noch einem kleinen µC bei bringen.

 

[Gast_4334]

Und dann hab ich auch gleich mal ausgetestet ob ich einen Übersetzer für das alte Sigma Objektiv schreiben kann und was soll ich sagen, hat auf den ersten Versuch geklappt. Kein Fehler mehr, Blende schließt und öffnet wie eh und je. Jetzt muss man das "nur" noch einem kleinen µC bei bringen.

Wie geil.

 

[jar]

hast du mal die Spannung gemessen ?

welche Cam hast du als Master genommen ? welche Spannung kommt aus dem Bajonett ? kann es nicht doch an falschen pullups gelegen haben ? welche pullups sind in der Linse verbaut (Wert), welche hast du nachgefriemelt (Wert) ?
Die Anpassung kann ja auch durch Treiberleistung geschehen sein.

Ich hatte mal die Treiberleistung für eine Ataritastaturverlängerung erhöhen müssen, der CMOS Port konnte original nur 5cm Kabel treiben, im ST520 mit bi-dir OC Treiber und 12V hab ich die Leitung auf 5m verlängern können ohne weitere Anpassung

 

[jplatte]

Und dann hab ich auch gleich mal ausgetestet ob ich einen Übersetzer für das alte Sigma Objektiv schreiben kann und was soll ich sagen, hat auf den ersten Versuch geklappt. Kein Fehler mehr, Blende schließt und öffnet wie eh und je. Jetzt muss man das "nur" noch einem kleinen µC bei bringen.

Glückwunsch! Musstest Du jetzt Befehle erkennen, oder reichte es, die 18 in die 19 (oder umgekehrt) zu übersetzen? Wenn die Kamera diese Zahl nur in dem entsprechenden Befehl sendet, sollte das ja eigentlich reichen.

Wie kritisch war denn jetzt das Timing? Ein PC ist ja typischerweise viel langsamer als ein µC, wenn man nur die reine Interrupt-Latenz betrachtet. Oder ist das Protokoll toleranter als gedacht?

Jörg

 

[jar]

Wie kritisch war denn jetzt das Timing? Ein PC ist ja typischerweise viel langsamer als ein µC, wenn man nur die reine Interrupt-Latenz betrachtet. Oder ist das Protokoll toleranter als gedacht?
Jörg

ich denke auch so schnell sind Linse und Cam nicht, sieht nach einigen µs aus die man Zeit hat dazwischen, das sollte ein 16-20 MHz Atmel schaffen

 

[Nightshot]

hast du mal die Spannung gemessen ?

Sind stinknormale 5V TTL Signale.

welche Cam hast du als Master genommen ?

Wie immer meine Test 5D.

welche Spannung kommt aus dem Bajonett ? kann es nicht doch an falschen pullups gelegen haben ? welche pullups sind in der Linse verbaut (Wert), welche hast du nachgefriemelt (Wert) ?

Ist doch eigentlich egal oder? Man macht ja gerade open collector, damit man auch unterschiedliche Spannungslagen anpassen könnte. Ich hab jetzt 4,7kOhm eingebaut. Dass es daran nicht liegen kann sieht man, da alle anderen Befehle erkannt werden und das auch ohne Anpassung.

Musstest Du jetzt Befehle erkennen, oder reichte es, die 18 in die 19 (oder umgekehrt) zu übersetzen? Wenn die Kamera diese Zahl nur in dem entsprechenden Befehl sendet, sollte das ja eigentlich reichen.

Ist jetzt eine quick and dirty Lösung, ich tausche in Echtzeit 19 gegen 18 aus. Daher meldet das Objektiv auch 18 als empfangen Befehl zurück. Da könnte sich die Kamera auch wundern, ich hab doch 19 geschickt, warum kommt 18 zurück? Ebenso die Statusanpassung nach Veränderung der Blende ist nicht umgesetzt. Da muss anscheinend schon mehr passieren, dass die Kamera einen Fehler erkennt.

Wie kritisch war denn jetzt das Timing? Ein PC ist ja typischerweise viel langsamer als ein µC, wenn man nur die reine Interrupt-Latenz betrachtet.

Die Signale laufen nicht wirklich durch den PC, sie laufen durch einen 40MHz FPGA, der von meinem PC kontrolliert wird. Bei fallender clock Flanke wird der neue Wert geschrieben und bei steigender Flanke gelesen. Ich hab also 6µs Zeit dem Objektiv einen anderen Wert zu präsentieren.

 

[jar]

Ist jetzt eine quick and dirty Lösung, ich tausche in Echtzeit 19 gegen 18 aus. Daher meldet das Objektiv auch 18 als empfangen Befehl zurück. Da könnte sich die Kamera auch wundern, ich hab doch 19 geschickt, warum kommt 18 zurück?

aha, also erwartet die Cam den gesendeten Befehl in gewissen Grenzen zurück ? also den Befehl gespiegelt ? oder auch die Daten ? also alles ?

mit der HW würde ich mal versuchen
http://www.watterott.com/de/Arduino-Pro-Mini-328-5V/16MHz?refID=32

jedes bit was einläuft wieder ausgeben, solange bis ich "den 18/19 Befehl" dazu erkannt habe

15 euro für den fertigen chip ist ja nicht schlimm, evt. noch einen USB prog

nun bist du soweit gekommen, da kann es doch an fehlendem C nicht scheitern, das AVR Studio gibt es kostenlos von Atmel, Sourcen und Lösungen genug im Netz

 

[MasterFX]

15 euro für den fertigen chip ist ja nicht schlimm, evt. noch einen USB prog

Ich hätte jetzt einfach nen Attiny25 gekauft. Der reicht locker aus und kostet nur 1,20€. Externe beschaltung wäre dann nur ein 16 MHz Quarz und zwei 22pF Kerkos für den Quarz (mit 20MHz läuft der auch noch). 6µs sind ja ne halbe Ewigkeit. Da macht der AVR ja fast 100 Befehle in der Zeit, egal ob jetzt Tiny oder Mega.