wait_click() with short timeout

lapser

1093

Re: wait_click() with short timeout

« Reply #30 on: 02 / March / 2013, 08:00:51 »

Advertisements

Quote from: reyalp on 02 / March / 2013, 02:56:51

Quote from: lapser on 02 / March / 2013, 00:48:25
What happens when a lua script doesn't yield? How is it interrupted? If it's blocked writing, I assume it's in a camera routine, and not in Lua, so does that mean it can't be interrupted?
I don't really understand what you mean hear. The OSes are preemptive, though the details aren't terribly clear (to me, at least)

I think I answered my own question by reading the set_yield docs:
http://chdk.wikia.com/wiki/Script_commands#set_yield

The script is "interrupted", (not the hardware pre-emptive kind), every 100 VM instructions. So if the script is writing a log file with "print", and writing to the log file is blocked because the camera is busy saving pictures, then the keyboard won't be polled.

One solution would be to buffer file writes from the keyboard task (scripts), and signal a separate writing thread to do the actual write to the SD card. It would have to be in its own, new thread because it would block for seconds at a time when the camera was busy saving pictures.

I think waterwingz mentioned that it's possible to start a new thread? Can you point me to some info about that?

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

waterwingz

12138

Re: wait_click() with short timeout

« Reply #31 on: 02 / March / 2013, 10:40:28 »

Quote from: lapser on 02 / March / 2013, 08:00:51

I think waterwingz mentioned that it's possible to start a new thread? Can you point me to some info about that?

I'm not sure if this is what you are looking for but the G10 has an extra task I added that continually blinks the blue LED on the power button and also flashes the blue LED on the Print button when entering <ALT>. I did that during porting so that I could tell if CHDK was still running as I tested things.

Take a look at task_blinker() in boot.c for that camera.

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14080

Re: wait_click() with short timeout

« Reply #32 on: 02 / March / 2013, 15:20:58 »

Quote from: lapser on 02 / March / 2013, 08:00:51

The script is "interrupted", (not the hardware pre-emptive kind), every 100 VM instructions. So if the script is writing a log file with "print", and writing to the log file is blocked because the camera is busy saving pictures, then the keyboard won't be polled.

Yes. Script runs in kbd task. If script calls a C function that takes a long time to execute, it will delay the kbd task. This has very little to do with script yielding.

Quote

One solution would be to buffer file writes from the keyboard task (scripts), and signal a separate writing thread to do the actual write to the SD card. It would have to be in its own, new thread because it would block for seconds at a time when the camera was busy saving pictures.

There's a whole lot of unverified assumptions here.

Quote

I think waterwingz mentioned that it's possible to start a new thread? Can you point me to some info about that?

The camera OSes use "tasks" not "threads". Look for "task" in the code. If you can't figure it out from there, you should probably not attempt this.

Logged

Don't forget what the H stands for.

lapser

1093

Re: wait_click() with short timeout

« Reply #33 on: 04 / March / 2013, 15:40:05 »

Quote from: reyalp on 02 / March / 2013, 15:20:58

There's a whole lot of unverified assumptions here.

That's true. I added a test timer to kbd_process() and discovered that there are fairly long delays (150 msec or more) between calls in continuous mode sometimes.

Quote

The camera OSes use "tasks" not "threads". Look for "task" in the code. If you can't figure it out from there, you should probably not attempt this.

Yes, I'm aware that the functions in the firmware are labeled "tasks". I'm not planning to do firmware hacks at the moment.

From looking at the code in kbd.c for the G1X, it looks like it hooks into the firmware location for the keyboard "task" and calls:
my_kbd_read_keys()

This function then actually reads the key state by calling the firmware function:
_GetKbdState(kbd_new_state);
Then it calls:
kbd_process()
which checks the key state and processes the action stack(s).

Would it be possible to call _GetKbdState from another task, i.e. core_spy_task(), and pass the results to my_kbd_read_keys()?

What's needed is a regular polling of the keyboard state every 10 msec, and saving the state in a buffer to be read by the keyboard task.

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

philmoz

3450

Re: wait_click() with short timeout

« Reply #34 on: 04 / March / 2013, 16:34:53 »

Quote from: lapser on 04 / March / 2013, 15:40:05

Would it be possible to call _GetKbdState from another task, i.e. core_spy_task(), and pass the results to my_kbd_read_keys()?

Probably not.
Calling _GetKbdState from multiple tasks will most likely cause asserts in the firmware or crash the camera.
Spytask has a 20ms loop delay (and I think a lower priority).

Quote

What's needed is a regular polling of the keyboard state every 10 msec, and saving the state in a buffer to be read by the keyboard task.

That's what the keyboard task is for - if it's being starved for time then so will every other task.

Phil.

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

reyalp

14080

Re: wait_click() with short timeout

« Reply #35 on: 04 / March / 2013, 16:36:20 »

