Module code V2 - test branch. - page 3 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 2 [3]   Go Down

Module code V2 - test branch.

  • 29 Replies
  • 16456 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Module code V2 - test branch.
« Reply #20 on: 12 / April / 2013, 03:51:36 »
Advertisements
Quote from: rudi on 12 / April / 2013, 03:40:32
Quote from: philmoz on 08 / April / 2013, 18:19:01
Sounds like your compiler is not defining __SIZEOF_POINTER__ correctly.
Thank you, Phil. There was the error.

The shared server use gcc, but there are missing many precompiler definitions.
My first way was a patch for __SIZEOF_POINTER__
Code: [Select]
#if __SIZEOF_POINTER__ == 4
    base_interface_t*   lib;                    // Pointer to interface library
#else
    uint32_t            lib;                    // all other __SIZEOF_POINTER__ sizes
#endifNow I use my own x64_64-gcc crosscompiler since rev. 2694. It should be good.

I've found it also fails on OS X so I'm going to change the code to be compilers independent.

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)
*

Offline srsa_4c

  • ******
  • 4451
Re: Module code V2 - test branch.
« Reply #21 on: 12 / April / 2013, 21:03:59 »
@philmoz

Is it possible for a GUI module to remain loaded when exiting ALT mode?
I've been trying to update my memory viewer mod, and this feature does not seem to work correctly. It's very much possible that I'm doing something stupid though.
If I don't set the (newly introduced) 'running' variable to 0 in _module_exit_alt(), the module continues running in the background. However, subsequent tries to load other GUI modules seem to activate my running module instead of the chosen module. What am I missing?
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Module code V2 - test branch.
« Reply #22 on: 12 / April / 2013, 21:23:07 »
Quote from: srsa_4c on 12 / April / 2013, 21:03:59
@philmoz

Is it possible for a GUI module to remain loaded when exiting ALT mode?
I've been trying to update my memory viewer mod, and this feature does not seem to work correctly. It's very much possible that I'm doing something stupid though.
If I don't set the (newly introduced) 'running' variable to 0 in _module_exit_alt(), the module continues running in the background. However, subsequent tries to load other GUI modules seem to activate my running module instead of the chosen module. What am I missing?

No, there can be only one 'simple' module loaded using 'gui_menu_run_fltmodule' (via module_run in module_load.c).
If this module does not unload then any attempt to load a new one will just call the one already loaded.

If you want to have a module that has a longer lifetime you need to define it's own library pointer and code in modules.c, and change the way it is loaded in the menu system to not use 'gui_menu_run_fltmodule'.

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)
*

Offline srsa_4c

  • ******
  • 4451
Re: Module code V2 - test branch.
« Reply #23 on: 12 / April / 2013, 22:00:39 »
Quote from: philmoz on 12 / April / 2013, 21:23:07
No, there can be only one 'simple' module loaded using 'gui_menu_run_fltmodule' (via module_run in module_load.c).
If this module does not unload then any attempt to load a new one will just call the one already loaded.

If you want to have a module that has a longer lifetime you need to define it's own library pointer and code in modules.c, and change the way it is loaded in the menu system to not use 'gui_menu_run_fltmodule'.
I see, thanks.
I was trying to maintain this as a drop-in (1 file) replacement for the original module. Since it has several state variables, putting it into background was a convenient way to not having to set it up over and over. I could make it save its state into its config file and reload that upon activation, but I don't like that idea (it could hang the camera when a movie is being recorded for example). Making bigger changes in other CHDK files would make it more painful to maintain and use.
Unfortunately I can't think of any other possible (GUI) module that would benefit from being able to run remain in the background.
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Module code V2 - test branch.
« Reply #24 on: 12 / April / 2013, 23:10:53 »
Quote from: srsa_4c on 12 / April / 2013, 22:00:39
Quote from: philmoz on 12 / April / 2013, 21:23:07
No, there can be only one 'simple' module loaded using 'gui_menu_run_fltmodule' (via module_run in module_load.c).
If this module does not unload then any attempt to load a new one will just call the one already loaded.

If you want to have a module that has a longer lifetime you need to define it's own library pointer and code in modules.c, and change the way it is loaded in the menu system to not use 'gui_menu_run_fltmodule'.
I see, thanks.
I was trying to maintain this as a drop-in (1 file) replacement for the original module. Since it has several state variables, putting it into background was a convenient way to not having to set it up over and over. I could make it save its state into its config file and reload that upon activation, but I don't like that idea (it could hang the camera when a movie is being recorded for example). Making bigger changes in other CHDK files would make it more painful to maintain and use.
Unfortunately I can't think of any other possible (GUI) module that would benefit from being able to run remain in the background.

You could add the state information to the 'conf' structure.

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)
*

Offline srsa_4c

  • ******
  • 4451
Re: Module code V2 - test branch.
« Reply #25 on: 11 / May / 2013, 11:24:31 »
Quote from: philmoz on 12 / April / 2013, 21:23:07
there can be only one 'simple' module loaded using 'gui_menu_run_fltmodule' (via module_run in module_load.c).
You probably won't like this, but I'm missing this functionality. I also noticed that it's no longer possible to launch such simple modules from the file browser.
I've been trying to work around this limitation, but so far without luck.

The main problem seems to be that all simple modules share a single module_handler_t structure (h_run). If a simple module remains loaded, module_run() will start it regardless of the requested module name. Unfortunately I'm kind of lost between all these structures and pointers.

