Adding new cameras, applying patches into trunk (with source code prepared)

  • 1473 Replies
  • 170325 Views
*

Offline philmoz

  • *****
  • 2936
    • Photos
  • Publish
    Advertisements
    Patch for SX30 & G12 to fix AV bracketing in continuous drive mode.

    Although the PROPCASE_AV value is set in shooting_av_bracketing (via shooting_set_av96_direct) these cameras don't appear to use the new value to change the iris aperture when in continuous shooting mode.

    Added a call to MoveIrisWithAv in shooting_av_bracketing for these two cameras to force the physical aperture change when the property is changed.

    Phil.

    Edit: Also, could we have the 'beta' tag removed from the G12 and SX30 autobuilds please.
    « Last Edit: 30 / April / 2011, 03:56:33 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 reyalp

    • ******
    • 9945
  • Publish
    This one slipped through the cracks, thanks for the reminder.

    Patch for G12 & SX30 (patched against changeset 1150).

    While looking at the EXMEM code in the firmware I noticed the 'memshow' eventproc that displays various useful information about the firmware heap memory allocation.

    Tracing through this code I found a function that fills an array of 10 int's with this memory info. It gives things like start and end address of the heap, total size, size allocated, free space and size of the largest free block. This last one is what the code in 'core_get_free_memory' (in main.c) attempts to calculate in a somewhat crude manner.
    Note that the heap start and size shown here are simply constants from ROM (at least on D10), so they don't account for CHDK stealing part of the heap (assuming CHDK not in exmem).
    Quote
    I checked the firmware for the SX20, D10, S95 and IXUS1000 and they all appear to have this function.
    The format of the structure does not appear to be quite the same in D10. For example, it stores start, length and calculates end, where g12 has start, end, size in the struct itself. I would guess (but haven't verified yet) this varies by dryos release, so we should only need a handful of different versions, rather than one for each camera.

    Rather then exposing the canon firmware dependent structure to normal CHDK code, it would be better to have a standard CHDK function that extracts the useful values in a consistent way, and restrict the ifdefs to the implementation of that function and possibly struct.

    It would probably be worth trying to add this function to the sig finder.

    A function to find the largest free block was found for vxworks a long time ago. I have a patch for this sitting around, probably time to revisit it.
    Don't forget what the H stands for.

    *

    Offline philmoz

    • *****
    • 2936
      • Photos
  • Publish
    This one slipped through the cracks, thanks for the reminder.

    Patch for G12 & SX30 (patched against changeset 1150).

    While looking at the EXMEM code in the firmware I noticed the 'memshow' eventproc that displays various useful information about the firmware heap memory allocation.

    Tracing through this code I found a function that fills an array of 10 int's with this memory info. It gives things like start and end address of the heap, total size, size allocated, free space and size of the largest free block. This last one is what the code in 'core_get_free_memory' (in main.c) attempts to calculate in a somewhat crude manner.
    Note that the heap start and size shown here are simply constants from ROM (at least on D10), so they don't account for CHDK stealing part of the heap (assuming CHDK not in exmem).
    Quote
    I checked the firmware for the SX20, D10, S95 and IXUS1000 and they all appear to have this function.
    The format of the structure does not appear to be quite the same in D10. For example, it stores start, length and calculates end, where g12 has start, end, size in the struct itself. I would guess (but haven't verified yet) this varies by dryos release, so we should only need a handful of different versions, rather than one for each camera.

    Rather then exposing the canon firmware dependent structure to normal CHDK code, it would be better to have a standard CHDK function that extracts the useful values in a consistent way, and restrict the ifdefs to the implementation of that function and possibly struct.

    It would probably be worth trying to add this function to the sig finder.

    A function to find the largest free block was found for vxworks a long time ago. I have a patch for this sitting around, probably time to revisit it.

    OK, thanks. Probably best to put this patch on hold for now. Will revisit it again when I have some time :)

    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 reyalp

    • ******
    • 9945
  • Publish
    Patch for SX30 & G12 to fix AV bracketing in continuous drive mode.

    Although the PROPCASE_AV value is set in shooting_av_bracketing (via shooting_set_av96_direct) these cameras don't appear to use the new value to change the iris aperture when in continuous shooting mode.

    Added a call to MoveIrisWithAv in shooting_av_bracketing for these two cameras to force the physical aperture change when the property is changed.
    Added, changeset 1162
    Note I changed the logic with 'value' slightly in shooting.c, since 0 is theoretically a valid value (not that I see Canon shipping an f/1.0 lens in a P&S any time soon ;))

    Also wanted to check that Av override works correctly in with just the propcase in non-continuous mode ? Otherwise the _MoveIrisWithAv would be needed elsewhere, for scripting at least.
    Quote
    Edit: Also, could we have the 'beta' tag removed from the G12 and SX30 autobuilds please.
    Done, 1163

    edit
    OK, thanks. Probably best to put this patch on hold for now. Will revisit it again when I have some time :)

    Phil.
    I'm looking into putting the functions into the sig finder at least. The vxworks one is slightly annoying because you need to find the mempart id of the canon heap for each camera :/
    « Last Edit: 30 / April / 2011, 23:23:15 by reyalp »
    Don't forget what the H stands for.


    *

    Offline philmoz

    • *****
    • 2936
      • Photos
  • Publish
    Added, changeset 1162
    Note I changed the logic with 'value' slightly in shooting.c, since 0 is theoretically a valid value (not that I see Canon shipping an f/1.0 lens in a P&S any time soon ;))
    Many thanks.

    Although, wouldn't a value of 0 be an f/0.0 lens (infinite aperture)? (f/1.0 = Av value of 96 by my calculation) :)

    Quote
    Also wanted to check that Av override works correctly in with just the propcase in non-continuous mode ? Otherwise the _MoveIrisWithAv would be needed elsewhere, for scripting at least.
    Yes, Av override works fine in single shot mode.

    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 reyalp

    • ******
    • 9945
  • Publish
    Although, wouldn't a value of 0 be an f/0.0 lens (infinite aperture)? (f/1.0 = Av value of 96 by my calculation) :)
    APEX Av = log2 (f number)2. Camera works in APEX*96 so 0 is f/1.0 and 96 is f/1.4 (or f/sqrt(2) if you want to be pedantic ;))
    Don't forget what the H stands for.

    *

    Offline reyalp

    • ******
    • 9945
  • Publish
    I'm looking into putting the functions into the sig finder at least. The vxworks one is slightly annoying because you need to find the mempart id of the canon heap for each camera :/
    in changeset 1165 I've added GetMemInfo to the sig finder for dryos. There appears to only be 2 variants, < R39 and >= R39

    I haven't checked all the cams, but all the ones I did check were all 100% matches so it should be good.
    Don't forget what the H stands for.

    *

    Offline philmoz

    • *****
    • 2936
      • Photos
  • Publish
    I'm looking into putting the functions into the sig finder at least. The vxworks one is slightly annoying because you need to find the mempart id of the canon heap for each camera :/
    in changeset 1165 I've added GetMemInfo to the sig finder for dryos. There appears to only be 2 variants, < R39 and >= R39

    I haven't checked all the cams, but all the ones I did check were all 100% matches so it should be good.
    Looking at the code the older version returns 9 values instead of 10, with the 'end address' missing (it calculates this from the start address and size in the function that uses the values).

    What's the best way to handle this in the wrapper code?
    Is it safe to use the CAM_DRYOS_2_3_R39 define to have differentiate the two - and fill in the missing value if this is not defined>

    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 reyalp

    • ******
    • 9945
  • Publish
    I'm looking into putting the functions into the sig finder at least. The vxworks one is slightly annoying because you need to find the mempart id of the canon heap for each camera :/
    in changeset 1165 I've added GetMemInfo to the sig finder for dryos. There appears to only be 2 variants, < R39 and >= R39

    I haven't checked all the cams, but all the ones I did check were all 100% matches so it should be good.
    Looking at the code the older version returns 9 values instead of 10, with the 'end address' missing (it calculates this from the start address and size in the function that uses the values).
    That agrees with my observation.
    Quote
    What's the best way to handle this in the wrapper code?
    Is it safe to use the CAM_DRYOS_2_3_R39 define to have differentiate the two - and fill in the missing value if this is not defined>
    As safe as anything else in CHDK ;)
    Don't forget what the H stands for.

    *

    Offline philmoz

    • *****
    • 2936
      • Photos
  • Publish
    Patch to speed up finsig signature finder.

    On the G12 / SX30 this reduces the time to generate the stubs_entry.S file from 29 seconds to 14 seconds (on my dev PC).

    Tested on a sampling of vxworks and dryos cameras and this still generates the same stubs_entry.S file (have not tested all cameras though so there's a small chance this may break something).

    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