changelog of trunk including comments / devtalk - page 24 - General Discussion and Assistance - CHDK Forum

changelog of trunk including comments / devtalk

  • 299 Replies
  • 243130 Views
*

Offline nafraf

  • *****
  • 1308
Re: changelog of trunk including comments / devtalk
« Reply #230 on: 09 / August / 2015, 23:30:16 »
Advertisements
In trunk 4219, following this suggestion, I added CAM_DISABLE_RAW_IN_DIGITAL_IS to be used on cameras where raw capture does not work in Digital IS mode.  It was set for a810 and ixus160_elph160.

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: changelog of trunk including comments / devtalk
« Reply #231 on: 10 / August / 2015, 21:29:58 »
Changeset 4220 & 4221 removes the need for PAUSE_FOR_FILE_COUNTER for the G1X, IXUS310 an SX40.

I moved the raw hook call to the task_DvlpSeqTask - I think this is just before the JPEG image gets created.

Might also work for other cameras that use PAUSE_FOR_FILE_COUNTER.

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 reyalp

  • ******
  • 14126
Re: changelog of trunk including comments / devtalk
« Reply #232 on: 16 / August / 2015, 15:15:40 »
Changeset 4220 & 4221 removes the need for PAUSE_FOR_FILE_COUNTER for the G1X, IXUS310 an SX40.

I moved the raw hook call to the task_DvlpSeqTask - I think this is just before the JPEG image gets created.
How thoroughly have you tested this? I'd suggest

DNG in continuous mode
rawop / script hooks. drtest.lua is probably a reasonable test.
PTP remote shoot

Assuming this is robust, we should probably try to standardize on it for new ports (IIRC sx170 required it)
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4451
Re: changelog of trunk including comments / devtalk
« Reply #233 on: 16 / August / 2015, 15:41:27 »
we should probably try to standardize on it for new ports
Unfortunately, we can't. In new models, Canon appears to have abandoned dvlpseqtask (not completely, but the task is no longer called right after exposure). The JPEG creation process and file numbering is now initiated in captseqtask. I've seen this on the ixus160 (r55) and the ixus150 (r54). Some details can be found in the ixus160 porting thread.

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: changelog of trunk including comments / devtalk
« Reply #234 on: 16 / August / 2015, 19:33:54 »
Changeset 4220 & 4221 removes the need for PAUSE_FOR_FILE_COUNTER for the G1X, IXUS310 an SX40.

I moved the raw hook call to the task_DvlpSeqTask - I think this is just before the JPEG image gets created.
How thoroughly have you tested this? I'd suggest

DNG in continuous mode
rawop / script hooks. drtest.lua is probably a reasonable test.
PTP remote shoot

Assuming this is robust, we should probably try to standardize on it for new ports (IIRC sx170 required it)

I've tested all three scenarios.

The drtest.lua script never saves the last DNG file; but this happens even with the old PAUSE_FOR_FILE_COUNTER code on these cameras. It also never saves the last DNG for my G12 so I suspect it's a problem with the script or the hooks.

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: changelog of trunk including comments / devtalk
« Reply #235 on: 28 / August / 2015, 20:51:13 »
I need some recommendation.

I have started adjusting the cpuinfo module to be compatible with ARMv7.
However, the amount of code that is architecture dependent is too big, so it should probably be split. Would it be acceptable if I split out the ARMv5 and v7 code to separate *.c files and include them in cpuinfo.c depending on the THUMB_FW define, or should this be handled in the makefile?

*

Offline reyalp

  • ******
  • 14126
Re: changelog of trunk including comments / devtalk
« Reply #236 on: 28 / August / 2015, 20:55:26 »
I need some recommendation.

I have started adjusting the cpuinfo module to be compatible with ARMv7.
However, the amount of code that is architecture dependent is too big, so it should probably be split. Would it be acceptable if I split out the ARMv5 and v7 code to separate *.c files and include them in cpuinfo.c depending on the THUMB_FW define, or should this be handled in the makefile?
I'd probably just build the module from different C files in the makefile, but I don't feels strongly either way.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4451
Re: changelog of trunk including comments / devtalk
« Reply #237 on: 29 / August / 2015, 14:43:32 »
I'd probably just build the module from different C files in the makefile, but I don't feels strongly either way.
Thanks, I proceeded as I originally intended. I also moved the asm function from the separate file to the arch-specific file and used assembler directives to control the instruction set. This method is not compatible with ARM modules, not sure if we'd ever want to build modules as ARM...

*

Offline reyalp

  • ******
  • 14126
Re: changelog of trunk including comments / devtalk
« Reply #238 on: 30 / August / 2015, 18:41:47 »
The drtest.lua script never saves the last DNG file; but this happens even with the old PAUSE_FOR_FILE_COUNTER code on these cameras.
This should be fixed in 4231. It restored the users raw enable setting before the final shot started saving :-[
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14126
Re: changelog of trunk including comments / devtalk
« Reply #239 on: 30 / August / 2015, 18:52:45 »
Thanks, I proceeded as I originally intended. I also moved the asm function from the separate file to the arch-specific file and used assembler directives to control the instruction set. This method is not compatible with ARM modules, not sure if we'd ever want to build modules as ARM...
This seems fine to me, I don't see any reason we would want to build the modules as arm, and if we did for a one off test, this one module being broken wouldn't be a big deal.

We have a general rule about not having ifdefs in models, but IMO the target CPU architecture should be an exception, because the resulting modules are incompatible anyway.
Don't forget what the H stands for.

 

Related Topics


SimplePortal © 2008-2014, SimplePortal