My goal would be to enable such modules to remain in the background, and getting re-activated on request. In some of my trials I managed to leave my module loaded and use other modules, but could not re-gain access to that loaded module due to the missing module_handler_t values.

Can you give some advice about possible ways of implementing the above?

Quote
You could add the state information to the 'conf' structure.
That wouldn't be smart for an unofficial module.
I also can't use my own (module specific) config file, because that could hang the camera during movie recording. I've been thinking about adding a special (persistent) module which could store arbitrary data, but that still wouldn't solve the problem that on certain cameras file operations (e.g. trying to load a module) cause hang when movie record is in progress.

This (possible hang) is a real issue btw. (and is of course independent of the above), and IMHO it should be dealt with somehow. It probably affects all some older VxWorks models.
update: looks like this affects the a410 but not the a430, so a (port-)local fix could be enough.
« Last Edit: 11 / May / 2013, 14:39:27 by srsa_4c »
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Module code V2 - test branch.
« Reply #26 on: 11 / May / 2013, 18:39:53 »
Quote from: srsa_4c on 11 / May / 2013, 11:24:31
Quote from: philmoz on 12 / April / 2013, 21:23:07
there can be only one 'simple' module loaded using 'gui_menu_run_fltmodule' (via module_run in module_load.c).
You probably won't like this, but I'm missing this functionality. I also noticed that it's no longer possible to launch such simple modules from the file browser.
I've been trying to work around this limitation, but so far without luck.

The main problem seems to be that all simple modules share a single module_handler_t structure (h_run). If a simple module remains loaded, module_run() will start it regardless of the requested module name. Unfortunately I'm kind of lost between all these structures and pointers.

My goal would be to enable such modules to remain in the background, and getting re-activated on request. In some of my trials I managed to leave my module loaded and use other modules, but could not re-gain access to that loaded module due to the missing module_handler_t values.

Can you give some advice about possible ways of implementing the above?

The purpose of the 'simple' module is to handle cases like the games that have a limited lifespan and effectively take over the system while running. There is no need for them to run in the background and there can only be one running at a time.

The 'simple' module loader could be extended to support more than one at a time - I didn't envisage this usage; but I see where you are coming from.

I removed the ability to run a module from the file browser because of the risk of running a module without properly initialising its handler in modules.c. It could be possible to add this back; but it would only work for 'simple' modules.

The other type of module that is currently supported are modules that need to remain in memory (e.g. script languages) or have a complex interface. These must have a custom module handler in modules.c and need to be accessed only through this handler (I'll add some comments to this in the code later).

Quote
Quote
You could add the state information to the 'conf' structure.
That wouldn't be smart for an unofficial module.
I also can't use my own (module specific) config file, because that could hang the camera during movie recording. I've been thinking about adding a special (persistent) module which could store arbitrary data, but that still wouldn't solve the problem that on certain cameras file operations (e.g. trying to load a module) cause hang when movie record is in progress.

This (possible hang) is a real issue btw. (and is of course independent of the above), and IMHO it should be dealt with somehow. It probably affects all some older VxWorks models.
update: looks like this affects the a410 but not the a430, so a (port-)local fix could be enough.

This is really a separate problem from the module system.

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)
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Module code V2 - test branch.
« Reply #27 on: 11 / May / 2013, 20:20:38 »
Quote from: srsa_4c on 11 / May / 2013, 11:24:31
Quote from: philmoz on 12 / April / 2013, 21:23:07
there can be only one 'simple' module loaded using 'gui_menu_run_fltmodule' (via module_run in module_load.c).
You probably won't like this, but I'm missing this functionality. I also noticed that it's no longer possible to launch such simple modules from the file browser.
I've been trying to work around this limitation, but so far without luck.

Attached is a patch (against trunk 2767) that allows up to 4 simple modules to be running.
It also adds the ability to run a simple module from the file browser.

Please test this and let me know if it solves your problem.

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)
*

Offline srsa_4c

  • ******
  • 4451
Re: Module code V2 - test branch.
« Reply #28 on: 11 / May / 2013, 21:10:41 »
Quote from: philmoz on 11 / May / 2013, 20:20:38
Attached is a patch (against trunk 2767) that allows up to 4 simple modules to be running.
It also adds the ability to run a simple module from the file browser.

Please test this and let me know if it solves your problem.
It does, thank you very much for this.
I have 2 notes on the patch:
- gui_fselect.c will need #include "module_load.h"
- module_run() seems to assume that its parameter points to a persistent string. I think this may not be true when it's called from a module (or when that string is a local variable on stack).
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Module code V2 - test branch.
« Reply #29 on: 12 / May / 2013, 02:20:42 »
Quote from: srsa_4c on 11 / May / 2013, 21:10:41
Quote from: philmoz on 11 / May / 2013, 20:20:38
Attached is a patch (against trunk 2767) that allows up to 4 simple modules to be running.
It also adds the ability to run a simple module from the file browser.

Please test this and let me know if it solves your problem.
It does, thank you very much for this.
I have 2 notes on the patch:
- gui_fselect.c will need #include "module_load.h"
- module_run() seems to assume that its parameter points to a persistent string. I think this may not be true when it's called from a module (or when that string is a local variable on stack).
Thanks for that. The 'name' storage in module_run needs some work - really needs to copy the string instead of storing the pointer.

Phil.

Edit: added to trunk in revision 2769

« Last Edit: 12 / May / 2013, 03:25:05 by philmoz »
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)
Pages: 1 2 [3]   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal