CHDK PTP multiple instances

andrew.stephens.754365

461

Re: CHDK PTP multiple instances

« Reply #40 on: 17 / September / 2013, 17:08:54 »

Advertisements

Appreciate the [very] quick answer reyalp

probably would have been looking at this for weeks to figure by myself...

« Last Edit: 17 / September / 2013, 17:11:47 by andrew.stephens.754365 »

Logged

waterwingz

12139

Re: CHDK PTP multiple instances - working with USB Remote concurrently

« Reply #41 on: 17 / September / 2013, 20:01:30 »

Mod edit:
For anyone stumbling on this post later, the code modification described below is now available using usb_force_active, available by default for almost all ports in CHDK 1.4 and later.

Quote from: andrew.stephens.754365 on 17 / September / 2013, 10:07:27

Based on some of your notes I guess my primary school picture, attached, is not a particularly sound basis to meditate upon ?

You've pretty much got it with that drawing. I can't comment on how well the daisy chaining of USB hubs like that will work. And you will have to manage the PTP PC software on your own. But here is what's needed on the CHDK side :

I turns out that the simplest way to make PTP communication co-exist with CHDK's USB Remote code only takes one line of code added to a camera's kbd.c file (marked as NEW in this code snippet).

Code: [Select]

void my_kbd_read_keys() {
    kbd_prev_state[0] = kbd_new_state[0];
    kbd_prev_state[1] = kbd_new_state[1];
    kbd_prev_state[2] = kbd_new_state[2];
    _GetKbdState(kbd_new_state);
    _kbd_read_keys_r2(kbd_new_state);
    if (kbd_process() == 0) {
        // we read keyboard state with _kbd_read_keys()
        physw_status[0] = kbd_new_state[0];
        physw_status[1] = kbd_new_state[1];
        physw_status[2] = kbd_new_state[2];
    } else {
        // override keys
        physw_status[0] = (kbd_new_state[0] | KEYS_MASK0) & (~KEYS_MASK0 | kbd_mod_state[0]);
        physw_status[1] = (kbd_new_state[1] | KEYS_MASK1) & (~KEYS_MASK1 | kbd_mod_state[1]);
        physw_status[2] = (kbd_new_state[2] | KEYS_MASK2) & (~KEYS_MASK2 | kbd_mod_state[2]);
    }
        usb_remote_key() ;
        if (conf.remote_enable) {
                physw_status[USB_IDX] = physw_status[USB_IDX] & ~(SD_READONLY_FLAG | USB_MASK);
                physw_status[USB_IDX] = physw_status[USB_IDX] | USB_MASK ;  // NEW : make it look like 5V is there no matter what
        } else {
                physw_status[USB_IDX] = physw_status[USB_IDX] & ~SD_READONLY_FLAG;
        }
}

I've tested it with a modified USB cable I use for CHDK development. Its a regular USB cable with a toggle switch inserted into the red 5V wire. This lets me test USB Remote code by toggling the switch. It also lets me download CHDK or a script or upload photos and then throw the switch to disconnect PTP without having to unplug the cable.

Using this setup and the switch closed, I was able to connect to my camera with CHDKPTP, go into shooting mode and issue a "shoot" command. With USB Remote enabled and sync enabled, this caused the picture shooting process to start but then wait on the USB 5V signal. I opened the switch and the picture taking process completed immediately. I was able to continue issuing commands to the camera - all I had to do next was make sure I closed the switch before the next shot.

Using your pictured setup, you would have to make a ptp connection to each camera and issue shoot commands to each over ptp. If your microcontroller then opened the 5V line, all cameras would shoot at exactly the same time. Which I believe is exactly what you are looking for!

Obviously, this requires a custom build and you will only be able to go into shooting mode using chdkptp using this simple code while CHDK is active. Adding a command to chdkptp to enable/disable this feature over ptp would be trivial. A CHDK menu option could also be added to do the same and/or some clever code inserted into the shooting sequence. Given the recent interest in this subject, maybe someone can convince reyalp that this is worth adding to the autobuild after suitable discussion about the implementation.

