the sx20 porting thread

neszt

RaduP
Sure, here is an updated version, I also modified the propset2.h , you might find it useful (assuming your camera uses the same props as mine).

Ohh, you hooked everything in taskCreateHook at 0x1938? Well, i'll follow this also..

RaduP

Yes, for me that's the only way I could get them to work. But make sure that you check with the blinking of LEDs to make sure it works. Also, the video task is not started right away, but when the video recording starts. Took me a while to realize that :/

neszt

I'am back again from long weekend. 😀

Now, i can report some good news.

I implemented whole the capt_seq.c, now i can override expo parameters, tested iso override and shutter speed including long exposures.

However a lot of menu functions works, srcipts, misc/filebroser, calendar, alt-mode button change. Text file reader freezes, when i open a file. Alos freezes when i try to run a game. The game screen appears correctly but after a second it freezes. (Probably missing or wrongly determined function address?)

I tested an intervallometer script, it runs, the first shot was taken correctly, but no more. It just waits. The script is running, coz' i can interrupt it.

Now, i need to work more, but it is very very good, that i'am over the first and hardest section, the booting and hooking procedure. 😎

neszt

neszt
I tested an intervallometer script, it runs, the first shot was taken correctly, but no more. It just waits. The script is running, coz' i can interrupt it.

Debugging this ubasic shot issue, i got no solution. I added the following debug log to ubasic_run() function:

sprintf(buf, "LINE BEG %d %d %d %d", tokenizer_line_number(), ended, tokenizer_finished(), ubasic_finished());
script_console_add_line(buf);
line_statement();
sprintf(buf, "LINE END %d %d %d %d", tokenizer_line_number(), ended, tokenizer_finished(), ubasic_finished());
script_console_add_line(buf);

I tried to run this basic program:

print "Taking shot 1 SLEEP"
sleep 1000
print "Taking shot 1 SHOT"
shoot
print "Taking shot 1 DONE"

I attached the result picture.

The ubasic_run() called from the following code:

    do {
        ubasic_run();
    } while(!ubasic_finished());

That's way, i don't understand, why the script does not continue after the first shoot token. (The first picture taken correctly)

RaduP

The basic commands are put in a stack, and to debug it you must see WTF is happening in this stack.
Here is some code I used:

void print_script_key_stack()
{
	char str[80];

	sprintf(str,"Pointer: %i, loc: %i,%i,%i,%i,%i,%i,%i,%i,%i,%i",kbd_int_stack_ptr,kbd_int_stack[0],kbd_int_stack[1],kbd_int_stack[2],kbd_int_stack[3],kbd_int_stack[4],kbd_int_stack[5],kbd_int_stack[6],kbd_int_stack[7],kbd_int_stack[8],kbd_int_stack[9]);
	draw_string(64,16,str, conf.osd_color);

}

I have it in core/kbd.c and call it from gui.c

neszt

RaduP
The basic commands are put in a stack, and to debug it you must see WTF is happening in this stack.
Here is some code I used:

Here is the result picture of your debug code.

When the basic script is running the Pointer and loc values changes quickly. The picture shows the state when the script seemly to be stoped.

RaduP

Those values have some meanings. One is delay/wait, other is keypresses, etc. You must determine if the stack contains the right sequence, based on what the script would do.
One other thign you can try is put too shoots in your script, and see if both are taken or just one.

neszt

RaduP
Those values have some meanings. One is delay/wait, other is keypresses, etc. You must determine if the stack contains the right sequence, based on what the script would do.

I need time, to understand this.

One other thign you can try is put too shoots in your script, and see if both are taken or just one.

Just one. After the first shot command (token) executed, the script seems to be halted, but it is interruptable. As the screenshot shows, the script not finishes yet, just somehow it is not continues. In a normal programing environment, it is inpossible. There is something i don't know regarding CHDK. Probably another task in the background locks this script or somthing similar.

neszt

How about the propset2.h? You mentioned, that it should be useful for me also. So days ago, when i downloaded you fresh source, i used your propset. Now i tried to use the original propset, and the basic script does even not take a single picture. (it is beeps, so the picture seems to be nearly taken, but after the autofocus finished, nothing happens..)

So your propset2.h helped me, but still something wrong. How to find the correct values for all PROPCASE_*?

RaduP

Oh, yes, it could be. To find the proper props, well, that's very difficult, there are some props I couldn't even find, such as the flash related stuff.
Anyway, in this case, I think it's not a prop problem. You must see where the script stops, it could be that it is waiting for the camera to be ready to take the next shot, something like in stubs_min.S not being right or something.