Quote from: lapser on 04 / March / 2013, 15:40:05

Yes, I'm aware that the functions in the firmware are labeled "tasks". I'm not planning to do firmware hacks at the moment.

The reason I (unnecessarily grumpily, sorry

) brought this up is if you search the code for "thread" you won't find much, where task will lead you to CreateTask which should largely answer the question about creating tasks.

Quote

Would it be possible to call _GetKbdState from another task, i.e. core_spy_task(), and pass the results to my_kbd_read_keys()?

Maybe, maybe not, but it doesn't seem like a good approach tome. As I said earlier, kbd_task is a modification of the original Canon PhySw task. The chdk keyboard twiddles some bits and calls into firmware code from the original task. Moving the _GetKbdState to a different task would further diverge from the original Canon implementation. Different cameras also have different code in this area, so it would be difficult to implement and even if it worked on one, it would be hard to be sure it worked everywhere.

Quote

What's needed is a regular polling of the keyboard state every 10 msec, and saving the state in a buffer to be read by the keyboard task.

That's pretty much describes what the original Canon PhySw does, at least as far as I understand it. CHDK has the scripting stuff stuck in there for historical and practical reasons. As I've said elsewhere, putting CHDK scripting in it's own task would probably be a good idea, but it's something that will take significant effort to get right and really needs to have a fair bit of thought into how to do it.

Logged

Don't forget what the H stands for.

lapser

1093

wait_click(1) for key check only

« Reply #36 on: 09 / March / 2013, 09:34:50 »

I noticed you changed wait_click(0) to wait_click(-1) for compatibility with old scripts. It would be nice to still be able to just check for a key, without a delay. How about this?

Code: [Select]

static int luaCB_wait_click( lua_State* L )
{
    int delay = luaL_optnumber( L, 1, 0 );
    //if (delay == 0) delay = -1;
    if(delay<2)delay--; //delay 1 for no delay or 0 for no timeout

Also, I had a problem once ending my script by pressing "menu". I think it may have been caused by this statement at the end of luaCB_wait_click:

return 1;

Shouldn't it return 0, since there is no return value?

« Last Edit: 09 / March / 2013, 14:25:14 by lapser »

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

reyalp

14080

Re: wait_click() with short timeout

« Reply #37 on: 09 / March / 2013, 15:15:48 »

Quote from: lapser on 09 / March / 2013, 09:34:50

I noticed you changed wait_click(0) to wait_click(-1) for compatibility with old scripts. It would be nice to still be able to just check for a key, without a delay. How about this?

That by definition shouldn't be wait_click()

Logged

Don't forget what the H stands for.

lapser

1093

Re: wait_click() with short timeout

« Reply #38 on: 09 / March / 2013, 16:14:20 »

Quote from: reyalp on 09 / March / 2013, 15:15:48

Quote from: lapser on 09 / March / 2013, 09:34:50
I noticed you changed wait_click(0) to wait_click(-1) for compatibility with old scripts. It would be nice to still be able to just check for a key, without a delay. How about this?
That by definition shouldn't be wait_click()

I agree. It should be get_key() or something. I'm planning to work on that and add a keyboard buffer soon. I'm thinking along these lines:

key= get_key() -- returns 0 if no key, otherwise gets key # from buffer

get_key(-1) -- clears keyboard buffer()
if(get_key(0)) -- returns true if key ready()
key=get_key(1) -- gets auto clicked key (with repeat)

is_key("key name") would work after get_key() too.

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

reyalp

14080

Re: wait_click() with short timeout

« Reply #39 on: 09 / March / 2013, 16:58:08 »

Quote from: lapser on 09 / March / 2013, 16:14:20

I agree. It should be get_key() or something. I'm planning to work on that and add a keyboard buffer soon. I'm thinking along these lines:

key= get_key() -- returns 0 if no key, otherwise gets key # from buffer

get_key(-1) -- clears keyboard buffer()
if(get_key(0)) -- returns true if key ready()
key=get_key(1) -- gets auto clicked key (with repeat)

is_key("key name") would work after get_key() too.

I would like some thought given to making the API simple, understandable and convenient.

Some thoughts:
is there really a need to have get_key followed by is_key? In wait_key, this makes some sense since you are waiting for any key, but if you aren't waiting it seems more sensible to just check the keys you are interested in.

get_key is not very description. Is it getting key state, or is clicks or

In Lua, we aren't restricted to simple returns numeric returns, it is simple to return the entire key state, e.g.
get_clicked_keys() could return an array of key names or <key name>=<bool> or <key name>=<click count>

A similar pattern could be used to get the current pressed / released state. If you had this and built a sleep loop with a short interval, you could in fact do your keyboard buffering entirely in Lua (which could be a standard module).

I'm not saying it should necessarily be done this way, but the CHDK script API has suffered greatly from people throwing in functions in a haphazard way.

Logged

Don't forget what the H stands for.