« Last Edit: 15 / September / 2017, 22:42:11 by reyalp »

Logged

Ported : A1200 SD940 G10 Powershot N G16

Karmaschinken

198

Re: CHDK PTP multiple instances

« Reply #42 on: 17 / September / 2013, 20:22:41 »

Wooooooohoooh! Man, this is really GREAT! What a smart solution! As far as I understand this is a real combination of both remote-triggering while having chdkptp running!

Now, what do I have to do to test that? I need to compile a CHDK-version with this modification? Okay, I have never done that, but I would like to try. Thanks man! Very smart!

Logged

waterwingz

12139

Re: CHDK PTP multiple instances

« Reply #43 on: 17 / September / 2013, 20:57:53 »

Quote from: Karmaschinken on 17 / September / 2013, 20:22:41

I need to compile a CHDK-version with this modification? Okay, I have never done that, but I would like to try.

http://chdk.wikia.com/wiki/CHDK-Shell

Logged

Ported : A1200 SD940 G10 Powershot N G16

andrew.stephens.754365

461

Re: CHDK PTP multiple instances

« Reply #44 on: 18 / September / 2013, 04:19:23 »

As before, truly appreciate the guru members input [lastly waterwingz at Reply#41 above] - thanks for your ongoing help.

[Edit: waterwingz, I was on the verge of stating 'awesome' - but I hate that word (didn't I just use that hateful word...aaargh].

Hi Karmaschinken,

please remember some of Hardware_Hacker's comments [Reply#31 in this thread] at http://chdk.setepontos.com/index.php?topic=8769.msg105454#msg105454 - for example:

"4/ Some Multi-Port Hubs are easy to modify in regard to switching the 5 volt power supply (syncing) and then fully "Discharg" the 5 volt supply via a suitable termination resistor.

5/ However you have to be aware of a another potential problem, that in a "Standard" Sync USB cable there is no "Discharge" path, except for the camera's internal non linear circuits. This has been a subject in several previous posts and dosn't appear to be a problem with twined cameras but could be major problem with your rig that has a combination of long USB cables and 50 cameras."

And some [justified ?] ones from me:

Since the power provided from the computer [along the usb +5V line] is insufficient then powered usb hubs are likely required and therefore the '50' relay option is needed.

Powered hubs contain transformers:
(i) are various propogation delays created in the transistion from +5V to 0V across the USB network ?
(ii) time variation of Arduino controlled chosen relays / optoisolators - might they also materially impact the final variation in voltage time transistion at the input to each camera.

Personally, i'm still just starting this journey [e.g what's the kbd.c that reyalp referred to -> ~~key~~ Knew build data ?

( no answer sought, just yet]. There's a lot more 'reading' to be done / knowledge to 'soak up' - and not just about chdk

Have to say - this chdk / chdkptp 'thing ' does appear to be a lovely little bit of kit though.

« Last Edit: 18 / September / 2013, 09:04:48 by andrew.stephens.754365 »

Logged

Hardware_Hacker

322

Re: CHDK PTP multiple instances

« Reply #45 on: 18 / September / 2013, 04:29:28 »

Quote from: andrew.stephens.754365 on 17 / September / 2013, 10:07:27

Quote from: Hardware_Hacker on 17 / September / 2013, 04:26:21

Based on some of your notes I guess my primary school picture, attached, is not a particularly sound basis to meditate upon ?

I have revised your "USB-Hub" circuit drawing.

I only have 4 port "Powered" USB-HUBS and they appear to be easy to "Hack"
to supply a common +5 volts to sync all my cameras.

My camera rig is still under construction.

The most important point, when using the USB as a sync input, is to minimise
the Decay Time constant so as to pass through the cameras switching zone
as rapidly as possible. This in turn minimises any USB switching zone Jitter
amoung the 50 cameras.

A low value of termination resistance is needed to achive this.

My definition of a "Powered USB Hub" is one that has a seperate connector
for an "External Power Supply"

H-H

Usb-Diagram(v3).png (305.04 kB, 800x600 - viewed 226 times.)

Usb-Diagram(v3)Lp.png (561.33 kB, 800x800 - viewed 247 times.)

« Last Edit: 18 / September / 2013, 04:33:21 by Hardware_Hacker »

Logged

andrew.stephens.754365

461

Re: CHDK PTP multiple instances

« Reply #46 on: 18 / September / 2013, 04:44:36 »

Thanks Hardware_Hacker...I might not need to google as much as first considered if this keeps up

Important point about delay - I did hope [after 25 years passing] that I would never have to consider an 'n^th order linear differential equation ' again in my lifetime. Ah well, here goes...

I'll examine your post in detail later

[I think] your slides are pretty 'cool '

« Last Edit: 07 / October / 2013, 13:47:06 by andrew.stephens.754365 »

Logged

waterwingz

12139

Re: CHDK PTP multiple instances

« Reply #47 on: 18 / September / 2013, 09:23:12 »

Quote from: andrew.stephens.754365 on 18 / September / 2013, 04:19:23

Personally, i'm still just starting this journey [e.g what's the kbd.c that reyalp referred to]

Take a look at the file name referenced in my previous post.

Logged

Ported : A1200 SD940 G10 Powershot N G16

andrew.stephens.754365

461

Re: CHDK PTP multiple instances

« Reply #48 on: 18 / September / 2013, 10:14:34 »

got that waterwingz ! this is getting serious - I had to look for the salt 3 times, in the same cupboard, at breakfast

[and it was right in front of me]

Logged

andrew.stephens.754365

461

Re: CHDK PTP multiple instances

« Reply #49 on: 18 / September / 2013, 18:44:18 »

I'm attempting to learn: The best 'high' level chdk description i've [quickly] come across follows - the wiki & forum is chock full of info [great]. However, are there any 'consolidated lower level' descriptions that describe 'how' chdk works ? [if 'G' can't find it, i'm not confident

]:

"First, the camera’s firmware checks the memory card. If the card is write-protected, and if it contains a file named DISKBOOT.BIN in its root directory, then this file is loaded and executed. This allows almost any program in the camera to be infiltrated.
If such a file is not found, the normal start-up process continues. This includes the launch of four different native tasks that run in parallel and manage the different units of the camera:

The Logging task takes care of the camera’s display unit. It is responsible for presenting information to the user.
The Keyboard task monitors the camera’s buttons for key presses.
The Image-capturing task is responsible for exposure and focus control and for reading the data from the sensor.
The Image-capturing task is responsible for exposure and focus control and for reading the data from the sensor.
The File-system task is responsible for writing images to the memory card and managing the card’s file system.
The CHDK adds an additional task that manages the CHDK functions. In addition, the CHDK needs hooks in the native tasks to communicate with them.

Therefore, the CHDK loader embodied in the file DISKBOOT.BIN performs the following steps:

Copies the core CHDK code into a suitable memory location within the camera. Of course, this is only possible if the camera has enough free memory. On some cameras this is not the case, and limited or no CHDK support is possible.
Restarts the camera with the CHDK code as the entry point. Instead of the native boot process, the CHDK boot process is now performed.

This process will:

Launch the CHDK task.
Add hooks to the native tasks (logging task, keyboard task, image-capturing task, file-system task) while loading and launching those tasks.

In this way, the changes applied to the native firmware are only temporary and remain minimal. Unfortunately, the position of the hooks is different for every firmware version, so a different CHDK version is required for each firmware version. The main task of migrating the CHDK code to a new camera is to find out the correct position of the required hooks."

« Last Edit: 18 / September / 2013, 18:55:57 by andrew.stephens.754365 »

Logged