Forum Übersicht - RE: Objektivsimulator für das Minolta-/Sony-A-Bajonett - 10

moin, ZITAT(matthiaspaul @ 2010-05-01, 22:54) Theoretisch könnten die während SS = high beobachteten MISO-Daten also von einem anderen (uns unbekannten) SPI-Gerät stammen, das in diesem Moment selektiert wird. Insofern ist das, was wir da im Log sehen, prinzipiell durchaus noch mit SPI vereinbar, es paßt nur nicht so recht zu der Tatsache, daß wir (meinen zu) wissen, daß sich zumindest auf diesem SPI-Bus nur zwei Instanzen, die Kamera-CPU (als Master) und das Objektiv (als Slave) miteinander unterhalten und es keine weiteren SPI-Geräte am gleichen Strang gibt. Aber 100% sicher ist das nicht.[/quote]
zumindest bei der a900 hängt der lens-Teil des internen SPI-Bussystems, an dem praktisch alles angeschlossen ist incl. dem Sensor selbst, nicht direkt an der main-CPU (IC4001) wie alles andere, sondern am I/O-Controller (IC4101). Der steuert auch die Kontakte F2 und F3 des Blitzschuhs, treibt die LED1..7 der AF-Feld-Anzeige (8+9 muss IC4001 selbst machen...) und überwacht das Drehen von Blenden- und AF-Motor (nicht die Position oder Drehwinkel, nur "Anschlag".
Das die externen Anschlüsse über ein zusätzliches IC geführt werden dient sicher einerseits dazu, mehr Treiberleistung zu haben und Kurzschlussfestigkeit zu realisieren (letztere habe ich gerade an der Dynax 5 getestet, funktioniert), verhindert aber sicher auch das "rausspiegeln" von internen Daten. Ich gehe vorerst weiter davon aus, dass die Daten wirklich vom Objektiv kommen. Schaltpläne aus der minolta-Zeit habe ich nicht, es dürfte aber ähnlich aussehen. Sobald die erste uAsim-Version läuft, können wir das in einer synthetischen Umgebung prüfen und abschließend klären.

ZITAT(DanielSch @ 2010-04-30, 12:55) (1)- Mit den Datenquellen hast du natürlich Recht. Aber mehr als die vier Objektive besitze ich nicht; ist bei mir noch eine Frage des Geldes.
(2)- Ich habe kein Problem mit der Blendenformel. Die Verkürzung der Brennweite im Nahbereich war mir auch schon bekannt; in den ROM-Daten wird sie aber beim Fokussieren im 0x80/0x81-Protokoll zumindest auf Byte 8 nicht berücksichtigt.
(3)- Ich schreibe meine meisten uC-Programme noch in Assembler, da ich oftmals eine Echtzeitfähigkeit brauche und die Ausführungszeiten genau nachvollziehen möchte. Da sich die Sprache seit Urzeiten nicht geändert hat, dürfte das Lesen des Programmes daher auch für jeden, der mit uC-s umgeht, kein größeres Problem darstellen.
(4)- Das Auslesen der Objektiv-ROMs ging mit meinem Aufbau recht einfach und störungsfrei. Den ATmega16 per RS232 an den Rechner anschließen, den SPI-Port mit einem Kabel an die Objektivkontakte ankleben, ein Programm wie TelNet aufmachen und dann den bereits fertig decodierten Protokollstrom mitlesen. Irgendwelche Pegeländerungen zwischen den Protokollpaketen kann man damit natürlich nicht erkennen.
(5)- Zum Chippen von Objektiven im manuellen Fokus-Betrieb reichen die Informationen bereits aus. In wie weit für einen AF noch zusätzliche Informationen nötig sind, werde ich mal an meinem Novoflex mit manueller Scharfstellung per Hand testen.[/quote]
zu (1) ich kann mir auch nicht alle Objektive auf einmal leisten, die ich gerne hätte Die Novoflex sind neu immer noch schweineteuer...
zu (2) aber eventuell wird die Verkürzung in den AF-Koeffizienten berücksichtigt, die Wirkung des Distanz-Switches beim 200/2.8APO und der Einfluss des D-Encoders beim SAL1870 deuten darauf hin. Auch die floatende Blende bei Zooms wird nicht durch Ändern der Anfangsöffnung, sondern mit einem Offset (in 0x03) dargestellt.
zu (3) wenn die Annahme, dass die LensChips eigenmächtig ohne SS senden und den Master zum "clocken" animieren, benötigen wir harte Echtzeitfähigkeit. Dann führt kein Weg an Assembler mit dem Codebuch auf den Knien vorbei.
zu (4) damit siehst Du nur die (im Sinne eines regulären SPI-Protokolls) gültigen Daten. Es passiert aber noch mehr auf den Leitungen, und genau daran werden die Kompatibilitätsprobleme liegen. Erste Hinweise habe ich gefunden, Details folgen.
zu (5) klar, das haben auch vasimv und James Lao T hinbekommen, letzterer verkauft die Teile als sog. AFconfirm-Chips in der Bucht. Aber damit geht definitv kein AF, auch wenn man die AF-Daten einprogrammiert; und Wolframs schizophrenes 200/2.8HS, welches sich meistens für ein 300/2.8HS hält, kann man damit auch nicht fixen.

ZITAT(DanielSch @ 2010-04-29, 21:38) Naja, das wäre auch mein Traum gewesen, die alten Novoflex auf Autofokus umzubauen. An die AF-Stange der Kamera einen kleinen Drehencoder angekoppeln und den Pistolengriff mit einem Schrittmotor mit Gewindespindel ausstatten. Oder gleich die HSM-Signale nutzen, die für mich jedoch noch völlig im Dunkeln liegen (sind elektrisch auf den zusätzlichen drei Pins der 8 poligen Platinen zu finden). [...]
An Gerätschaften hätte ich daheim einen alten Logikanalyzer (1630D von HP) sowie ein digitales Speicheroszi (54201D von HP) herumstehen. Falls also noch genauere Timings benötigt werden oder etwas verifiziert werden müsste, könnte ich das eventuell machen.[/quote]
Ich würde auch direkt über den SSM-Weg gehen, das ist ein bidirektionales Protokoll ohne "Schweinereien" wie versteckten Daten im Timing. Geht sicher leichter, als die Stange abzugreifen.

Darf ich Dich gelegentlich um den Einsatz des Speicher-Oszi bitten (eilt nicht!? Ich hätte gern die Form der Takt- und Bitflanken (Anstiegszeit und Abfallzeit), und die genaue Zeitbeziehung zwischen Takt und Daten (delta-T von Anstieg Takt zu Anstieg Daten, gültig sind sie erst bei fallender Flanke). Zuerst reicht ein Byte locker, also ein Block von 8 Takten. Das Timing ist sehr genau einzuhalten, sonst gibt es Kompatibilitätsprobleme... Weitere Timingdetails genauer zu untersuchen macht erst dann Sinn, wenn wir eine Vorstellung davon haben, worauf es ankommt.

ZITAT(Nils @ 2010-05-01, 23:48) ...äh, blöde Frage aber was macht Ihr hier in diesem Fred eigentlich und mit welchem Ziel? [/quote]
Spielen?

gruesze, thomas

moin,

ZITAT(Pressemitteilung)gestern wurde von minolta@home (made by ddd) eine post-production Dynax 5-LA vorgestellt.
Dieses Modell dient der Protokollanalyse und hat daher einen formschönen Anschluss für Logikanalysatoren und Oszilloskope an der Objektivschnittstelle, welcher die Analyse am "lebenden Objekt" erlaubt. Im Gegensatz zu dem bereits vor einiger Zeit gezeigten Prototypen auf Basis der Dynax 3000i steht damit jetzt auch das ADI (D)-Protokoll und das SSM-Protokoll für die Analyse bereit. Die Verfügbarkeit im Handel und die vorraussichtliche UVP konnten noch nicht genannt werden.

Ein Foto mit dem neuen Produkt in seiner Einsatzumgebung:
[attachment=77125_la.jpg]
Ein Foto aus der Produktion wurde dankenswerter Weise auch zur Verfügung gestellt:
[attachment=77135la_prod.jpg][/quote]

So liebe Mitbastler, wie versprochen wird es jetzt ernsthafter.
Die D5 läuft, und erste Samples sind gezogen:
[attachment=77145_SAL18...23_1_all.gif]
Dies ist der komplette, ca. 0,5s dauernde Ablauf beim MF (!-Init der D5 mit einem (D)-Objektiv. Da ist richtig was los, nicht einmal 1+32Byte lesen und gut wie bei der i-Serie.
[attachment=77155_SAL18...3_1_det1.gif]
Der Anfang. Ein Block im uns bekannten Format, jetzt aber mit 1+45Byte Länge. Offenbar "echot" der Master aud SI die Daten des Slaves im folgenden Byte.
[attachment=77165_SAL18...3_1_det2.gif]
Der 2. Block (der 1. Block besteht aus drei Teilen, Init, 1+45 Daten, Quittungs(?)block): komplett ungesehen bisher, echtes "Neuland".

[attachment=77175_SAL18...oo_123_1.zip]
Und hier das Sampletrace-File. Kann mit Digitrace angesehen werden (Quelle und Installationsanleitung am Ende hier in post #87).
Der letzte Bereich ist völlig anders als alles andere: hier variiert der Takt, und zwar heftig! Seht es Euch an, beschreiben kann man das nicht.
Screenshots zeigen bringt auch nix, bei hinreichend hoher Zeitauflösung um alles zu erkennen bräuchte man gut 10x 24" nebeneinander...

Nochmal: hier ist nix SSM oder AF oder so. Die Kamera steht auf MF!

Mein Analyseproggi (dgtana) kann damit natürlich noch nix anfangen. Die ersten 32 Byte liest es, Erweiterung auf 45 Byte ist easy. Den Rest muss ich erst etwas länger anstarren, bevor ich eine Vorstellung bekomme, was das ist.

so, wieder spät geworden.

gruesze, thomas

ZITAT(ddd @ 2010-05-02, 1:49) zu (3) wenn die Annahme, dass die LensChips eigenmächtig ohne SS senden und den Master zum "clocken" animieren, benötigen wir harte Echtzeitfähigkeit. Dann führt kein Weg an Assembler mit dem Codebuch auf den Knien vorbei.[/quote]
Der Prolog in Deinem gestrigen Log deutet für meine Begriffe darauf hin. Ganz am Anfang geht CLK für eine atypisch lange Zeit auf High (offenbar eine komplette Byteperiode) und es sieht so aus, als ob das Objektiv auf SS mit einem identischen Impuls zeitverzögert um eine halbe Byteperiode antwortet. Es wäre allerdings auch denkbar, daß diese SS-Low-Periode ebenfalls von der Kamera stammt, nur wozu soll das dann gut sein?

Die halbe Byteperiode kann Zufall sein. Es wäre aber denkbar, daß die Objektive, die so einen Impuls auf SS erzeugen können, so programmiert sind, daß sie, während CLK = High andauert, bewußt erstmal eine gewisse Zeit (die offenbar gerade vier typischen Bitperioden entspricht) warten, bevor sie in das Protokoll eingreifen und SS auf Low ziehen. Würden sie nicht warten, würde u.U. die normale Kommunikation gestört werden.
ZITATzu (4) damit siehst Du nur die (im Sinne eines regulären SPI-Protokolls) gültigen Daten. Es passiert aber noch mehr auf den Leitungen, und genau daran werden die Kompatibilitätsprobleme liegen. Erste Hinweise habe ich gefunden, Details folgen.[/quote]
Zum Beispiel bringt genau dieser gerade angesprochene Impuls unsere bisherigen Auswertetools durcheinander, da er natürlich trotz seiner Überlänge als normaler Clock-Impuls mitgezählt wird und damit alle folgenden Daten um einen Bittakt in der Auswertung verschoben sind. (Das gilt auch für den analogen Impuls nach dem ersten Datenpaket.) Man muß also entweder diesen Impuls erkennen und im Rahmen der Auswertung ignorieren, oder ihn vor der Auswertung aus den Tracelogs entfernen.

Interessant ist in diesem Zusammenhang auch der letzte Clock-Impuls des ersten Bytes (FFh); der hat nämlich nicht die normale Länge, sondern ist nur etwa halb so lang. Man könnte fast meinen, daß der Impuls deshalb so kurz ist, damit er von älteren Chips (die den Prolog-Impuls noch nicht kannten) "überlesen" wird. Dann käme man nämlich mit dem zusätzlichen Prolog-Impuls gerade wieder auf 8 Clock-Impulse für ein Byte, so daß die Synchronisation in Bezug auf die nachfolgenden Bytes des gesamten Datenpakets wieder stimmt. Selbst der aus der Sicht der Kamera resultierende Wert FFh würde immer noch stimmen, nur daß das Bit 0 in Wahrheit nicht vom gleichen Byte stammte, sondern vom Prolog, und daß die Bits 7-1 eigentlich die Bits 6-0 des 1. Bytes darstellten (was nicht auffällt, solange alle auf "1" stehen). Das würde bedeuten, daß das Timing wichtig ist, daß alte Objektive nicht mit einer Clock arbeiten können, die wesentlich schneller ist, als in Deinem Beispiel, und daß neuere Objektive hier abhängig vom Timing zusätzliche interne Zustände durchlaufen.

Eines ist jedenfalls klar: Die Clock wird - möglicherweise timergestützt - in jedem Fall softwaregesteuert erzeugt, nicht, wie von mir ursprünglich vermutet, starr von einem durchlaufenden Hardware-Takt abgeleitet.

Sehr interessant wäre jetzt, wie sich ein altes Objektiv wie das AF 2,8/24mm o.ä. an der Dynax 5 verhält.

Viele Grüße,

Matthias

Da die bisherigen R1.00-Fassungen von DGTxLDMP.DEB nicht mit dem zusätzlichen Taktimpuls am Anfang zurechtkommen (alle Daten werden durch den Impuls um ein Bit verschoben), habe ich den Algorithmus so überarbeitet, daß der Bitcounter nun nicht mehr von 0 auf 7 hochzählt, sondern von 7 auf 0 runter.

Die unten angehängten Skripte DGT2DMP0.DEB, DGT3DMP0.DEB und DGT4DMP0.DEB sind zunächst einfach nur aktualisierte, aber funktional äquivalente Fassungen der alten DEBUG-Skripte, mit dem einzigen Unterschied, daß sie jetzt Kommentare enthalten (alte DEBUG-Versionen kommen damit u.U. nicht klar, aber so ist's hoffentlich etwas besser lesbar). DGT2DMP0.DEB schreibt jetzt nicht mehr in LENSDUMP.BIN, sondern aus Konsistenzgründen in LENSDMP2.BIN. Diese Skripte funktionieren nach wie vor nur, wenn das Tracelog keinen Prologimpuls enthält.

Soweit nichts Neues. Durch die Änderung des Algorithmus bekommt man jetzt aber die Möglichkeit, den Bitcounter zweckzuentfremden, um eine einstellbare Zahl Clock-Impulse am Anfang des Tracelogs zu ignorieren. Ist der Bitzähler an Codeoffset +10Fh mit 8 vordefiniert, so arbeiten die Skripte wie gehabt (siehe oben), setzt man diesen jedoch auf 1, so wird das erste Byte schon nach einem Takt als "vollständig" erachtet und weggeschrieben. Für alle folgenden Bits (inklusive des dann erst folgenden einleitenden 11111111b = FFh) stimmt dadurch die Bytesynchronisation wieder, so daß diese Bytes richtig dekodiert werden. Und das sind ja die Bytes, die uns eigentlich interessieren...

Die neuen Skripte DGT2DMP1.DEB (für LSIN/MISO), DGT3DMP1.DEB (für CSLNS/SS) und DGT4DMP1.DEB (für LSOUT/MOSI) sind von DGTxDMP0.DEB abgeleitet, schlucken aber, wie oben beschrieben, den ersten Impuls und beginnen erst danach mit der eigentlichen Dekodierung der Daten.

Beispielhaft hier der Code von DGT2DMP1.DEB (die Umstellung von DL = 8 auf DL = 1 erfolgt implizit durch den Befehl "E 10F 1":

A
             &#59; assume ES = DS = CS, SS:SP initialized, CS segment allocated
mov   dx,200 &#59; DS:DX -> ASCIZ source file name "TRACELOG.DGT"
xor   cx,cx  &#59; share compatibility mode
mov   ah,3D  &#59; open file
int   21     &#59; call DOS
 jc   184    &#59;  bail out on error
mov   di,500 &#59; ES:DI -> target buffer (growing)
mov   dx,8   &#59; (10Eh) assume clock status DH = low, set bit counter DL = 8
mov   bx,ax  &#59; file handle
;read_sector:&#59;  (113h)
push  dx     &#59; preserve status
mov   cx,200 &#59; count of bytes to read (1 sector)
mov   dx,300 &#59; DS:DX -> source buffer
mov   ax,3F00&#59; read file by handle BX, assume AL = 0 (for buggy emulators)
clc          &#59; assume no error (for buggy emulators)
int   21     &#59; call DOS
 jc   163    &#59;  close file on read error
test  ax,ax  &#59; zero bytes read?
 jz   163    &#59;  close file on EOF
mov   si,dx  &#59; DS:SI -> source buffer
pop   dx     &#59; restore status
mov   cx,ax  &#59; count of bytes to process
cld          &#59; count upwards
;scan_buffer:&#59;  (12Ch)
lodsb        &#59; read tracelog byte from DS:[SI] into AL, increment pointer
mov   ah,al  &#59; stream status
and   ah,1   &#59; strip off all but channel 1 (CLK)
cmp   ah,dh  &#59; clock level change?
 je   15F    &#59;  nothing to process, if same as before
mov   dh,ah  &#59; store current status for next round
test  ah,ah  &#59; sample on falling edge
 jnz  15F    &#59;  skip if rising edge
shr   al,1   &#59; extract desired channel 2 (LSIN/MISO)
and   al,1   &#59; 1 if channel bit high, 0 if channel bit low
mov   ah,[220]; get previously processed result byte
or    ah,al  &#59; merge new bit from bitstream into result byte
ror   ah,1   &#59; prepare for next bit in the row
mov   [220],ah; temporarily store away interims result
dec   dx     &#59; decrement bit counter DL
cmp   dl,0   &#59; 8 bits read?
 ja   15F    &#59;  byte not finished, get next bit from bitstream
mov   [220],dl; reset result byte to 0 for next round
mov   dl,8   &#59; bit counter back to 8 for next byte
mov   al,ah  &#59; get decoded byte
stosb        &#59; store decoded byte AL at ES:[DI], increment pointer
test  di,di  &#59; target buffer overflow?
 jz   163    &#59;  bail out and close file 
;scan_skip:  &#59;  (15Fh)
 loop 12C    &#59;  dec counter CX, finished reading buffer? else get next byte
jmp   113    &#59; source buffer empty, read next sector
;close_source:;  (163h)
pop   dx     &#59; stack alignment (cosmetics since not necessary inside DEBUG)
mov   ah,3E  &#59; close source file by handle BX
int   21     &#59; call DOS
xor   cx,cx  &#59; attributes
mov   dx,210 &#59; DS:DX -> ASCIZ target file name "LENSDMP2.BIN"
mov   ah,3C  &#59; create or trunc file
int   21     &#59; call DOS
 jc   184    &#59;  bail out on error
mov   bx,ax  &#59; file handle 
mov   dx,500 &#59; DS:DX -> buffer contents to store on disk
sub   di,dx  &#59; get count of decoded bytes
mov   cx,di  &#59; count of bytes to write
mov   ah,40  &#59; write file by handle BX
int   21     &#59; call DOS
mov   ah,3E  &#59; close file by handle BX
int   21     &#59; call DOS
;exit_program:;  (184h)
nop          &#59; mark end of code
 

F 200 L FE00 0
E 200 "TRACELOG.DGT"
E 210 "LENSDMP2.BIN"
E 10F 1
G=100 184
D 500
Q
Q            &#59; R1.01 2010-05-02 MPL
 

Das Ganze funktioniert natürlich nur solange gut, wie nicht später weitere "Streuimpulse" im Tracelog zu finden sind, die die Synchronisation wieder außer Tritt bringen. Leider folgt nach dem ersten großen Datenblock ein weiterer solcher Impuls, deshalb taugt das Skript ohne weitergehende Maßnahmen nur zur sauberen Extraktion des ersten Blocks. Für den schnellen Überblick ist das aber schon mal ganz gut, denn was es mit den nachfolgenden Daten auf sich hat, müssen wir ja sowieso erst noch herausbekommen...

Würden gleich mehrere Störimpulse am Anfang des Tracelogs vorkommen, könnte man mit DL-Initialisierungswerten zwischen 1 und 7 bis zu sieben solcher Störimpulse unterdrücken bzw. die Bytesynchronisation für einen beliebigen, weiter hinten im Tracelog liegenden zu dekodierenden Teilabschnitt voreinstellen. Das erste Byte im Dump bzw. der Bereich vor und hinter diesem Teilbereich muß dann ignoriert werden.

So sieht das mit DGT2DMP1.DEB dekodierte Dump aus Thomas' d5_SAL1870F3556_initmf18oo_123-1.dgt dann aus (Hinweis: Die Offset-Angaben links beziehen sich auf den Puffer im Skript und entsprechen nicht irgendwelchen Adressen im Objektiv-Chip - darüberhinaus kommt es durch die Unterdrückung von Impulsen skriptbedingt um scheinbare Verschiebungen von bis zu einem Byte):
ZITATxxxx:0500 80|FF_81_26_50_00_1F_0F_10_21_31_80_FF_57_14_00_
xxxx:0510 04_4B_00_93_1C_F6_33_F4_EF_25_0B_2A_20_00_A5_00_
xxxx:0520 11_B3_02_F5_04_8D_84_15_96_00_00_00_22_00_28|FF
xxxx:0530 25 01 00 1E 01 00 00 00 C8 BF 24 80 09 14 C0 C7
xxxx:0540 03 44 48 0C E0 FF 15 05 00 C1 12 C0 24 87 FD 0C
xxxx:0550 FD 7B C9 82 0A 08 40 29 40 C4 AC 40 3D 41 23 61
xxxx:0560 85 E5 BF 24 80 09 14 C0 C7 03 44 48 0C E0 FF 15
xxxx:0570 05 00 C1 12 C0 24 87 FD 0C FD 7B C9 82 0A 08 40
xxxx:0580 29 40 C4 AC 40 3D 41 23 61 85 E5 FF FF 7F 49 00
xxxx:0590 CC 7F 93 02 F9 FF FF FF FF FF FF FF FF FF FF FF
xxxx:05A0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
xxxx:05B0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
xxxx:05C0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
xxxx:05D0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
xxxx:05E0 FF FF FF FF FF FF FF BF 24 00 E8 FF FF 5E[/quote]
Das Byte an Offset +0h muß, wie gesagt, ignoriert werden, ebenso wie alles ab dem Byte an Offset +2Fh, da nach dem ersten Datenblock (also den ersten 46 Nutzdatenbytes) die Bytesynchronisation durch den zweiten Störimpuls im Tracelog wieder verschoben ist. Aber zumindest an den ersten Datenblock kommen wir so mit minimalem Aufwand heran:

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 
FF
81 26 50 00 1F 0F 10 21 31 80 FF 57 14 00 04 4B 00 93 1C F6 33 F4 EF 25 0B 2A 20 00 A5 00 11 B3
02 F5 04 8D 84 15 96 00 00 00 22 00 28
 

Zum Vergleich: An der Dynax 3000i war schon vorher Schluß, obwohl das Sony Alpha DT 3,5-5,6/18-70mm (SAL-1870) offensichtlich mehr Daten enthält (xx = veränderliche Bytes in Abhängigkeit von Brennweite und/oder Entfernung):

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 
81 26 50 xx 1F 0F 10 xx 31 80 FF xx xx 00 04 xx 00 93 1C xx 33 xx xx xx 0B 2A 20 00 A5 00 11 B3
 

Zusätzlich sind noch die Skripte DGT2DMP2.DEB (für LSIN/MISO), DGT3DMP2.DEB (für CSLNS/SS) und DGT4DMP2.DEB (für LSOUT/MOSI) angehängt, die sich von den DGTxDMP1.DEB-Skripten nur darin unterscheiden, daß die ersten beiden Takte ignoriert werden. Dadurch stimmen zwar die Daten des ersten Datenblocks nicht, aber stattdessen dann die Daten nach dem zweiten Störimpuls, d.h. der Anfang des zweiten Datenblocks wird richtig dekodiert:

ZITAT
xxxx:0500 C0|FF 40 13 28 80 8F 07 88 90 18 C0 FF 2B 0A 00
xxxx:0510 82 25 80 49 0E FB 19 FA F7 92 05 15 10 80 52 80
xxxx:0520 88 59 81 7A 82 46 C2 0A 4B 00 00 00 11 00 94|FF_
xxxx:0530 92_00_00_8F_00_00_00_00 E4 5F 12 C0 04 0A E0 E3
xxxx:0540 01 22 24 06 F0 FF 8A 02 80 60 09 60 92 C3 7E 86
xxxx:0550 FE BD 64 41 05 04 A0 14 20 62 56 A0 9E A0 91 B0
xxxx:0560 C2 F2 5F 12 C0 04 0A E0 E3 01 22 24 06 F0 FF 8A
xxxx:0570 02 80 60 09 60 92 C3 7E 86 FE BD 64 41 05 04 A0
xxxx:0580 14 20 62 56 A0 9E A0 91 B0 C2 F2 FF FF BF 24 00
xxxx:0590 E6 BF 49 81 FC FF FF FF FF FF FF FF FF FF FF FF
xxxx:05A0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
xxxx:05B0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
xxxx:05C0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
xxxx:05D0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
xxxx:05E0 FF FF FF FF FF FF FF 5F 12 00 F4 FF FF FE
[/quote]
Erstaunlicherweise folgt danach ein Wort mit nur 5 Bit, was die Bytesynchronisation erneut durcheinanderbringt. Deshalb müssen wir erneut um 5 Bit verschieben und den Rest mit DGT2DMP7.DEB dekodieren:
ZITAT
xxxx:0500 FE|07 9A 40 01 7C 3C 40 84 C4 00 FE 5F 51 00 10
xxxx:0510 2C 01 4C 72 D8 CF D0 BF 97 2C A8 80 00 94 02 44
xxxx:0520 CC 0A D4 13 34 12 56 58 02 00 00 88 00 A0 FC 97
xxxx:0530 04 00 78 04 00_00_00_20 FF_92_00_26_50_00_1F_0F_
xxxx:0540 10_21_31_80_FF_57_14_00_04_4B_00_93_1C_F6_33_F4_
xxxx:0550 EF_25_0B_2A_20_00_A5_00_11_B3_02_F5_04_8D_84_15_
xxxx:0560 96 FF_92_00_26_50_00_1F_0F_10_21_31_80_FF_57_14_
xxxx:0570 00_04_4B_00_93_1C_F6_33_F4_EF_25_0B_2A_20_00_A5_
xxxx:0580 00_11_B3_02_F5_04_8D_84_15_96|FF FF FF 25 01 30
xxxx:0590 FF 4D 0A E4 FF FF FF FF FF FF FF FF FF FF FF FF
xxxx:05A0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
xxxx:05B0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
xxxx:05C0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
xxxx:05D0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
xxxx:05E0 FF FF FF FF FF FF FF_92_00_A0 FF FF FF FE
[/quote]
Die nächsten zwei Bytes werden mit inverser Clock getaktet, dadurch kommt ein weiterer Synchronisationssprung um einen Takt hinzu, so daß wir wieder das Original-Skript DGT2DMP0.DEB verwenden können:
ZITAT
xxxx:0500 FF 03 4D A0 00 3E 1E 20 42 62 00 FF AF 28 00 08
xxxx:0510 96 00 26 39 EC 67 E8 DF 4B 16 54 40 00 4A 01 22
xxxx:0520 66 05 EA 09 1A 09 2B 2C 01 00 00 44 00 50 FE 4B
xxxx:0530 02 00 3C 02 00 00 00 90 7F 49 00 13 28 80 8F 07
xxxx:0540 88 90 18 C0 FF 2B 0A 00 82 25 80 49 0E FB 19 FA
xxxx:0550 F7 92 05 15 10 80 52 80 88 59 81 7A 82 46 C2 0A
xxxx:0560 CB 7F 49 00 13 28 80 8F 07 88 90 18 C0 FF 2B 0A
xxxx:0570 00 82 25 80 49 0E FB 19 FA F7 92 05 15 10 80 52
xxxx:0580 80 88 59 81 7A 82 46 C2 0A CB|FF FF FF_92_00_98_
xxxx:0590 FF_26_05_F2 FF FF FF FF FF FF FF FF FF FF FF|FF
xxxx:05A0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
xxxx:05B0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
xxxx:05C0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
xxxx:05D0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
xxxx:05E0 FF FF FF FF FF FF 7F 49 00 D0 FF FF 7F FE
[/quote]
Danach wird es kompliziert, deshalb breche ich das hier vorerst ab...

Interessant ist aber schon mal, daß sich zwei 41 Bytes lange Bereiche (inklusive des Headers FFh 92h) innerhalb des Blocks 3 wiederholen und auch, daß diese Bereiche mit dem Hauptdatenbereich aus Block 1 weitestgehend identisch sind. Die beiden späteren Blöcke unterscheiden sich dadurch vom Hauptblock, daß sie mit einem anderen Header beginnen (FFh 92h 00h statt FFh 81) und daß am Ende einige Bytes (00h 00h 00h 22h 00h 28h) fehlen:

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 
FF
81 26 50 00 1F 0F 10 21 31 80 FF 57 14 00 04 4B 00 93 1C F6 33 F4 EF 25 0B 2A 20 00 A5 00 11 B3
02 F5 04 8D 84 15 96
00 00 00 22 00 28
[... 10 andere Bytes ...]
FF
92
00 26 50 00 1F 0F 10 21 31 80 FF 57 14 00 04 4B 00 93 1C F6 33 F4 EF 25 0B 2A 20 00 A5 00 11 B3
02 F5 04 8D 84 15 96
FF
92
00 26 50 00 1F-0F 10 21 31 80 FF 57 14 00 04 4B 00 93 1C F6 33 F4 EF 25 0B 2A 20 00 A5 00 11 B3
02 F5 04 8D 84 15 96
 

Und betrachtet man nur sämtliche MISO-Codes, die auf dem Bus zu sehen waren, während das Objektiv selektiert war, sieht die Sache auch schon übersichtlicher aus:

FF 81 26 50 00 1F 0F 10 21 31 80 FF 57 14 00 04 4B 00 93 1C F6 33 F4 EF 25 0B 2A 20 00 A5 00 11 B3 02 F5 04 8D 84 15 96 00 00 00 22 00 28
[...]
FF 92 00 00 8F 00 00 ?? 00 20
[...]
FF 92 00 26 50 00 1F 0F 10 21 31 80 FF 57 14 00 04 4B 00 93 1C F6 33 F4 EF 25 0B 2A 20 00 A5 00 11 B3 02 F5 04 8D 84 15 96
FF 92 00 26 50 00 1F 0F 10 21 31 80 FF 57 14 00 04 4B 00 93 1C F6 33 F4 EF 25 0B 2A 20 00 A5 00 11 B3 02 F5 04 8D 84 15 96
[...]
FF 92 00 98 FF 26 05 F2
[...]
FF 92 00 A0
 

Viele Grüße,

Matthias

moin, ZITAT(littlelamb @ 2010-04-29, 20:17) 1) lade Dir Hier mit folgenden Einstellungen (Product: "Logic Analyser", Series:"LAP-A Series", Model:"LAP-16032U" und nach Ankreuzen des Punktes "Software" die Analyser Software V3.08 herunter. Die Software hat einen Demo-Mode, wo sie auch OHNE Analyserhardware funktioniert.[/quote]
ja, das hat geklappt.
Deine sample-files habe ich jetzt teilweise durch. Es sieht etwas anders aus, aber das passt schon.
Darf ich Dich, wenn ich soweit bin, um gezielte einzelne Auslesereien bitten? Einfach alles auslesen bringt wenig, keiner kann die Datenmassen sinnvoll auswerten.

Zur Zeit habe ich nur einen Lauf auf dem Wunschzettel, und es eilt nicht!
Ein sample von der 5000AF mit dem SAL1870@18mm-oo, Kamera auf MF, samplen beim Drücken der Obj.Entriegelung mit 800kHz oder 1MHz und Trigger auf SS drop wäre nett.
Ich hoffe da auf mehr Ähnlichkeiten zur 3000i und möchte gern sehen, ob wie ich annehme, das Protokoll von der AF-Serie zur i-Serie nicht verändert wurde.


Aber jetzt haben wir neue Probleme:
die bitclock und die Datenübertragungsrate und die relativen timing-Eigenschaften der vier bisher gesampelten Gehäuse unterscheiden sich grundsätzlich und signifikant!

8000i : 66.7kHz, 5.26kByte/s = 190µs/Byte mit 120µs Byte +  70µs Pause (Hans@littlelamb w/ zeroplus LAP-16032U @ 200kHz)
5000AF: **.*kHz, 2.33kByte/s = 427µs/Byte mit ***µs Byte + ***µs Pause (Hans@littlelamb w/ zeroplus LAP-16032U @ ***kHz)
3000i : 33.3kHz, 1.66kByte/s = 600µs/Byte mit 240µs Byte + 360µs Pause (Thomas@ddd w/ digitrace (Samsung P35-1.6GHz,XP32bit) @ ca.800kHz)
D5    : 60,6kHz, 3.06kByte/s = 327µs/Byte mit 195µs Byte + 132µs Pause (Thomas@ddd w/ digitrace (Samsung P35-1.6GHz,XP32bit) @ ca.800kHz)
 

Achtung: meine samples sind auf der Zeitachse nicht präzise! Ich muss mir noch einen Oszillator basteln, der mit mehreren Teilerstufen die Mängel des ParPort-digitrace überwindet.

Speziell die Unterschiede zwischen der 3000i und der 8000i überraschen mich. Ich hätte innerhalb einer Generation ein einheitliches timing erwartet.
Offenbar ist das timing zumindest bei den frühen Generationen eher von der Gehäuseklasse als der Generation abhängig.
Auch das unterschiedliche "Tastverhältnis" zwischen Byte und Pause hätte ich nicht erwartet. D.h. aber umgekehrt, dass dies (innerhalb gewisser Grenzen) kein kritischer Parameter sein kann!
Der skalierte Aufbau der timings ist aber abgesehen davon sehr einheitlich, die Reihenfolge und auch die relativen Abstände müssen also relativ genau eingehalten werden.

Wir sehen aber je nach Triggerbedingung und Gehäuse offenbar noch immer nicht alles:
ZITAT(matthiaspaul @ 2010-05-02, 10:02) (1) Der Prolog in Deinem gestrigen Log deutet für meine Begriffe darauf hin. Ganz am Anfang geht CLK für eine atypisch lange Zeit auf High (offenbar eine komplette Byteperiode) und es sieht so aus, als ob das Objektiv auf SS mit einem identischen Impuls zeitverzögert um eine halbe Byteperiode antwortet. Es wäre allerdings auch denkbar, daß diese SS-Low-Periode ebenfalls von der Kamera stammt, nur wozu soll das dann gut sein?

(2) Die halbe Byteperiode kann Zufall sein. Es wäre aber denkbar, daß die Objektive, die so einen Impuls auf SS erzeugen können, so programmiert sind, daß sie, während CLK = High andauert, bewußt erstmal eine gewisse Zeit (die offenbar gerade vier typischen Bitperioden entspricht) warten, bevor sie in das Protokoll eingreifen und SS auf Low ziehen. Würden sie nicht warten, würde u.U. die normale Kommunikation gestört werden.

(3) Zum Beispiel bringt genau dieser gerade angesprochene Impuls unsere bisherigen Auswertetools durcheinander, da er natürlich trotz seiner Überlänge als normaler Clock-Impuls mitgezählt wird und damit alle folgenden Daten um einen Bittakt in der Auswertung verschoben sind. (Das gilt auch für den analogen Impuls nach dem ersten Datenpaket.) Man muß also entweder diesen Impuls erkennen und im Rahmen der Auswertung ignorieren, oder ihn vor der Auswertung aus den Tracelogs entfernen.

(4) Interessant ist in diesem Zusammenhang auch der letzte Clock-Impuls des ersten Bytes (FFh); der hat nämlich nicht die normale Länge, sondern ist nur etwa halb so lang. Man könnte fast meinen, daß der Impuls deshalb so kurz ist, damit er von älteren Chips (die den Prolog-Impuls noch nicht kannten) "überlesen" wird. Dann käme man nämlich mit dem zusätzlichen Prolog-Impuls gerade wieder auf 8 Clock-Impulse für ein Byte, so daß die Synchronisation in Bezug auf die nachfolgenden Bytes des gesamten Datenpakets wieder stimmt. Selbst der aus der Sicht der Kamera resultierende Wert FFh würde immer noch stimmen, nur daß das Bit 0 in Wahrheit nicht vom gleichen Byte stammte, sondern vom Prolog, und daß die Bits 7-1 eigentlich die Bits 6-0 des 1. Bytes darstellten (was nicht auffällt, solange alle auf "1" stehen). Das würde bedeuten, daß das Timing wichtig ist, daß alte Objektive nicht mit einer Clock arbeiten können, die wesentlich schneller ist, als in Deinem Beispiel, und daß neuere Objektive hier abhängig vom Timing zusätzliche interne Zustände durchlaufen.

(5) Eines ist jedenfalls klar: Die Clock wird - möglicherweise timergestützt - in jedem Fall softwaregesteuert erzeugt, nicht, wie von mir ursprünglich vermutet, starr von einem durchlaufenden Hardware-Takt abgeleitet.

(6) Sehr interessant wäre jetzt, wie sich ein altes Objektiv wie das AF 2,8/24mm o.ä. an der Dynax 5 verhält.[/quote]
zu 1) ich glaube nicht, dass das Objektiv SS ziehen kann. SS= slave select geht an den /OE-Eingang der LensChips und dürfte Kameraseitig ein reiner Ausgang sein. Ich prüfe das noch, die 3000i hatte ich ja so umgebaut, dass ein Einschleifen zwischen Kamera und Objektiv möglich ist (die Dynax 5 erst mal nicht, die hat nur einen Abgriff). Vorschläge wie? Ich habe noch keine geniale Idee dazu...
Es scheint mir eher so, dass das Objektiv durch Setzen von MISO bei fehlendem SS das Gehäuse zum Clocken auffordern kann oder damit einen Interrupt auslösen kann. Dazu kann ich erst mehr sagen, wenn ich an der D5 mehrere LensChip-Klassen durch habe.

zu 2) der Impuls triff mglw. auch bei der 3000i auf, Hans' samples deuten bei der 8000i und der 5000AF darauf hin. Könnte mit meinem Trigger zu tun haben, besser mit dessen delay. Schwierig auszutesten, da ich mit ca. 800kHz samplefrequenz am limit meiner Bastellösung bin. Weniger Auflösung macht es nicht besser, und ohne Trigger klappt es zu selten bei der begrenzten Messzeit (1,2s). Ich werde ev. einen anderen Trigger setzen, z.B. den Entriegelungs-Switch oder den Auslöser abgreifen und als Trigger nutzen. Besser wäre es, endlich den uAsim zum Laufen zu bekommen, der die digitrace-Beschränkungen bis auf die HW-limits des ParPort nicht hat.

zu 3) klar...

zu 4) das würde ich nicht vertiefen! Ich habe immer gelegentliche drops beim samplen, da XP alles, aber niemals echtzeitfähig ist, nicht einmal in einem sehr lockeren Sinne; und normales Unix oder linux auch nicht. Daher muss ich uAsim auf RTlinux machen (OS/9 ginge auch, QNX mag ich nicht mehr) oder wir müssen mit dem vorhandenen Halbwissen schon auf µC unter handgemachtem Assembler wechseln.
Hans' oder Daniels LA ist zum Auslesen zwar wesentlich besser, aber damit können wir niemals testhalber ein Objektiv oder Gehäuse gegenüber dem jeweils anderen Partner simulieren. Und jeder Mitbastler hat nur eine begrenzte Zahl an Gehäusen und Objektiven. Wer noch bei SSM einsteigen möchte: ich habe ein Angebot für eine funktionsfähige Dynax 40 für 15€ incl. Versand gefunden. Anfragen per PM!

zu 5) ich kann mich noch nicht entscheiden. Wenn das wilde Zeug am Ende der D5-samples echt ist, dann kann immer noch eine (wesentlich schnellere) HW-Masterclock laufen, welche meist heruntergeteilt wird.
Irgendwie erinnern mich die wilden Taktereien am Ende an Quadratur-Impulse...

zu 6) kommt natürlich noch! Und jede Menge weiteres, ich habe alle Varianten mit mindestens einem Vertreter da: alt/80, alt/81-32, neu/80, neu/81-45, STF, (D), SSM, xi/82, TC. Nur alt/81-45 fehlt mir. Neu/81-32 scheint nicht zu existieren.
edit: hier das minolta AF 24 f/2.8 1.Gen. (Ofenrohr-Style) an der Dnyax 5, ein Objektiv mit RomRev 0x80, 32 Byte Datensatz und altem Toshiba ML00*-LensChip:
[attachment=77705_mAF24...oo_123_1.zip]
Die D5 fragt zuerst 1+45Bytes ab, später aber nur mehr die im Objektiv vorhandenen 32 Byte. Demnach ist im Datensatz nicht codiert, ob die Datensätze 32 oder 45 Byte lang sind, und selbst bei RomRev 0x80 werden stur 1+45 Bytes gelesen. Der Inhalt wiederholt sich wie schon von PonyProg u.ä. bekannt ab Byte 0x20 wieder vom Beginn des Datensatztes, d.h. Byte 0x20 enthält dasselbe wie Byte 0x00 usw.
Aber im Gegensatz zu der 3000i, die im MF-Modus scheinbar nix tut, ist hier immer Traffic auf dem Bus. Ob eventuell doch der interne SPI-Bus der Kamera auf den Lens-Kontakten sichtbar ist? Ich bin mir nicht mehr sicher.
Es könnte sein, dass der interne Bus zum Debuggen rausgeführt wird; das Objektiv ignoriert alles bei SS inaktiv aber ein spezieller Debug- oder Prüf-Adapter kann dann die Interna mitloggen. Es hilft nix, wir können das nur klären, indem wir simulieren und sehen, was geschieht. Ich lese erstmal nix weiter aus, es bringt im Moment nix. Den uAsim zum Laufen zu bringen, wird noch ein paar Tage dauern.
edit ende.

