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

moin, ZITAT(Integral @ 2010-04-15, 11:45) nochmal zwei Photos davon:
>>> Blickwinkel 01 =>
[attachment=7593ICT0082.jpg]
>>> Blickwinkel 02 =>
[attachment=7594ICT0080.jpg]
meine "Vermutung" =>
* das "Flexible PC board" ist in beiden Fällen das selbe ( physisch und elektrisch)
* das LENS-ROM ist in beiden Fällen das selbe ( elektrisch)
vor dem Verlöten des LENS-ROM in das 200/2.8 HS APO G wird PIN-8 einfach "brutal" mit einer Zange abgezwickt[/quote]
ok.
Wenn man weiss, dass der Pin abgekniffen ist, kann man es auch auf dem 1.Bild sehen.

Auf eine solche Lösung wäre ich aber nicht gekommen, sowas macht man normalerweise nur beim Basteln auf dem Küchentisch.
Ist ja wie im Labor von Daniel D.: "dem Inschenjör ist nix zu schwör..."
(Liebe Ingenieure, bitte nicht beleidigt sein! Pragmatische Lösungen sind nicht die schlechtesten, aber doch manchmal sehr überraschend)

Danke für die Aufklärung!
gruesze, thomas

ZITAT(matthiaspaul @ 2010-04-15, 13:01) Deiner Beschreibung nach ist der 330R-Widerstand bei der Dynax 3000i aber in Serie mit dem Transistorschalter, das ist offenbar auch bei der 7000 AF so (Wert unbekannt). Bei der 9000 AF hingegen war ein solcher Widerstand meinen alten Aufzeichnungen zufolge nicht vorhanden, ich müßte das nochmal im Service Manual nachschauen.

Bei der Dynax 500si Super, Dynax 7 und Dynax 9 existiert ein Widerstand (unbekannter Größe) hingegen parallel zur Schaltstrecke des Transistor, dafür gibt es keinen zusätzlichen Serienwiderstand. Ich könnte mir vorstellen, daß dieser Widerstand höherohmiger (als 330R) ist, da im Standby ja nur ein verschwindend geringer Strom fließen muß. Im Normalbetrieb ist dann der Transistor geschlossen, und es besteht eine vergleichsweise niederohmige Verbindung (aber eine Kurzschlußstrombegrenzung hinge dann, wenn überhaupt, nur noch vom Transistor ab).[/quote]
ich konnte die Strom-Quelle des Transistors nicht finden, er hängt jedenfalls nicht direkt an den 5V des Schaltreglers, den ich gefunden habe. Es kann weitere geben. Die Schaltung zieht sich in die Tiefen des Gehäuses hinein, das habe ich nicht zerlegt. Ich habe nur den Deckel runter. Man kann den Strombegrenzer ja auch vor dem T einschleifen.
Der Test zeigt aber, dass 330 Ohm in der 5V-Zuleitung des LensROMs keinesfalls stören, von daher werde ich die dort auf jeden Falle bei allen weiteren Schaltungsversuchen beibehalten.

Eine Bitte an alle Bastler:
Im Gegensatz zu einer laufenden Kamera, welche das Objektivbajonett elektrisch abschaltet, sobald die Entriegelungstaste gedrückt ist und/oder der Verriegelungsstift nicht vorstehen kann (also beim Eindrehen eines Objektivs), liegen bei den hier beschriebenen Schaltungen Spannungen auch beim Ansetzen und Eindrehen eines Objektives an!
Das ist kein zulässiger Zustand.
Daher immer Stromversorgung (serielle Schnittstelle oder ParPort Versorgungsspannung) trennen, bevor ein Objektiv angesetzt oder abgenommen wird.
Das gilt nicht, wenn die Objektivkontakte "ohne Drehen" angesetzt werden.

ZITATDie Ursache für Timing-Probleme ohne Oszi zu finden, ist ziemlich schwierig...[/quote]
es bräuchte mindestens einen Zweistrahler, wenn Flankenprobleme reinspielen. Besser wäre ein LA mit mindestens 4 Kanälen ...

ZITATKann man bei PonyProg den Takt einstellen? Vielleicht würde es helfen, den zu vermindern? Kann man innerhalb des Zeitrahmens den Zeitpunkt des Sampelns noch durch ein Software-Delay beeinflussen? [...][/quote]
nein, nur indirekt duch Auswahl verschiedener Bausteine. Aber die verhalten sich praktisch alle gleich, mit alten Objektiven kann man jedes SPI-EEPROM wählen und es funktioniert. Die ROMs wiederholen ihren Datensatz solange, wie SCK anliegt, in einer Endlosschleife.
An einer offenen Schnittstelle (Serielle offen, gar nix dran, kein Adapter) oder mit Adapter ohne Objektiv kommt 0xFF (nicht unerwartet, man kann die Polarität umschalten, dann kommt halt 0x00).
Bei neuen Objektiven sind etwa 1-2 Byte/32Byte ungleich 0xFF bei Auswahl des kleinsten SPI-EEPROMs 25010. Diese sind nicht willkürlich verteilt, es gibt ein "Muster", aber die Inhalte sind offensichtlich falsch und welche der Bytes bei einem Lauf "gelesen" werden streut stark.
Ab "25020" kommen zuverlässig nur 0xFF, also Leerwerte.

Ich sehe mir die PonyProg-Sourcen an, dann kann ich mehr dazu sagen.

Wenn das nicht geht und auch Wolfram mit dem ParPort-Adapter keinen Erfolg hat, versuche ich es doch mit dem CBM. Ist der zu lahm, muss ich halt die Amiga wieder ausmotten oder gleich die pdp11 nehmen (wo habe ich nur den WireWrap-Fädler hingepackt?). Wird dann der absolut kleinste Ausleseadapter der Welt
PCs sind halt, gerade unter Win32, viel zu aufwändig bzgl. direkter Zugriffe auf die hardware, und es gibt auch keine wirklich dafür geeignete Schnittstelle. Seriell ala PonyProg ist ein übler Hack; und ParPort ist extrem empfindlich und schneller hinüber als man schauen kann, wenn denn überhaupt noch einer auf dem Board ist. Dazu war und ist mir die lowlevel-Programmierung der x86-Architektur immer fremd gewesen, ich komme diesbezüglich halt aus einer anderen Ecke.
Kommerzielle Programmieradapter, mit denen das sicher alles gar kein Problem ist, kosten Minimum ab ca. 600€, soviel möchte ich nicht investieren.

gruesze, thomas

Schönen Abend!

ZITAT(ddd @ 2010-04-15, 11:52) 1. Wolfram, was steht auf dem Chip des ParPort-Adapters? Auf dem ibä-Foto oder dem Foto auf der Website des Anbieters kann ich es nicht lesen.
Ich habe am SerPort nix verstellt, nur SPI und Typ 25080 (es gehen bei den alten aber alle Typen von 25010-25256).
Ob das auch für den ParPort richtig ist, kann ich Dir erst sagen, wenn ich den Chip auf dem Adapter und die Schaltung desselben kenne.[/quote]

