Forum Übersicht - A-Bajonett-Objektive » Objektivsimulator für das Minolta-/Sony-A-Bajonett

[edit] für "Neueinsteiger" fasse ich mal ganz kurz zusammen:

Es geht hier um die komplette Analyse der Objektivschnittstelle incl. (D)/ADI-Protokoll und SSM-Protokoll.
Ziel ist es, sowohl gegenüber einem Objektiv ein Kameragehäuse zu simulieren, als auch gegenüber einem Kameragehäuse ein Objektiv.
Mit diesen Erkenntnissen können dann interessante Sachen adaptiert werden.

Irrwege:
- alles zum Thema "Spannungen", speziell 3V oder 3,3V, hat sich als falsch herausgestellt. Alle dahingehenden Überlegungen waren ein langer Umweg. Die Objektivschnittstelle arbeitet mit 5V-CMOS-Pegeln, auch bei der mit nur 3V betriebenen 9000AF.
- PonyProg und ähnliche Ausleselösungen liefern nur einen Teil der ROM-Inhalte, zumindest bei Objektiven mit 8 Kontakten und Sony-Objektiven mit 5 Kontakten. minolta-Objektive der ersten Generation können damit ausgelesen werden, andere nicht.
- die Daten auf der Objektivschnittstelle, welche während inaktivem SlaveSelect gesendet werden, sind offenbar nicht für die Objektivschnittstelle. Die Leitungen sind alle unidirektional.
- unterschiedliche Kameras verwenden unterschiedliche Taktfrequenzen auf der Objektivschnittstelle, diese liegen soweit bisher bekannt im Bereich zwischen ca. 30kHz (Dynax 3000i) und 125kHz (Dynax 5 beim 0x92er-Datensatz).
- Das Protokoll ist SPI-artig, inhaltlich liefert die Dekodierung als SPI korrekte Werte, das Timing weicht aber von typischen SPI-Implementierungen ab.
Diese Hinweise dienen dazu, die entsprechenden posts "überlesen" zu können. Ich werde mit der Zeit alle meine posts mit entsprechenden Vermerken versehen.

Der aktuelle Stand der Erkenntnis ist in einem Satz Tabellenkalkulationsblätter zusammengefasst, diese liegen als OOoCalc-odc und MS-xls8-Dateien und teilweise als csv-Export vor, die jeweils aktuellste Version binde ich hier als zip-Archiv ein:
(03.06.2010) [attachment=7880:LensROM.zip](26.06.2010) [attachment=7972:LensROM5.zip](21.04.2011) [attachment=9485:LensROM7.zip] (06.12.2014) [attachment=14777:LensROM8.zip]
[/edit]

moin,

ich habe mal gebastelt:

(inspiriert durch die Infos von vasimv@dyxum.com)

Ich plane schon länger eine für mich interessante Bastelei, aber irgendwie konnte ich mich nicht in die Gänge schieben

Nun trat ein Problem auf, Details drüben bei den "Orangen": Falsches/defektes Lens-ROM in 200/2.8 APO G HS

Jetzt habe ich den Ausleseadapter fertig und damit schon mal die benötigten ROM-Inhalte des 200/2.8HS.
Offenbar gibt es die ROMs nicht mehr als Ersatzteil. Es dürften also in Zukunft weitere Fälle auftreten, da dasselbe ROM z.B. auch im 300/2.8APO-G-HS eingesetzt wird ...
Es geht also an das Rechippen: AVR ATtiny20/24/24A/44/44A/84 im SOIC14-Gehäuse habe ich als ersten Versuch geplant. Wird eine fummelige Bastelei, da das Pinout nicht passt, aber sonst dürfte es keine Schwierigkeiten geben.
Die bekannten AFconfirm-Chips sind ungeeignet, da die keine Eingänge für Taster, Schalter usw. haben.

Damit wäre das Rechippen aller AF-Objektive mit 5 Kontakten möglich, auch der Zoom-Objektive und mglw. inkompatibler Fremd-Objektive, und natürlich auch meine Bastelei. Wer mag könnte damit das STF auf AFconfirm umchippen

Wer mag mitmachen?

Und jetzt die Frage:
Ich habe Probleme mit dem Auslesen von D-Objektiven. Mein Adapter hat nur 5 Kontakte und müsste daher das ROM in den Rückwärtskompatibilitätsmodus setzen.
Tut aber nicht es kommt nur 0xFF ...
Ok, ich habe bisher, da noch ein falscher Spannungsregler und keine lowESR-Cs in dem Adapter stecken, nur verschmerzbare Objektive getestet: MAF-2450F40-OR (ok) und SAL-1870F3556 (nix).
Hat jemand eine Idee oder weitergehende Infos?

Funktioniert speziell die Kitscherbe DT-1870 z.B. an einer x000AF oder einer i-Serie-Kamera?

Meine 3000i habe ich nicht ausprobiert. Jetzt geht es definitiv nicht mehr ohne größere Maßnahmen, sie dient nur als Objektivhalter und Kontaktleiste. Das Flexikabel von der Objektivkontaktleiste ist komplett abgelötet und hat nur Verbindung zum Adapter, nicht zum Rest der Kamera. Ich weiß nicht mal, ob der Rest funktioniert, war ein Bastelkauf in der Bucht zusammen mit anderem Bastelmaterial: einem xi-Objektiv mit defektem Motor und verölter Blende, verölt ist gut, nur noch mit Gewalt beweglich... gekauft als "funktioniert problemlos", speziell 3000i + xi-Objektiv

gruesze, thomas

moin,

die Ursache des Ausleseproblems scheint klar zu sein: Die Versorgungsspannung bricht zusammen. Mein Spannungsregler verbrät mit ca. 10mA einfach zu viel... (der "richtige" braucht nur 1mA)

Nicht überraschend enthalten D-Objektive kein ROM, sondern einen Mikrokontroller. Dasselbe gilt erst Recht für die xi-Objektive, das krude PowerZoom und natürlich alle SSM- und SAM-Objektive.

Aber auch die Sony-Objektive mit nur 5 Objektivkontakten, die (nahezu) unverändert von den minolta-Vorgängern weitergebaut werden, enthalten nicht mehr die maskenprogrammierten Toshiba-SPI-ROMs der custom-Baureihe ML00? (?=A, B, .. Z).
Obwohl kein D-Endcoder oder sonstige Zusatzfunktionen vorhanden sind, kann ich auch das SAL-16F28 oder SAL-20F28 (beide 5 Kontakte) nicht auslesen, das Verhalten ist absolut identisch mit dem SAL-1870-Kitzoom (8 Kontakte, D-Encoder).

Somit droht bei "Elektronik"ausfall bei allen alten Objektiven in Zukunft der Totalschaden, da die Ersatzteile zumindest für manche Typen nicht mehr verfügbar sind, sicher nie wieder hergestellt werden und nicht für alle höherwertige Typen einfach Spenderobjektive kannibalisiert werden können (300/2.8nonHS z.B. hat dasselbe ROM wie das 50/1.7, nur anders beschaltet: ein 50/1.7 schlachten für ein 300/2.8 geht ja noch...)
Ohne ROM ist der AF definitiv nicht nutzbar, auch Teildefekte legen diesen zuverlässig lahm.

gruesze, thomas

PS: ich werde hier mit der Zeit die Infos zum Objektiv-Protokoll und den ROM-Inhalten zusammentrgaen. Einiges ist hier, bei Dyxum und anderswo breit verstreut bereits vorhanden, vieles fehlt aber auch noch.

ZITAT(ddd @ 2010-04-04, 21:37) Es geht also an das Rechippen: AVR ATtiny20/24/24A/44/44A/84 im SOIC14-Gehäuse habe ich als ersten Versuch geplant.[/quote]
Alles klar!

ZITAT(ddd @ 2010-04-04, 21:37) Wer mag mitmachen?[/quote]
Also ich eher nicht. Ich denke, ich bleibe bei meiner manuellen Ausrüstung.

...duck und weg

Grüssle, Peter

