CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD - page 13 - Creative Uses of CHDK

ahull

634

Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD

« Reply #120 on: 07 / November / 2012, 04:52:46 »

Advertisements

I suspect that what happens is something like this pseudo code..

UnstowIris()
Start motor forwards .
Wait for PI signal interrupt, if not received within X ms, >Error
Return 1
else
(Iris now fully out)
Return 0

StowIris()
Start motor backwards
Wait for PI signal interrupt, if not received within X ms >Error
Return 1
else
(iris now fully in)
Return 0

Now here is a bit of speculation... this could be done two ways, you could waste a lot of processing power watching a GPIO pin for change of state, using a software loop. OR, you could use a hardware interrupt to save you the bother.

I.e Set interrupt handler for transition of GPIO Pin N (attached to the PI output)... do some other stuff,
Every time we get a transition on GPIO Pin N, we go and service that interrupt and log the State of the mechanism, then return from the interrupt. .

If this is the case, then we may simply need to find this routine (or these routines, if different pins have separate handlers), and call it/them the required number of times during power up and/or shooting.

I say simply, but there are likely a few other things (timing for example) that are important.

Another possibility is that the camera treats the mechanism as a finite state machine, and thus if we can find where it saves the current state, we can alter it accordingly.

i.e. In normal operation, if the current state of the state machine says the mechanism is not ready, the camera perform the sequence of tasks needed to ready the mechanism, if however the state machine says the mechanism is ready to shoot, it will simply shoot. If we can alter the camera from not ready to ready, it will shoot regardless.

So perhaps we need to dump ram, ready the mechanism, dump the ram, and do a bit of diffing.

« Last Edit: 07 / November / 2012, 05:40:22 by ahull »

Logged

SticK

779

Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD

« Reply #121 on: 07 / November / 2012, 09:30:31 »

Your pseudo code makes sense. One has to keep in mind that with stepper motors, FW can, and likely does, keep track of armature angular position (including number of revolutions) since unstow PI RESET, in open loop drive to at least 1/12th revolution. This applies to FOCUS and IRIS steppers. The ZOOM is driven by a heavily geared-down servo that moves the PI obstruction and it keeps angular position (to within 1/3 rev) using its two encoder feedback PIs. So angular position could be also be part of the expectancy window code. Thus your code could look like this:
UnstowIris()
Start motor forwards .
Wait for PI signal interrupt, if not received within X ms and|or not recv'd in approx N revolutions, >Error
Return 1
else
(Iris now fully out)
Return 0

Quote "Set interrupt handler for transition of GPIO Pin N (attached to the PI output)"
For the GPIO toggle solution, I have one concern: that the DIGIC AD_AIN# is an *input only* if the S90 is like the IXUS. Do you know if that input is also an output?

Quote "possibility is that the camera treats the mechanism as a finite state machine"
More than likely. Some empirical evidence was found with srsa's poke() IRIS error override. When ->REC, the camera "hung" in that it produced an ASSERT, shut down USB, but continued operating in a "limp home" mode where pressing the POWER button on the camera resulted in a clean shutdown including shutter change of state, even 2 minutes after the ASSERT. Even a malloc fail ASSERT allows the camera to disconnect USB and shutdown.

I can measure the mechanical delays if needed, to within about 1%.

Very interesting thoughts overall.

Logged

ahull

634

Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD

« Reply #122 on: 07 / November / 2012, 12:38:43 »

Quote

For the GPIO toggle solution, I have one concern: that the DIGIC AD_AIN# is an *input only* if the S90 is like the IXUS. Do you know if that input is also an output?

In truth, I have absolutely no idea if we can treat the input GPIOS as outputs, and I can foresee an issue in the sense that even if it can be toggled somehow to be an output we would then be feeding an output into another output, a good recipe for magic smoke...

.. so I think we would probably get more mileage from trying to figure out which ram locations or variables equate to the state of the mechanism, and then attempting to fool the software in to thinking we are ready to shoot by manipulating these, or by tracking down the interrupt handlers if they exist, and fooling the software by calling them the correct number of times to suggest we received our interrupts from the relevant PIs, OR... by disassembly of these routines to find out how they set the state machine.

I remember reading some info about DryOS interrupt routines... http://chdk.wikia.com/wiki/DryOS_Porting so there are obviously interrupt handlers, how many and what their function is I am uncertain.

So a bit of digging through the S90 rom dumps, should give is some more clues.

A bit of googling reveals some possibly related info from the magic lantern project on Canon DSLRs (which have quite a lot in common with the compacts)... http://magiclantern.wikia.com/wiki/Register_Map

This gives some possible insight in to both the IRQ setup and the GPIO configuration.

« Last Edit: 07 / November / 2012, 13:00:35 by ahull »

Logged

SticK

779

Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD

« Reply #123 on: 07 / November / 2012, 13:16:17 »

Quote "that even if it can be toggled somehow to be an output we would then be feeding an output into another output, a good recipe for magic smoke... "
Collision of course // in that topology, we'd simply snip off the PI (as input, the DIGIC has a pulldown on those pins).

Thanks for the heads up on the FW links // always interesting // but unfortunately low-level programming is out of my league. Sounds like a very good 3rd alternative though.

If you need S90_101a ROM, it should still be here...
http://www.sendspace.com/file/x270u3

Please let me know if it's no longer available.

Logged

srsa_4c

4451

Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD

« Reply #124 on: 08 / November / 2012, 13:32:09 »