Der Chip ist ein 74HC244.

Im Anhang habe ichnoch 2 Bilder des Paralleln Prog Adaoters.

Gruß,
Wolfram

moin,

man kann das Timing von PonyProg doch beeinflussen, zumindest in ein paar Stufen. Im source habe ich dies gefunden:

SPI-Speed (spi-bus.cpp):
 
TURBO       shot_delay=0
FAST        shot_delay=1
NORMAL      shot_delay=5
SLOW        shot_delay=10
VERYSLOW    shot_delay=80
ULTRASLOW   shot_delay=1000
 

und dann in der PONYPROG200.INI die Zeile SPIBusSpeed=NORMAL

Rumgetestet, hier die Ergebnisse:

TURBO       old 25080 ok    new 25080 und höher nicht, darunter siehe *1)
FAST        vergessen zu messen...
NORMAL      old alle  ok    new 25080 und höher nicht, darunter siehe *3)
SLOW        old 25080 ok    new 25080 und höher nicht, darunter siehe *4)
VERYSLOW    old 25080 ok    new 25080 und höher nicht, darunter siehe *5)
ULTRASLOW   fkt. nicht, wird auf NORMAL zurückgesetzt
 
1)
25010: abwechselnd 0xFF und 0x00, manchmal fehlt ein 0x00, Versatz des Leserasters
25020: abwechselnd 0xFF und 0x00, selten ein 0x00 als 0xFF oder 0x07 oder 0x10
25040: abwechselnd 0xFF und 0x00, in Einzelfällen statt 0x00 ein 0xFF
3)
25010: 0xFF, alle 10 Bytes 0x12, vereinzelt andere Bytes, auch sonst
25020: 0xFF, alle 20 Bytes oft 0x12, andere Bytes incl. gelegentlich 0xFF
25040: 0xFF, meist alle 30 Byte oft 0x12, andere Bytes, auch sonst gelegentlich!=0xFF
4)
25010: abwechselnd 0xFF und 0x10
25020: abwechselnd 0xFF und 0x10
25040: abwechselnd 0xFF und 0x10, selten ein 0x10 als 0x20 oder 0x7F oder 0x90
5)
25010: abwechselnd 0xFF und 0x20, manchmal Leserasterversatz durch 2x 0x20 hintereinander
25020: abwechselnd 0xFF und 0x20, öfter Leserasterversatz durch 2x 0x20 hintereinander
25040: abwechselnd 0xFF und 0x20, öfter Leserasterversatz durch 2x 0x20 hintereinander
 