Interessante Bastelei! Das würde meine Elektronik Kentnisse deutlich überfordern !
Tja, das wäre schön gewesen, eine Reparaturmöglichkeit für ältere Objektive.

moin,

dass das für das non-AF-System auf Basis des SR-Bajonetts keine Relevanz hat, ist mir schon klar ardon:

Ich werde weiter basteln, dauert halt. So schwierig ist das gar nicht, es frisst nur Zeit.

Neue Erkenntnisse:

1. Es gibt entgegen der bisher vorliegenden Informationen Objektive mit RomRev=0x81, welche nur 32 Byte lange Datensätze enthalten.
Prominentes Beispiel: minolta 200mm f/2.8 APO G HS (minolta Part# 2612-100 und 2612-600).

2. Das Tokina AT-X 270 Pro II AF 28-70 f/2.6-2.8 enthält ein fehlerhaftes ROM:
Das Objektiv ist im ROM als Objektiv mit fester maximaler Öffnung von f/2.8 und auch maximaler Blendenzahl von f/22 definiert.
Die Nichtanzeige der Anfangsblende 2.6 liegt also nicht an der Kamera oder unzureichender Auflösung der Kodierung der Blendenstufen, sondern einem falsch programmierten ROM.
Ausserdem setzt es am 70mm-Anschlag des Zoombereiches das Makro-Flag unabhängig von der Entfernungseinstellung. Bei einer Naheinstellgrenze von 70 cm eine etwas überraschende Setzung...
Meine Interpretation: auch Tokina hatte keine bzw. keine vollständige Lizenz für das A-Bajonett. Sonst wäre wohl kaum ein solch dummer Fehler in den ROM-Daten eines teuren (zur damaligen Zeit) Spitzenobjektives.

... more to come

gruesze, thomas

ZITAT(ddd @ 2010-04-04, 22:37) ich habe mal gebastelt:[/quote]
Sehr hübsch!
ZITATIch plane schon länger eine für mich interessante Bastelei, aber irgendwie konnte ich mich nicht in die Gänge schieben [/quote]
Tja, das geht mir in den letzten Jahren leider auch so. Ich komme aus Zeitmangel kaum noch zum Basteln und genau dieses Projekt "Objektivausleseadapter" nebst daraus resultierenden Folgeprojekten schiebe ich auch schon lange vor mir her... ;-)
ZITATJetzt habe ich den Ausleseadapter fertig und damit schon mal die benötigten ROM-Inhalte des 200/2.8HS.
Offenbar gibt es die ROMs nicht mehr als Ersatzteil. Es dürften also in Zukunft weitere Fälle auftreten, da dasselbe ROM z.B. auch im 300/2.8APO-G-HS eingesetzt wird ...[/quote]
Die Chips fallen zwar sehr selten aus, aber Du hast Recht, wenn es passiert, dann ist mangels Ersatzteilen guter Rat teuer...
ZITATEs geht also an das Rechippen: AVR ATtiny20/24/24A/44/44A/84 im SOIC14-Gehäuse habe ich als ersten Versuch geplant. Wird eine fummelige Bastelei, da das Pinout nicht passt, aber sonst dürfte es keine Schwierigkeiten geben.[/quote]
Ich denke auch, daß die ATtinys dafür eine gute Wahl sind. Es gibt zwar bestimmt besser für die Aufgabe geeignete Mikrocontroller, aber dafür sind die AVRs weit verbreitet, leicht und günstig zu bekommen und bestens dokumentiert.
ZITATDie bekannten AFconfirm-Chips sind ungeeignet, da die keine Eingänge für Taster, Schalter usw. haben.[/quote]Wobei ich bisher davon ausging, daß auch dafür Mikrocontroller verwendet werden, bei denen sich bisher ungenutzte Pins entsprechend programmieren ließen. Ich habe mir bisher aber noch keinen AF-Confirm-Chip gekauft, deshalb die Frage, ob die Typbezeichnungen lesbar sind. Welche Chips kommen denn auf den real existierenden Platinchen zum Einsatz?

Die "klassische" Vorgehensweise von Minolta mit einem (EE)PROM, dessen Inhalt über zusätzliche Eingänge einfach komplett umgemappt wird, mag zwar für die Massenproduktion sinnvoll sein (bzw. gewesen sein), ist aber irgendwie nicht besonders flexibel.
ZITATWer mag mitmachen?[/quote]
Grundsätzlich sehr gerne, ich befürchte nur, daß ich auch in Zukunft nicht viel Zeit finden werde...

Du rennst hier mit dem Thema allerdings offene Türen ein. Ganz im Sinne der Anwender und z.B. im Hinblick auf die Beseitigung der vielfältigen Kompatibilitätsprobleme mit Sigma-Objektiven liegt es uns am Herzen, alle Informationen, die Entwicklern und Anwendern weiterhelfen können, die Probleme zu lösen, zu sammeln und aufzubereiten.

ZITATIch habe Probleme mit dem Auslesen von D-Objektiven. Mein Adapter hat nur 5 Kontakte und müsste daher das ROM in den Rückwärtskompatibilitätsmodus setzen.[/quote]
Bist Du denn sicher, daß es einen solchen regelrechten Kompatibilitätsmodus überhaupt gibt? Ich ging bisher eher davon aus, daß das alte Objektivprotokoll über die 5-polige Schnittstelle mehr oder weniger unabhängig von der zusätzlichen Schnittstelle funktionieren würde. Sprich, über die alte Schnittstelle werden die Daten aus dem Objektiv-ROM (bzw. einem Mikrocontroller) ausgelesen und über die neue Schnittstelle werden Befehle in das Objektiv übertragen. Das können Befehle zur Ansteuerung der xi-, SSM-/SAM-Motoren sein, Befehle zur Umschaltung auf das USB-Protokoll für den Data Saver DS-100 oder Befehle, um über das "alte" Interface andere zusätzliche Informationen in die Kamera zu übertragen (z.B. Entfernungseinstellungen bei (D)-Objektiven, erweiterte Objektivdaten). Ich nahm allerdings bisher an, daß diese Umschaltung immer nur temporär erfolgen würde und über das alte Interface ansonsten die normalen Objektivdaten übertragen würden.

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

ZITATFunktioniert speziell die Kitscherbe DT-1870 z.B. an einer x000AF oder einer i-Serie-Kamera?[/quote]
Ich habe speziell diese Kombination nicht getestet, aber zumindest "normale" xi- und (D)-Objektive mit 8 Kontakten funktionieren auch an Kameras mit nur 5 Kontakten, natürlich kann die Kamera die Entfernungsinformationen nicht nutzen (und fordert sie auch gar nicht an) und die xi-Motoren funktionieren auch nicht, da die 6V-Spannungsversorgung, die über zwei der drei neuen Kontakte bereitgestellt wird, ja nicht vorhanden ist und die alte 3V-Versorgung, die im Rahmen des 5-poligen Interfaces realisiert ist, natürlich viel zu schwach ist, um darüber Motoren zu betreiben.

Das Sony Alpha 2,8/70-200mm G SSM und das Sony Alpha Carl Zeiss Vario-Sonnar 2,8/24-70mm ZA SSM funktionieren - ohne AF - jedenfalls einwandfrei auch an der Minolta 9000 AF und 7000 AF.

ZITATMeine 3000i habe ich nicht ausprobiert. Jetzt geht es definitiv nicht mehr ohne größere Maßnahmen, sie dient nur als Objektivhalter und Kontaktleiste. Das Flexikabel von der Objektivkontaktleiste ist komplett abgelötet und hat nur Verbindung zum Adapter, nicht zum Rest der Kamera. Ich weiß nicht mal, ob der Rest funktioniert, war ein Bastelkauf in der Bucht zusammen mit anderem Bastelmaterial: einem xi-Objektiv mit defektem Motor und verölter Blende, verölt ist gut, nur noch mit Gewalt beweglich... gekauft als "funktioniert problemlos", speziell 3000i + xi-Objektiv [/quote]
Wofür verwendest Du die Kamera denn dann überhaupt? Ich dachte, Du sniffst die Daten, die Kamera und Objektiv austauschen, einfach nur zur Analyse mit oder - nächster Schritt - hängst Dich mit dem Mikrocontroller dazwischen, um die meisten Daten unverändert durchzureichen und nur bestimmte Datensätze zu faken. Wenn die Kamera sowieso nur noch der Spannungsversorgung dient, kannst Du doch eigentlich auch eine ganz eigene Spannungsversorgung realisieren?

