new branch - CHDK : Elf Edition - Developers wanted - page 29 - General Discussion and Assistance - CHDK Forum  

new branch - CHDK : Elf Edition - Developers wanted

  • 312 Replies
  • 58290 Views
*

Offline philmoz

  • *****
  • 3107
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #280 on: 18 / October / 2014, 18:06:23 »
Advertisements
Modules that take over the camera until they exit (e.g. games and the Mandelbrot generator) don't have to be integrated into the menu. You can select a module .FLT file in the file browser and run it directly from there. With a bit of work, these could potentially be added to the user menu much like we allow scripts to be added.

So we already have a primitive method of allowing any module to be executed.

Opening the core up to allow arbitrary module to load and inject themselves into the menu, and run in the background could be done; but would require a fair bit of work.

The current version/dependancy checking between compiled modules and the core code probably needs review as well.

Phil.
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)

Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #281 on: 18 / October / 2014, 19:01:57 »
So we already have a primitive method of allowing any module to be executed.
I guess that you can also do like Steev and rewrite / recompile an existing module (like a game) and insert your own code.  Add the hijacked game to the user menu and it's easy to access (although you have to live with the game's name).

As I study the FLT mechanism, I think I see the first big snag - module_exportlist.c .  If I understand the code correctly,  any CHDK variable that you wish to reference from within any module needs to be in this list.  So module writers need to live with what is in the list or their author needs to "request" some additions?


Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline srsa_4c

  • ******
  • 3906
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #282 on: 18 / October / 2014, 19:59:15 »
With a bit of work, these could potentially be added to the user menu much like we allow scripts to be added.
This has already been done, I'm using it to start my extra modules.

A dynamic (sub)menu for (simple) modules would be a nice feature. I think it was planned but its implementation was causing FsIoNotify asserts.

*

Offline philmoz

  • *****
  • 3107
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #283 on: 18 / October / 2014, 20:12:57 »
As I study the FLT mechanism, I think I see the first big snag - module_exportlist.c .  If I understand the code correctly,  any CHDK variable that you wish to reference from within any module needs to be in this list.  So module writers need to live with what is in the list or their author needs to "request" some additions?

Correct, that's used to link the loaded module code into the core CHDK running in memory.
If a function or variable is not exposed here it's not available to a module.
For variables I added the camera_XXX structures to reduce the number of entries in module_exportlist.c - this way only the structure addresses needs to be fixed when the module loads.

With a bit of work, these could potentially be added to the user menu much like we allow scripts to be added.
This has already been done, I'm using it to start my extra modules.

A dynamic (sub)menu for (simple) modules would be a nice feature. I think it was planned but its implementation was causing FsIoNotify asserts.

With the recent fixes to the open/close code (to use the Canon semaphore) this might work now without risking the startup crashes it caused before.

Phil.
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)


*

Offline srsa_4c

  • ******
  • 3906
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #284 on: 02 / November / 2014, 16:40:51 »
We need to be more careful with include/versions.h . I just realized that my frequently used hex viewer module is corrupting the CHDK configuration. I compiled it in May 2013 and just copied the module to my cards ever since. It loads on today's trunk too. It has a version check for CONF_VERSION, and that version hasn't been updated even though the config structures have changed.
Stuff like this can also affect those who only update their diskboot files but not the modules. It's not a big thing (can be solved with a reinstall), but annoying.
This bug report is probably not related (or at least that issue was not caused by my module), but who knows.

*

Offline reyalp

  • ******
  • 11900
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #285 on: 02 / November / 2014, 17:39:51 »
We need to be more careful with include/versions.h . I just realized that my frequently used hex viewer module is corrupting the CHDK configuration. I compiled it in May 2013 and just copied the module to my cards ever since. It loads on today's trunk too. It has a version check for CONF_VERSION, and that version hasn't been updated even though the config structures have changed.
Thank for the reminder. It would be good to have some clear guidelines on when the version needs to be updated. We have http://chdk.wikia.com/wiki/Module_System but it's not very clear and also out of date.

I'm not terribly clear on this myself, but I guess conf, screen etc are pretty straightforward, any change to order or meaning of conf items should be a new major version.

Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3107
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #286 on: 01 / December / 2014, 21:12:00 »
After some discussions with waterwingz on his conversion of the GPS code to a module, I decided to take a closer look at the module implementation :o

I think there's some room for improvement (and some potential bugs to be fixed).

One thing I want to do is change the 'struct XXX { ... };' definitions to 'typedef struct { ... } XXX;'
There's only two (flat_hdr and ModuleInfo).

This aligns with the usage across most of the code, and is my preferred pattern.

Not a big change; but it could break existing module code not in SVN (I know srsa_4c has a few custom modules).
So I wanted to get a consensus before committing to SVN.

Any objections?

Phil.
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)

*

Offline srsa_4c

  • ******
  • 3906
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #287 on: 02 / December / 2014, 12:09:25 »
I think there's some room for improvement (and some potential bugs to be fixed).

...

So I wanted to get a consensus before committing to SVN.
No objections from my side. You can leave notes here or in the commit log if the improvements/changes turn out to be nontrivial.


*

Offline philmoz

  • *****
  • 3107
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #288 on: 02 / December / 2014, 13:48:42 »
I think there's some room for improvement (and some potential bugs to be fixed).

...

So I wanted to get a consensus before committing to SVN.
No objections from my side. You can leave notes here or in the commit log if the improvements/changes turn out to be nontrivial.

One thing I noticed is that, although the file browser allows selecting a .FLT file from anywhere on the card, it will only be run if it lives in the A/CHDK/MODULES directory. I think this is a side effect of changes I made to this part of the module loader a when I added the auto-load / unload stuff.

I can see two options:
1 - simplify the code and only allow modules to be loaded from A/CHDK/MODULES, add warning in file browser if selecting a .FLT from somewhere else.
2 - fix the code and allow loading modules from anywhere in the file browser, may require some additional memory

I vote for option 1.
Edit: I think I've worked out a reasonable way to support module loading from any directory. This should also fix modules added to the user menu from arbitrary directories.

Phil.
« Last Edit: 02 / December / 2014, 22:10:28 by philmoz »
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)

*

Offline philmoz

  • *****
  • 3107
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #289 on: 02 / December / 2014, 16:18:11 »
This is the list of things I'm looking to change/fix:
- remove (or fix) ability to load modules from directory other than A/CHDK/MODULES (see previous post)
- create .bss segment at runtime instead of storing a block of 0's in the module file (store .bss size only)
- add a simple lock to help prevent multiple tasks from trying to load modules at the same time (code uses global variables)
- remove global variables where possible
- keep the uncached memory buffer used to load the module file between module loads, instead of re-allocating it each time
- move the symbol table used to link modules to CHDK code to a separate .c file (out of module_load.c), currently module_load.c has to load all the .h files in order to resolve the addresses in the symbol table. An auto generated file can eliminate this.
- general cleanup and commenting of the code

I'll post a patch once I've done more testing, I'd like to get wider testing of these changes before committing to SVN.

Phil.

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)

 

Related Topics