the sx10 porting thread - page 43 - General Discussion and Assistance - CHDK Forum supplierdeeply

the sx10 porting thread

  • 613 Replies
  • 219998 Views
Re: the sx10 porting thread
« Reply #420 on: 26 / June / 2009, 02:26:03 »
Advertisements
Just uploaded the updated movie_rec.c to http://drop.io/wltyjxn.

That didn't fix the crash. I suspect I screwed up a jump table somewhere.

Re: the sx10 porting thread
« Reply #421 on: 26 / June / 2009, 04:23:39 »
Did a quick code audit and found a couple of wrong addresses.

I've updated the zip to include the movie_rec.c and my fixes at http://drop.io/wltyjxn - look for the one with the date.

Same crash as before however.

I'll look at it tomorrow after some sleep.


Re: the sx10 porting thread
« Reply #422 on: 26 / June / 2009, 06:21:53 »
Hi there, is there any chance that there will be developed something for the 1.03a? Mine has that FW and I was greatly disapointed for not being able to use CHDK on my SX10...

Re: the sx10 porting thread
« Reply #423 on: 26 / June / 2009, 12:16:53 »
Hi there, is there any chance that there will be developed something for the 1.03a? Mine has that FW and I was greatly disapointed for not being able to use CHDK on my SX10...

1.03a is pretty recent, so there is a good chance that it will be done. What is needed currently is a dump of the 1.03 rom. This can be done using cardtricks from http://chdk.wikia.com/wiki/CardTricks

Rumours suggest that 1.03 is pretty close to 1.02, and if it is, then the port will be developed fast.


Re: the sx10 porting thread
« Reply #424 on: 26 / June / 2009, 17:21:22 »
I'd be excited to test a 1.00c port. I finally started trying to work on it last week, but I don't think I know what I'm doing enough to finish it (and it looks like cormac's already done much more than me). For reference, this camera was ordered from Newegg around the beginning of March '09.

Thanks for working on it!

Re: the sx10 porting thread
« Reply #425 on: 27 / June / 2009, 00:09:43 »
cormac or anyone else:

If you're going to insert debug code, here's some stuff to know. It took me a bit to realize all the issues with this stuff and ARM assembly. Here's the LED blink function I used:

Code: [Select]
#define LED_PR 0xC0220060
#define LED_SPIN_DELAY 5000000

int led_blink(int save_R0) {
int i;
volatile long *p=(void*)LED_PR;

p[0] = 0x46;
for (i=0; i< LED_SPIN_DELAY; i++) // Wait a while
{
     asm volatile ( "nop\n" );
}
p[0] = 0x44;
for (i=0; i<LED_SPIN_DELAY; i++) // Wait a while
{
    asm volatile ( "nop\n" );
}
return save_R0;
}

(That was thrown together mostly by copying similar stuff from the wiki and hardware addresses from the sx10 platform code.)

Unlike IA-32 (Intel), the ARM calling convention does not require that any called function preserve all the registers. Functions are allowed to stomp all over r0-r3, and gcc behaves accordingly as does whatever compiler canon uses. So when you see something like:

Code: [Select]
    MOV     R0, SP
    MOV     R1, #0x74
    BL      sub_FFB003BC
    MOV     R0, #0x53000

Don't put "BL led_blink" right before "BL sub_FFB003BC" and after the arguments are placed in r0-r3. Otherwise led_blink() will conceivably stomp all over r0 and r1 (in the example above) unless it does something special to preserve them. (In the code above, a trick is used to preserve r0 by specifying an argument, the first of which will always be passed via r0, then returning it which will also always be returned via r0.)

It looks like the easiest thing to do is use the r0 preserving trick above, then put the call to led_blink or whatever just after a call to something else. That way we know "BL sub_FFB003BC" has stomped all over r0-r3 and placed it's return value in r0. So we only have to preserve r0 for the code immediately after that to get what it expects. If gcc decides to use r4+ then it knows it has to preserve those and we don't have to worry about it as it should generate the right code.

(I was stumped for a bit as to why something like led blinking code would crash the camera when I was messing with this.)

See http://chdk.wikia.com/wiki/CHDK_Coding_Guidelines

Re: the sx10 porting thread
« Reply #426 on: 27 / June / 2009, 01:27:11 »
I was using calls to debug_led, but that seems to break things. I'll try this and see how it goes.

Thanks!

Re: the sx10 porting thread
« Reply #427 on: 27 / June / 2009, 17:31:12 »
Hi all,

What's wrong ?
ok so I load it and it works.
but then I try to load a script or change the language and CHDK can't see files.
I do it well (I guess) note pad then save as*.bas but it doesn't work.
have try to benchmark my 32GB SDHC card and what a surprise my class 6 is a fake one. it's only a class 3.
so when I record video in full quality it only rec for a couple of seconds.
I have a question I see somewhere on the site that the native quality of video is 75. so why the default of CHDK is 84 ?
thanks and tell me about script if I'm wrong


*

Offline fe50

  • ******
  • 3107
  • IXUS50 & 860, SX10 Star WARs-Star RAWs
    • fe50
Re: the sx10 porting thread
« Reply #428 on: 27 / June / 2009, 17:59:42 »
but then I try to load a script or change the language and CHDK can't see files.
Do you use the "complete" package from the Autobuild Server ?
If you use a partitioned card, the CHDK files must be placed on the 2nd partition; on such cards CHDK starts from the first (small) partition and then swaps to the big one...

Quote
I have a question I see somewhere on the site that the native quality of video is 75. so why the default of CHDK is 84 ?
No, the default value for the CHDK video quality normally is 84, this should match the Canon quality setting.

1.01b ultra intervalometer appears to work
« Reply #429 on: 27 / June / 2009, 22:21:57 »
Use the first version on the DL page.  The second version does not seem to work- the camera hangs and resets itself after a few seconds of trying to start the script.

 

Related Topics