EDIT: Inzwischen habe ich realisiert, daß Du das Objektiv mit einem SPI-Programmieradapter ausgelesen hast (s.u.). ;-)

ZITAT(ddd @ 2010-04-05, 19:50) die Ursache des Ausleseproblems scheint klar zu sein: Die Versorgungsspannung bricht zusammen. Mein Spannungsregler verbrät mit ca. 10mA einfach zu viel... (der "richtige" braucht nur 1mA)[/quote]
10 mA ist in der Tat ein bißchen happig. Siehe auch weiter unten zum Thema Spannungsversorgung.
ZITATNicht überraschend enthalten D-Objektive kein ROM, sondern einen Mikrokontroller. Dasselbe gilt erst Recht für die xi-Objektive, das krude PowerZoom und natürlich alle SSM- und SAM-Objektive.[/quote]
Ja.
ZITATAber auch die Sony-Objektive mit nur 5 Objektivkontakten, die (nahezu) unverändert von den minolta-Vorgängern weitergebaut werden, enthalten nicht mehr die maskenprogrammierten Toshiba-SPI-ROMs der custom-Baureihe ML00? (?=A, B, .. Z).[/quote]
Das wäre wohl auch nicht ganz zeitgemäß.
ZITATObwohl kein D-Endcoder oder sonstige Zusatzfunktionen vorhanden sind, kann ich auch das SAL-16F28 oder SAL-20F28 (beide 5 Kontakte) nicht auslesen, das Verhalten ist absolut identisch mit dem SAL-1870-Kitzoom (8 Kontakte, D-Encoder).[/quote]
Das wundert mich. Eigentlich sollte das Timing ja nicht besonders kritisch sein, aber wenn sonst alle Voraussetzungen erfüllt sind, liegt es vielleicht doch am Timing?

Vielleicht ist die Spannungsversorgung auch ungeeignet, eigentlich arbeitet die alte Schnittstelle mit 3V (Batteriespannung der Minolta 9000 AF). Neuere Kameras verwenden wohl 3,3V, aber ob 5V, wie vom beim SI-Prog-Adapter zur Verfügung gestellt, angelegt werden dürfen, weiß ich nicht. Ich würde es jedenfalls besser nicht tun. Eine zu hohe Spannung könnte auch den offenbar sehr hohen Stromverbrauch erklären.

Zu den Themen Spannungsversorgung und ML00x-Chips siehe auch:

http://www.mi-fo.de/forum/index.php?showto...ost&p=40879

ZITATPS: ich werde hier mit der Zeit die Infos zum Objektiv-Protokoll und den ROM-Inhalten zusammentrgaen. Einiges ist hier, bei Dyxum und anderswo breit verstreut bereits vorhanden, vieles fehlt aber auch noch.[/quote]
Sehr gerne.
ZITATNeue Erkenntnisse:

