1.4 development planning thread - page 6 - General Discussion and Assistance - CHDK Forum  
« previous next »
Pages: 1 2 3 4 5 [6] 7 8 9 10 11 ... 20   Go Down

1.4 development planning thread

  • 195 Replies
  • 69253 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #50 on: 15 / January / 2015, 18:17:28 »
Advertisements
Quote from: srsa_4c on 15 / January / 2015, 17:48:39
I have almost finished porting the sx280 to current trunk. My current problems are:
- COLOR_TRANSPARENT and COLOR_BLACK
The frame buffer I'm drawing to is in a 16bpp YUV format. There is no palette (the firmware may use a palette somewhere but that doesn't matter).
I'm currently using 8 bits to represent a color (2 bits Y, 3 bits U and V), and unpack the color components in draw_pixel_std(). I plan to make a benchmark for this, perhaps a lookup table can be faster.
I'm not using transparency for speed reasons (transparency information is kept in a separate 8bpp frame buffer). And, of course, color 0xff is not black.
Would it make sense to export these 2 "colors" for the modules? Or, should I hardcode them in DIGIC 6 modules? I don't like the latter very much as the drawing method may change in the future.

Maybe I'm not understanding this correctly; but it seems to me that (for 1.4 at least) removing the ability for users to select custom colors might solve the problem. Then you're only left with the CHDK 'colors' - instead of looking up the palette color via the chdk_colors array you could use the IDX_xxx values for colors and convert them to 16bit YUV in the drawing code.

e.g.
    #define COLOR_WHITE             (chdk_colors[IDX_COLOR_WHITE])
becomes
    #define COLOR_WHITE             IDX_COLOR_WHITE
in gui_draw.h.

You then have a lookup table in gui_draw.c for converting to YUV.

For black we would replace the definition in palette.h with an IDX_COLOR_BLACK version in gui_draw.h. Transparent remains as 0.

Quote
- Multiple cameras using the same firmware
The sx280 port is also usable on the sx270 and sx275 models (they have the exact same firmware). This problem is not new, but 3 is a new record. Should I add 2 identical ports or could we do something else about this?

I would initially go with separate directories/ports for each camera - this avoids the inevitable questions when people check the build info on the camera and see the wrong model. Ideally the build system should be able to take care of this automatically; but I don't know how much work it will be.

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: 1.4 development planning thread
« Reply #51 on: 15 / January / 2015, 19:21:47 »
Quote from: philmoz on 15 / January / 2015, 18:17:28
Maybe I'm not understanding this correctly; but it seems to me that (for 1.4 at least) removing the ability for users to select custom colors might solve the problem. Then you're only left with the CHDK 'colors' - instead of looking up the palette color via the chdk_colors array you could use the IDX_xxx values for colors and convert them to 16bit YUV in the drawing code.

e.g.
    #define COLOR_WHITE             (chdk_colors[IDX_COLOR_WHITE])
becomes
    #define COLOR_WHITE             IDX_COLOR_WHITE
in gui_draw.h.

You then have a lookup table in gui_draw.c for converting to YUV.

For black we would replace the definition in palette.h with an IDX_COLOR_BLACK version in gui_draw.h. Transparent remains as 0.
I lost track of the palette related changes, I'll try to update my knowledge.

Attached is was a patch with the current state of the DIGIC 6 related change (including the sx280 port). I'm sure there's a lot that can be improved (for example the build system/makefile related changes). I had to change the benchmark to make it compile (-O0 creates some unusable relocations).

edit:
lib/lua/setjmp.S is taken as-is from newlib 2.1
I did not try to batch-build the old ports yet.
« Last Edit: 29 / January / 2015, 18:25:18 by srsa_4c »
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #52 on: 15 / January / 2015, 23:43:18 »
Quote from: philmoz on 15 / January / 2015, 18:17:28
Quote
- Multiple cameras using the same firmware
The sx280 port is also usable on the sx270 and sx275 models (they have the exact same firmware). This problem is not new, but 3 is a new record. Should I add 2 identical ports or could we do something else about this?

I would initially go with separate directories/ports for each camera - this avoids the inevitable questions when people check the build info on the camera and see the wrong model. Ideally the build system should be able to take care of this automatically; but I don't know how much work it will be.

Phil.

After thinking about this, I've made some changes to the build system that might work better for this (patch attached).

The changes are:
- Add two new definitions TARGET_CAM & TARGET_FW, if not specified they default to PLATFORM and PLATFORMSUB respectively.
- If either TARGET_xxx is defined then the build takes place using the source in PLATFORM/PLATFORMSUB; but the build info compiled in the code & output the .zip filenames use TARGET_CAM and TARGET_FW.
- Updated batch build logic and camera_list.csv files to include TARGET_FW to create 'clone' versions; but with correct firmware version in build info.

Some examples:

    make PLATFORM=a1100 PLATFORMSUB=100c firzipsubcomplete
will create zip files named a1100-100c-... and the build info in CHDK will show the camera as a1100 and firmware as 100c (same as existing system).

    make PLATFORM=a1100 PLATFORMSUB=100c TARGET_FW=100b firzipsubcomplete
will create zip files named a1100-100b-... and the build info in CHDK will show the camera as a1100 and firmware as 100b; but the source code will come from the platform/a1100/sub/100c directory.

The end result of a batch build is the same set of zip files; but the versions that were previously just copies now have the correct version info inside CHDK.

This should also work for the sx270/sx275/sx280 where the same source code can build multiple camera versions.