ZITAT(matthiaspaul @ 2010-05-02, 15:53) Erstaunlicherweise folgt danach ein Wort mit nur 5 Bit, was die Bytesynchronisation erneut durcheinanderbringt.[/quote]
vertiefe dass nicht! Das ist fast sicher ein Lesefehler. Tritt öfter auf, ist Tageszeit/Temperatur-in-Kairo/Wolkenbedeckungsgrad-20km-weiter/usw.-abhänig; sprich völlig willkürlich.

gruesze, thomas

Hallo,

ich habe mich mal den Vormittag hingesetzt und wieder ein paar Messungen gemacht. Aufgenommen habe ich die Sequenz, die beim Einschalten / Antippen der Auslösetaste bei der Alpha 550 OHNE Objektiv erscheint. Die gesamte Sequenz wiederholt sich für etwa 20 Sekunden, dann geht die Kamera in den Standby.
Bekannt aus dem Ganzen ist bereits Block 4; er frägt die Objektivdaten ab. Die anderen 3 Blöcke sind bisher völlig unbekannt, könnten aber auf weitere SPI-Teilnehmer (auch wenn hier manche der Meinung sind, das Ganze ist kein SPI, nenn ich das mal so) hindeuten. Zumal deren Taktfrequenz völlig abweichend ist.

