Adding new cameras, applying patches into trunk (with source code prepared) - page 23 - General Discussion and Assistance - CHDK Forum

Adding new cameras, applying patches into trunk (with source code prepared)

  • 1685 Replies
  • 878495 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Advertisements
Philmoz,

the #define fix works perfectly for the startup issue, you can add that to the trunk....

It was the exmem that was causing the video to not record.  it would try but the buffer bar showed and then it stopped recording.
is there anything i can do to make it work?

Disable the OPT_CHDK_IN_EXMEM option and enable OPT_EXMEM_TESTING. Rebuild and try recording a video. If it's a problem with the exmem memory block overlapping the video buffers then it will show the corruption info on screen (write down the values shown and send them to me). If video still fails; but no exmem memory corruption is shown then reduce the EXMEM_BUFFER_SIZE (try 3MB, 0x300000), you will also need to increase MEMISOSTART (to 0x3A089E0 if EXMEM_BUFFER_SIZE is 3MB).

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)

Thanks Philmoz,

I used a 3mb buffer size, video works for the most part (sometimes fails) but there is still a video buffer bar on the screen that has one block highlighted - this is with the quality set at 84 (this is default setting)
The emem testing still says ok, even when the video does fail...

Should i try going to a 2mb buffer?  
also, just so i know, what is the buffer that we are changing do/for?

what would memisostart be for the 2mb?

at this point, with Exmem & Exmem testin all the functions i have tested are working correctly, no crashes, edge define and zebra enable at the same time, raw works good, scripts seem to work good and free ram with everything enabled was at 2.6 mb
and Exmem testing says OK.
video was working as described above...

so what do you think?
« Last Edit: 14 / April / 2011, 21:37:29 by bdasmith »
sx20is 1.02d

*

Offline philmoz

  • *****
  • 3450
    • Photos

I used a 3mb buffer size, video works for the most part (sometimes fails) but there is still a video buffer bar on the screen that has one block highlighted - this is with the quality set at 90
The emem testing still says ok, even when the video does fail...


I'm not sure what this 'video buffer bar' is you are referring to is - is this a CHDK OSD thing or something the camera displays?

When the video fails what happens? Does it just stop recording, does the camera crash, or is the video corrupted?

If the video recording just stops then you probably have the quality setting too high for your SD card and it can't write the data fast enough. Turn off the quality override in CHDK and make sure it is working with the default camera settings.

If the camera is crashing or the video is corrupted then we need to do more testing of the exmem buffer size and/or location.

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)

sorry to be unclear!

ummm..okay...

this is is at the videos default setting, i accidently wrote the wrong number in previous post (edited it)

when the video fails, i mean it just stops recording...

the buffer bar (this is just what i call it, don't know what it is for sure) is the camera OS thing.

so default settings, just stops recording, yet exmem test still says ok.

hope that helps :)
sx20is 1.02d

*

Offline philmoz

  • *****
  • 3450
    • Photos
sorry to be unclear!

ummm..okay...

this is is at the videos default setting, i accidently wrote the wrong number in previous post (edited it)

when the video fails, i mean it just stops recording...

the buffer bar (this is just what i call it, don't know what it is for sure) is the camera OS thing.

so default settings, just stops recording, yet exmem test still says ok.

hope that helps :)

Sounds like your SD card can't keep up - what type/class is it?

If you disable CHDK (unlock the card) can you record videos OK?
The CHDK quality setting of 84 may not be the same as the cameras default video quality setting.
If video recording with CHDK disabled works then turn off the CHDK video quality override (Video Parameters, Video Mode = Default) and try it again with CHDK.

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)

sorry to be unclear!

ummm..okay...

this is is at the videos default setting, i accidently wrote the wrong number in previous post (edited it)

when the video fails, i mean it just stops recording...

the buffer bar (this is just what i call it, don't know what it is for sure) is the camera OS thing.

so default settings, just stops recording, yet exmem test still says ok.

hope that helps :)

Sounds like your SD card can't keep up - what type/class is it?

If you disable CHDK (unlock the card) can you record videos OK?
The CHDK quality setting of 84 may not be the same as the cameras default video quality setting.
If video recording with CHDK disabled works then turn off the CHDK video quality override (Video Parameters, Video Mode = Default) and try it again with CHDK.

Phil.


without exmem enabled, my class 10 sd card records video just fine at video setting 99....

its only with the exmem enabled....changing from 4mb to 3mb made it record, but just not as perfect as normal
thats why i was asking about lowering from 3 to 2mb.