Try to replace shoot with something else, like pressing the shutter button, see if that works.

reyalp

neszt
So your propset2.h helped me, but still something wrong. How to find the correct values for all PROPCASE_*?

You can use the propcase viewer in the debug menu. There's also a propcase comparison mode, and some scripts that do the same thing. You can easily check whether known propcase IDs match their expected values listed for propset 2 in http://chdk.wikia.com/wiki/Propertycase

The problem sounds like some variable, function or propcase that tells the script the shooting process is complete is not working correctly. Look at kbd_sched_shoot(), and then check the code for each thing pushed on the stack. You can easily add some debug code to each case in the switch that handles them.

You can also try a script that uses key presses instead of a shoot, e.g.

	press("shoot_half")
	repeat 
		sleep(10)
	until get_shooting() == true
	sleep(10)
	press("shoot_full")
	sleep(50)
	release("shoot_full")
	release("shoot_half")
	repeat
		sleep(10)
	until get_shooting() ~= true

neszt

RaduP
Oh, yes, it could be. To find the proper props, well, that's very difficult, there are some props I couldn't even find, such as the flash related stuff.
Anyway, in this case, I think it's not a prop problem. You must see where the script stops, it could be that it is waiting for the camera to be ready to take the next shot, something like in stubs_min.S not being right or something.

Try to replace shoot with something else, like pressing the shutter button, see if that works.

I inserted many wait_click to the basic source and it worked. (I tested with print) Every time, i push the any button, the script executed the next basic line. So it's ok. I'll recheck all the addresses in the stubs_min.S.