Den zweiten Test, den ich gemacht habe, betrifft das Novoflex im AutoFokus-Betrieb mit Scharfstellung von Hand. Und was soll ich sagen: Es funktioniert! Je weiter man vom Scharfstell-Punkt entfernt ist, desto schneller dreht sich der AF-Motor (im Rahmen seiner Möglichkeiten). Kommt man schließlich in die Nähe des Schärfepunktes, so fährt er immer langsamer bis es schließlich am Schärfepunkt den AF-confirm gibt und man (zumindest bei der a550 - Auslösesperre ohne AF-confirm! auslösen darf. Ich wage daher jetzt mal mutig zu behaupten, dass man für den AF keinerlei Datenübertragung vom/zum Objektiv braucht außer die statischen Daten, die im 0x80/0x81-Protokoll gesendet werden.

Schöne Grüße,
Daniel

ZITAT(ddd @ 2010-05-03, 1:01) ZITAT(matthiaspaul @ 2010-05-02, 10:02) (1) Der Prolog in Deinem gestrigen Log deutet für meine Begriffe darauf hin. Ganz am Anfang geht CLK für eine atypisch lange Zeit auf High (offenbar eine komplette Byteperiode) und es sieht so aus, als ob das Objektiv auf SS mit einem identischen Impuls zeitverzögert um eine halbe Byteperiode antwortet. Es wäre allerdings auch denkbar, daß diese SS-Low-Periode ebenfalls von der Kamera stammt, nur wozu soll das dann gut sein?[/quote]
zu 1) ich glaube nicht, dass das Objektiv SS ziehen kann. SS= slave select geht an den /OE-Eingang der LensChips und dürfte Kameraseitig ein reiner Ausgang sein.
[/quote]
Thomas, ich weiß nicht, ob das bei jedem Gehäuse so ist, aber zumindest bei einigen Gehäusen ist diese Leitung bidirektional ausgelegt - die DSLR-A700 und DSLR-A900 gehören dazu, aber auch zu xi-Zeiten gab es das schon. Über den Zweck kann ich im Moment nur mutmaßen, tippe vorerst auf xi-Objektive, aber möglicherweise ist bei SSM-/SAM-Objektiven etwas Ähnliches zu finden.
ZITATIch prüfe das noch, die 3000i hatte ich ja so umgebaut, dass ein Einschleifen zwischen Kamera und Objektiv möglich ist (die Dynax 5 erst mal nicht, die hat nur einen Abgriff). Vorschläge wie? Ich habe noch keine geniale Idee dazu...[/quote]
Eine richtungsabhängige Signalseparierung mit automatische Richtungserkennung und -umschaltung für eine bidirektional betriebene Leitung ist nicht einfach zu realisieren. Ich hätte da zwar eine grobe Idee (antiparallele Laufzeitstrecke mit Verriegelungslogik nach dem Prinzip "Baustellenampel", hoffe aber, daß wir das nicht brauchen. ;-)

