HDMI power and alternative remote inputs ( was Re: G7 X porting thread)

@srsa_4c thanks for adding the hdmi power functions to the fins_dryos. I verified sx160 is correct.

Attached is an updated patch which adds analog AV detect (https://chdk.setepontos.com/index.php?topic=13448.0) remote for g7x, sx160, sx710 and and HDMI support for the latter two.

I'm still thinking about how to do it, bit implementing these reinforced my feeling that the amount of copy/paste should be reduced. The implementations vary only by defines.

I looked at adding the relevant mask/index stuff to the sigfinder. The analog AV is "event" 0x200 on all 3 of these cameras, so it may be easy.

The HDMI bit appears to be one where the "event" field is -1.
sx160
levent 0xffffffff, 0x20000000, index 0 (non-inverted logic)
The raw flags are 0x0301011d

g7x
0xfc6137fc 0x05010145 0xffffffff 2     0x00000020 1

sx710
0xfc5bfa90 0x04010105 0xffffffff 0     0x00000020 1

I added the analog AV bit to the dryos sigfinders. It appears to be valid for a wide range of cameras, verified correct on d10, elph130, sx160, g7x, sx710hs and elph180. Updated patch with these supported attached.

Note that this most likely only useful for cameras where AV out is combined with USB. Old cameras that used a separate AV plug had a mechanical switch. I don't if there are any of these with the AV plug bit detected.

Minimal HDMI remote for testing
1 micro or mini HDMI to standard HDMI adapter
1 HDMI standard to DVI female adapter
1 paper clip

Here's an updated patch that puts the logic in common code with ifdefs. If there aren't major objections, I'll probably check this in fairly soon. There's some additional stuff I want to do, but this seems OK for a starting point.

Although the ifdefs are a bit ugly, I like this better, since platforms only need platform defines and some functions to get the bits. The various remote types are now identified by constants.
The relevant camera.h defines are now:
    #undef  CAM_REMOTE_AtoD_CHANNEL             // Camera supports using 3rd battery terminal as well as USB for remote - value = A/D channel to poll (normally 5)
    #define CAM_REMOTE_AtoD_THRESHOLD       200 // 3rd battery terminal A/D reading threshold ( lower = 1, higher = 0 )
    #undef  CAM_REMOTE_HDMI_HPD                 // Camera supports using HDMI hotplug detect for remote signal
    #undef  CAM_REMOTE_HDMI_POWER_OVERRIDE      // Camera requires HDMI power to be forced on in rec mode
    #undef  CAM_REMOTE_ANALOG_AV                // Camera supports analog AV detect for remote signal
The first two are the same as the trunk code, so the existing cams with A/D support no longer need anything in the patch.

I added code to reset the remote channel on platform changes, and call set_usb_remote_state when the input channel changes.

I moved HDMI power override out of mode_get, into the main loop where mode_get is called (mode_get is called in other places too)

I also added A/D channel support for D10 and SX710, because I needed to test it and they use the same dummy battery.

A/D channels values have changed for SX710, it has the battery temperature on channel 3 (rather than 5), and the open circuit is ~4090 rather than 1023 on the old cams (presumably a 12 bit ADC). I haven't checked with this a digic 6 thing, or applies to other newer cams.

The cameras seem to provide 3v on the battery temp pin. I measured ~0.09 mA with a 10k resistor and ~12 mA with a 3.5k on both.

Edit:
To check A/D values, you can use the following in chdkptp
=return call_event_proc'Driver.Create'
 =t={} for i=0,10 do t[i] = call_event_proc('GetAdChValue',i) end return t
Doing this with a normal battery, and a battery with the temperature terminal taped over should identify the battery A/D.

Thanks reyalp for adapting the patch.
I will test it also with my G7X as soon as possible.

i have now tested it on my g7x (just the hdmi hot plug related stuff), everything is working.

I checked this in, trunk r5062.

This includes battery temp A/D support for g7x, ixus140_elph130, ixus175_elph180

It appears that the new A/D setup may be digic 6 specific: G7X is the same as SX710 (12 bit, channel 3) while elph180 is like older cameras (10 bit, channel 5).

For G7X, using the battery remote has some peculiarities probably related to the "genuine" battery detection.  Using a Canon battery:
* If the temperature terminal only (between + and -) is covered, the camera boots, but isn't detected on PTP, and after switching to shooting mode, it shut down with "charge the battery" even though the battery had enough charge shoot after I uncovered the terminal. (edit: I tried with a fully charged battery and shooting worked OK, but PTP was still non-functional)
* If both the temperature terminal and the fourth terminal are blocked, it's treated like an external power adapter. Works fine, no battery status in the Canon UI.
* If only the fourth pin is blocked, the "non canon battery" message is displayed.

I didn't experiment to see whether the problem is due to the terminal being open circuit, or whether the battery needs to see power on it. It should be possible to work around in either case, but the threshold would need to be adjusted if triggering was done by switching an additional resistor inline with the thermistor.

i have now tested it on my g7x (just the hdmi hot plug related stuff), everything is working.

Thanks for reporting, and all your work on this project.

Some ideas for future additions

Control of HDMI power:
From script, it could be used as an output for microcontroller, UAV etc applications, which has been requested occasionally. Since it's 5V, it could also be used to trigger other cameras USB remote with trivial circuitry. Script wouldn't allow very precise sync, but if there isn't too much overhead in the actual process, doing it from the remote hook of the master camera could be good.

Spoofing analog A/V detect:
It might be desirable to provide something like usb_force_active for the A/V detect. This should allow A/V out while also using the detect signal as a remote trigger, which would potentially be useful for FPV applications. Using the USB remote for triggering would also work in this situation, but a full splitter cable is harder to make.

Reading A/V detect and HDMI hotplug from script:
You can currently only get these if they are the selected remote channel. A script function to read them directly would make it easier to use multiple inputs. Battery A/D can already be read using event procs.

Added HDMI input support for the ixus115/elph100.
I used a HDMI C plug that has a small PCB (see picture) to make soldering easier. Pinout is here.

Control of HDMI power:
From script, it could be used as an output for microcontroller, UAV etc applications, which has been requested occasionally.

I would like to control an external device (Motor Slider, Plant Lamp) in a time-lapse script via Arduino. Since that seems to me to be an elegant solution with the HDMI 5V output. If I understood correctly then the 5V voltage can also switch in recording mode.
Does it work even if the camera is in half-pressed shutter?
Could you also generate pulses (3 * 50ms with 50ms break)?

Another possibility I see with the control of the focus lamp with a photodiode. That should probably always go.

Are there any other alternatives, for example via the USB port?