moin, ZITAT(DanielSch @ 2010-05-06, 12:28) 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.[/quote]
genau weil mir das zuviel Aufwand ist, versuche ich einen Emulator zu basteln, der PC-basiert sowohl ein Objektiv gegenüber einem Gehäuse als auch ein Gehäuse gegenüber einem Objektiv emulieren kann (der ominöse uAsim).
Das ganze hat aber noch ein so frühes alpha-Stadium, dass ich noch nix posten kann. Wie es funktioniert ist aber schon klar, es fehlt primär die Zeit...
Deshalb habe ich auch die beiden Mess-Gehäuse "aufgetrennt", wobei ich an der D5LA2 noch ca. 2-3h zum fertig bauen benötige. Das geht nur ohne Kaffee (Lackdraht an Stellen anlöten, wo man eigentlich nicht rankommt). Die D5 kann man offen nicht betreiben ohne massiv irreversibel rumzulöten, da zu viele Bedienelemente im Deckel vorhanden sind. Und ich möchte, dass die D5 nach dem Umbau auch normal funktioniert; ohne heraushängende Drähte oder klobige Anbauten (mit einem winzigen Kurzschlussstecker, selbstschließende Kontakte in der benötigten Größe hätte ich selbst bauen müssen...). Allein schon, um sicherzustellen, dass die Messwerte verlässlich sind, da das Gehäuse ohne eingeschleiften Krempel das gleiche Verhalten zeigt wie mit. Die 3000i ist dafür ungeeignet, da sie nicht einmal die Blende oder Belichtungszeit anzeigen kann, und man auch keine Blende vorgeben oder sonstwie (ausser dem Umschalten auf Phighspeed) in die Belichtungssteuerung eingreifen kann. Ich bin mir sicher, dass einiges im Lens-Datensatz für AE ist, denn das STF enthält viele Daten und diese ändern sich mit der manuellen STF-Blende und der Fokusentfernung: das STF hat einen D-Encoder (bzw. etwas vergleichbares), obwohl es nur 5pin ist und diese Infos nicht an das Gehäuse weiterleitet. Die AE-Daten werden aber beeinflusst.
Bitte versuche keinesfalls, die a550 zu öffnen. Da drin sieht es nicht besser aus als in der D5, und es ist alles so eng und gar kein Platz vorhanden. Ich habe jedenfalls immer mehr Hochachtung vor den Montagemitarbeiterinnen, die Teile zu fertigen ist echt eine Strafarbeit.
Das ein Objektiv, welches auch scharfgestellt werden kann, angeschlossen sein muss, halte ich auch für notwendig. Deshalb nützen auch AF-Zwischenringe für unsere Zwecke nix, da diese den Fokus verschieben und Einfluss auf die Belichtungssteuerung (AE) haben. Da es auch keine Original-AF-Zwischenringe gibt, ist nicht klar, wie die korrekt funktionieren müssten. Einfach nur Signale durchschleifen ist auf jeden Fall unrichtig, man kann dies am Verhalten vom STF mit und ohne Original-Konverter sehen (Daten weiter unten).
ZITAT(DanielSch @ 2010-05-06, 12:28) könnte man sich nun gezielt an die Bedeutung der restlichen, noch unbekannten Bytes machen.[/quote]
Damit daran mehr Leute teilnehmen können, poste ich mal alle Daten, die ich gemessen und zusammengetragen habe. Ich habe Daniels xls-Datei (hier in post# 127) mitverwendet, allerdings sieht meine deutlich anders aus. Jeder hat halt seine eigene Arbeitsweise.
Die Daten gibt es Paket im zip, enthalten sind die kompletten Daten als Mappe mit mehreren sheets im *.odt und *.xls-Format, die beiden wichtigsten sheets (LensListe und ROM-Daten) auch als *.csv. Allerdings fehlen Infos in den *.csv, da ich mit Farbmarkierungen, Zellengrößen und Kommentaren arbeite, da es unmöglich ist alle Infos als Text in Feldern irgendwie noch über- und/oder durchschaubar darzustellen.
[attachment=7777:LensROM.zip]
Hier noch die TC-Daten im Klartext, da ich die sehr interessant finde:
2
3
4
5
6
7
8
id bw fe 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 20 ..
SAL14TC vmtl.Inhalt: *1.4 - 1F FF FF 07 12 11 EF 07 07 00 FF FF FF F7 94 1F F4 0F FF FF 0F FF FF FB FF FF FF FF FF 44 FF FF ..
!! !! !! ?? ?!
mAF200F28HS@oo-nf@PP 200 oo 81 20 58 00 19 00 1E 58 24 00 FB 1A FE 00 00 6A F3 C3 00 00 3B 01 F1 2D 49 A3 00 00 32 00 09 66
mAF200F28HS+SAL14TC@3000i 280 oo A1 20 58 08 12 11 0E 60 2C 01 FB 1A FE F8 95 8A F4 D3 00 00 4B 01 F1 29 49 A3 00 00 32 44 09 66
SAL135S28@initaf45oo@3000i 135 oo 81 2C 2C 00 18 11 0E 4F 58 80 04 00 00 DA 00 00 00 00 00 00 00 00 00 26 2F 8B 00 00 53 00 DF B2 ..
SAL135S28+SAL14TC@3000i 190 oo A1 2C 2C 08 12 11 FE 57 60 81 04 00 00 D2 95 20 F4 10 00 00 10 00 00 22 2F 8B 00 00 53 44 DF B2 ..
Ein "offener" TC ist ein ungültiger Zustand, und beim Sampeln treten sehr viele Fehler auf. Der vmtl. Inhalt ist durch etliche Messungen ermittelt, wobei die Bytes +0x1A und +0x1D immer noch unsicher sind.
Auf jeden Fall ist klar, was der TC macht:
Er addiert seinen ROM-Inhalt zu dem Inhalt des angesetzten Objektivs, nur bei den Bytes +0x04 und +0x05 und vmtl. den Bytes +0x10 und +0x1D überschreibt er stur die Objektivdaten statisch mit seinem Inhalt.
Wem eine 1 fehlt: das Teil rechnet mithilfe eines 1bit-Volladdierers direkt im seriellen Datenstrom, wobei der Übertrag beim Beginn eines Bytes nicht gelöscht oder übertragen, sondern auf 1 gesetzt wird.
Die Formel ist folglich: ( 1 + TC_ROM + Lens_ROM ) mod 256.
Das lässt einige Vermutungen zu:
- die statisch überschriebenen Werte müssen Flags sein, weitere Flag-Bytes sind möglich.
- alle numerischen Werte sind logarithmisch im Restklassenring Z256 dargestellt, da der TC14 eine Multiplikation mit sqrt(2) darstellt, welche hier auf eine Addition ohne Übertrag reduziert wird.
Daher sieht die Blendendarstellung und die Brennweitendarstellung so aus wie bereits gepostet, und alle anderen Koeffizienten müssen auch als solche Formen gelesen werden.
Scherz am Rande: der TC modifiziert nicht die Blendenwerte, sondern setzt den Offset in Byte +0x03; genau wie dies bei Zoom-Objektiven mit floatender Blende gemacht wird. Der TC stellt sich also insoweit wie ein Stufen- oder Satz-Objektiv dar.
gruesze, thomas
(edit: unnötig lange Markierung fehlender Daten im CODE-tag entfernt)
f39t26450p261122n1.zip
)
Was Ihr da alle zusammen leistet, ist einfach super!
SC01079...e__ndern.jpg]