Uns geht es aber im Moment noch gar nicht darum, die Signale nach Richtung zu trennen, sondern erstmal nur darum, zu sehen, ob die Leitung in unserem Fall überhaupt bidirektional arbeitet. Dafür müßte es schon reichen, zwei NOT-Gatter (oder etwas Äquivalentes) passender Technologie hintereinander zu schalten und versuchsweise mal in der einen, mal in der anderen Richtung in den SS-Signalweg zu legen. Dann müßte man ja sehen, ob alles weiterhin normal funktioniert, ob der Impuls ausbleibt, usw. Damit das vordere Gatter nicht Gefahr läuft, gegen einen Ausgang zu treiben, setzt man noch einen strombegrenzenden Widerstand davor; der verschleift zwar das Signal, aber wenn er nicht zu hochohmig ist, sollte das die Kommunikation nicht beeinträchtigen.

Erst, wenn wir so feststellen, daß das Objektiv SS wirklich auf Low zieht, müssen wir uns dazu weiter den Kopf zerbrechen.
ZITATEs scheint mir eher so, dass das Objektiv durch Setzen von MISO bei fehlendem SS das Gehäuse zum Clocken auffordern kann oder damit einen Interrupt auslösen kann. Dazu kann ich erst mehr sagen, wenn ich an der D5 mehrere LensChip-Klassen durch habe.[/quote]
Auch das wäre möglich, ändert aber nichts daran, daß SS birektional sein kann.
ZITATZITAT
(4) Interessant ist in diesem Zusammenhang auch der letzte Clock-Impuls des ersten Bytes (FFh); der hat nämlich nicht die normale Länge, sondern ist nur etwa halb so lang.[/quote]
zu 4) das würde ich nicht vertiefen! Ich habe immer gelegentliche drops beim samplen,
[/quote]
Hoffen wir, daß das nur ein Drop ist und keine Schikane. ;-)