Issues:
- bin_compat.h generation is broken from the changes to camera_list.csv. Since this does not appear to be used I turned it off. If it really is not used then we should delete this.
- will probably break CHDK-Shell.
- slightly longer batch build time since the 'clone' versions are now built instead of copied

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 reyalp

  • ******
  • 14080
Re: 1.4 development planning thread
« Reply #53 on: 16 / January / 2015, 00:32:37 »
Quote from: philmoz on 15 / January / 2015, 23:43:18
This should also work for the sx270/sx275/sx280 where the same source code can build multiple camera versions.
If these cameras have unique PIDs (which I expect they do) the correct one will have to be set to make a usable FI2.
(edit: I only skimmed the patch, so disregard if it already does this)
Quote
Issues:
- bin_compat.h generation is broken from the changes to camera_list.csv. Since this does not appear to be used I turned it off. If it really is not used then we should delete this.
I would like to see the bin_compat stuff finished for 1.4 if possible.
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #54 on: 16 / January / 2015, 04:25:53 »
Quote from: reyalp on 16 / January / 2015, 00:32:37
Quote from: philmoz on 15 / January / 2015, 23:43:18
This should also work for the sx270/sx275/sx280 where the same source code can build multiple camera versions.
If these cameras have unique PIDs (which I expect they do) the correct one will have to be set to make a usable FI2.
(edit: I only skimmed the patch, so disregard if it already does this)
Quote
Issues:
- bin_compat.h generation is broken from the changes to camera_list.csv. Since this does not appear to be used I turned it off. If it really is not used then we should delete this.
I would like to see the bin_compat stuff finished for 1.4 if possible.

Updated patch:
- Adds TARGET_PID to allow override PLATFORMID when building (defaults to PLATFORMID if not set). Also added as an override column to camera_list.csv.
- Forces creation of bin_compat.h for the specific target camera and firmware being built. This means each camera will have the correct values in bin_compat.h for its firmware and camera, multiple entries are no longer needed (to cater for copied zip files). Since bin_compat.h is a compile-time generated file it can be removed from SVN.

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 msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: 1.4 development planning thread
« Reply #55 on: 16 / January / 2015, 06:46:05 »
Quote from: philmoz on 15 / January / 2015, 23:43:18
- will probably break CHDK-Shell.
This would be a great disaster and the end of the shell. Probably there will be no more updates for the CHDK-shell. The off of trace assembla is already a big problem.

In the consequence we would lose contributors and tester.

msl
Logged
CHDK-DE:  CHDK-DE links
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
Re: 1.4 development planning thread
« Reply #56 on: 16 / January / 2015, 09:34:38 »
Quote from: msl on 16 / January / 2015, 06:46:05
Quote from: philmoz on 15 / January / 2015, 23:43:18
- will probably break CHDK-Shell.
This would be a great disaster and the end of the shell. Probably there will be no more updates for the CHDK-shell. The off of trace assembla is already a big problem.

In the consequence we would lose contributors and tester.
I don't think we have heard anything from whim in quite a while.  I know he said he still "lurks" but he has not logged in since October.

Time to consider what a "newbie friendly" replacement GUI build app might need to do?
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline srsa_4c

  • ******
  • 4451
Re: 1.4 development planning thread
« Reply #57 on: 16 / January / 2015, 15:16:17 »
Quote from: philmoz on 16 / January / 2015, 04:25:53
Updated patch:
- Adds TARGET_PID to allow override PLATFORMID when building (defaults to PLATFORMID if not set). Also added as an override column to camera_list.csv.
Sounds good. We'll have to decide which one of the current copied ports should we keep as some of those have drifted away slightly (a810 vs a1300 for example).
Quote
- Forces creation of bin_compat.h for the specific target camera and firmware being built. This means each camera will have the correct values in bin_compat.h for its firmware and camera, multiple entries are no longer needed (to cater for copied zip files). Since bin_compat.h is a compile-time generated file it can be removed from SVN.
The sigfinder doesn't support DIGIC 6 firmware images at all ATM, stubs_entry.S won't have the necessary lines for those ports.

We could also store bin_compat related data in the csv (addresses, etc) as it seems to be the most appropriate place for that data.

Quote from: waterwingz on 16 / January / 2015, 09:34:38
Time to consider what a "newbie friendly" replacement GUI build app might need to do?
It probably should be much simpler than the current shell (both its code and its GUI).
The old shell will continue to be working as-is for 1.3.
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.4 development planning thread
« Reply #58 on: 16 / January / 2015, 15:39:31 »
Quote from: srsa_4c on 16 / January / 2015, 15:16:17
We could also store bin_compat related data in the csv (addresses, etc) as it seems to be the most appropriate place for that data.

I thought about that; but the camera_list.csv file is (currently) only used for batch builds, not individual compiles.

If I could figure out an easy way to use it for all builds then a lot of the values in platform/cam/sub/fw/makefile.inc could be moved to the csv file (e.g.PLATFORMID, PLATFORMOS, etc). This would also then give a single reference file with a lot of useful information.

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: 1.4 development planning thread
« Reply #59 on: 16 / January / 2015, 15:43:37 »
Quote from: philmoz on 16 / January / 2015, 15:39:31
I thought about that; but the camera_list.csv file is (currently) only used for batch builds, not individual compiles.

If I could figure out an easy way to use it for all builds then a lot of the values in platform/cam/sub/fw/makefile.inc could be moved to the csv file (e.g.PLATFORMID, PLATFORMOS, etc). This would also then give a single reference file with a lot of useful information.
We could generate a header file from the csv content for bin_compat, and other information could also be extracted with awk for example, as a build step.
Logged
Pages: 1 2 3 4 5 [6] 7 8 9 10 11 ... 20   Go Up
« previous next »
 

Related Topics