edit: maybe we should also move this conversation to the 'experimental alternate memory' thread
edit: this conversation moved to personal messages...
« Last Edit: 14 / April / 2011, 23:28:27 by bdasmith »
sx20is 1.02d

*

Offline philmoz

  • *****
  • 3450
    • Photos
Patch to fix a problem with the code generated by GCC 4.4.0 when compiling the readdir function in platform/generic/wrappers.c.

I believe this is the cause of the problem reported on the G12 using builds from the autobuild server (http://chdk.setepontos.com/index.php?topic=6299.0).

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

  • ******
  • 14132
Patch to fix a problem with the code generated by GCC 4.4.0 when compiling the readdir function in platform/generic/wrappers.c.

I believe this is the cause of the problem reported on the G12 using builds from the autobuild server (http://chdk.setepontos.com/index.php?topic=6299.0).

Phil.

Applied in changeset 1144

Code: [Select]
+  static char de[40] = ""; // (philmoz 15/4/2011) Must initialize this variable or GCC 4.4.0 will generate bad code and the File Browser will crash.
Whaaa ?

Are you sure it's compiler generating bad code ? If it's actually bad code being generated, it seems like it should affect all dryos autobuilds.
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3450
    • Photos

Are you sure it's compiler generating bad code ? If it's actually bad code being generated, it seems like it should affect all dryos autobuilds.


I have no idea why this only affects the G12 that we know of; but below is what the compiler is generating on my system.

Edit: Same problem occurs on SX30 1.00h with autobuild server version 1143. So could be affecting other cameras as well.

GCC 4.5.1 with 'de' uninitialized, and GCC 4.4.0 with 'de' initialized both generate:
Code: [Select]
00185ba0 <readdir>:
  185ba0: e92d4010 push {r4, lr}
  185ba4: e59f401c ldr r4, [pc, #28] ; 185bc8 <readdir+0x28>
  185ba8: e1a01004 mov r1, r4                              <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  185bac: eb0013d6 bl 18ab0c <_ReadFastDir>
  185bb0: e5d40000 ldrb r0, [r4]                            <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  185bb4: e3500000 cmp r0, #0
  185bb8: 11a00004 movne r0, r4
  185bbc: 03a00000 moveq r0, #0
  185bc0: e8bd4010 pop {r4, lr}
  185bc4: e12fff1e bx lr
  185bc8: 001b0104 .word 0x001b0104

GCC 4.4.0 with 'de' uninitialized generates this:
Code: [Select]
0018633c <readdir>:
  18633c: e92d4010 push {r4, lr}
  186340: e59f401c ldr r4, [pc, #28] ; 186364 <readdir+0x28>
  186344: e2841034 add r1, r4, #52 ; 0x34                <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  186348: eb001248 bl 18ac70 <_ReadFastDir>
  18634c: e5f40034 ldrb r0, [r4, #52]!                        <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  186350: e3500000 cmp r0, #0 ; 0x0
  186354: 11a00004 movne r0, r4
  186358: 03a00000 moveq r0, #0 ; 0x0
  18635c: e8bd4010 pop {r4, lr}
  186360: e12fff1e bx lr
  186364: 001b0cd0 .word 0x001b0cd0

Look at the lines I've highlighted - GCC 4.4.0 with 'de' uninitialized is passing and testing the address 12 bytes past the end of the 'de' memory.

I need to test the next version created from the autobuild server to ensure that it really fixes the problem.

(At a guess I'd say that the changes made to cleanup the stdio functions, or the changes made to the exmem code, have altered the way GCC 4.4.0 is handling the file - thus exposing this compiler bug. Wouldn't be the first time I've seen behaviour like this - the stories I could tell...)


Phil.
« Last Edit: 15 / April / 2011, 02:34:51 by philmoz »
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

  • ******
  • 14132
Patch for SX30 & G12 (patched against changeset 1141).
- Added code to override the -0.5 DNG exposure bias that is set in the dng.c code. If your DNG files are 1/2 stop underexposed this is why. Exposure bias set to 0 for G12 & SX30.
- Changed logical screen width to 360 (from 320).
- Cleanup old code in capt_seq.c & added some comments to boot.c
- Aligned vid_bitmap_refresh logic on both cameras. It's still not perfect; but I get less problems with menus vanishing with this version.

Phil.
Added, changeset 1145

Patch for SX20 1.02d to enable exmem and loading CHDK into exmem.
Also enables startup crash fix for SX20.

Tested by bdasmith.

Added, changeset 1146
« Last Edit: 16 / April / 2011, 02:11:40 by reyalp »
Don't forget what the H stands for.

 

Related Topics


SimplePortal © 2008-2014, SimplePortal