Viele Grüße,

Matthias

moin, ZITAT(DanielSch @ 2010-05-03, 15:35) Den zweiten Test, den ich gemacht habe, betrifft das Novoflex im AutoFokus-Betrieb mit Scharfstellung von Hand. Und was soll ich sagen: Es funktioniert! Je weiter man vom Scharfstell-Punkt entfernt ist, desto schneller dreht sich der AF-Motor (im Rahmen seiner Möglichkeiten). Kommt man schließlich in die Nähe des Schärfepunktes, so fährt er immer langsamer bis es schließlich am Schärfepunkt den AF-confirm gibt und man (zumindest bei der a550 - Auslösesperre ohne AF-confirm! auslösen darf. Ich wage daher jetzt mal mutig zu behaupten, dass man für den AF keinerlei Datenübertragung vom/zum Objektiv braucht außer die statischen Daten, die im 0x80/0x81-Protokoll gesendet werden.[/quote]
ich komme auch zunehmend dazu, an das Rausspiegeln des MainSPI-Bus über die Lens-Schnittstelle zu glauben.

Zum AFconfirm: Wie verhalten sich eigentlich die Chips von James Lao T? Läuft der AF-Motor oder nicht?
@jolini: Du hast doch einen, wie ist es?

Beim STF ist die Sache brutal gelöst: es hat als AF-Kupplung eine starre Kreuzschlitz-Kupplung (kann sich nicht drehen), blockiert also schlicht den AF-Motor! Und dabei hat es gerade kein AFconfirm und schaltet die Kamera immer auf MF.
Wie ist es beim Voigtländer SL Macro Apo Lanthar 125mm f/ 2.5 gelöst? Das ist MF, hat aber AFconfirm; und zwar schon lange bevor es AFconfirm-Chips gab.
@Matthias: Du hast doch eines?

ZITAT(matthiaspaul @ 2010-05-03, 23:52) Thomas, ich weiß nicht, ob das bei jedem Gehäuse so ist, aber zumindest bei einigen Gehäusen ist diese Leitung bidirektional ausgelegt - die DSLR-A700 und DSLR-A900 gehören dazu, aber auch zu xi-Zeiten gab es das schon. Über den Zweck kann ich im Moment nur mutmaßen, tippe vorerst auf xi-Objektive, aber möglicherweise ist bei SSM-/SAM-Objektiven etwas Ähnliches zu finden.
ZITAT(4) Interessant ist in diesem Zusammenhang auch der letzte Clock-Impuls des ersten Bytes (FFh); der hat nämlich nicht die normale Länge, sondern ist nur etwa halb so lang.[/quote]
ZITATzu 4) das würde ich nicht vertiefen! Ich habe immer gelegentliche drops beim samplen,[/quote]
Hoffen wir, daß das nur ein Drop ist und keine Schikane. ;-)[/quote]
zuerst das einfache: (4) ist sicher ein drop, denn sowas habe ich häufiger, und immer an wechselnden Stellen.
Wenn minolta/Sony, wie nach den jetzigen Erkenntnissen mittlerweile wahrscheinlich, tatsächlich den MainSPI-Bus auf den Objektivkontakten herausspiegelt, und damit weitreichende Einblicke in innere Abläufe offenbart, dann werden die kaum zum Ärgern von Spielkälbern wie uns mal ein paar 5bit-Strukturen eingebaut haben.
Zur Klarstellung: das Rausspiegeln kann nur zwei Gründe haben: 1) debug-Schnittstelle, 2) Design-Fehler. Da ich (2) für wenig wahrscheinlich halte, bleibt eigentlich nur (1).