I found the actual values by comparing your values with your fimrware (and sometimes comparing sx10's values with sx10 firmware), and i looked similar code part in my firmware, but it is very dark to me. Why this addresses is too short? What is + values?

For example: DEF(canon_shoot_menu_active, 0x7B08 + 1)

RaduP

neszt
Why this addresses is too short? What is + values?

For example: DEF(canon_shoot_menu_active, 0x7B08 + 1)

The addresses are short because they are at the beginning of the RAM.
They are base + offset because they are easier to find this way on different cameras. base is the address of the structure, and the offset is the location in that structure.

reyalp

The + value is just a way of making it easier understand how the value was found, and find the same variable in other dumps. If the firmware does

LDR r0,=0x7B08
LDRB r1,[R0,1]

You would be able to find the code by searching for 0x7B08, but not by searching for 0x7B09

I'm not sure what you mean by "too short". Almost everything in stubs_min.S is a RAM address rather than ROM, so is in RAM address space.

neszt

reyalp
The + value is just a way of making it easier understand how the value was found, and find the same variable in other dumps. If the firmware does

LDR r0,=0x7B08
LDRB r1,[R0,1]

You would be able to find the code by searching for 0x7B08, but not by searching for 0x7B09

I'm not sure what you mean by "too short". Almost everything in stubs_min.S is a RAM address rather than ROM, so is in RAM address space.

Thanks, it's absolutely clear now. I rechecked every addresses again, and i found one wrong. Corrected:

DEF(enabled_refresh_physical_screen, 0x9D60 + 0x2😎 // in FFA0499C

But this not solved the problem.

However, there are 2 another values about 99 percent sure, not 100%, and the FlashParamsTable is not found yet.

DEF(physw_status, 0x32444) // in FF832B90
DEF(physw_run, 0x1C38 + 0x0C) // in FF832B90
DEF(FlashParamsTable,0xFFB7454C) // ?
DEF(zoom_busy, 0x6E9C + 0x1C) // in FF9568F4
DEF(focus_busy, 0x6D40 + 😎 // 99%
DEF(canon_menu_active, 0x3128 + 4) // in FF8903B4
DEF(canon_shoot_menu_active, 0x8838 + 1) // in FF9A9F7C
DEF(recreview_hold, 0x76F4 + 0x10) // 99%
DEF(zoom_status, 0xC6B😎 // in FFAAEEC4
DEF(movie_status, 0x2BF8 + 0x3😎 // in FF878924
DEF(enabled_refresh_physical_screen, 0x9D60 + 0x2😎 // in FFA0499C
DEF(playrec_mode, 0x2E54 + 0x4) // in FF882228

neszt

reyalp
You can use the propcase viewer in the debug menu. There's also a propcase comparison mode, and some scripts that do the same thing. You can easily check whether known propcase IDs match their expected values listed for propset 2 in http://chdk.wikia.com/wiki/Propertycase

Huhh. Big set. 😀 I checked some randomly, and those was ok. I'll check these all in a couple of days.

The problem sounds like some variable, function or propcase that tells the script the shooting process is complete is not working correctly. Look at kbd_sched_shoot(), and then check the code for each thing pushed on the stack. You can easily add some debug code to each case in the switch that handles them.

What kbd_sched_shoot() does do? Am i think right, that this controlls the camera to take a shoot by executing a basic "shoot" token? I would like to be sure before debugging. (I don't understand what is pushed on the stack and why it is needed?)

You can also try a script that uses key presses instead of a shoot, e.g.
[code]
press("shoot_half")
repeat
sleep(10)
until get_shooting() == true
sleep(10)
press("shoot_full")
sleep(50)
release("shoot_full")
release("shoot_half")
repeat
sleep(10)
until get_shooting() ~= true
[/code]

The first line gives "Unk key" error. I traced it back, and i saw there is a link in kbd.c from KEY_SHOOT_HALF to shoot_half, so i don't understand why this error appears..

reyalp

You should be able to watch the values in misc debug values to see if they make sense. E.g. focus_busy should be non-zero while focusing. (playrec_mode may be an exception, in my experience the debug OSD doesn't update correctly even if the value works otherwise)

What kbd_sched_shoot() does do? Am i think right, that this controlls the camera to take a shoot by executing a basic "shoot" token? I would like to be sure before debugging. (I don't understand what is pushed on the stack and why it is needed?)

It pushes items onto the script stack to tell the keyboard task what to do.

Keep in mind the camera is multitasking. The kbd.c stuff (and all the script stuff) runs in the kbd (aka physw) task. This task runs in a loop, polling physw_status every 10 ms. So we when shoot, we can't just press the halfshoot, delay until the camera is ready for a full shoot, press full shoot and so on. The kbd task has to keep running, and the script stack tells it what to do next. So all kpbd_sched_shoot() does is push a bunch of values onto the stack. The switch statement that deals with these values is where the actual work happens, and this is done over many iterations of the kbd task.

The first line gives "Unk key" error. I traced it back, and i saw there is a link in kbd.c from KEY_SHOOT_HALF to shoot_half, so i don't understand why this error appears..

That's a lua script, not a ubasic script. Sorry. The translation to ubasic should be straightforward. Edit: or save it with a .lua extension. But that was copy/pasted from a larger script without testing, so it may not be 100% correct.

neszt

reyalp
That's a lua script, not a ubasic script. Sorry.

Ohh, i renamed it to lua, and worked! This script takes a photo. 😀 Now, i understand how. However, this script started and finished successfully, so it's ok. Morover, it can take more photos, so the basic script pausing effect not appears in lua script. What it means?

reyalp

neszt
Ohh, i renamed it to lua, and worked! This script takes a photo. 😀 Now, i understand how. However, this script started and finished successfully, so it's ok. Morover, it can take more photos, so the basic script pausing effect not appears in lua script. What it means?

This script doesn't use the shoot function. Instead it does roughly the same thing with buttons presses. You can try a lua script with shoot(), it will probably have the same problem as ubasic.

The shoot command tries to do approximately what the script does, using half press until the camera is ready, and then doing full press and so on. So, go back to my previous post and look at the switch statement that processes all the stuff on the script stack.

neszt

reyalp
The shoot command tries to do approximately what the script does, using half press until the camera is ready, and then doing full press and so on. So, go back to my previous post and look at the switch statement that processes all the stuff on the script stack.

Well, i found, that only one int keeps in the stack. This is no 7, whitch is SCRIPT_WAIT_SAVE.

I found in main.c:

	if ((state_shooting_progress == SHOOTING_PROGRESS_PROCESSING) && (!shooting_in_progress())) {
	    state_shooting_progress = SHOOTING_PROGRESS_DONE;
            if (raw_need_postprocess) raw_postprocess();
        }

and shooting in progress:

int shooting_in_progress()
{
    int t = 0;
    _GetPropertyCase(PROPCASE_SHOOTING, &t, sizeof(&t));
    return t != 0;
}

So i checked propcase shooting, and mine is 208 rather than 206, whitch is in the propcase table.

And now i understand what told me Radup, when talked about propcase.

But i use Radups modified propset2.h, with value 208! I checked with debug parameters, and 208 is becomes 0, after a while after the shoot, and the script still waits. Is it enought to copy the new propset2.h to include? In the camera.h:

#elif defined (CAMERA_sx20)
    #define CAM_PROPSET                 2

« Previous Page Next Page »