SX10 Shutter Speeds - page 4 - General Discussion and Assistance - CHDK Forum

SX10 Shutter Speeds

  • 47 Replies
  • 21045 Views
*

Offline reyalp

  • ******
  • 14134
Re: SX10 Shutter Speeds
« Reply #30 on: 07 / October / 2009, 21:35:03 »
Advertisements
I do understand that.  I don't have no coding experience, just not experience in current C.  I usually tend to pick up and learn things quickly, mostly by doing what I'm doing, open and take apart what has already been created.
OK, but you need to know the difference between a pre-processor directive and an actual C statement, among many other things. You should not expect to get a beginners C education here.

I'm a strong proponent of learning by doing, but trying to do this with CHDK is going to be difficult.
1) it is much more difficult to debug than something on your PC. You can't try a bit of code and print the result, you can't open it up the debugger and step through it when things goes bad.
2) it does a lot of peculiar, hacky low level stuff because it interacts with undocumented, reverse engineered canon firmware. Things that would be OK in regular software will blow up in your face, and things that look insane turn out to be required.

Quote
The newer version of the GUI has it labbelled as ELF objdump  "Keep disassembly of main.elffor each cam..."
Ok, that is indeed the disassembly of CHDK itself, not of your cameras firmware dump. This would be useful for debug your build process, but obviously won't help you reverse engineer the cameras firmware.
Don't forget what the H stands for.

Re: SX10 Shutter Speeds
« Reply #31 on: 07 / October / 2009, 21:51:32 »
I'm a strong proponent of learning by doing, but trying to do this with CHDK is going to be difficult.
1) it is much more difficult to debug than something on your PC. You can't try a bit of code and print the result, you can't open it up the debugger and step through it when things goes bad.
2) it does a lot of peculiar, hacky low level stuff because it interacts with undocumented, reverse engineered canon firmware. Things that would be OK in regular software will blow up in your face, and things that look insane turn out to be required.
Don't worry, I'm not planning on doing anything too radical (besides, that's why I'm using my work camera for now...).
Anyways, I put the proper if statements in and it worked like it was intended.  I was mainly just trying tomake certain that it was getting passed to the proper section of the if statement for assignment, which it is doing (also after adding in the additional >960 part as well).  So it may very well be that the shutter speed is getting limited elsewhere leaving me SOL for now.  There are a few minor things I may still try.

As a side note, is there any reason why the if needs to be here at all and not just use the "1000000.0*pow(2.0, -apex_tv/96.0)" function for them all?  I would suppose that it is mainly to leave things in the regular range that aren't a problem alone they way they are intended in the firmware.

Ok, that is indeed the disassembly of CHDK itself, not of your cameras firmware dump. This would be useful for debug your build process, but obviously won't help you reverse engineer the cameras firmware.
yes, I understand that now, just thought I happened upon a short cut (firmware already disassembled for me).  Are firmware disassemblies not available in a repository somewhere? or is it just the dump binaries?

Anyways, thanks for the help for now.  Let me know if you have any further insights, as I really would like to solve my shutter problem if at all possible.  Otherwise, I'll have to revert to using my old S2 or A570 for high speed shots.

*

Offline reyalp

  • ******
  • 14134
Re: SX10 Shutter Speeds
« Reply #32 on: 07 / October / 2009, 22:02:20 »
As a side note, is there any reason why the if needs to be here at all and not just use the "1000000.0*pow(2.0, -apex_tv/96.0)" function for them all?  I would suppose that it is mainly to leave things in the regular range that aren't a problem alone they way they are intended in the firmware.
The canon apex2us code doesn't do exactly the same thing, and since this would affect all photographs, it's far better to leave the default as completely unchanged.
Don't forget what the H stands for.

Re: SX10 Shutter Speeds
« Reply #33 on: 07 / October / 2009, 22:19:55 »
The canon apex2us code doesn't do exactly the same thing, and since this would affect all photographs, it's far better to leave the default as completely unchanged.

OK that's what I've figured.
Anyways, took a last kick at the SX10 with hardcoded values 300us (~1/3333s) and 150us (~1/6666s) and both exposures came out identical.  So I guess I can pretty much be certain that what I need lies elsewhere.  Not much else I can do for now until I get time to learn a bit about firmware dumps.

I'm just surprised this hasn't come up elsewhere yet.  I would maybe think that the SX1 would have the same issue as it is a similar camera, and ceratinly the SX20 might, unless it's just a fluke on the SX10.  I would also like to know if other SX10 FW versions have the problem (I've got 103A).

My big question would be why?  Is Canon onto the CHDK work and decided to program against it?  Or is it coincidental and is just happening because they slightly changed some operations?


*

Offline reyalp

  • ******
  • 14134
Re: SX10 Shutter Speeds
« Reply #34 on: 07 / October / 2009, 22:49:06 »
My big question would be why?  Is Canon onto the CHDK work and decided to program against it?  Or is it coincidental and is just happening because they slightly changed some operations?
I'm sure it's the latter.

As for other cameras, I'm sure some of them are affected. Not that many people have an actual use for such high shutter speeds.
Don't forget what the H stands for.

Re: SX10 Shutter Speeds
« Reply #35 on: 09 / October / 2009, 20:46:20 »
To all you ARM experts out there, time for a little assistance again if you don't mind.   I couldn't let this go yet so I got the binary dump disassembled (~100MB for SX10, guess that's why they're not posted) and did a quick crash course in ARM.  I have been able to pick up and follow through some of the ARM logic and have especially looked at those sections referenced in capt_seq.c   There is one part I'm not quite getting, I can see where ARM uses constructs like (I'll use an example out of the SX10):

