new branch - CHDK : Elf Edition - Developers wanted

[waterwingz]

changeset 1569 reuses a conf number in core/conf.c

Code: [Select]

    CONF_INFO(248, conf.charmap_file,        CONF_CHAR_PTR,   ptr:"", NULL),

The last one should be 250.

Fixed. r1576

it looks like something is possibly clobbering one of the two USB remote conf variables at 248 or 249.   I'll look closer tomorrow but is there any chance 250 is overwriting them when the file is stored ?

[philmoz]

it looks like something is possibly clobbering one of the two USB remote conf variables at 248 or 249.   I'll look closer tomorrow but is there any chance 250 is overwriting them when the file is stored ?

I've gone back over the code changes and I can't see any reason why this would happen - that's not to say there isn't a problem with my config file changes; but it's not obvious. If you can find any pattern to the problem that would help a lot.

The only time I've problems with menu settings changes seeming to get lost is if I turn off the camera before exiting the menu or ALT mode (after changing a setting). You can also get this if you use chdkptp to reboot the camera.

Phil.

[waterwingz]

I've gone back over the code changes and I can't see any reason why this would happen - that's not to say there isn't a problem with my config file changes; but it's not obvious. If you can find any pattern to the problem that would help a lot.

Thanks philmoz.  That saved me some time looking there.  I've tracked it down finally,  its an interesting one. 

I finally noticed that with my testing version, if I had Remote Enabled when I reset the camera it would crash.  If I deleted the CCDHK.CFG file from the SD card (and thereby losing the Remote Enabled setting), then CHDK would load normally again. Hence my concern about config.xxx values.

Turns out this is only a problem when I have the OSD debugging code in the USB remote modules compiled in.  That was not a problem when I was using the stable branch but turns out to cause the above mentioned problem when used in the main dev ELF trunk.

I tracked it down to this line :

Code: [Select]

draw_string(2,16,buf,MAKE_COLOR(COLOR_YELLOW,COLOR_RED));

If I commented out the every draw_string, this work fine. So I inserted a one time 1 second delay at the start of the usb remote OSD debug code and re-enabled the draw_strings.

Bingo.

It appears that the USB remote debug print code was running too early in the startup sequence - before the various things necessary to display on the LCD are setup.  Interesting that this was not a problem in the stable branch though.

[pelrun]

A menu UI niggle I just noticed: submenus that are loaded as modules can only be opened using the set button, whilst permanent submenus can be opened via both set and right buttons.

[pelrun]

Quick patch for the menu UI issue attached. (against trunk)

[philmoz]

It appears that the USB remote debug print code was running too early in the startup sequence - before the various things necessary to display on the LCD are setup.  Interesting that this was not a problem in the stable branch though.

You have the debug display code in the function being called from the kyeboard task.
It would be better if you could move the debug display code to a seperate function and call this from the spytask task, which is where most of the gui display stuff lives.

If that's not possible you could add a variable that gets set after the call to gui_init in core_spytask that lets your usb remote code know it is safe to display debug info.

Phil.

[waterwingz]

You have the debug display code in the function being called from the kyeboard task.
It would be better if you could move the debug display code to a seperate function and call this from the spytask task, which is where most of the gui display stuff lives.

If that's not possible you could add a variable that gets set after the call to gui_init in core_spytask that lets your usb remote code know it is safe to display debug info.

Yup - I added a time delay - the debug code is the usual "brute force" thing most debug displays are. It's built out by default.

I suppose a proper  "usb remote" debug display might be helpful if others want to add logic modules.  I'll put it on the "to do" list.  I was also going to add something that modified what the USB remote OSD icon or text shows on a half press / full press to make it easier to see what the camera is doing.

[philmoz]

Quick patch for the menu UI issue attached. (against trunk)

Thanks for that, fixed in changeset 1579.

Phil.

[philmoz]

Changeset 1580 in the main trunk contains a re-work of the Zebra module code.

This is to make the zebra module platform independent.

It also include some re-organisation of the code and some additional comments.

Tested on G12, SX30, SX40, IXUS310 and IXUS700.

I'm fairly confident it functions equivalently to the old code; but I may have missed something.

Please report any zebra issues with this build here.

Phil.

[tsvstar]

I do not test reworked zebra, but I have comment about module-related code.

Purpose of API_VERSION's is strictly definition of data structure. If something is changed then version should be changed.

camera_info and camera_screen structures was changed so their version should be changed.
Because changed structures are backward-compatible minor version numbers should be changed.
Reworked zebra module should check this new versions as requirement instead current 1.0.

camera_screen is very common module which is used in all modules so to avoid multiple checks its version is combined with common gui_version.common_api. So minor version of this variable should be increased.

This changes will prevent possible usage of new module with old core and this what API version system is for.

[Dave1116]

I've compiled trunk CHDK ver 1.1.0-1607 with GCC 3.4.6 and it works well .  Had to comment out TBOX references to have the compiler complete the compile.  Other than that this version is working well, even compiled in the canendar upgrade that I like(wish they atleast had the calabdar on the mis. screen as that screen scrolls anyway another item would not be bad).   Anyway just thought i might throw a "well done guys" your way, I know how much work it is and appricate it.

Dave1116

[outslider]

Two things:

1.

Had to comment out TBOX references to have the compiler complete the compile.

Could you specify, what was the problem? Could you post compiler warnings/errors?

2. Why now there is no 'modules' entry in menu? I believe that it was usefull. User could add/remove modules without any changes to menu. Is this caused by startup crash?

[philmoz]

2. Why now there is no 'modules' entry in menu? I believe that it was usefull. User could add/remove modules without any changes to menu. Is this caused by startup crash?

Yes. Even the last version that tsvstar did, that delayed the 'opendir' call, was still randomly crashing.

It's on my list of things to look at; if someone else doesn't do it first.

Phil

[philmoz]

Revision 1632 includes a re-work of the platform/generic/shooting.c code to move most of the code to core/shooting.c (new file).

This means the code is compiled as thumb instead of arm which saves about 4.5K on the CHDK build size.

I've tested this on all my cameras and everything appears to work correctly; but it's a large change and I may have inadvertently broken something.

Please report any 'new' suspicious behaviour with this version here.

Phil.