PowerShot SX230 HS - Porting Thread - page 53 - General Discussion and Assistance

waterwingz

12140

Re: PowerShot SX230 HS - Porting Thread

« Reply #520 on: 24 / March / 2012, 17:56:05 »

Advertisements

Quote from: Buffernut on 24 / March / 2012, 17:21:41

The CHDK autobuild 1759 included a change to fix a video crash.

That patch was very specific to the sx150.

Logged

Ported : A1200 SD940 G10 Powershot N G16

funnel

349

Re: PowerShot SX230 HS - Porting Thread

« Reply #521 on: 24 / March / 2012, 18:25:34 »

I'm having the same crash problem on the sx220. I'm trying to figure it out without success. One solution I found that's working is to completely disable the OSD.

To pinpoint the error I tried to disable all the tasks in boot.c and vid_bitmap_refresh() in lib.c. I also tried the new live view buffers code. No luck with that too. I think it's an exmem problem but I'm not sure yet.

Logged

reyalp

14119

Re: PowerShot SX230 HS - Porting Thread

« Reply #522 on: 24 / March / 2012, 18:39:14 »

I noticed this port has some hard coded stuff for overriding video time limits, which is always active (it's in asm code, so putting ifs around it would take some work).

Has anyone experimented with disabling the CHDK movie_record_task ? If that makes the problem go away, then making a movie_record_task without the above mentioned changes might be the next thing to try.

Logged

Don't forget what the H stands for.

funnel

349

Re: PowerShot SX230 HS - Porting Thread

« Reply #523 on: 25 / March / 2012, 05:58:02 »

I think I found where the Disp_Con.c 1452 crash problem comes from.

I followed the code in boot.c and disabled the function that throws the assert which caused to throw a new more meaningful assert:

Code: [Select]

StackDump:
0x078C6CD1
0xEEEEEEEE
0xAAA9AA28

which leads in main.dump to:

Code: [Select]

078c6c9a <draw_hline>:
 78c6c9a:	b5f0      	push	{r4, r5, r6, r7, lr}
 78c6c9c:	4c10      	ldr	r4, [pc, #64]	; (78c6ce0 <draw_hline+0x46>)
 78c6c9e:	041f      	lsls	r7, r3, #16
 78c6ca0:	6823      	ldr	r3, [r4, #0]
 78c6ca2:	0c3f      	lsrs	r7, r7, #16
 78c6ca4:	4298      	cmp	r0, r3
 78c6ca6:	d217      	bcs.n	78c6cd8 <draw_hline+0x3e>
 78c6ca8:	6864      	ldr	r4, [r4, #4]
 78c6caa:	42a1      	cmp	r1, r4
 78c6cac:	d214      	bcs.n	78c6cd8 <draw_hline+0x3e>
 78c6cae:	1814      	adds	r4, r2, r0
 78c6cb0:	429c      	cmp	r4, r3
 78c6cb2:	d900      	bls.n	78c6cb6 <draw_hline+0x1c>
 78c6cb4:	1a1a      	subs	r2, r3, r0
 78c6cb6:	4b0a      	ldr	r3, [pc, #40]	; (78c6ce0 <draw_hline+0x46>)
 78c6cb8:	0040      	lsls	r0, r0, #1
 78c6cba:	68dd      	ldr	r5, [r3, #12]
 78c6cbc:	0056      	lsls	r6, r2, #1
 78c6cbe:	434d      	muls	r5, r1
 78c6cc0:	4c08      	ldr	r4, [pc, #32]	; (78c6ce4 <draw_hline+0x4a>)
 78c6cc2:	182d      	adds	r5, r5, r0
 78c6cc4:	e006      	b.n	78c6cd4 <draw_hline+0x3a>
 78c6cc6:	1c28      	adds	r0, r5, #0
 78c6cc8:	6823      	ldr	r3, [r4, #0]
 78c6cca:	1c39      	adds	r1, r7, #0
 78c6ccc:	f000 fca8 	bl	78c7620 <draw_get_icon_colors+0x80>
 78c6cd0:	3e01      	subs	r6, #1
 78c6cd2:	3501      	adds	r5, #1
 78c6cd4:	2e00      	cmp	r6, #0
 78c6cd6:	dcf6      	bgt.n	78c6cc6 <draw_hline+0x2c>
 78c6cd8:	bcf0      	pop	{r4, r5, r6, r7}
 78c6cda:	bc01      	pop	{r0}
 78c6cdc:	4700      	bx	r0
 78c6cde:	46c0      	nop			; (mov r8, r8)
 78c6ce0:	078f6ab0 	.word	0x078f6ab0
 78c6ce4:	078fd12c 	.word	0x078fd12c

which next leads to core/gui_draw.c

Code: [Select]

void draw_hline(coord x, coord y, int len, color cl)
{	
    if (x >= camera_screen.width || y >= camera_screen.height) return;
    if (x < 0) { len += x; x = 0; }
    if ((x + len) > camera_screen.width) len = camera_screen.width - x;
    register unsigned int offset = y * camera_screen.buffer_width + ASPECT_XCORRECTION(x);
    len = ASPECT_XCORRECTION(len);      // Scale the line length if needed
    for (; len>0; len--, offset++)
        draw_pixel_proc(offset, cl);
}

Disabling draw_hline() prevents the crashes. I did two successful >15min recordings.
At least I found where the problem comes from.

Now we need to look further what's wrong in there.

Logged

funnel

349

Re: PowerShot SX230 HS - Porting Thread

« Reply #524 on: 25 / March / 2012, 14:34:40 »

Apparently the camera doesn't like to draw pixels on an inactive buffer. I fixed the code in gui_draw.c and works on my sx220. I couldn't crash it as far as I could test. I uploaded an experimental build for sx230 100c and 101a. I build it from reyalp_ptplive branch because it has the active buffer addresses already in stubs_min.s. Can somebody try it and report back? It fixes the crash on sx220 so it should on sx230.

Code: [Select]

static void draw_pixel_std(unsigned int offset, color cl) {
    //frame_buffer[0][offset] = frame_buffer[1][offset] = cl & 0xff;
	
	if(vid_get_active_bitmap_buffer()){
		frame_buffer[1][offset] = cl & 0xff; 
	}
	else{
		frame_buffer[0][offset] = cl & 0xff; 
	}
}

sx230.zip (380.78 kB - downloaded 71 times.)

Logged

reyalp

14119

Re: PowerShot SX230 HS - Porting Thread

« Reply #525 on: 25 / March / 2012, 16:30:04 »

Great detective work funnel.

I'm confused by this though:

Quote

   if(vid_get_active_bitmap_buffer()){
      frame_buffer[1][offset] = cl & 0xff;
   }
   else{
      frame_buffer[0][offset] = cl & 0xff;
   }

vid_get_active_bitmap_buffer() should return a pointer to the actual buffer, not a 0/1 index. So it seems with this code you will always be using the first case (it shouldn't ever return NULL, although you might want to watch it with misc debug vals to see what it does do)

One possibility is that some address or dimension is wrong, so using frame_buffer[0] clobbers something outside of the buffer.

« Last Edit: 25 / March / 2012, 17:35:15 by reyalp »

Logged

Don't forget what the H stands for.

funnel

349

Re: PowerShot SX230 HS - Porting Thread

« Reply #526 on: 25 / March / 2012, 17:10:49 »

Actually I knew that would confuse somebody. I made a new function in lib.c named vid_get_active_bitmap_buffer() that just returns active_bitmap_buffer. The other one is named vid_get_bitmap_active_buffer(). Just swapped the words.

Logged

reyalp

14119

Re: PowerShot SX230 HS - Porting Thread

« Reply #527 on: 25 / March / 2012, 17:36:33 »

OK, deception successful

Logged

Don't forget what the H stands for.

philmoz

3450

Re: PowerShot SX230 HS - Porting Thread

« Reply #528 on: 25 / March / 2012, 17:42:38 »

Quote from: funnel on 25 / March / 2012, 17:10:49

Actually I knew that would confuse somebody. I made a new function in lib.c named vid_get_active_bitmap_buffer() that just returns active_bitmap_buffer. The other one is named vid_get_bitmap_active_buffer(). Just swapped the words.

To avoid the inevitable confusion (and extra function call overhead), why not use:

Code: [Select]

   frame_buffer[active_bitmap_buffer][offset] = cl & 0xff;

This is very strange behaviour, and a nice piece of detective work.
Perhaps the camera is using the inactive buffer to store something else while recording a movie - odd that it has not shown up on any other cameras.

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)

ArnoldBis

Re: PowerShot SX230 HS - Porting Thread

« Reply #529 on: 25 / March / 2012, 22:23:32 »

Quote from: ArnoldBis on 29 / November / 2011, 09:42:56

Quote from: waterwingz on 28 / November / 2011, 23:25:15
Update : never mind my previous comment. On my G10, I can set the Canon for Super Fine and use the CHDK menu to override that to Normal. The port on your SX230 might still need some work.

Yes, I think that the JPEG quality/compression setting override for the SX230 port (which is working great otherwise) has been bugged for a while. See, for example:

Quote from: Luth on 02 / September / 2011, 12:57:49
Have you looked into the .jpg compression bug yet?
I've been mostly using chdk for bracketing photos and no matter which quality settings i choose, the file comes out rathers small in filesize.
For eg. same pic without chdk is around 5MB and with chdk its 2.5MB, so the quality is a bit low. Compression seems to be normal or below always.

Quote from: grahamlyth on 24 / September / 2011, 09:09:33
So far, this version works great for me, with one exception.

...

However, there is definitely something weird going on with JPEG compression. With the camera set to JPEG Compression Fine, file sizes are larger with CHDK switched off than they are with CHDK on (with all overrides disabled). Exif shows Fine compression in each case. Anecdotally (I don't have a properly controlled test to prove it) the difference in file size seems to be greater with complex scenes.

Quote from: Peter_A720 on 23 / August / 2011, 05:22:35
I can confirm the known 400 ISO limit, but it seems to me that there is another fatal Problem:

If I use CHDK, the JPG-files are all the time very small (2-3MB) with 12M-Pixel!!! So the JPG-compression-quality must be always "Normal"

I tried every quality override and Extra Photo Operations setting, the only changes are the Exif information of the JPEG images.

With JPG-compression-quality "Fine" (works only without CHDK) the JPG-file sizes are 3.5 to 5MB, so I expect with JPG-compression-quality "superfine" JPG-file sizes up to 8MB

So it definitely seems like this is an issue that people have experienced with different cameras.

Could this: http://chdk.setepontos.com/index.php?topic=5574.msg70030#msg70030 change (that is, adding a DEFINE to platform_camera.h) fix this problem re: JPEG quality overrides? I am not a developer so I cannot compile in the change myself. Thanks.

Logged