FF89D150: E51F5210 LDR R5, [PC, #-528];
and this directs to load R5 from the literal pool at the given address (-528dec offset from PC+8), which leads to address: FF89CF48 (HEX: 00006c14)
In the "capt_seq.c", this has been replaced directly with the HEX value instead: "LDR   R5, =0x6C14\n"

The first question I have is, why can't we leave the original reference?  Is it because this function lies outside the FW and can't reference the address properly?  Also, since it is loading from the literal pool in the FW version, isn't there a potential that that address in the literal pool has store operations associated with it elsewhere? (I searched but couldn't find any directly, just more load references).

Then we have 2 lines down:

F89D158: E5950004 LDR R0, [R5, #4]
which is a similar literal pool reference call, however this one is relative to R5 not PC.  This should lead to address: FF89CF4C (HEX:0000EA60)  -address reference in R5+4 offset

However in capt_seq.c it is constructed as LDR   R0, [R5,#4] as in the original form as well, except within this module, R5 doesn't have an address reference anymore.  How is the function supposed to get the proper value from the literal pool?


Thanks for any help and insight
-tgq

*

Offline reyalp

  • ******
  • 14134
Re: SX10 Shutter Speeds
« Reply #36 on: 09 / October / 2009, 22:32:42 »
FF89D150: E51F5210 LDR R5, [PC, #-528];
and this directs to load R5 from the literal pool at the given address (-528dec offset from PC+8), which leads to address: FF89CF48 (HEX: 00006c14)
In the "capt_seq.c", this has been replaced directly with the HEX value instead: "LDR   R5, =0x6C14\n"

The first question I have is, why can't we leave the original reference?  Is it because this function lies outside the FW and can't reference the address properly?
Look at the description of LDR in ARM Architecture Reference Manual, and the addressing mode section referenced there. An immediate offset from a register (in this case PC) only allows a 12 bit offset. Since the original canon code is in ROM (which starts at FFxxxxxx) CHDK code in RAM (which starts at 0) could not access the same literal.

Note that the CHDK code ends up doing exactly the same thing. =0x6C14 means "create the value 0x6C14 in the literal pool, and create a PC relative load to load it".  MOV R5, #0x6614 would mean "load the immediate value 0x6614" except that this isn't a valid constant to use in that instruction.
Quote
  Also, since it is loading from the literal pool in the FW version, isn't there a potential that that address in the literal pool has store operations associated with it elsewhere?
No, it's in ROM. More generally, variable data wouldn't normally go in the text section of a program.

Quote
F89D158: E5950004 LDR R0, [R5, #4]
which is a similar literal pool reference call, however this one is relative to R5 not PC.  This should lead to address: FF89CF4C (HEX:0000EA60)  -address reference in R5+4 offset
No, this isn't a literal pool reference.
Quote
However in capt_seq.c it is constructed as LDR   R0, [R5,#4] as in the original form as well, except within this module, R5 doesn't have an address reference anymore.  How is the function supposed to get the proper value from the literal pool?

This isn't loading from a literal pool. The value in R5 is an RAM address that was loaded from the literal pool. The second instruction loads the value from that address + 4 (in RAM).  In other words, it's an array or structure pointer derefernce. This is necessary because ARM can't directly load from an arbitrary 32 bit address (because you can only encode a 12 bit offset in the load instruction)

Hope that clears things up.
Don't forget what the H stands for.

Re: SX10 Shutter Speeds
« Reply #37 on: 10 / October / 2009, 00:04:37 »
Thanks reyalP, I think I understand somewhat better now.  The hardest part is I'm pretty much blind to what values are sitting in the register, so I have to see what's being done to them.

I had a bit of a brainstorm and realized when I was doing my checks before, I left in the 960 that you were using (1/1024s), but realized that this may be giving me false feedback as the minimum shutter is 1/3200, so I retried my test using 1150 (1/4040s) and found that the min shutter is getting trimmed before reaching apex2us, so I've been searching the wrong side of the code...  Back to the drawing board for now, but at least I've been learning.

*

Offline reyalp

  • ******
  • 14134
Re: SX10 Shutter Speeds
« Reply #38 on: 10 / October / 2009, 00:59:53 »
I had a bit of a brainstorm and realized when I was doing my checks before, I left in the 960 that you were using (1/1024s), but realized that this may be giving me false feedback as the minimum shutter is 1/3200, so I retried my test using 1150 (1/4040s) and found that the min shutter is getting trimmed before reaching apex2us
If it's being trimmed before apex2us, then reinstating the original value in apex2us should do the trick. Unless there is another check later on, or it is a fundamental limit of the hardware or something.
Don't forget what the H stands for.

*

Offline RaduP

  • *****
  • 926
Re: SX10 Shutter Speeds
« Reply #39 on: 10 / October / 2009, 01:09:22 »
Thanks reyalP, I think I understand somewhat better now.  The hardest part is I'm pretty much blind to what values are sitting in the register, so I have to see what's being done to them.

If you absolutely have to check, there are ways that might work.
For example, have a function that writes the content of the registers in a file. At the beginning of that function save all the registers, and at the end restore them.

 

Related Topics


SimplePortal © 2008-2014, SimplePortal