1.4 development planning thread - page 9 - General Discussion and Assistance - CHDK Forum

1.4 development planning thread

  • 195 Replies
  • 70215 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #80 on: 24 / January / 2015, 16:14:15 »
Advertisements
The script changes should be easy enough to port back to 1.3.
Are you thinking just the header changes, or other stuff too?

This could get messy if we deiced further incompatible changes are needed to the header stuff. I think it's pretty good now though, so maybe not a high risk.

I need to double check; but the original cleanup to the script parameters and allowing long variable names is probably needed as well to support the other header changes.

I would not include the return value changes to the Lua script functions as that would break existing scripts.

I still plan on adding the Av, Tv and Sv data types for parameters; but that could be made a 1.4 feature and only allowed if the script version was 1.4 or higher.

Phil.
« Last Edit: 24 / January / 2015, 16:15:51 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)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

Re: 1.4 development planning thread
« Reply #81 on: 24 / January / 2015, 16:42:35 »
The script changes should be easy enough to port back to 1.3.
Are you thinking just the header changes, or other stuff too?

This could get messy if we deiced further incompatible changes are needed to the header stuff. I think it's pretty good now though, so maybe not a high risk.

I need to double check; but the original cleanup to the script parameters and allowing long variable names is probably needed as well to support the other header changes.

I would not include the return value changes to the Lua script functions as that would break existing scripts.

I still plan on adding the Av, Tv and Sv data types for parameters; but that could be made a 1.4 feature and only allowed if the script version was 1.4 or higher.

Phil.
As a matter of principal,  I'm not in favor of "backporting" changes like this to a "stable" version.   reyalp's proposed timeline for a July release is fine with me as long as we are okay with suggesting more people start using 1.4.0 starting in March.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: 1.4 development planning thread - thinking about a release date?
« Reply #82 on: 25 / January / 2015, 04:28:20 »
I could ask if there is a magic number of weeks we need to wait? ... it's not like we are at risk of running out of version numbers.
Very rhetorical questions...  ;) The goal is to to find a good middle way like reyalp's time line proposal!
While I understand the cost is a bit of reyalp's & hacki's time (and mine - see below)
This is a little bit to cheap. There is also an autobuild for CHDK-DE including a forum and documentation. Or is this not of interests?

We provide an ad-free all-in-one solution. This costs spare time, which is not infinitely available. It takes time to understand all the new developments, e.g. reyalp's heavy raw hook stuff. A good understanding is the base for good documentation.

Sorry for the offtopic.
CHDK-DE:  CHDK-DE links

*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #83 on: 29 / January / 2015, 18:38:18 »
I need some advice. I'm currently using a makefile variable (defined in platform/<cam>/sub/<rev>/makefile.inc) to differentiate between ARM and Thumb-2 (DIGIC 6) ports. However, the current layout of the makefile includes does not seem to favor this method (some parts of the build process get the variable, other parts do not). If I specify the variable on make command line, things seem much better - but having to do this is inconvenient.
Could there be a better way?


*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #84 on: 29 / January / 2015, 18:47:27 »
I need some advice. I'm currently using a makefile variable (defined in platform/<cam>/sub/<rev>/makefile.inc) to differentiate between ARM and Thumb-2 (DIGIC 6) ports. However, the current layout of the makefile includes does not seem to favor this method (some parts of the build process get the variable, other parts do not). If I specify the variable on make command line, things seem much better - but having to do this is inconvenient.
Could there be a better way?

Is this in your SVN repository?

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)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #85 on: 29 / January / 2015, 18:54:11 »
Is this in your SVN repository?
No, it's local and probably not complete (it does build though). Here's a diff: http://filebin.net/swzcehbh0m

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #86 on: 29 / January / 2015, 19:00:15 »
Is this in your SVN repository?
No, it's local and probably not complete (it does build though). Here's a diff: http://filebin.net/swzcehbh0m

Thanks.

Is the problem that not all of the CHDK code is being built as Thumb2, or the THUMB_FW define is not getting set for all source files? Also which source files are affected?

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)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #87 on: 29 / January / 2015, 19:08:03 »
Is the problem that not all of the CHDK code is being built as Thumb2, or the THUMB_FW define is not getting set for all source files?
Could be both. Build is still successful without specifying THUMB_FW=1 on command line, but
- object files go into .o/ instead of .o2/ (the variable is not visible in makefile_base.inc due to include order)
- modules built with the core crash the camera (vector 0x10, did not investigate why exactly)

Quote
Also which source files are affected?
Don't know yet. Saving the romlog does work, modules do not.


*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #88 on: 29 / January / 2015, 19:30:33 »
Is the problem that not all of the CHDK code is being built as Thumb2, or the THUMB_FW define is not getting set for all source files?
Could be both. Build is still successful without specifying THUMB_FW=1 on command line, but
- object files go into .o/ instead of .o2/ (the variable is not visible in makefile_base.inc due to include order)
- modules built with the core crash the camera (vector 0x10, did not investigate why exactly)

Quote
Also which source files are affected?
Don't know yet. Saving the romlog does work, modules do not.

I think this sort of control / definition should go in a new makefile.inc in the camera directory instead of the firmware sub directory (it applies to the camera model, not just one version).

If we then add the following to makefile_base.inc (after the other includes at the top) it should work (note I haven't tested this yet).
Edit: Put this after the shortcut definitions so $(cam) is defined, and move the definition of $O to after this include.
Code: [Select]
ifdef PLATFORM
  -include $(cam)/makefile.inc
endif

Phil.
« Last Edit: 29 / January / 2015, 21:38:45 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)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #89 on: 30 / January / 2015, 16:14:29 »
I think this sort of control / definition should go in a new makefile.inc in the camera directory instead of the firmware sub directory (it applies to the camera model, not just one version).

If we then add the following to makefile_base.inc (after the other includes at the top) it should work (note I haven't tested this yet).
Edit: Put this after the shortcut definitions so $(cam) is defined, and move the definition of $O to after this include.
Code: [Select]
ifdef PLATFORM
  -include $(cam)/makefile.inc
endif
Thanks, that seems to fix the compilation issue (only tried 'make fir' so far, batch targets are still todo).
I just found another issue: the text file reader locks up the camera. When started, it starts repeatedly redrawing the whole screen. I can leave it successfully with the ALT button, but the camera locks up if I press the MENU button.
Rev. 3449 doesn't redraw continuously, it just loses the border right after start. It also doesn't crash the camera.
I suspect that the guard pixel-thing has been enabled somehow for this module since r3449. No idea why it locks up. Issue is independent of the recent makefile rework.
The text reader is working normally on a different camera.

 

Related Topics