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

PowerShot SX230 HS - Porting Thread

  • 706 Replies
  • 326239 Views
Re: PowerShot SX230 HS - Porting Thread
« Reply #520 on: 24 / March / 2012, 17:56:05 »
Advertisements
The CHDK autobuild 1759 included a change to fix a video crash.
That patch was very specific to the sx150.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline 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.

*

Offline 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.
Don't forget what the H stands for.

*

Offline 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.


*

Offline 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;
}
}

*

Offline 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 »
Don't forget what the H stands for.

*

Offline 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.

*

Offline reyalp

  • ******
  • 14119
Re: PowerShot SX230 HS - Porting Thread
« Reply #527 on: 25 / March / 2012, 17:36:33 »
OK, deception successful  :-[
Don't forget what the H stands for.


*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: PowerShot SX230 HS - Porting Thread
« Reply #528 on: 25 / March / 2012, 17:42:38 »
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.
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 »
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:

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.

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.

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.

 

Related Topics


SimplePortal 2.3.6 © 2008-2014, SimplePortal