Some notes.
- The DIGIC's analog inputs are dedicated (can't be set like GPIOs), as far as I know. The GPIO pins can be set to act like inputs or outputs, just like it's documented in the Magic Lantern wiki. To my knowledge, GPIO's don't have interrupt capability (the camera's button states are polled).
- The "non-working" mecha-related event procedures are mostly routines actually used by the camera. They are exposed as event procedures, so that the hardware can be controlled by Canon Basic scripts in "factory mode". Moreover, the "Disable" and "Enable" pairs are reference counted, so for example "DisableMechaCircuit" won't do anything without a prior call to "EnableMechaCircuit".
- The camera goes through a hardware checklist when rec mode is activated, and another (short) checklist, when the camera is shut down. I don't know (yet) what else would be needed to disable the firmware's access to the lens mechanism.
- The above mentioned "checklist" routines (they are tasks, actually) are very much alike in new (S90) and old (A420) cameras. Even the line numbers seen in assert calls are close.

Logged

SticK

779

Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD

« Reply #125 on: 08 / November / 2012, 14:12:24 »

@srsa_4c
Thank you for your valuable notes. Hence extending what you say, the "A" of AIN likely means Analog, making sense to me as they are indeed separate pin types from the ones explicitly labeled GPIO. I am at the beginning of a process in an attempt to document LED drive behavior and RESET PI timings, on the IRIS for now just to get a basic handle. This will be somewhat tricky because the traces are extremely fine but I think with some diligence attaching AWG#42 might work, hopefully. That way we can find out what happens during PLAY->REC and REC->PLAY (or PDN). The hope is that the LEDs are powered only during those transitions and not during normal shooting. That can help give a stronger timing reference point, but, from the schematic I speculate that the LEDs are powered even during normal shooting ... we'll see.

Logged

Microfunguy

4037

Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD

« Reply #126 on: 08 / November / 2012, 14:24:49 »

Quote from: SticK on 08 / November / 2012, 14:12:24

I think with some diligence attaching AWG#42 might work

With a stereo microscope and Antex number '57' 0.12mm diameter soldering-iron bit :-

http://www.antex.co.uk/prodtype.asp?strParents=183&CAT_ID=195&numRecordPosition=1

Logged

SticK

779

Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD

« Reply #127 on: 08 / November / 2012, 15:19:31 »

My Weller ETU tip is 0.4mm, but because it is a wedge type, I can rotate it in the iron so thin side is perpendicular to the soldering plane. There I get 0.15 mm with excellent heat transfer and soldering control because of its thicker width. My plan at present is to attach wires directly to the main ZOOM connector (junction where the pins meet ribbon cable) for tensile strength and for eventual disconnection of the lens components. By enabling shutter signal exit directly off the main ZOOM connector, we can fully test srsa's IS error override by cleanly and simply disconnecting the entire IS+SHUTTER component. The arrow is a connector:

IRIS MOTOR&PI -> ZOOM (easiest to explore solutions with)
FOCUS MOTOR -> ZOOM -> main PCB
IS+SHUTTER -> ZOOM

The FOCUS MOTOR PI is on the ZOOM ribbon cable. I do have the unused flash cable to practice on too and I will try it first, naturally.

Logged

ahull

634

Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD

« Reply #128 on: 08 / November / 2012, 17:01:20 »

Quote from: srsa_4c on 08 / November / 2012, 13:32:09

Some notes.
- The DIGIC's analog inputs are dedicated (can't be set like GPIOs), as far as I know. The GPIO pins can be set to act like inputs or outputs, just like it's documented in the Magic Lantern wiki. To my knowledge, GPIO's don't have interrupt capability (the camera's button states are polled).

Interesting, if they don't have interrupt capabilities, then that probably makes life simpler, since we can then be sure that the tasks that control the lens mechanism are probably synchronous, i.e. we perform mecha task a, then mecha task b, then mecha task c when initializing the mechanism, rather than setting all the tasks off at once, and this makes sense from what I observe of the camera preparing to set up for a shot. We therefore probably only need to convince the camera that the mechanism is set and focused by setting some flags some where, prior to calling the routine that actually does the shooting.

Quote

- The "non-working" mecha-related event procedures are mostly routines actually used by the camera. They are exposed as event procedures, so that the hardware can be controlled by Canon Basic scripts in "factory mode". Moreover, the "Disable" and "Enable" pairs are reference counted, so for example "DisableMechaCircuit" won't do anything without a prior call to "EnableMechaCircuit".
- The camera goes through a hardware checklist when rec mode is activated, and another (short) checklist, when the camera is shut down. I don't know (yet) what else would be needed to disable the firmware's access to the lens mechanism.
- The above mentioned "checklist" routines (they are tasks, actually) are very much alike in new (S90) and old (A420) cameras. Even the line numbers seen in assert calls are close.

It may be the case that these are the very routines we need to convince the camera we have called prior to our "shoot without setting up the mechanism" routine, since I would assume one of the things that the factory tests do is actually take a picture.

Logged

ahull

634

Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD

« Reply #129 on: 08 / November / 2012, 17:37:46 »

Reading through that Magic Lantern info again, I see....

Quote

Status RegistersEdit

Not sure what these status register describe

0xC0F04008 JUKAI WR
0xC0F04108 FEN YWR
0xC0F04208 WB
0xC0F04408 JPEG WR
0xC0F04608 FEN WR
0xC0F04B08 FEN RD
0xC0F04D08 JPEG RD

0xC0F26208 VRAM
0xC0F26808 JUKAI RD

0xC0F070DC [32] HEAD error status
...----------1-- CCD Shifter error occurred
...---------1--- FIFO error occurred
...--------1---- AF Shifter error occurred

Which suggests there may well be an error register, or registers, and this could be what is polled to see if we have a problem and need to shut down. If so, we may just need to keep this/these register(s) clean, by repeatedly feeding with a non error state (probably all zeros) and we can do what we like. (although that sounds far too simple an answer to our problem

).

« Last Edit: 08 / November / 2012, 17:40:40 by ahull »

Logged