Hier habe ich mal alle SPI-artigen Verbindungen aus dem Blockschaltbild zusammengestellt:
ZITATBus-SPI:
MAIN_IC4001 [IC4001(MainCPU)] (Bus)
- IC4101(IO-C),
- IC5901(Photometrie),
- IC4201(AS-C),
- IC4003(32kEEPROM),
- IC0001(DC-Cont),
- IC4601(BattDet),
- VertGrip.

Stern-SPI:
STAR [IC1001(ImagP1)] (Punkt-zu-Punkt)
- E1[IC2001(ImagP2)],
- E2[IC2401(ImagP3],
- AS[IC4201(AS-C],
- CA[IC4001(MainCPU],
- LCD[LCD901(3"LCD)]).

Einzel-SPIs:
CMOS [IC1001(ImagP1) <-> IC5004(CmosImag)]
SUBLCD [IC4201(AS-SubCPU) <-> IC7301(DispDr)]
LENS [IC4201(IO-C) <-> Lens][/quote]
[attachment=7774:a900_LENS_SPI.gif]
Das ist jetzt ein kleiner Ausschnitt aus dem Blockschaltbild der A900. Matthias, Du meinst die rot eingekreisten Richtungsmarkierungen, oder?
Die D5 kann anders aufgebaut sein, Blockschaltbilder habe ich nur von Sony (die sind sehr übersichtlich und sauber dokumentiert, klasse!.
Die A700 sieht praktisch identisch aus.

Das deutet darauf hin, dass SS Bidi ist. Ich habe aber bisher in keinem sample, weder von Hans noch Daniel noch mir Hinweise darauf gefunden.
Ein SSM habe ich an der D5 noch nicht gesampelt (kommt alles noch), und mein xi ist Schrott: Blende klebt, ZoomMotor ist defekt, mglw. funktioniert der Zoom/Fokus-Ringgeber nicht (kein Power-MF möglich).
Alle anderen Objektive zeigen jedenfalls nix, was auf ein SS-Interrupt durch das Objektiv hindeutet.

Ich habe zu den xi noch eine Frage: lt. BDA der Dynax 5 funktionieren in manchen Modi die xi-Funktionen nicht. Umkehrschluss: eigentlich kann die D5 xi? Also AutoZoom z.B. ?
Kann jemand etwas dazu sagen? Ich kann es nicht testen, da mein xi halt defekt ist. Die Elektronik lässt immerhin ein Auslesen zu:

[attachment=77755_mAF28...xx_123_1.zip] der Trace und hier der Inhalt des ersten Blocks:

body=d5 lens=mAF2880xi settings=initmfxxxx lfn=1h
block 1
0x00: FF
0x00: 82 29 50 00 21 21 10 2B 31 00 FB 53 EE 00 00 6F 00 A4 00 D9 29 C2 11 22 3B 27 80 00 65 00 45 66
0x20: 04 25 26 00 00 00 00 00 00 00 00 00 00
 
analysis of the first 45 byte content block:
LensID (last2B): 26181 (!)
RomRevision    : 0x82/35 (?)
Anfangsöffnung : 4.18
Kleinste Blende: 22.63
Blendenoffset  : 0.00
Makrobit    (7): 0
Byte 0x04      : 0x21 00100001 33
Byte 0x05      : 0x21 00100001 33
Byte 0x06      : 0x10 00010000 16
Brennweite     : 27 mm (0x2B)
Byte 0x08 p.unk: 0x31 00110001 49 partly unknown
MF-bit      (7): 0
MF2-bit?   (6): 0
Byte 0x09 p.unk: 0x00 0 0 partly unknown
AFStop-bit  (2): 0
Byte 0x0A p.unk: 0xFB 11111011 251 partly unknown
ROMlen-bit  (2): 0
noAFStop?  (0): 1
...
 

so, muss zur Arbeit. gruesze, thomas

ZITAT(ddd @ 2010-05-04, 12:13) Beim STF ist die Sache brutal gelöst: es hat als AF-Kupplung eine starre Kreuzschlitz-Kupplung (kann sich nicht drehen), blockiert also schlicht den AF-Motor! Und dabei hat es gerade kein AFconfirm und schaltet die Kamera immer auf MF.
Wie ist es beim Voigtländer SL Macro Apo Lanthar 125mm f/ 2.5 gelöst? Das ist MF, hat aber AFconfirm; und zwar schon lange bevor es AFconfirm-Chips gab.[/quote]
Das ist praktisch genauso wie beim STF gelöst. Beim STF läßt sich die kreuzschlitzförmige Spindelaufnahme überhaupt nicht bewegen, beim Apo-Lanthar ist die Aufnahme nur schlitzförmig, dafür läßt sie sich um ein paar wenige Grad hin- und herdrehen, bevor sie blockiert. Beides hat den gleichen Effekt; die Spindel und damit der AF-Motor der Kamera wird hart blockiert - die Kameraelektronik erkennt das beim Drehversuch und deaktiviert den Motor. Nicht ganz klar ist, ob die Kamera überhaupt einen Versuch unternimmt, die Spindel zu drehen (es könnte ja noch irgendwo im Objektiv-Chip codiert sein, daß das Objektiv gar keinen Spindelantrieb hat, so daß die Kamera gar nicht erst versucht, anzukuppeln, und es wäre denkbar, daß sich das von Kamera zu Kamera unterscheidet).

Siehe auch: http://www.mi-fo.de/forum/index.php?showto...st&p=254620

ZITATMatthias, Du meinst die rot eingekreisten Richtungsmarkierungen, oder?[/quote]
Ja, das wird aber auch noch an anderen Stellen deutlich.
ZITATDie D5 kann anders aufgebaut sein, Blockschaltbilder habe ich nur von Sony (die sind sehr übersichtlich und sauber dokumentiert, klasse!.[/quote]
Die sind erheblich besser als die von Minolta. Für vorbildliche Serviceunterlagen ist Sony schon seit Jahrzehnten bekannt.
ZITATIch habe zu den xi noch eine Frage: lt. BDA der Dynax 5 funktionieren in manchen Modi die xi-Funktionen nicht. Umkehrschluss: eigentlich kann die D5 xi? Also AutoZoom z.B. ?
Kann jemand etwas dazu sagen?[/quote]
Ich habe selbst keine xi-Objektive, insofern kann ich das nicht überprüfen. Nach allem, was ich weiß, unterstützen die neueren Gehäuse die xi-Funktionen nur noch bruchstückhaft.

Einige xi-Funktionen wurden wohl wenigstens noch von einigen Gehäusen der si-Folgegeneration unterstützt, etwa Image Size Lock (ISZ) und die Brennweitenanzeige im Sucher bei der Minolta Dynax 700si (und vermutlich auch bei der Dynax 800si).

Was bis heute bei allen Gehäusen funktioniert, ist die Auto Compact-Funktion, die das Objektiv auf die kürzeste Auszugslänge zusammenfahren läßt, wenn man die Kamera ausschaltet - verwandt mit der automatischen Verstellung des Entfernungsring auf Unendlich beim Ausschalten, ebenfalls mit dem Ziel, den Auszug zu minimieren.
Gleiches gilt auch für die servomotorische Zoomringverstellung (AZ), die aber vermutlich nicht viel mehr als die Stromversorgung über die Kontakte im oligen Bajonett benötigt.
Daß Autofokus (AF) funktioniert, könnte man fast als gegeben voraussetzen, aber zumindest in Bezug auf die beiden Variofokusobjektive Minolta AF Zoom 3,5-4,5/28-105mm xi und Minolta AF Zoom 4,5-5,6/35-200mm xi, bei denen sich beim Verstellen des Zoomrings auch der Schärfepunkt verschiebt und vom AF-Motor automatisch ausgegleichen wird, ist das nicht ganz selbstverständlich. Aber das kann ja nur im AF-Betrieb, nicht im MF-Betrieb funktionieren.

Auto Standby Zoom (ASZ) und Advanced Program Zoom (APZ) funktionieren nicht mehr, genausowenig wie die 150%-Motivübersichtsfunktion (Sportsuchereffekt). Das war auch schon bei den si-Gehäusen nicht mehr der Fall.

http://www.mi-fo.de/forum/index.php?showto...st&p=249957
http://www.mi-fo.de/forum/index.php?showto...st&p=106602
http://www.mi-fo.de/forum/index.php?showto...ost&p=70982
http://www.mi-fo.de/forum/index.php?showto...ost&p=40879
http://www.mi-fo.de/forum/index.php?showto...ost&p=37156

Viele Grüße,

Matthias

ZITAT(matthiaspaul @ 2010-05-04, 13:48) Einige xi-Funktionen wurden wohl wenigstens noch von einigen Gehäusen der si-Folgegeneration unterstützt, etwa Image Size Lock (ISZ) und die Brennweitenanzeige im Sucher bei der Minolta Dynax 700si (und vermutlich auch bei der Dynax 800si).[/quote]Unter http://www.progsch.net/mediawiki/index.php?title=Xi-Objektiv gibt es eine Übersicht.
ZITAT(matthiaspaul @ 2010-05-04, 13:48) Was bis heute bei allen Gehäusen funktioniert, ist die Auto Compact-Funktion, die das Objektiv auf die kürzeste Auszugslänge zusammenfahren läßt, wenn man die Kamera ausschaltet - verwandt mit der automatischen Verstellung des Entfernungsring auf Unendlich beim Ausschalten, ebenfalls mit dem Ziel, den Auszug zu minimieren.
Gleiches gilt auch für die servomotorische Zoomringverstellung (AZ), die aber vermutlich nicht viel mehr als die Stromversorgung über die Kontakte im oligen Bajonett benötigt.
Daß Autofokus (AF) funktioniert, könnte man fast als gegeben voraussetzen, aber zumindest in Bezug auf die beiden Variofokusobjektive Minolta AF Zoom 3,5-4,5/28-105mm xi und Minolta AF Zoom 4,5-5,6/35-200mm xi, bei denen sich beim Verstellen des Zoomrings auch der Schärfepunkt verschiebt und vom AF-Motor automatisch ausgegleichen wird, ist das nicht ganz selbstverständlich. Aber das kann ja nur im AF-Betrieb, nicht im MF-Betrieb funktionieren.

Auto Standby Zoom (ASZ) und Advanced Program Zoom (APZ) funktionieren nicht mehr, genausowenig wie die 150%-Motivübersichtsfunktion (Sportsuchereffekt). Das war auch schon bei den si-Gehäusen nicht mehr der Fall.[/quote]So ist es. Motorische Brennweitenverstellung und Fokussierung gehen, das Einfahren beim Ausschalten (Auto-Compact) auch. Ohne dass der Anwender am Zoomring dreht, verändern die xi-Objektive auf heutigen Kameras jedoch die Brennweite nicht mehr, das heißt, wie erwähnt funktioniert weder der automatische Brennweitenvorschlag (der mit dem Eye-Start verbunden war) noch die automatische Brennweitennachführung. Streng genommen gilt dies jedoch nicht für alle si-Gehäuse: Die 700si unterstützt die Brennweitennachführung (Image Size Lock), die durch einen Druck auf die Funktionstaste des Objektivs aktiviert wird. Und die Auto-Programm-Zoom-Funktion mit Bildgrößenspeicher (APZ) kann die 700si als letzte ihrer Art, die noch Chipkarten schluckt, mit der Karte "Child" oder "Sports/Action 2" auch.

ZITAT(ddd @ 2010-05-04, 11:13) Zum AFconfirm: Wie verhalten sich eigentlich die Chips von James Lao T? Läuft der AF-Motor oder nicht?
@jolini: Du hast doch einen, wie ist es?[/quote]
Positiv, AF-Motor läuft, genau wie beschrieben, erst schnell dann mit Annäherung an den Confirm-Punkt langsamer bis zum Stillstand bei Erreichen.

mfg / jolini

Guten Morgen an alle!

Also ich stelle mal folgende Behauptung aufgrund der bisherigen Erkenntnisse und Erfahrungen auf:
1) Alle Objektive von Minolta mit 5 Pins haben "nur" ein Lens-ROM ohne weitere Logik.
2) Alle gemessenen Daten oder beobachteten Daten am SPI Bus des Objektives betreffen die Kommunikation mit anderen Kamera-Komponenten.
3) Die bisher bekannten ROM-Datensätze enthalten alle Daten zur Ansteuerung oder Rückmeldung an die Kamera über "Memory-Mapping"
4) Die AF Regelung führt die Kamera durch und nicht das Objektiv. Daher muss die Kamera "nur" die Information über die Objektivmechanik/Optik haben um einen Schärfepunkt anzusteuern.
Ansonst müßte das Objektiv eine Schärfe-Messlogik-Vorrichtung haben die die alten Objektive sicher nicht haben. Im eingeschränkten Maße vielleicht die Bildstabilisierten, die gibts aber sowieso nicht für die Sony Alpha DSLR Serie (zumindest bis jetzt).
5) Ein Rechipen von "alten" Minolta-Objektiven muß daher bereits möglich sein.
6) Je Objektiv ist vielleicht eine andere Schaltungslogik erforderlich, die zusätzliche Schalter bzw. Brennweiten-Codierungen mitberücksichtigen kann.

(D) -, SSM, Xi SAM Objektive sind sicherlich komplexer und haben einen eigene aktive Logik eingebaut, sonst wäre die Funktionalität nicht umsetzbar.

Gruß, Wolfram

ZITAT(DanielSch @ 2010-05-03, 15:35) Ich wage daher jetzt mal mutig zu behaupten, dass man für den AF keinerlei Datenübertragung vom/zum Objektiv braucht außer die statischen Daten, die im 0x80/0x81-Protokoll gesendet werden.[/quote]


Sehe ich auch so.

Gruß, Wolfram

moin,

ja Wolfram, ich bin mir mittlerweile auch (fast) sicher, dass die 5pol-Objektive wohl keine Logik enthalten. Diese Objektive enthalten nix, was irgendeine Rückmeldung veranlassen kann im Zusammenhang mit AF oder AE.
Die, soweit vorhanden, Schalter wie FokusStop, DistanceSwitch, Entfernungsencoder (bei den alten Makros), Makroschalter und Brennweiten-Encoder funktionieren bei allem, was ich bisher gesehen/gefunden habe ganz schlicht über Kontakte am LensChip und selektieren leicht variierende Datensätze.

Ich baue gerade die D5LA zur D5LA2 um, dann kann ich auch bei dieser einschleifen.
ZITAT(matthiaspaul @ 2010-05-04, 0:52) Eine richtungsabhängige Signalseparierung mit automatische Richtungserkennung und -umschaltung für eine bidirektional betriebene Leitung ist nicht einfach zu realisieren. Ich hätte da zwar eine grobe Idee (antiparallele Laufzeitstrecke mit Verriegelungslogik nach dem Prinzip "Baustellenampel", hoffe aber, daß wir das nicht brauchen. ;-)

Uns geht es aber im Moment noch gar nicht darum, die Signale nach Richtung zu trennen, sondern erstmal nur darum, zu sehen, ob die Leitung in unserem Fall überhaupt bidirektional arbeitet. Dafür müßte es schon reichen, zwei NOT-Gatter (oder etwas Äquivalentes) passender Technologie hintereinander zu schalten und versuchsweise mal in der einen, mal in der anderen Richtung in den SS-Signalweg zu legen. Dann müßte man ja sehen, ob alles weiterhin normal funktioniert, ob der Impuls ausbleibt, usw. Damit das vordere Gatter nicht Gefahr läuft, gegen einen Ausgang zu treiben, setzt man noch einen strombegrenzenden Widerstand davor; der verschleift zwar das Signal, aber wenn er nicht zu hochohmig ist, sollte das die Kommunikation nicht beeinträchtigen.

Erst, wenn wir so feststellen, daß das Objektiv SS wirklich auf Low zieht, müssen wir uns dazu weiter den Kopf zerbrechen.[/quote]
ich werde es simpler machen:
Einschleifen eines HC244@5V-Vcc in SCK, SI, SO und SS; zuerst mit fixer Richtung und Sampeln vor und hinter dem Treiber. Da das Schmitt-Trigger sind, gibt es keine Flankenprobleme, Gatterlaufzeit liegt um 4-6ns und ist irrelevant.
Dann werde ich die Signale SCK, SI und SO mit SS gaten, wieder beide Setien samplen. Jeweils Funktion prüfen usw.
Dann wissen wir, ob SS BiDi ist und ggfs. bei welchen LensChip-Arten; und ob die SCK-Pulse und SO-Daten ohne SS für das Objektiv sind oder nicht.

Versehentlich hatte ich die D5 beim ersten Versuch falsch angeschlossen: SO>SI, Vcc>GND, SCK>SS, SS>SCK, GND>Vcc und SI>SO. Mehrere Minuten lang, bis ich endlich nachgemessen und eine negative Spannung von -3,3V gefunden und alles nochmal auseinander genommen habe. Die Eingänge sowohl der Kamera als auch des Objektives (SAL1870DT, also µC-LensChip) halten das aus, es ist nix abgeraucht und alles hat nach korrektem Verdrahten funktioniert!
Zumindest bei einem Messobjekt muss man die Vorsicht nicht übertreiben, die Objektivschnittstelle scheint komplett kurzschlussfest und strombegrenzt und Eingangsspannungs-unempfindlich (natürlich nicht 230V~) zu sein.

-Don't do that at home!- Wer seine aktuelle Kamera oder teure Objektive bei solchen Experimenten röstet, beklage sich nicht bei mir.

gruesze, thomas (dem die Augen wehtun vom Feinstleiterlöten mit der Nadel unter der Lupe und der Daumen brennt vom versehentlichen Berühren des Blitzelkos -AUTSCH- jetzt ist er entladen...)

Da wir scheinbar nun übereinkommen, dass nur das 0x80 bzw. 0x81 Protokoll wichtig ist, könnte man sich nun gezielt an die Bedeutung der restlichen, noch unbekannten Bytes machen.

Ich würde hierzu einen Mikrocontroller vorschlagen, der erstmal nur das 0x80-Protokoll emuliert (das könnte mein Programm aus Beitrag #117 bereits). Zusätzlich sollte es möglich sein, dessen "ROM"-Inhalt on the fly zum Beispiel per RS232 zu ändern. Da ich nicht gewillt bin meine a550 zu zerlegen um an die Kontakte zu kommen, müsste ich einen meiner (noch zahlreich) rumliegenden Eigenbau-Objektiv-Adapter so modifizieren (da ich der Meinung bin, dass man ein funktionierendes Objektiv angesetzt haben sollte, das scharfgestellt werden kann -> um zum Beispiel eine eventuelle Belichtungskorrektur erkennen zu können), dass die Kontaktkabel herausgeführt sind. Dafür müsste ich jedoch noch eine Art Leerplatine anfertigen, auf der nur die Kontaktpads mit Kabeln verbunden werden. Diese kann man dann an ein Entwicklungsboard anschließen. Die Platinenfertigung und der Adapterumbau sowie einerseits die Programmierung des Mikrocontrollers und einer geeigneten PC-Software dürfte jedoch einiges an Zeit verschlingen. Noch mehr Zeit wird dann jedoch wohl das gezielte Durchprobieren der ROM-Bits verbrauchen.

Sollte sich hier also jemand berufen fühlen, so möge er sich melden.

Schöne Grüße, Daniel