Ich weiß, dass die SPI-EEPROM-Typen 25010..25040 anders behandelt werden als die Typen ab 25080 (diese sind deutlich schneller bei gleichem SPIBusSpeed, aber bisher habe ich nur dies im source gefunden:

eeptypes.h:
 
#define E250XX  0x06
// Sub types
#define E25000  0x060000
#define E25010  0x060001
#define E25020  0x060002
#define E25040  0x060004
 
#define E25XXX  0x09
// Sub types
#define E25XX0  0x090000
#define E25080  0x090004
#define E25160  0x090008
#define E25320  0x090010
#define E25640  0x090020
#define E25128  0x090040
#define E25256  0x090080
 

C++ ist nun gar nicht meine Welt, ANSI-C no problem. Ich habe noch nicht durchschaut, wo die unterschiedlichen Typengruppen nun in Parameter für das jeweilige Timing umgesetzt werden.

Auf jeden Fall ist jetzt klar, dass es ein Timing-Problem ist.

Und ich hatte schon MC1488/89 und 74HC244 aus den Tiefen meiner Bastelvorräte rausgesucht, um die Pegelfehler oder Flankensauereien zu bereinigen.

Schluss für heute, thomas

@Wolfram: habe den ParPort-Schaltplan von Lancos schon kurz angeschaut, weitere Analyse davon und Vergleich mit dem Kanda-Adpater von Dir folgt!

moin,

es gibt Neuigkeiten. Leider noch nicht die ultimative Lösung, aber neue Hilfsmittel auf dem Weg dahin:

So sieht das SPI-Protokoll zwischen PonyProg2000 (ein SPI-EEPROM 25080 lesend) via Serieller Schnittstelle + SI-base (+vier Widerstände) und dem minolta AF-Zoom 24-50 f/4.0 aus
[attachment=7603:SPI25080..._24hires.gif]
Auf Kanal 1 des LogicAnalysers liegt der Takt (SCK), auf Kanal 2 die Daten (MISO) und auf Kanal 3 Slave Select (SS), dieser dient auch als Trigger.

Hier ein Ausschnitt der ersten Bytes inclusive Interpretation:
[attachment=7604:SPI25080...s_detail.gif]

nur zur Erinnerung:

maf-2450f40@24 (PonyProg2000, inverse Bitreihenfolge)
01 94 0A 00 84 88 88 E4 94 00 DF 2A 6F 00 60 7A 00 05 00 00 00 00 00 00 00 00 00 00 00 00 B7 C6
 

Wie man leicht sieht, kommt zuerst ein Byte 0xFF als Startbyte (dies gehört zum Protokoll, dient vmtl. der Synchronisation), und dann der bekannte Inhalt des LensROMs in der Bitreihenfolge, wie wir es bereits von PonyProg2000 kennen.
SPI ist wirklich simpelst...

Der LA schafft nur ca. 1,25µs Auflösung, es sieht so aus, als ob die bits auf der steigenden Flanke des Taktes übergeben werden. Gelegentlich kommt die bit-Flanke um ein jiffy verzögert.
D.h. dass das LensROM in etwa 1µs nach der Flanke das bit rausgeschieben muss.
Der Takt liegt bei etwa 50 kHz (15-17 jiffys = 18,6-21,1µs Periodendauer).

Schluss für heute, es ist spät geworden.

gruesze, thomas

ZITAT(ddd @ 2010-04-18, 3:19) Wie man leicht sieht, kommt zuerst ein Byte 0xFF als Startbyte (dies gehört zum Protokoll, dient vmtl. der Synchronisation)[/quote]
Das erste vom Objektiv übertragene Byte soll (angeblich) ein "spezielles" Muster haben, anhand dessen die Kamera erkennen kann, ob überhaupt ein geeignetes Objektiv angeschlossen ist. Wenn es nicht den erwarteten Wert hat, soll die Kamera das Objektiv ignorieren und auf Arbeitsblendenmessung umschalten - so war es jedenfalls ursprünglich mal gedacht.

In verschiedenen Quellen (die nicht im Detail stimmen müssen) findet sich dafür der Wert 01010101b = 55h, der sich - neben einer Funktion als Magic - auch für eine echte Taktsynchronisation eignen würde. Aber da die Bitclock in der Kamera meines Wissens sowieso von der Hardware generiert wird und nicht - wie bei PonyProg - in der Software (wenn auch vielleicht mit Hardware-Timer-Unterstützung), würde es das in der Realität beobachtete 11111111b = FFh für eine reine presence detection genausogut tun.
ZITATes sieht so aus, als ob die bits auf der steigenden Flanke des Taktes übergeben werden.[/quote]
Ja, Deinem Log zufolge legt das Objektiv-ROM als Slave neue Daten offenbar mit der steigenden Taktflanke von "L3" (SCLK) an "L1" (MISO) an. Diese Daten müßten dann vom Master (PonyProg) mit der fallenden Taktflanke von SCLK gelesen werden (das ist aber nicht grundsätzlich bei allen Devices so). Das deutet auf SPI-Mode 2 (CPOL=1, CPHA=0) oder SPI-Mode 1 (CPOL=0, CPHA=1) hin...

Wie wir dem Log entnehmen können, legt das Objektiv seine Daten bereits in dem Moment an, in dem SS auf Low geht. Das spricht für CPHA=0, denn nur dann würden die Daten schon mit der ersten Clock-Flanke übernommen. In Verbindung mit CPOL=1 aus obiger Beobachtung würde das für SPI-Mode 2 stehen. So weit, so gut...

Der Ruhezustand der PonyProg-Clock ist Low, sprich, die Clock ist high-aktiv. Das gilt eigentlich nur für CPOL=0, was dann unter Einbeziehung der obigen Beobachtung in Bezug auf die Zustandsänderungen auf der MISO-Leitung für CPHA=1 und damit für SPI-Mode 1 sprechen würde.

Wie PonyProg selbst mit seiner MOSI-Leitung umgeht und wann es MISO sampelt, können wir oben nicht sehen (wäre vielleicht noch interessant, die MOSI-Leitung in die Analyse aufzunehmen), aber die Atmel AT25010A/20A/40A und AT25080A/160A/320A/640A EEPROMs unterstützen z.B. nur die SPI-Modes 0 und 3. Wegen CPOL=0 oben können wir wohl davon ausgehen, daß PonyProg für die Kommunikation mit den gängigen SPI-EEPROMs Modus 0 (CPOL=0, CPHA=0) erwartet. Kann man da in PonyProg diesbezüglich noch etwas einstellen?

Letztlich ist für uns nicht relevant, was PonyProg macht, sondern welches Verhalten unser Objektiv-ROM zeigt. Deutet das nicht darauf hin, daß PonyProg mit falscher Clock-Polarität in Bezug auf unser Objektiv-ROM arbeitet, also eigentlich Idle-High und damit low-aktiv sein müßte?

Eine weitere Beobachtung: PonyProg hält "L4" für die gesamte Dauer der Übertragung auf Low. Das ist ja im Rahmen des SPI-Protokolls nicht notwendigerweise so, wird aber in unserem Falle benötigt, da der Adreßzeiger im Objektiv-ROM sonst für eine neue Übertragung wohl wieder auf +00h zurückspringt, ist also genau richtig hier. Aber was ist da ganz am Ende nach 32 übertragenen Bytes passiert? Stammt dieser Peak auf "L4" von PonyProg oder vom Objektiv? (Zumindest ab der xi-Generation kann das Objektiv über diese Leitung in bestimmten Situationen auch einen Interrupt an die Kamera auslösen, aber auch der wäre meines Wissens low-aktiv.)

Zuguterletzt sehen wir auch, daß der von PonyProg an "L3" angelegte Takt ziemlich unregelmäßig arbeitet. Das ist für SPI in der Regel kein Problem, aber damit fällt die Idee flach, durch elektrisches Verzögern des Takts um fast eine ganze Periodendauerlänge das Objektiv-ROM letztlich bereits knapp vor dem Moment auf die Flanke reagieren zu lassen, zu dem PonyProg die eigentlich zugehörige Flanke überhaupt erst erzeugt und so ein möglicherweise zu knappes PonyProg-Timing in Bezug auf das Sampeln der "L1"-(MISO)-Leitung wieder in den grünen Bereich zu schieben. Davon abgesehen dürften solche Zero-Delay-Maßnahmen bei Taktfrequenzen im Kilohertzbereich noch überhaupt nicht notwendig sein.
ZITATDer Takt liegt bei etwa 50 kHz (15-17 jiffys = 18,6-21,1µs Periodendauer).[/quote]
Sehr interessant wäre jetzt, die Kommunikation zwischen Objektiv und Kamera an einer Kamera zu beobachten (z.B. bei offener Kamera oder mit einem modifizierten AF-Zwischenring), nicht abgekoppelt an einem PC mit PonyProg. Dann wüßten wir, mit welcher Taktrate das Protokoll in der Realität läuft ("crazyplato" sprach mal von etwa 100 kHz) und auch, ob es noch weitere Besonderheiten gibt, die wir bisher nicht beachtet haben.

Viele Grüße,

Matthias

moin, ZITAT(matthiaspaul @ 2010-04-18, 16:54) Das erste vom Objektiv übertragene Byte soll (angeblich) ein "spezielles" Muster haben, ...
Aber da die Bitclock in der Kamera meines Wissens sowieso von der Hardware generiert wird und nicht - wie bei PonyProg - in der Software (wenn auch vielleicht mit Hardware-Timer-Unterstützung), würde es das in der Realität beobachtete 11111111b = FFh für eine reine presence detection genausogut tun.[/quote]
ok, ich habe die SPI-spec noch nicht gelesen und einfach mal angenommen, dass das 0xFF zum Protokoll gehört.
Immerhin sendet das LensROM dieses 0xFF nur beim ersten Mal, während es die Nutzdaten solange in der Endlosschleife ausgibt, wie SS+SCK anliegen.

Wir dürfen auch weiterhin nicht davon ausgehen, dass es sich hier um normgerechtes SPI handelt. Es ist eher ein SPI-ähnliches proprietäres Protokoll.

ZITATEine weitere Beobachung: PonyProg hält "L4" für die gesamte Dauer der Übertragung auf Low. Das ist ja im Rahmen des SPI-Protokolls nicht notwendigerweise so, wird aber in unserem Falle benötigt, da der Adreßzeiger im Objektiv-ROM sonst für eine neue Übertragung wohl wieder auf +00h zurückspringt, ist also genau richtig hier. Aber was ist da ganz am Ende nach 32 übertragenen Bytes passiert? Stammt dieser Peak auf "L4" von PonyProg oder vom Objektiv? (Zumindest ab der xi-Generation kann das Objektiv über diese Leitung in bestimmten Situationen auch einen Interrupt an die Kamera auslösen, aber auch der wäre meines Wissens low-aktiv.)[/quote]
Es werden hier insgesamt nicht nur 32 Byte, sondern 1024 Byte übertragen (ein 25080 hat 8kBit). Der L4-Peak ist ein Artefakt von PonyProg: zu jedem Zeitpunkt muss zur Speisung der parasitären Spannungsversorgung ein Signal high sein. Zumindest wird darauf im source hingewiesen und auf den dadurch erzeugten Dreckeffekt.

ZITATZuguterletzt sehen wir auch, daß der von PonyProg an "L3" angelegte Takt ziemlich unregelmäßig arbeitet. ...
Sehr interessant wäre jetzt, die Kommunikation zwischen Objektiv und Kamera an einer Kamera zu beobachten (z.B. bei offener Kamera oder mit einem modifizierten AF-Zwischenring), nicht abgekoppelt an einem PC mit PonyProg. Dann wüßten wir, mit welcher Taktrate das Protokoll in der Realität läuft ("crazyplato" sprach mal von etwa 100 kHz).[/quote]
ja, und wie stabil der Takt meines "LogicAnalysers" ist, weiß ich auch nicht...
[attachment=7609:LA_LensROM_k.jpg]
Ich zeige es ja ungern, aber mein Ziel ist es, dass Ganze mit Minimalmethoden aufzudröseln. Es ist Technik der späten 1970 bis frühen 1980er Jahre, damit kenne ich mich einigermaßen aus. Seither konnte aus Kompatibilitätsgründen nichts Grundsätzliches daran geändert werden. Ich möchte erreichen, dass weitere Bastler es versuchen; der Aufwand an Mitteln und Gerät ist sehr überschaubar. Ich habe leider nicht die Möglichkeit, bei meinem AG mal eben einen echten LA oder ein LeCroy-DSO auszuleihen; und die allerwenigsen dürften über solche Mittel verfügen.
Sobald das hier leidlich funktioniert, steht das Abgreifen der Kommunikation zwischen Kamera und Objektiv an:
Nur so kann das D-Protokoll oder (Fernziel) das SSM-Protokoll analysiert werden. Das xi-Protokoll finde ich wenig spannend, da es vollständig obsolet ist. Aber unmöglich wäre auch das nicht.
Ich werde dazu gelegentlich eine Dynax 5 zum Schlachten besorgen. Es wäre nett, wenn alle hier Interessierten an gegebener Stelle in den nächsten Tagen mal die Füße stillhalten

moin,

weitere Test haben ergeben, dass weder PonyProg noch die LensROMs ein normkonformes SPI (wie Matthias es beschrieben hat) verwenden:
DT1870@35mm ausgelesen mit PonyProg:SPI25080. Das globale Timing sieht genauso aus wie beim oben gezeigten AF24-50/4.0.
Aber im Detail sieht man die Ursache des scheinbaren Lesefehlers! PonyProg zeigt an, was es liest. Nur 1 bits ...
[attachment=7613:SPI25080...s_detail.gif]
So sieht es aus, wenn man das DT1870 als SPI25010 ausliest:
[attachment=7614:SPI25010...0_35pony.gif]
[attachment=7615:SPI25010..._35hires.gif]
[attachment=7616:SPI25010...s_detail.gif]

Wie ich aus den sourcen von PonyProg weiß, werden die SPI-EEPROMs 25010, 25020 und 25040 anders gehandhabt als alle SPI-EEPROMs ab dem 25080.
Welche Unterschiede bestehen, konnte ich noch nicht erkennen, wo genau im source die Definition der Protokollvarianten versteckt ist, habe ich noch nicht gefunden.

Ich habe übrigens auch mit dem AF24-50/4.0 bei SPI25010 Lesefehler (es wird nur 0x94 gelesen, eines der Bytes welche im Datensatz vorkommen).
Vorher war das nicht so; dieser Fehler tritt erst auf, nachdem ich mit der Timingeinstellung im ini-File herumgespielt habe.
Natürlich habe ich alles auf die Standardwerte zurückgesetzt! Und ich habe das PonyProg auch nicht neu kompiliert...

Es führt also kein Weg am Belauschen der Kommunikation einer echten Kamera mit den Objektiven herum.

Darauf basierend kann man dann einen Simpel-Adapter zum Auslesen der LensROMs mit einem Laptop basteln und ein Minimlaprogramm, welches diesen korrekt bedient.
Warum? Damit es leicht möglich ist, viele Objektivtypen auszulesen und einen vollständigen Überblick über die Funktionen und deren Implementierung zu bekommen.

Ausserdem muss der geplante Objektivsimulator das Protokoll korrekt so fahren, wie es die Kameras gern möchten.
Nur dann ist ein Rechippen möglich und die Basis für weitergehende Basteleien vorhanden.

gruesze, thomas

moin Wolfram, ZITAT(riw61 @ 2010-04-15, 23:09) Im Anhang habe ich noch 2 Bilder des Paralleln Prog Adaoters.[/quote]
ich habe mir das angesehen. Die Schaltung muss von vor 1995 stammen...

Gegen den 74HC244 ist nix einzuwenden, auf dem basiert auch mein epochemachender LogicAnalyzer.
Lt. Datenblatt und real tut der, was er soll. Wird seit Ende der 1980er Jahre auf fast jeder Steckkarte und jedem Motherboard, nicht nur bei PCs, verwendet.

Aber die Schaltung ist noch dämlicher als die des SerPort: 4bit Ausgabe und 1bit Rückkanal, 2bit werden für den Treiber-OE und 2bit für die Rückführung der Steuersignale des Centronics-Ports selbst verbraten.
Sonst ist das Ganze ultraschlicht, immerhin sind Längswiderstände (1k), Schutzdiode gegen Gegenspannung und Blockkondensator vorhanden. Der einzige querliegende R hat 100k und dient als Pullup für den Eingang des Rückkanals.

Nach meinen jetzigen Erfahrungen sollte das elektrisch/pegelmäßig/flankensteilheitsmäßig usw. problemlos sein bei den hier benötigten und/oder möglichen Taktfrequenzen bis maximal ca. 200kHz.

Aber PonyProg macht irgendeinen Murks beim Protokoll, und die LensROMs halten sich auch nicht an die (1980 noch gar nicht existierende?) Norm.

Weiteres folgt...

gruesze, thomas

moin,

weiteres Rumbasteln zeigte folgende Ergebnisse:

- PonyProg kann die Polarität der Signale einzeln invertieren. SCK invertiert bringt aber auch nix, statt 0xFF wird dann 0x00 gelesen und die LA-logs sehen bis auf die vertauschte Polarität von SCK identisch aus.

- meine 3000i scheint defekt zu sein (ich hatte sie als Bajonettspender besorgt, die Funktion war mir egal und ich habe diese nicht getestet).
Egal ob mit 5,2V oder 6,4V betrieben, PowerOn beim Anlegen der Versorgung geschlossen oder offen und erst nach dem Anlegen der Batteriespannung geschaltet, es rührt sich nix. Die Versorgungsspannungen sind ok, es werden die 4,9V und 13,2V erzeugt, egal welche der beiden Eingangsspannungen an den Batterieklemmen anliegt (sicherheitshalber mit echten Batterien versucht, eine 2CR5 wollte ich dafür aber nicht kaufen). Es liegen übrigens beide Spannungen an, sobald die Batteriespannung angelegt wird. Der PowerOn-Schalter schaltet in Stellung Lock nur einen Teil der GND-Plane weg (richtig gelesen, es wird GND geschaltet!
Die Bajonettklemmen stehen immer unter Spannung, auch wenn der Entriegelungsknopf gedrückt wird und/oder der PowerOn auf Lock steht. An L1, L2 und L3 liegen (hochomig) 4,9V an, L4 und L5 sind auf GND. Das ist bei den aktuellen Modellen anders (besser) gelöst. Jedenfalls sind die Objektive darauf ausgelegt, hot angeschlossen zu werden, meine diesbezüglichen Warnungen sind bei Kurzschlussstrombegrenzten und mit korrekten Spannungen versorgten Adaptern hinfällig. Die Pin-Anordnung eignet sich nach genauerer Betrachtung halt doch dafür.

Eigentlich wollte ich das Protokoll zwischen 3000i und LensROM belauschen, aber das geht leider nicht. Sobald ich eine Dynax 5 oder Dynax 60 habe, geht's es damit weiter.

Wer eine mechanisch defekte hat oder seine heile spendet, ich habe Interesse! Nicht umsonst, aber allzuviel zahle ich nicht (zustandsabhängig).

gruesze, thomas

Edith sagt: wer zu blöde ist, wird mit Unsinn nicht unter drei Tagen bestraft!

moin,

meine 3000i funktioniert korrekt, nur ich war zu blöd:

Als ich bei der Vorbereitung auf das Zerlegen der zu beschaffenden Dynax 5 deren SM studiert habe, fiel mir der "Battery Inserted Switch" auf.
Ich habe daraufhin das Batteriefach der 3000i nochmal genauer inspiziert, und nur mit dem Wissen um die Existenz eines solchen Schalters nach gründlicher Suche einen winzigen Plastikstift in der Ecke neben den Batteriekontakten entdeckt.

Beim Einschalten der Kamera ist folgender Ablauf vorgesehen/einzuhalten:
Batteriespannung anlegen, Batterie-inserted-switch aktivieren, Power-Schalter von Lock auf On stellen. Batteriespannung ist bei mir 5,1V (4xAA Eneloop), gemessen unter Last (5,2V Leerlauf).

Dann funktioniert das Gehäuse, auch mit meinem eingeschleiften Kabelverhau, Abgriff L1..L5 am MainFlexi und Anschluss L1..L5 am Objektivkontakt-Flexi. Es liegen jetzt statt der direkten Lötverbindung insgesamt ca. 15cm Flachbandkabel, 6 Kontaktebenen und 4 Lötstelle zusätzlich im Leitweg zum Objektiv; ausserdem der Abgriff für den LA (Eingang PC74HC244P@3,4V direkt) mit weiteren ca. 10cm Schaltdraht und 3 Kontaktebenen auf Steckplatine. Erstaunlicherweise funktioniert alles, der LA kann die Kommunikation problemlos mitloggen, das Objektiv fokussiert und die Kamera löst aus (ohne Film ).

Nebenbefund: An den Objektivkontakten L1, L2 und L4 liegen bei korrekt spannungsversorgter Kamera (also mit aktiviertem BattInsSw) ca. 2,7V an, L3 und L5 liegen auf GND; unabhängig von der Stellung des Power-Schalters. Diese hochohmig gemessene Spannung scheint ein Artefakt zu sein (nicht unter Belastung gemessen)!
Auch beim Drücken der Objektivverriegelung ändern diese sich nicht, aber beim Loslassen wird L2 kurz auf 4,9V angehoben (vmtl., das DMM ist zu träge und steigt auf 3,irgendwas und fällt schon wieder ab): ein neu angeschlossenes Objektiv wird also sofort abgefragt. Sonst wird die Spannung an L2 nur beim Andrücken des Auslösers hochgeschaltet und folglich das Objektiv ausgelesen. Die Kontakte L6..L8 habe ich nicht, die existieren erst ab den xi-Modellen.

Deshalb suche ich auch weiterhin eine (am liebsten) Dynax 5, ich nehme auch eine 60 oder 5D. Eine 7 oder höher möchte ich nicht ohne Not aufmachen, eine mechanisch defekte (Verschluss zerdellt, Spiegel abgebrochen, Filmführung hinüber usw.) nehme ich natürlich gern. Angebote oder Hinweise auf solche bitte per PM.

Genug der Vorrede, jetzt wird es ernst:
Angeschlossen habe ich das SAL1870 aka DT 18-70mm f/3.5-5.6 in der Sony-Version.
Die Frequenz des Taktsignals beträgt ca. 32kHz (12..13 jiffys @ 1,25µs Auflösung), die Polarität ist positiv genau wie die Polarität der Daten (MISO), welche bei fallender Flanke des Taktsignals gültig sind:
[attachment=7623:3000i_1870_18oo.gif]
Dies ist der komplette Ablauf der Kommunikation zwischen Gehäuse und Objektiv beim ersten Andrücken des Auslösers. Die fallende SS-Flanke fehlt, sie ist der Trigger und liegt -1 jiffy (-1,25µs) vor dem ersten Sample.

Wie man aber leicht sieht, ist das niemals standardisierte SPI hier bestenfalls eine Ideenvorlage oder das zugrunde liegende Prinzip. Schon die bit-Order ist "falsch" (lsb first).
Ich habe bisher nur die ersten Bytes händisch rekonstruiert, ein Auswerteproggi für die Sample-Dumps muss ich noch schreiben. Daher hier jetzt eine mehr qualitative Beschreibung des Ablaufes:

SS geht low (aktiv), SCK taktet 8 Zyklen, ein Byte wird eingelesen. Dann folgt eine Pause von ca. 390µs und das nächste Byte wird mittels 8 Taktzyklen eingelesen. Dieses Muster wird für 33 Byte durchgeführt, dann geht SS high (inaktiv) und SCK führt 8 weitere 8-Taktzyklenbursts(Bytes) durch, MISO bleibt aber low. Dies sind keine Daten! Nach einer langen Pause von ca. 34,5ms folgt ein zweiter Datenblock von 18 Byte nach demselben Schema. Eine zweite lange Pause von ca. 34,5ms folgt und zuletzt werden bei inaktivem SS zwei Bytes eingelesen und mit einem abgesetzten 6 byte-burst-Zyklus ohne Daten die Übertragung abgeschlossen. Hier der Anfang im Detail:
[attachment=7625:3000i_18...o_detail.gif]

Der erste Block ist noch klar, damit werden die bei RomRev 0x80 und 0x81/32 üblichen 32 Byte plus das erste Signatur- oder Syncbyte 0xFF übertragen.
Aber dann? 33-1+18 ergibt alles, aber niemals 45. Und was sind die beiden letzten Byte?
Zusätzlich verändert sich bei mehrmaligem Andrücken des Auslösers kurz hintereinander das Muster.
Die LensROMs können also keine reinen ROMs sein, sie müssen irgendwelche Latches enthalten.
Ich bin jetzt zu müde/faul, um den ganzen Satz von Hand auszuwerten. Auf jeden Fall ist das, was bisher bekannt war und z.B. von vasimv und crazyplato auf dyxum gepostet wurde, bestenfalls die halbe Wahrheit.
Ein Auslesen der LensROMs mit einem simplen SPI-Ablauf liefert niemals den 2. Datenblock und auf gar-nie-nimmer-wieauch-keinen Fall die beiden letzten Bytes! Alle bisher geposteten Daten sind ungültig.

gruesze, thomas

ps: als ich dem Bundesfinanzminister nach dem ersten erfolgreichen Auslesen vor der Tür ein Rauchopfer brachte, hatte ich eine interessante Begegnung: eine große rotbraune Katze kam um die Hausecke (wir haben eine schwarz-weiß gefleckte Gartenkatze), schaute mich kurz an, leicht säuerlich/beleidigt; denn er/sie war ein Rotfuchs. Schnürte dann gemächlich den Gartenweg entlang und bog ins Dorf ab. Leider hatte ich keine Kamera in der Hand...

moin,

hier jetzt die Doku zum LA (Logic Analyzer) in der Minimalversion für Nachbau- und Mitmachinteressierte:

Werkzeugliste:
Schraubendreher Philips Nr.0 (zum Aufmachen der Kamera)
Fein-Lötkolben 16W oder Lötstation
Elektroniklot dünn
Elektronik-Seitenschneider
scharfes Messer oder Abisolierzange
DigitalMultimeter für Kontrollmessungen
PC oder Laptop mit Parallelport und Windows 95/98/ME/NT4/2k/XP (Vista oder Win7 ?)
 

Bauteileliste:
IC 74HC244 (oder 74HC245, keinesfalls LS-Typ! HCT geht vmtl auch nicht!)
Kondensator 100nF Keramik (16V reicht)
Widerstand 1k/0,25W (Wert unkritisch, 10k gehen auch)
Schaltdraht, Schaltlitze und/oder Flachbandkabel (Reststücke reichen)
Schrumpfschlauch dünn oder Lochrasterplatine (Reststück 10x6 Loch reicht)
Parallelportkabel 25pin D-SUB male auf beliebig, mindestens 10adrig, Länge unkritisch bis 2m
Kameragehäuse A-Bajonett nach Belieben oder AF-Zwischenring
 

Das Kameragehäuse oder der AF-Zwischenring und das Parallelport-Kabel werden "geopfert"!

Mittels Flachbandkabel (oder unelegant Schaltlitze) 5/6-adrig die Signale L1(MISO), L2(Vdd=4,9V), L3(SCK), L4(SS), L5(GND) und ggfs. L6(MOSI) aus dem AF-Zwischenring oder dem Kameragehäuse herausführen. Objektivkontakt-Flexi ist immer an der linken (Blick durch den Sucher! vorderen Flanke des Sucherprismas angelötet, L1 ist immer oben, sicherheitshalber gegen die Kontaktpins messen. Zum Herankommen muss nur das Oberteil abgenommen werden, allerdings sind manche Schrauben etwas versteckt. Ggfs. im Service Manual nachsehen, auch das eines ähnlichen Gehäuses gibt nützliche Hinweise zum grundsätzlichen Aufbau. Die Flexis lassen sich recht gut löten und sind temperaturbeständig, allerdings halten sie keinen mechanischen Zug aus! Also das herausgeführte Kabel zugentlasten... Zum leichteren Anlöten vorher die Litzenenden verzinnen und einen winzigen Put Zinn auf dem Flexikontakt aufbringen. Achtung, das Flexi löst sich ggfs. vom Untergrund, also gegenhalten. Am besten die Kontakte einzeln auflöten und jeweils abkühlen lassen. Nach dem Verlöten unbedingt die Flussmittelreste entfernen, Lotspritzer/-perlen entfernen und auf Kurzschlüsse usw. sichtprüfen und messen. Welche Kontaktmethode am so hergestellten Abgriff benutzt wird, bleibt der Vorliebe des Nachbauers überlassen. Ich habe die Enden verzinnt und stecke auf einem Steckbrett zusammen, was ich brauche.

Das ParPort-Kabel wird zum LA umgebaut: Dazu den Centronics-Stecker entfernen, alle Adern abisolieren und durchmessen. Es gibt verschiedene Kabel, gute haben verdrillte Adernpaare + Doppelschirm, die meisten sind schlicht 18adrig+Schirm. Wir benötigen die Kontakte (Pin-Nr des D-SUB-Steckers zum PC) 1, 2, 3, 4, 5, 6, 7, 8, 9 und GND. Bei einfachen Kabeln sind die Pins 18..25 verbunden und auf GND, bei guten einzeln als Paar! Details siehe Wikipediaarallelport. Die Pins 2..9 sind die Datenleitungen bit 0..7 bzw. Kanal 1..8. Pin1 (Strobe) wird zur Spannungsversorgung des Treiber-ICs missbraucht, dieses ist "legal".
Je nach IC liegen die Ein- und Ausgänge der Treiber auf unterschiedlichen Pins, und auch die Selektierung unterscheidet sich etwas: 244 ist ein 2x4fach-Treiber, 245 ist ein 8fach-Bidirektionaler Bustreiber. Die einzelnen Treiber sind aber in beiden Bausteinen gleich! Die Pins 2..8 werden auf die Ausgänge der 8 Treiber geschaltet, deren Eingänge sind die probes (Kontakte zum Abgreifen der Signale). Die Chip-Select und Direction-Eingänge sind entsprechen gegen GND oder mittels 1k gegen Pin1=Vcc zu legen. Pin 1 kommt an Pin20=Vcc, GND an Pin10 und wird als GND-probe herausgeführt. Der Abblockkondenstor 100nF wird so kurz als möglich zwischen Pin10 und 20 des IC eingelötet. Das ganze kann man auf Lochraster aufbauen oder fliegend verdrahten, Schrumpfschlauch in diesem Falle nicht vergessen. Ich habe vor, das Ganze zum Universellen Kamera- und Objektivsimulator auszubauen. Dies geht nur mit dem 244, nicht mit dem 245. Daher würde ich den empfehlen; auch andere Treiber, die ausgangsseitig TTL machen, mit 3,0-3,5V Vcc auskommen, 5V-tolerante Eingänge haben und maximal 10mA verbraten, sind brauchbar.
Schaltplan für beide Varianten folgt, hänge ich hier noch ein.
[attachment=7632:uAsim1.gif]
edit: 1.Schaltplanversion eingehängt. Bitte die Rev. 0.1 beachten...
edit2: Alle unbenutzten Eingänge eines CMOS sind auf definierte Pegel zu legen, da offene (floatende) Eingänge zum Schwingen neigen. Unbedingt den 4.Kanal bei Nichtgebrauch auf GND legen!

Von dem Digitrace-Vorschlag, ein rein passives Kabel zu verwenden, rate ich dringendst ab!

Als Software kommt Digitrace von JWA Systems zum Einsatz: Anleitung und Download Digitrace
Zum Installieren sowohl "The new version comes as a setupper and contains some more files:" als auch "An upgrade is available: Digitrace_0_0_0_9.zip" herunterladen.
(Direkte links lege ich nicht, es ist auf der etwas unübersichtlichen Seite aber leicht zu finden)

setupper.exe ausführen und hinterher den Inhalt von Digitrace_0_0_0_9.zip in das Programmverzeichnis entpacken.
Dann den angelegten Start-Link von "Digitrac.exe" auf "Digitrace_0_0_0_9.exe" ändern und erst jetzt das Programm aufrufen.
Unter XP ist kein Neustart erforderlich, andere BS nicht getestet.

Digitrace ist absolut minimalistisch, es benutzt den ParPort als Eingang. Es ist nicht echtzeitig, d.h es werden erst alle Samples gelesen und dann angezeigt.
Das liegt vor allem an grundsätzlichen Limits der intel-Architektur: der ParPort wird über IO-Befehle angesprochen, diese benötigen selbst auf aktuellen GHz-Prozessoren ziemlich genau 1µs zur Ausführung (der linux-Kernel benutzt Lesezugriffe auf Port80 als recht genaue Warteschleife von 1µs Dauer, die anders kaum realisierbar wären). Da nach dem Lesen des ParPort noch das Byte weggeschrieben werden muss, ist die maximale Abtastfrequenz auf ca. 800MHz = 1,2µs Sampelabstand begrenzt, es können also Signale mit maximal 400kHz erkannt werden, sicher klappt es nur bis ca. 200kHz. Der Rechner sollte beim Gebracuh sonst idle sein! Win (egal welche Version) ist genausowenig wie linux/Unix echtzeitfähig. Ich habe mit dem Laptop typisch 1,25µs Auflösung, die Werte reichen von 1,22µs - 1,40µs. Die Auflösung wird beim Starten des Programms ermittelt und nicht mit den SampleDumps gespeichert, also vor jeder Messung das Programm neu starten und die Auflösung notieren.
Die Settings des Programms, die bei mir funktionieren:
- Trigger Channel = 3 (hier liegt L4(SS) an)
- Pre Trigger Delay = 2
- Samplesize = 1000000 (1 Mio, Maximum! = Messzeit 1,25s bei 1,25µs Auflösung = 1MByte SampleDump-Größe
- Divisor = 0
- InputPort (Hex) = 378 (richtig für LPT1).
- Die Farben sind mir egal...
- Granularity kann nicht geschrieben, nur gelesen werden. Dieser Wert wird bei jedem Start neu ermittelt, unbedingt notieren, wenn eine "genaue" Analyse in der Zeitdomäne durchgeführt werden soll! Die SampleDumps enthalten diesen Wert nicht!

Genauere Beschreibung des Messablaufes folgt hier per edit. Heute wohl nicht mehr, ich werde mir Benny Rebels Show antun.

gruesze, thomas

Hervorragend!

Natürlich drängen sich jetzt sofort schon wieder neue Fragen auf: ;-)

- Findet auch mit dem Minolta AF Zoom 4/24-50mm (1. Objektivgeneration, ROM?, 5 Kontakte) diese erweiterte Kommunikation an der Minolta Dynax 3000i statt, oder bleibt es dort beim bekannten "Minolta-SPI"? (Meine Vermutung: Es findet keine erweiterte Kommunikation statt.)

- Wie verhält sich das Sony Alpha DT 3,5-5,6/18-70mm (D-Objektiv, CPU, 8 Kontakte) an einer Kamera der ersten Generation (Minolta 9000AF, 7000AF, 5000AF) in Bezug auf das Protokoll?

- Was ist der genaue "Auslöser" für das Fehlverhalten des DT-Objektivs an PonyProg im Sinne von: Wieso sendet das Objektiv nicht wenigstens die ersten 32 Bytes, sondern, wie wir gesehen haben, stattdessen nur "1"-Sync-Impulse? War einfach der Takt zu hoch (die vormals kurzen High-Zeiten der Einsen könnten das nahelegen)? Fehlen dem Objektiv die Pausen zwischen den einzelnen Bytes, die bei der Dynax 3000i zu sehen sind (und möglicherweise so auch bei der AF-Serie existieren)? Ist der vermeindtliche High-Pegel der Eingänge irgendwie relevant für das Verhalten des Objektivs? Wenn wir die offenbar fehlenden zusätzlichen Randbedingungen isolieren und nachstellen können, würde uns das ermöglichen, wenigstens den ersten Datenblock mit den bisherigen Einfachstmitteln auszulesen - das liefert uns nicht alle Informationen, ist aber trotzdem keine vertane Arbeit, denn die bisher erhobenen Daten sind ja alles andere als wertlos. Daß wir mit dieser Methode nicht alle Daten moderner Objektive würden lesen können, war ja eigentlich schon vorher klar.

Viele Grüße,

Matthias

Hallo Thomas,

du hast eine große Portion Respekt von mir. Einfach super dein Ergebnis & Einsatz.

Leider bin ich mit dem Parallel-SPI Interface nicht weitergekommen. Ich kriege einfach keine Daten von einem Objektiv mit 5 Kontakten, trotz 5V Spannung. Ich tippe da entweder auf einen Kontaktfehler oder einen Fehler im Zusammenspiel mit dem Parallel-Port.
Ich geb aber nicht auf.

ZITAT(ddd @ 2010-04-22, 1:20) Nebenbefund: An den Objektivkontakten L1, L2 und L4 liegen bei korrekt spannungsversorgter Kamera (also mit aktiviertem BattInsSw) ca. 2,7V an, L3 und L5 liegen auf GND; unabhängig von der Stellung des Power-Schalters. Diese hochohmig gemessene Spannung scheint ein Artefakt zu sein (nicht unter Belastung gemessen)![/quote]

Interessante Erkenntnis mit den 2.7V ; das entspricht der Spannung die ich vor dem Auslöten der Widerstände gemessen habe. Das war also die Ruhespannung.

Das bist jetzt dabei die neueren Objektive zu untersuchen, aber wie sieht das mit einer "alten" Linse aus (5 Kontakte)? Passt da das Protokoll auch nicht oder sind die Lensroms einfach "unempfindlich".

Grüße, Wolfram

moin, ZITAT(riw61 @ 2010-04-22, 20:34) Ich geb aber nicht auf. [/quote]
das wäre auch Schade!
Dein ParPort-Programmieradapter wird aber noch gebraucht: zum Programmieren des Mikrokontrollers, welcher Dein defektes ROM ersetzen wird, ist der sehr wohl gut geeignet.

Erstmal gibt es jetzt wie gewünscht Daten eines alten Objektives.
Ich war ja erst mal froh, auch moderne Objektive auslesen zu können. Das zum Vergleich ein bereits "ausgelesenes" getraced werden muss war klar.

minolta AF 24mm f/2.8 1.Baureihe ("Ofenrohr", 5 Kontakte, keinerlei Schalter, kein Zoom, RomRev 0x80, S# 14117***
[attachment=7627:3000i_mA...o_oo_122.gif]
kompletter Trace
[attachment=7628:3000i_mA...122_det1.gif]
Ausschnitt 1. Datenblock
[attachment=7629:3000i_mA...122_det2.gif]
Ausschnitt 2. Datenblock
[attachment=7630:3000i_mA...122_det3.gif]
Ausschnitt 3. Datenblock
[attachment=7631:3000i_mA...122_det4.gif]
Ausschnitt 4. Datenblock

Die Bilder sind zu klein für eine händische Auswertung, aber jetzt zwei Dutzend Schnipsel hier einhängen erscheint mir nicht sinnvoll, siehe weiter unten.

Leider habe ich den 4. Datenblock bisher als Artefakt des Mehrfachandrückens des Auslösers interpretiert, er gehört aber klar zum Datensatz. Es ist ein Block mit nocheinmal 18+2 Byte, wobei das erste Byte jedes Blockes bis auf die 2Byte-er ein 0xFF Init/Magic/Sync-Byte ist. Die Auflösung der Ausschnitte ist unterschiedlich, es soll den Ablauf zeigen. Wir haben also einen 33Byte-Block, einen 18Byte Block, einen 2Byte Block ohne Init und einen 18Byte+2Byte-Block am Ende. Insgesamt werden also selbst bei RomRev 0x80 73Byte übertragen, wovon 3Byte Init ohne Inhalt sind und sich der 2. 18Byte-Block beim mAF24F28o als identisch mit dem 1. 18Byte-Block und den ersten 18 Byte des 33Byte-Blocks zeigt. Die beiden 2Byte-Blöcke sind verschieden! Es findet also ein Handshake über die drei Leitungen statt. Die Länge der Datensätze ist nicht in der RomRev oder den Inahlten kodiert, sondern wird mittels dieses Handshakes realisiert (Vermutung! zum Beweis fehlt mir eventuell ein 0x81/45Byte-Objektiv, ich muss erst noch meine weiteren auslesen).
Dieses Objektiv ist das simpelste und älteste, welches ich habe. Weniger geht nicht, und damit ist endgültig bewiesen:
Die Toshiba ML00? (?=A, b,..Z)-Bausteine sind keine ROMs, und keine (simplen) SPI-devices. Das LensProtokoll ist SPI-artig, aber eben kein (pseudo-)Standard-SPI ala Motorola.
Alle bisher bekannt gewordenen Daten sind mindestens unvollständig, wenn nicht falsch.

Insbesondere Block 3 ist interessant: hier bleibt SS inaktiv, und der LensChip legt (MI)SO low, woraufhin die Kamera mit 2 8bit-Taktbursts antwortet.
Das kann ein Masken-ROM (eine solche Konstruktion wurde bisher angenommen) definitv nicht, die LensChips selbst der allerersten Baureihe sind aktive Bausteine.
Ein Auslesen mit einem (pseudo-)Standard-SPI-Adapter wie z.B. PonyProg ist sinnfrei, Versuche dahingehend können wir einstellen!
Die alten Toshibas verhalten sich nur weniger unfreundlich als die neuen Mikrokontroller, wenn ein falsches Protokoll gefahren wird.

Ich gehe davon aus, dass das Protokoll bereits bei der x000AF-Baureihe in dieser Weise implementiert wurde. Welche Unterschiede gibt es zwischen der x000AF-Baureihe und der Dynax x000i-Baureihe?
Am Objektivprotokoll wurde mit der Dynax x000xi-Baureihe einiges geändert (MOSI auf L6 und zusätzliche Spannungsversorgung für Motoren auf L7-L8)

Die trace-Daten liegen in einem simplen Format vor, jeder Sample ist einfach als Byte mit den bits 0..7 als Ch1..Ch8 abgelegt. Die trace-Datei ist also genau 1MByte groß und enthält keinerlei Zusatzinformationen, daher verwende ich folgende Dateinamenskonvention:
<cam-device>_<lens-device>_<lens-setting>_<granularity>-<lfn>.dgt mit
cam-device = Kameragehäuse oder Simulator
lens-device = Objektiv oder Simulator, Namenskonvention ala Sony mit SAL=Sony, mAF=minolta/KoMi; AnfangsBrennweite[EndBrennweite] F/M/S/R/.. Anfangsblende[EndblendeZoom] ggfs.Zusatz wie o=Ofenrohr usw.
lens-setting = [Brennweite]Entfernung (oo=Unendlich, oo+=Endanschlag bei Objektiven, die über oo hinaus gehen), nf/fs=Fokusstopp, ...
granularity = Auflösung der Samples in 10ns-Einheiten (122=1,22µs)
lfn = laufende Nummer ab 1 für Mehrfachauslesen
.dgt = Erweiterung von Digitrace für trace-Dateien.
Ich benutze den Dateinamen für das Interpreterprogramm, daher ist die Einhaltung der Konvention kritisch. Der Interpreter wird erstmal quick'n'dirty, kann aber dann in das geplante Digitrace-unabhängige universelle Simulator-Programm für A-Bajonett-Kameras und Objektive (ab sofort als UAsim bezeichnet), welches in ANSI-C (+inline asm) realisiert wird, integriert werden. Ich werde ein paar Tage dafür brauchen, wirklich schwierig ist das ganze nicht. Allerdings wird das fertige Proggi nur unter linux laufen und kein GUI haben, also nix für Mäuse-Schubser; dafür quelloffen unter GPL. Es wird rüde sein (Ints sperren z.B., maximale Priorität usw.), also bitte niemals auf einem Produktions-Rechner starten...

Ausserdem gibt es einen Adapter, der das Ganze nutzbar macht, Details folgen.

Ich habe nicht vor, damit Umsätze zu generieren! Das ist eine Spielerei für mich, Mitmacher müssen nur ggfs. entstehende Bauteil- und Versandkosten mittragen.

gruesze, thomas