1. Es gibt entgegen der bisher vorliegenden Informationen Objektive mit RomRev=0x81, welche nur 32 Byte lange Datensätze enthalten.
Prominentes Beispiel: minolta 200mm f/2.8 APO G HS (minolta Part# 2612-100 und 2612-600).[/quote]
Ja, gibt es. Hier sind auch noch ein paar verstreute Beispiele von ROM-Dumps:

http://www.mi-fo.de/forum/index.php?showto...st&p=180801
http://www.mi-fo.de/forum/index.php?showto...st&p=180945

EDIT: Hab Dich vorhin falsch verstanden, die Kombination des Wertes 81h mit nur 32 Byte langen Datensätzen war mir bisher unbekannt. Normalerweise liefern die Objektive mit 32 Byte Daten den Wert 80h und die mit 45 Bytes Daten den Wert 81h. Diese von Dir entdeckte Kombination deutet, wenn das kein Fehler ist, darauf hin, daß das Byte an Offset +00h einen anderen Zweck erfüllt, als bisher angenommen.
ZITAT2. Das Tokina AT-X 270 Pro II AF 28-70 f/2.6-2.8 enthält ein fehlerhaftes ROM:
Das Objektiv ist im ROM als Objektiv mit fester maximaler Öffnung von f/2.8 und auch maximaler Blendenzahl von f/22 definiert.
Die Nichtanzeige der Anfangsblende 2.6 liegt also nicht an der Kamera oder unzureichender Auflösung der Kodierung der Blendenstufen, sondern einem falsch programmierten ROM.[/quote]
Die interne Repräsentation der Blenden erfolgt (mindestens) in 1/8EV-Granularität, wie ich in den Achtziger Jahren untersucht und auch vor etlichen Jahren mal hier im Forum dokumentiert hatte:

http://www.mi-fo.de/forum/index.php?showto...st&p=122551 Blendenreihe
http://www.mi-fo.de/forum/index.php?showto...ost&p=50472 Blitzprotokoll
http://www.mi-fo.de/forum/index.php?showto...st&p=240632 Blendenreihe
http://www.mi-fo.de/forum/index.php?showto...ost&p=36997 Objektivkontakte

Kam das Tokina AT-X 270 Pro II AF 2,6-2,8/28-70mm nicht zu einer Zeit heraus, als die Minolta-Kameras (von der Minolta 9000 AF mit PBS-90 oder EB-90, die in 1/4 EV-Stufen arbeiten können, abgesehen) Werte nicht sowieso nur in 1/2 EV-Granularität anzeigen konnten? Blende 2,4 wäre eindeutig zu viel gewesen, und Blende 2,5 wurde eben erst von Kameras unterstützt, die die 1/3 EV-Blendenreihe unterstützten. Insofern wäre es zu keiner Änderung in der Anzeige gekommen. Vielleicht hat man sich bei Tokina deshalb dazu entschlossen, keine Werte zu verwenden, die außerhalb der Werte lagen, die in "freier Wildbahn" schon entdeckt wurden. Das wäre allerdings durchaus ein plausibes Anzeichen für eine konservative Herangehensweise, die aus vorherigem Reverse Engineering resultieren könnte.

Vgl. auch: http://www.mi-fo.de/forum/index.php?showto...st&p=122551
ZITATAusserdem setzt es am 70mm-Anschlag des Zoombereiches das Makro-Flag unabhängig von der Entfernungseinstellung. Bei einer Naheinstellgrenze von 70 cm eine etwas überraschende Setzung...[/quote]
Allerdings. Wird das Macro-Flag nicht normalerweise nur genutzt, um bei den alten Minolta AF Zooms (der ersten Generation) mit Macro-Schalter den AF-Motor im speziellen Makrobereich dieser Objektive abzuschalten?

Siehe http://www.mi-fo.de/forum/viewtopic.php?t=19228

Viele Grüße,

Matthias

ZITAT(ddd @ 2010-04-04, 22:37) Ok, ich habe bisher, da noch ein falscher Spannungsregler und keine lowESR-Cs in dem Adapter stecken, nur verschmerzbare Objektive getestet: MAF-2450F40-OR (ok) und SAL-1870F3556 (nix).
Hat jemand eine Idee oder weitergehende Infos?[/quote]
Okay, auf dem von Dir eingebundenen Screenshot von PonyProg sind im Hex-Dump die folgenden, sich wiederholenden Bytes zu finden:
ZITAT0Ah 00h 84h 88h 88h 1Ch 94h 00h DFh 9Ch 80h 00h 60h 0Eh 00h 05h
00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h B7h C6h 01h 94h[/quote]
Bevor man mit diesen Daten etwas anfangen kann, muß man sie erst noch etwas umstellen. Zunächst mal muß man die Reihenfolge der Bits vertauschen, so daß sie einfacher lesbar werden. Zur Illustration dekodiere ich das hier mal per Hand:
ZITAT0Ah = 00001010b -> 01010000b = 50h
00h = 00000000b -> 00000000b = 00h
84h = 10000100b -> 00100001b = 21h
88h = 10001000b -> 00010001b = 11h
88h = 10001000b -> 00010001b = 11h
1Ch = 00011100b -> 00111000b = 38h
94h = 10010100b -> 00101001b = 29h
00h = 00000000b -> 00000000b = 00h
DFh = 11011111b -> 11111011b = FBh
9Ch = 10011100b -> 00111001b = 39h
80h = 10000000b -> 00000001b = 01h
00h = 00000000b -> 00000000b = 00h
60h = 01100000b -> 00000110b = 06h
0Eh = 00001110b -> 01110000b = 70h
00h = 00000000b -> 00000000b = 00h
05h = 00000101b -> 10100000b = A0h
00h = 00000000b -> 00000000b = 00h
00h = 00000000b -> 00000000b = 00h
00h = 00000000b -> 00000000b = 00h
00h = 00000000b -> 00000000b = 00h
00h = 00000000b -> 00000000b = 00h
00h = 00000000b -> 00000000b = 00h
00h = 00000000b -> 00000000b = 00h
00h = 00000000b -> 00000000b = 00h
00h = 00000000b -> 00000000b = 00h
00h = 00000000b -> 00000000b = 00h
00h = 00000000b -> 00000000b = 00h
00h = 00000000b -> 00000000b = 00h
B7h = 10110111b -> 11101101b = EDh
C6h = 11000110b -> 01100011b = 63h
01h = 00000001b -> 10000000b = 80h
94h = 10010100b -> 00101001b = 29h[/quote]
Also:
ZITAT50h 00h 21h 11h 11h 38h 29h 00h FBh 39h 01h 00h 06h 70h 00h A0h
00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h EDh 63h 80h 29h[/quote]
Der Anfang der Daten im Puffer des Programmers liegt in diesem Beispiel an Offset +1Eh, erkennbar am Byte 80h. Stellt man die Daten in die richtige Reihenfolge, ergibt sich folgender ROM-Inhalt des Minolta AF Zoom 4/24-50mm (vgl. auch: http://www.dyxum.com/dforum/lens-rom-data_...9761.html#49761):
ZITAT80h 29h 50h 00h 21h 11h 11h 38h 29h 00h FBh 39h 01h 00h 06h 70h
00h A0h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h EDh 63h[/quote]
+00h: 80h -> Objektiv-ROM mit 32 Bytes Dateninhalt http://www.mi-fo.de/forum/index.php?showto...st&p=180801+01h: 29h -> Offenblende Avo (4.0) (bei Zooms mit Gleitblende für die kleinste Brennweite) http://www.mi-fo.de/forum/index.php?showto...st&p=180793+02h: 50h -> Kleinster einstellbarer Blendenwert Avmax (22) http://www.mi-fo.de/forum/index.php?showto...st&p=180793+03h: 00h -> Offenblendbelichtungsmeßfehler/Blendenabweichung (beim Zoomen) und Status-Flags (Bit 7 = Macro-Flag, Bit 6?-0: Blendenabweichung)+04h: 21h -> Blendenabweichung/Transmission o.ä? (korrespondiert mit Offenblende minus Konstante, oft ist Konstante = 8, manchmal weniger)+05h: 11h -> ?+06h: 11h -> ?+07h: 38h -> Brennweite (ca. 50mm), ändert sich beim Zoomen http://www.mi-fo.de/forum/index.php?showto...ost&p=50472+08h: 29h -> Geometrische Offenblende für AF (4.0) (bei Zooms mit Gleitblende der schlechteste, d.h. kleinste Blendenwert) http://www.mi-fo.de/forum/index.php?showto...st&p=274765+09h: 00h -> Flags (Bit 7 = Drehrichtung Getriebe http://www.mi-fo.de/forum/index.php?showto...st&p=260912 und http://www.mi-fo.de/forum/index.php?showto...st&p=263696, Bit 6 = Manuelle Fokussierung o.ä?, Bits 5-3: unbekannt, Bit 2: Fokusstopptaste gedrückt, http://www.mi-fo.de/forum/index.php?showto...st&p=260174, Bits 1-0: unbekannt)+0Ah: FBh -> Flags (Bit 0: Fokusstopptaste nicht gedrückt, http://www.mi-fo.de/forum/index.php?showto...st&p=260174)+0Bh: 39h -> unbekannt, ändert sich beim Zoomen+0Ch: 01h -> unbekannt (Distance Rotary Encoder?), ändert sich beim Zoomen und Fokussieren (Fokusdistanz-Schalter EFh oder FEh, http://www.mi-fo.de/forum/index.php?showto...st&p=260174)+0Dh: 00h -> ?+0Eh: 06h -> ?+0Fh: 70h -> unbekannt (Distance Rotary Encoder?), ändert sich beim Zoomen und Fokussieren (Fokusdistanz-Schalter EFh oder FEh, http://www.mi-fo.de/forum/index.php?showto...st&p=260189)+10h: 00h -> ?+11h: A0h -> ?+12h: 00h -> ?+13h: 00h -> ?+14h: 00h -> ?+15h: 00h -> ?+16h: 00h -> ?+17h: 00h -> ?+18h: 00h -> ?+19h: 00h -> ?+1Ah: 00h -> ?+1Bh: 00h -> ?+1Ch: 00h -> ?+1Dh: 00h -> ?+1Eh: 63EDh -> Lens ID 25581 http://www.mi-fo.de/forum/viewtopic.php?t=14914

Wer Informationen zu dem von Thomas ("ddd" aufgebauten Ausleseadapter sucht, findet im verlinkten Beitrag von "vasimv" alle wichtigen Informationen dazu:

http://www.dyxum.com/dforum/lens-rom-data_...6268.html#56268

[attachment=7504:siprog_base.png]

Bei dem Adapter handelt es sich um den SI-Prog-Adapter von Claudio Lanconelli (Lancos):

http://www.lancos.com/e2p/siprog_base.png

Zum Auslesen von Objektiv-ROMs muß die Programmierstecker J2 wie folgt mit dem Objektivkontakten (siehe http://www.mi-fo.de/forum/index.php?showto...ost&p=40879) verbunden werden:

Pin 1 (VCC) -> verbinden mit "L2" (LVDD1/VDD1: 5V 3,0 - 3,3V. Hinweis: 5V ist möglicherweise zuviel!
Pin 2 (RESET) -> verbinden mit "L4" (CSLNS/SS)
Pin 3 (PROG?) -> nicht belegen
Pin 4 (SCK) -> verbinden mit "L3" (LSCK/SCK)
Pin 5 (MOSI) -> nicht belegen
Pin 6 (MISO) -> verbinden mit "L1" (LSIN/MISO)
Pin 7 (VEXT) -> nicht belegen
Pin 8 (NC1) -> nicht belegen
Pin 9 (NC2) -> nicht belegen
Pin 10 (GND) -> verbinden mit "L5" (DGND)

"L6" (LSOUT/MOSI) und "L7" (LVDD0/VDD0: 5V - 6V) werden nicht beschaltet. Soll "L6" verwendet werden, würde es mit Pin 5 (MOSI) verbunden werden. "L8" (PGND) muß nur beschaltet werden, wenn auch "L7" beschaltet wird. "L4" kann alternativ auch dauerhauft mit Pin 10 (GND) verbunden werden.

Der Programmer PonyProg2000 kann hier heruntergeladen werden:

http://www.lancos.com/prog.html

Viele Grüße,

Matthias

moin, ZITAT(matthiaspaul @ 2010-04-06, 20:09) Pin 1 (VCC) -> verbinden mit "L2" (VCC: 3,0 - 3,3V. Hinweis: 5V ist möglicherweise zuviel!
Pin 2 (RESET) -> nicht belegen
Pin 3 (PROG?) -> nicht belegen
Pin 4 (SCK) -> verbinden mit "L3" (SCK)
Pin 5 (MOSI) -> nicht belegen
Pin 6 (MISO) -> verbinden mit "L1" (LSIN/MISO)
Pin 7 (VEXT) -> nicht belegen
Pin 8 (NC1) -> nicht belegen
Pin 9 (NC2) -> nicht belegen
Pin 10 (GND) -> verbinden mit "L5" (DGND) und "L8" (PGND) und "L4" (SS)

"L6" (LSOUT/MOSI) und "L7" (VDD: 5V - 6V) werden nicht beschaltet.[/quote]
schon alles soweit richtig, Du hast mir jede Menge Tipparbeit für die Doku abgenommen. Allerdings gibt es ein paar Abweichungen:

Ich habe eine Minimal-Version des SI-base-Boards auf Lochstreifen-Platine gebastelt, ohne die externe Spannungsversorgung.
Leider führt die lokale Elektronik-Apotheke den LM2936Z-5.0 nicht, und ich habe vorerst einen LM2940CT-5.0 im Einsatz.
Achtung, von dem LM2936Z sind gefakte oder fehlerhafte Versionen in der Vergangenheit am Markt aufgetaucht. Nur absolut seriöse Quellen verwenden.
Auch sollte der Kondensator am Ausgang des LM29xx unbedingt ein lowESR-Typ sein und so nahe als irgend möglich zwischen Pin2+3 des Reglers montiert werden, da der Regler sonst im ungünstigsten Fall schwingen könnte.
Entgegen Deiner Annahme weiter oben wird die "Schaltung" von der seriellen Schnittstelle des Rechners versorgt. Die Kamera ist komplett abgekoppelt, sie dient nur als mechanischer Halter und hat die Objektivkontaktleiste samt Flexiboard gespendet. Interessantes Detail: die 3000i hat nur 5 Kontakte, aber das Federblech in der Kontaktleiste hat 6 Federn, ist also bereits für eine bidirektionale Objektivschnittstelle incl. L6=MOSI ausgelegt. Auch der Kunststoffrahmen der Kontaktleiste ist schon breit genug für alle 8 Kontakte.

Ich habe allerdings auch die 2. Modifikation von vasimv eingebaut (im post direkt unter dem oben verlinkten):
L4=SS (/CS) ist mit Pin 2 verbunden und entsprechend der Adapterplatine SPI-EEPROM (s.u.) des Si-base mit einem R 10kOhm gegen Masse (Pin 10, L5) Vdd (Pin 1, L2) verbunden.
Den Blockkondensator 100nF über der Spannungsversorgung des ROMs habe ich weggelassen: dieser müsste nahe an dem ROM im Objektiv angelötet werden, sonst bleibt er wirkungslos.
MOSI (Pin 5, L6, SI) bleibt frei (vorerst...). /HOLD und /WP haben wir nicht, SO=MISO (MasterInSlaveOut).
[attachment=7507:spi_eep.gif]
hier die Lötseite:
[attachment=7509:Loetseite.jpg]
Bauteilliste:

Bauteile SI base w/o Ext.Sp.Vers. + SPI-EEP:
 
U3 = LM2936Z-5.0 (segor: 2,40) [gestrichen!]ODER LM2936Z-3.3 (2,60)[/gestrichen]
Q1 = BC547
D1, D2, D3 = 3x 1N4148
Z1, Z2, Z3 = 3x 5V1 Zenerdiode 500mW [gestrichen!]ODER 3V3 / 3V6[/gestrichen]
 
R1 = 15k
R3, R7 = 2x 10k
R4, R5, R6 = 3x 4k7
C3, C4 = 2x 47u lowESR, 16V
C12 = 100n
 
DB9 female oder 1:1-Kabel abschneiden, anlöten
Stiftleiste 10x1 oder Flachbandkabel
Lochrasterplatine oder Lochstreifenplatine, 10x20 Bohrungen
a-Bajonett mit Lens-Kontaktleiste (defekte Kamera...)
 
Hinweis: mit der 3,3 V Versorgung ist die Funktion als universeller Programmieradapter nicht gewährleistet.
[s]- die Längswiederstände R4, R5 R6 und der Spannungsteiler R1, R3 müssen dann auch angepasst werden -
Zum Auslesen der LensROMs ist das die sicherere Alternative![/s]
 

EDIT: der hier angedachte Umbau auf 3,3 V geht in dieser Form auf jeden Fall nicht! Weiterlesen bitte hier (post#33, Seite 3)

Und ich habe die Kontakte L6, L7 und L8 natürlich offen. Ich halte es auch für keine gute Idee, L5 (DGND) und L8 (PGND) direkt zu verbinden!
Ich muss in den lv2-Manuals noch mal nachsehen, wie das in der Kamera ist.

Lt. Pete Ganzel (sein Bild ist im dyxum-thread im Startpost verlinkt) liegt an L2=Vdd 4,9 V an.
Hier ein 2. Bild von Pete:
[attachment=7508:LensRomK.jpg]

Rest später!

gruesze, thomas

edit: ergänzt, Fehler gefixt, Anhänge eingearbeitet. edit2: 3.3 V ergänzt, s.u. edit3: 3.3 V zusätzliche Hinweise, s.n.w.u. edit4: 3,3 V Warnung, Querverweis

ZITAT(ddd @ 2010-04-06, 23:20) schon alles soweit richtig, Du hast mir jede Menge Tipparbeit für die Doku abgenommen.[/quote]
Leider weicht die Pinbelegung dieses Verbinders J2 beim SI-Prog deutlich von der Standardbelegung für 10-polige ISP-Programmierstecker bei AVRs ab. Die Standardbelegung für gängige AVR-ISP-Programmer (wie STK200, STK300, usw.), auch bekannt als "KANDA"-Verbinder, lautet wie folgt:

Pin 1 (MOSI)
Pin 2 (VCC, je nach Ziel, oft aber +3,3V oder +5V)
Pin 3 (LED, meist unbeschaltet)
Pin 4 (GND)
Pin 5 (RESET)
Pin 6 (GND)
Pin 7 (SCK)
Pin 8 (GND)
Pin 9 (MISO)
Pin 10 (GND)
 
+-----+
> 1 2 |
| 3 4 |
| 5 6 |
| 7 8 |
| 9 10|
+-----+
 
(RESET ist auch hier low-aktiv.)
 

Hat man also nicht den SI-Prog sondern einen anderen (größeren) AVR-Programmer vorliegen, würde die Zuordnung der Signale des 2x5-poligen Programmiersteckers zu den Objektivsignalen wie folgt aussehen:

Pin 1 (MOSI) -> nicht verbinden
Pin 2 (VCC, je nach Ziel, oft aber +3,3V oder +5V) -> verbinden mit "L2" (LVDD1/VDD1: 5,0V, u.U. auch 3,3V)
Pin 3 (LED) -> nicht verbinden
Pin 4 (GND) -> nicht verbinden
Pin 5 (RESET) -> verbinden mit "L4" (CSLNS/SS)
Pin 6 (GND) -> nicht verbinden
Pin 7 (SCK) -> verbinden mit "L3" (LSCK/SCK)
Pin 8 (GND) -> nicht verbinden
Pin 9 (MISO) -> verbinden mit "L1" (LSIN/MISO)
Pin 10 (GND) -> verbinden mit "L5" (DGND)

"L4" (CSLNS/SS) kann man alternativ auch an Pin 10 (GND) anschließen, sofern es Probleme bei der Steuerung des Reset-Signals durch den Programmer gibt. "L6" (LSOUT) könnte an Pin 1 (MOSI) angeschlossen werden, das könnte aber auch zu Problemen führen. "L7" (LVDD0) wird ggfs. an +6V angeschlossen. Nur, wenn "L7" (LVDD0) angeschlossen wird, muß auch "L8" (PGND) angeschlossen werden.

Wo wir schon dabei sind, eine andere, bei vielen AVR-Programmern implementierte Belegung sieht wie folgt aus:

Pin 1 (MISO) -> verbinden mit "L1" (LSIN/MISO)
Pin 2 (VCC, je nach Ziel, oft aber +3,3V oder +5V) -> verbinden mit "L2" (LVDD1/VDD1: 5,0V, u.U. auch 3,3V)
Pin 3 (SCK) -> verbinden mit "L3" (LSCK/SCK)
Pin 4 (MOSI) -> nicht verbinden
Pin 5 (RESET) -> verbinden mit "L4" (CSLNS/SS)
Pin 6 (GND) -> verbinden mit "L5" (DGND)
 
+-----+
> 1 2 |
| 3 4 |
| 5 6 |
+-----+
 
(RESET ist auch hier low-aktiv.)
 

ZITATAuch sollte der Kondensator am Ausgang des LM29xx unbedingt ein lowESR-Typ sein und so nahe als irgend möglich zwischen Pin2+3 des Reglers montiert werden, da der Regler sonst im ungünstigsten Fall schwingen könnte.[/quote]
Ja.
ZITATEntgegen Deiner Annahme weiter oben wird die "Schaltung" von der seriellen Schnittstelle des Rechners versorgt. Die Kamera ist komplett abgekoppelt, sie dient nur als mechanischer Halter und hat die Objektivkontaktleiste samt Flexiboard gespendet.[/quote]
Okay, danke für die Erklärung. Dann ist der Kondensator natürlich besonders wichtig.
ZITATInteressantes Detail: die 3000i hat nur 5 Kontakte, aber das Federblech in der Kontaktleiste hat 6 Federn, ist also bereits für eine bidirektionale Objektivschnittstelle incl. L6=MOSI ausgelegt.[/quote]
Sehr interessant! Trivia: Die Minolta Dynax 3000i ist auch die einzige Kamera im gesamten System, die ein paar Kontakte mehr im damals neuen Minolta-Hotshoe hat; einer davon ist auch auf Deinem Foto sichtbar, die anderen beiden liegen verdeckt unter den Kufen. Diese Zusatzpins erlauben es, auf dem Hotshoe montierte Geräte (Blitzgeräte u.ä.) direkt aus der Kamera zu versorgen, so daß sie keine eigenen Batterien mitbringen müssen und besonders klein ausfallen können. Ich hoffe, daß Sony diese Idee wieder aufgreift, denn das würde heute noch mehr Möglichkeiten eröffnen als es das damals schon hätte.

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

ZITATAuch der Kunststoffrahmen der Kontaktleiste ist schon breit genug für alle 8 Kontakte.[/quote]
Ja, das war aber auch schon bei der Minolta 9000 AF, 7000 AF und 5000 AF so. Offenbar hat Minolta also von Anfang an geplant, die Objektivschnittstelle irgendwann später um drei zusätzliche Pins zu erweitern. Eingeführt wurden sie erst mit der xi-Serie (dritte Gehäusegeneration). Interessanterweise findet sich dieser freie Bereich auch bei den Yashica AF-Kameras und bei der Samsung Kenox GX-1. Zufall?

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

ZITATIch habe allerdings auch die 2. Modifikation von vasimv eingebaut:[/quote]
Hat "vasimv" die eigentlich auch irgendwo dokumentiert?
ZITATL4=SS ist mit Pin 2 verbunden und entsprechend der Adapterplatine SPI-EEPROM des Si-base mit einem R 10kOhm gegen Masse (Pin 10, L5) verbunden.[/quote]
So läßt sich der Chip unter Programmkontrolle selektieren, statt ihn dauerhaft selektiert zu halten.

Möglicherweise verstehe ich Dich ja nur irgendwie falsch, aber warum zieht "vasimv" Pin 2 gegen Masse und nicht gegen VCC? RESET und SS sind doch low-aktiv, d.h. der Chip wird selektiert, wenn SS aktiv wird, also auf Low-Pegel geht. Wozu sollte man den Kollektor des BC547 über 10K auf GND ziehen? Dann kann das Signal doch nur High werden, wenn der Chip über einen internen Pullup verfügt, der deutlich kleiner als 10K ist. Viele Chips haben solche internen Pullups an ihren Reset-Eingängen, aber ob die stark genug sind, gegen diese 10K anzukämpfen? Und ob die Chips in den Objektiven das auch haben?

Möglicherweise gibt es deswegen sogar diese von Dir berichteten Probleme beim Auslesen einiger Deiner Objektive?

ZITATUnd ich habe die Kontakte L6, L7 und L8 natürlich offen. Ich halte es auch für keine gute Idee, L5 (DGND) und L8 (PGND) direkt zu verbinden![/quote]
Da ist was dran. In einem sauberen Design sollte man DGND und PGND tunlichst getrennt halten und nur an einem Ort (sternförmig) zusammenführen, um die Störeinkopplung in die Signale minimal zu halten und Masseschleifen zu vermeiden. Ich meine mich aber erinnern zu können, daß die beiden Massen in den Objektiven sowieso verbunden waren (hab's aber jetzt nicht mehr nachgemessen).
EDIT: Das mag zwar im Einzelfall zutreffen, aber zumindest gibt es Objektive, wo das nicht der Fall ist, wie ich hier mal dokumentiert hatte. Solange "L7" nicht verwendet wird, kann auch "L8" unbeschaltet bleiben.
ZITATLt. Pete Ganzel (sein Bild ist im dyxum-thread im Startpost verlinkt) liegt an L2=Vdd 4,9 V an.[/quote]
Siehe hier: http://www.dyxum.com/dforum/lens-rom-data_...8891.html#48891

Vermutlich hat er das an irgendeiner Kamera tatsächlich so gemessen. Meine 3,0V rühren von der Minolta 9000 AF her, die mit zwei 1,5V-Mignonzellen arbeitet und die Objektiv-ROMs nur mit 3V speist. Da alle Objektive auch mit der 9000 AF klarkommen müssen, muß die Schaltung zumindest 3V-kompatibel sein, möglicherweise aber 5V-tolerant. Ich meine mich entsinnen zu können, daß ich in den Schaltplänen anderer Kameras etwas von 3,3V gelesen habe, habe aber jetzt nicht nachgeschaut. Aufgrund der Tatsache, daß die Chips aber sowieso mit 3V klarkommen müssen, sehe ich im Moment keinen Grund, ein unnötiges Risiko einzugehen und dort eine deutlich höhere Spannung anzulegen.

EDIT: Auch bei der 9000 AF liegen 5V an, siehe weiter unten in diesem Thread!

Ganz anders sieht es mit der Spannung an "L7" aus. Dort liegt (bei den analogen Kameras) die unstabilisierte Batteriespannung von 6V an, insofern muß die Elektronik oder die Motoren, die darüber gespeist werden, mit einer wesentlich höheren Spannung klarkommen.

Viele Grüße,

Matthias

ZITAT(matthiaspaul @ 2010-04-07, 1:51) Hat "vasimv" die eigentlich auch irgendwo dokumentiert?
ZITATL4=SS ist mit Pin 2 verbunden und entsprechend der Adapterplatine SPI-EEPROM des Si-base mit einem R 10kOhm gegen Masse (Pin 10, L5) verbunden.[/quote]
So läßt sich der Chip unter Programmkontrolle selektieren, statt ihn dauerhaft selektiert zu halten.

Möglicherweise verstehe ich Dich ja nur irgendwie falsch, aber warum zieht "vasimv" Pin 2 gegen Masse und nicht gegen VCC? RESET und SS sind doch low-aktiv, d.h. der Chip wird selektiert, wenn SS aktiv wird, also auf Low-Pegel geht. Wozu sollte man den Kollektor des BC547 über 10K auf GND ziehen? Dann kann das Signal doch nur High werden, wenn der Chip über einen internen Pullup verfügt, der deutlich kleiner als 10K ist. Viele Chips haben solche internen Pullups an ihren Reset-Eingängen, aber ob die stark genug sind, gegen diese 10K anzukämpfen? Und ob die Chips in den Objektiven das auch haben?

Möglicherweise gibt es deswegen sogar diese von Dir berichteten Probleme beim Auslesen einiger Deiner Objektive?[/quote]
nein, ich habe Blödsinn geschrieben: natürlich wird SS=L4=Pin 2 mit dem 10k-Pullup gegen Vdd (Pin 1) gezogen. Habe es oben lesbar korrigiert (Fehler durchgestrichen).
Dokumentiert hat vasimv dass im Post direkt unter dem von Dir verlinkten. Habe ich oben ergänzt, wir sind halt parallel am Tippen/Editieren

Hintergrund: die ROMs sind eben keine echten SPI-Devices, sondern senden stur in einer Endlosschleife auf MISO ihren Datensatz mit der anliegenden Clock an SCK, sobald SS aktiv ist.
PonyProg dagegen versucht, erstmal die Adresse zu übergeben (auf MOSI ins Nirwana) und beginnt dann mit dem Lesen. Daher stimmt das Leseraster nicht, am Anfang fehlen x*32+2Byte (x=0, 1, ...) und die Daten beginnen ab Offset 0x1E und wiederholen sich bis zum Ende des Leserahmens. Durch gesteuertes Aktivieren von SS stimmt das timing so zuverlässig, dass der Offset immer bei 0x1E liegt. Ohne diese Verbesserung klappt das wohl nicht zuverlässig.

ZITATVermutlich hat er das an irgendeiner Kamera tatsächlich so gemessen. Meine 3,0V rühren von der Minolta 9000 AF her, die mit zwei 1,5V-Mignonzellen arbeitet und die Objektiv-ROMs nur mit 3V speist. Da alle Objektive auch mit der 9000 AF klarkommen müssen, muß die Schaltung zumindest 3V-kompatibel sein, möglicherweise aber 5V-tolerant. Ich meine mich entsinnen zu können, daß ich in den Schaltplänen anderer Kameras etwas von 3,3V gelesen habe, habe aber jetzt nicht nachgeschaut. Aufgrund der Tatsache, daß die Chips aber sowieso mit 3V klarkommen müssen, sehe ich im Moment keinen Grund, ein unnötiges Risiko einzugehen und dort eine deutlich höhere Spannung anzulegen.[/quote]
stimmt, die Überlegung ist zwingend. Dann werde ich wohl zwei Varianten aufbauen, es gibt ja auch den LM2936Z-3.3 (segor 2,60). Verflixt, jetzt muss ich oben nochmal Edith bemühen.

Schluss für heute. Den Rest der Woche bin ich verplant, ab Samstag geht's hier meinerseits weiter.

gruesze, thomas

ZITAT(ddd @ 2010-04-06, 23:20) Bauteilliste:

R4, R5, R6 = 3x 4k7
[...]
Hinweis: mit der 3,3 V Versorgung ist die Funktion als universeller Programmieradapter nicht gewährleistet.
 

[/quote]
BTW. Zum Betrieb an 3,3V sind diese drei Serienwiderstände R4, R5, R6 möglicherweise schon zu groß. Ich würde dann auf etwas in der Größenordnung 1K (oder noch weniger) ausweichen.

Viele Grüße,

Matthias

moin, ZITAT(matthiaspaul @ 2010-04-07, 10:13) BTW. Zum Betrieb an 3,3V sind diese drei Serienwiderstände R4, R5, R6 möglicherweise schon zu groß. Ich würde dann auf etwas in der Größenordnung 1K (oder noch weniger) ausweichen.[/quote] das kommt vom übermüdeten schnelltippen...
Beim Ändern der Schaltung auf 3,3V müssen auch die Zenerdioden angepasst werden, sonst liegt an den Signaleingängen (relativ) Überspannung an, das tolerieren die meisten Bausteine nur bis abs.max. Vcc +0,5 V, hier also 3,8 V.
Also ZD 3,3 V oder ev. ZD 3,6 V. Ausserdem muss der Spannungsteiler aus R1 (15k) und R3 (10k) vor der Basis von Q1 vmtl. angepasst werden, und natürlich die Längswiederstände R4, R5 und R6 (4k7).
Das Umrüsten auf 3,3 V ist also nicht einfach so möglich. Ich habe das oben vermerkt!

Daher habe ich nachgemessen: die a900 führt 3,2 V (gemessen mit meinem Schätzeisen) zwischen L2 und L5 am Objektivbajonett ohne angesetztes Objektiv.
Jetzt, nach einem tieferen Blick ins SM, kann ich (fast) sicher sagen:

Am LensROM dürfen entweder 3,3 V oder 5,0 V anliegen!
Die Versorgungsspannung LVDD1 (Kontakt LND032) wird aus der Versorgung IC_4001_3.3V/5.0V abgeleitet via Q4105 (Schalttransistor), diese ist umschaltbar zwischen 3,3 V und 5,0 V.

Das Objektivkontakt-Flexi ist FP-897, statt L1 .. L8 heißen die Pins bei Sony LND031 .. LND038. PGND und REG_GND (DGND) sind strikt getrennt, ohne lv3 vom DD-299 (power board) bleibt die Verbindung zwischen beiden ungeklärt.
Die Leitungen LSIN/LENS_SI (MISO), LSOUT/LENS_SO (MOSI) und LSCK/LENS_SCK(SCK) hängen am IC4001 (main cpu) und sind ein Bus, der fast die gesamte Kamera durchzieht und von Spannungsreglern bis hin zur AE-Einheit alles verbindet.

gruesze, thomas

PS: eigentlich wollte ich endlich was zur weiteren Analyse der ROM-Inhalte liefern, aber das muss noch warten.

FRAGE:
wie ist es mit der Veröffentlichung von kompletten ROM-Inhalten? (deshalb oben auch nur die verdrehten Daten am Bildschirm)
Die sind urheberrechtlich geschützt, insbesondere die aktueller Sony-Objektive.
Auszüge zu akademischen oder Lehrzwecken sehe ich als nicht problematisch, aber komplett?

Könnten die Daten hier nicht-öffentlich gesammelt werden für historische und Reparatur-Zwecke?

Ich denke, dass Frank als Betreiber hier die Entscheidung vorbehalten bleiben muss.
Solange von ihm keine eindeutige Stellungnahme erfolgt, werde ich keine kompletten ROM-Inhalte posten.

ZITAT(ddd @ 2010-04-07, 11:45) Jetzt, nach einem tieferen Blick ins SM, kann ich (fast) sicher sagen:

Am LensROM dürfen entweder 3,3 V oder 5,0 V anliegen!
Die Versorgungsspannung LVDD1 (Kontakt LND032) wird aus der Versorgung IC_4001_3.3V/5.0V abgeleitet via Q4105 (Schalttransistor), diese ist umschaltbar zwischen 3,3 V und 5,0 V.[/quote]
Dann könnte es sogar vom Objektiv abhängen (identifiziert woran?), ob 3,3V oder 5,0V angelegt werden sollen oder dürfen.
ZITATwie ist es mit der Veröffentlichung von kompletten ROM-Inhalten? (deshalb oben auch nur die verdrehten Daten am Bildschirm)
Die sind urheberrechtlich geschützt, insbesondere die aktueller Sony-Objektive.
Auszüge zu akademischen oder Lehrzwecken sehe ich als nicht problematisch, aber komplett?[/quote]
Selbst das sähe ich in unserem Falle als ziemlich unproblematisch an.

Es handelt sich hier nicht um Programmcode, sondern um Daten. Will man hundertprozentige Kompatibilität erreichen, müssen diese Daten in strenger Abhängigkeit von den Eigenschaften des jeweiligen Objektivs in einer ganz bestimmten Form vorliegen, damit das Objektiv mit der Kamera funktionieren kann. Anders als bei Programmcode gibt es hier keinerlei Freiheitsgrade ("dichterische Freiheit", in denen irgendeine schöpferische Höhe stecken könnte, die die Form der Datenrepräsentation schützenswert machen könnte. Das Copyright-Symbol auf manchen Objektiven bezieht sich meinem Verständnis nach nicht auf den die Eigenschaften des Objektivs beschreibenden Inhalt der ROMs, sondern höchstens auf die Objektivrechnung, pfiffige Details der Konstruktion oder das A-Bajonett an sich, die patentiert sein könnten. Auch das Objektivprotokoll selbst (im weitesten Sinne ein Verfahren) könnte geschützt sein, aber es handelt sich hier um SPI, ein industrieweit milliardenfach eingesetztes Standardprotokoll, nicht um eine Minolta-spezifische Lösung.

Alle Informationen, die wir hier verbreiten, sind entweder selbst generiert und/oder stammen aus Quellen, die "im Prinzip" jedermann zugänglich sind (dazu gehören auch Service Manuals, die man vom Hersteller kaufen kann), wenn auch vermutlich nicht jeder in der Lage ist, sie in nicht aufbereiteter Form zu erkennen und zu verstehen. Sprich, wir verraten hier keine Geheimnisse und stehen auch nicht unter NDAs o.ä.

Weder beim Kauf der Kamera noch bei Kauf der Objektive mußte man eine Erklärung abgeben, nach der man sich die Kommunikation der Systemkomponenten untereinander nicht anschauen oder darüber öffentlich diskutieren dürfe. Eine solche Klausel wäre auch absurd, schließlich ist eine Systemkamera nur dann eine echte Systemkamera, wenn die Schnittstellen offen sind - nicht unbedingt, daß die Dokumentation vom Hersteller auf dem Silbertablett geliefert wird, aber zumindest darf es keine künstlichen Sperren geben, die den Anschluß eigener Geräte verhindern würden - solche technisch unnötigen, künstlichen Sperren bzw. Verbündelungen (artificial ties) einzubauen, wäre zumindest nach amerikanischem Wettbewerbsrecht sogar verboten, da es den Wettbewerb und damit den technischen Fortschritt behindern würde. Natürlich muß der Hersteller keine Garantie übernehmen, wenn seine Produkte abseits der von ihm getesteten Umgebungen eingesetzt werden, und er kann sich bei Schäden, die aus solchen Experimenten resultieren, weigern, die Geräte zu reparieren - das Risiko muß jeder eingehen, der sich auf solche Selbstbaulösungen einläßt, genauso wie wenn er ein Fremdobjektiv anmontiert.

Du hast schon angesprochen, daß selbst die Veröffentlichung von Codeauszügen zu wissenschaftlichen und journalistischen Zwecken erlaubt wäre, soweit es der Vermittlung des Wissens und für das Verständnis zweckdienlich ist.

Wir "knacken" hier auch keinen Verschlüsselungsalgorithmus oder Kopierschutzverfahren oder stellen "Raubkopien" her, sondern lesen nur Daten aus, die ohne jeglichen Schutz frei für jeden zugänglich sind, der ein bißchen von Elektronik versteht, und beschreiben, wie etwas funktioniert.

Es ist auch keinesfalls so, daß Reverse Engineering "per se" verboten wäre (oder durch entsprechende Klauseln verboten werden könnte), wie viele meinen (und wie manchmal auch die Hersteller etwa bei der Installation von Software zu suggerieren versuchen). Es hängt immer davon ab, was man damit macht.

Möchte z.B. ein Hersteller eines Fremdprodukts vollständige Kompatibilität mit dem Produkt eines anderen Herstellers sicherstellen, und gibt ihm der Hersteller des letzteren Produkts keine Möglichkeit, diese Informationen z.B. in Form einer Dokumentation und Spezifikation zu kaufen, so bleibt dem Fremdhersteller gar nichts anderes übrig, als die Spezifikation durch Reverse Engineering zu gewinnen. Das ist völlig legal, wenn der Fremdhersteller dieses Wissen als funktionalen Leitfaden bei der clean room-Entwicklung seiner eigenen Produkte benutzt, um Kompatibilität zu erreichen. Er darf natürlich nicht hingehen und die Daten einfach 1:1 übernehmen und so in seinen eigenen Objektiv-ROMs verwenden (was aber sowieso nicht sinnvoll ist), sondern er muß sie schon selbst von Grund auf neu erzeugen. In der Regel werden sich die Objektive soweit voneinander unterscheiden, daß auch die resultierenden Daten unterschiedlich aussehen werden. Aber z.B. eine Blende 4.0 muß nunmal als 29h codiert werden, da führt kein Weg dran vorbei, will man kompatibel bleiben. Und wenn bestimmte Kameraalgorithmen nicht mit den vorliegenden Objektivdaten arbeiten, sondern stattdessen eine Lens-ID nutzen, kann auch ein Fremdhersteller nicht wahlfrei eine neue ID wählen, sondern muß u.U. die ID eines Original-Objektivs nutzen.

Wir untersuchen die ROM-Inhalte nicht, weil wir irgendeine Form von "Datenklau" fördern wollen (was will man auch mit dem ROM-Inhalt anfangen, wenn man das entsprechende Objektiv nicht besitzt?), sondern weil es Leute gibt, die Objektive besitzen, deren ROMs defekt sind und weil die Hersteller Minolta und Konica Minolta sich aus dem Fotomarkt zurückgezogen haben und dafür keine Ersatzteile mehr anbieten (nach z.T. Jahrzehnten auch durchaus verständlich). Auch von anderen Herstellern gibt es keine passenden Ersatzteile, so daß den Eigentümern gar keine andere Möglichkeit bleibt, als sich die Chips mit dem passenden Inhalt selbst herzustellen - oder sich dabei von anderen helfen zu lassen.
Genauso ist es für Nutzer von Fremdobjektiven, die mit neueren Kameras nicht mehr zusammenarbeiten, völlig legitim, nach Abhilfe für diese Probleme zu suchen. Wie wir alle wissen, werden sie dabei von den Fremdzubehörherstellern regelmäßig im Stich gelassen, so daß auch diese Besitzer eigene Lösungen finden müssen, wollen sie ihr sonst nicht mehr weiternutzbares Eigentum nicht verschrotten.

Und genau um diese Wissensvermittlung, die die Eigentümer der Produkte in die Lage versetzt, diese Probleme zu lösen, geht es uns hier.

Viele Grüße,

Matthias

Um die Umwandlung der von PonyProg ausgelesenen Daten in die richtige Form zu automatisieren, habe ich mal ein kleines DEBUG-Skript geschrieben, das unter allen DOS- und Windows-Installationen funktionieren sollte (getestet habe ich es mit diversen Versionen von DR-DOS, PC DOS, MS-DOS sowie unter Windows 98 SE und Windows XP - und da sich die DEBUG-Dialekte z.T. leicht unterscheiden, ist das Skript etwas länger als notwendig, wenn man sich auf eine Plattform festlegen würde):

LENSDUMP.DEB:

A 100
push cx
mov si,200
mov di,si
lodsb
mov cx,8
rcl al,1
rcr ah,1
loop 10A
mov al,ah
stosb
cmp di,22D
jne 106
pop cx
nop
 
F 200 L FF 0
N LENSDUMP.BIN
L 200
D 200 L 2D
G=100 11A
D 200 L 2D
N LENSDUMP.BIN
W 200
Q
Q
 

Voraussetzung für die ordnungsgemäße Funktion ist, daß die 32 oder 45 Datenbytes ab dem passenden Offset (im obigen Beispiel +1Eh) aus dem PonyProg-Hex-Dump in die Datei LENSDUMP.BIN kopiert wurden, wo sie dann ab Offset +00h beginnen. Diese Offsetverschiebung nimmt das Skript nicht vor.

Aufruf an der Kommandozeile, wenn das Skript LENSDUMP.DEB und der ausgelesene Objektivinhalt in LENSDUMP.BIN im aktuellen Verzeichnis vorliegen (und DEBUG über %PATH% gefunden werden kann):

DEBUG < LENSDUMP.DEB

Nach dem Aufruf sind die Daten in der Datei LENSDUMP.BIN in das richtige Format umgewandelt. Außerdem gibt das Skript die ersten 45 Bytes der Datei zur Kontrolle in einer Vorher-/Nachher-Darstellung auf dem Bildschirm aus.

Die Vorgehensweise ist vollständig bijektiv, d.h. ein zweimaliger Aufruf des Skripts wandelt die Daten wieder in die ursprüngliche Form um.

Viele Grüße,

Matthias