Porting a camera sx530hs

reyalp

14080

Re: Porting a camera sx530hs

« Reply #270 on: 18 / July / 2017, 01:32:14 »

Advertisements

Quote from: axman on 17 / July / 2017, 01:08:35

Quote from: reyalp on 13 / July / 2017, 21:48:31
You need to ensure that a known OK value is set when ignore_current_write is used, something like

Code: [Select]
" LDR R3, =ignore_current_write\n" // mod start " LDR R3, [R3]\n" " CMP R3, #0\n" " MOVNE R0,#1\n //fake return value of skipped sub_FF02D9F0 call " BNE loc_B\n" // skip flushing the cacheBut it's unknown whether just setting the value to 1 is OK or not.

The code that uses the value only checks whether it's equal to 1 or not. Maybe either case is OK, but we should use specific value.

Did ^ this. chdkptp shoot = 1x jpg saved to sdcard good.

Just to be clear, the above code (the MOVNE) is only used if ignore_current_write is set, meaning when remoteshoot is used.

Quote

fwt log; 00039160: UI:fw mid:ff1efd1c arg2:1

So when shooting normally (without remoteshoot), the arg2 value is consistently 1?

I wouldn't expect this to vary depending on CHDK overrides or shooting mode, but perhaps continuous or not might behave differently.

If the value is consistently 1, and the code with MOVNE works with remoteshoot, I'd say it's probably good enough.

Logged

Don't forget what the H stands for.

axman

145

Re: Porting a camera sx530hs

« Reply #271 on: 18 / July / 2017, 14:24:49 »

Quote from: reyalp on 18 / July / 2017, 01:32:14

Quote from: axman on 17 / July / 2017, 01:08:35
Quote from: reyalp on 13 / July / 2017, 21:48:31
You need to ensure that a known OK value is set when ignore_current_write is used, something like

Code: [Select]
" LDR R3, =ignore_current_write\n" // mod start " LDR R3, [R3]\n" " CMP R3, #0\n" " MOVNE R0,#1\n //fake return value of skipped sub_FF02D9F0 call " BNE loc_B\n" // skip flushing the cacheBut it's unknown whether just setting the value to 1 is OK or not.

The code that uses the value only checks whether it's equal to 1 or not. Maybe either case is OK, but we should use specific value.

Did ^ this. chdkptp shoot = 1x jpg saved to sdcard good.
Just to be clear, the above code (the MOVNE) is only used if ignore_current_write is set, meaning when remoteshoot is used.

Thanks for extra clarity detail. I had understood it backwards.

Quote

fwt log; 00039160: UI:fw mid:ff1efd1c arg2:1

Quote

So when shooting normally (without remoteshoot), the arg2 value is consistently 1?

I wouldn't expect this to vary depending on CHDK overrides or shooting mode, but perhaps continuous or not might behave differently.

If the value is consistently 1, and the code with MOVNE works with remoteshoot, I'd say it's probably good enough.

Arg2 value is 1 regardless of any test.

exec shoot, arg2 is 1.
exec remoteshoot, arg2 is 1.
continuous or single, arg2 is 1.
DNG or jpg, arg2 is 1.
did not try exotic shooting modes, all above in 'P'
did not try any overrides other than DNG

I'm not sure I have implemented the MOVNE suggestion correctly.

I tried this;

Code: [Select]

"        MOVNE    R0, #3\n"

No difference, arg2 is 1.
I was expecting ~~either~~ a failure..

filewrite attached for ref.

Of course I will remove that #3 bogon. Just trying to learn something, thrashing around in the dark.

filewrite.c (14.23 kB - downloaded 20 times.)

Logged

reyalp

14080

Re: Porting a camera sx530hs

« Reply #272 on: 18 / July / 2017, 17:32:23 »

Quote from: axman on 18 / July / 2017, 14:24:49

No difference, arg2 is 1.

Maybe I'm missing something, but I don't see how this could happen if you are actually running the code posted.

Code: [Select]

CMP R3, #0 // compare ignore_current_write value with 0
MOVNE	R0, #3 // if result is non equal, set R0 to 3
BNE loc_B // if result is not equal go to loc_B
...
loc_B
MOV     R7, R0 // copy R0 to R7
BL		log_fwt_mid // log, value in R0 is the first argument (arg2 in the print)

So either:
1) I missed something in the above code
2) you aren't running the code you think you are (didn't fully rebuild or uploaded wrong build)
3) you are looking at the wrong log or missing something in it
4) ignore_current_write isn't being set at that point when you use remoteshoot

I've done #2 and #3 more often than I like to admit

Logged

Don't forget what the H stands for.

axman

145

Re: Porting a camera sx530hs

« Reply #273 on: 20 / July / 2017, 00:10:06 »

Thanks for adding comments to the asm instructions; very helpful to me. About the build, I've checked, re-checked and checked yet again. I just re-compiled again with no changes, to confirm.

**** Firmware creation completed successfully
-> sx530hs-100c-1.5.0-branch_4821-4879.zip
-> sx530hs-100c-1.5.0-branch_4821-4879-full.zip

The above -full.zip is what is reported on the camera using 'build info'. I can post a screenshot, if useful. But I'm confident that the build I'm testing with is the one that I compiled, and it's the same one that I hacked with MOVNE R0, #3.

About point 4); If I assume 'ignore_current_write' is not being set at that point - even though it seems to log when it passes through that section - what could cause that? Compiler optimizing it away? And how to explain the fact that remoteshoot works?

I don't know enough about what's supposed to happen.. Speculation on my part, possibly useless, but I want to point something out, just in case:

Debug logging is only in 3 spots;

spot# log tag purpose
-----------------------------------------------------------------
1st log_fwt_erly capture 0x107c0 just after "loc_A:\n"
2nd log_fwt_mid capture 0x107bc just after MOV R7,R0 and "loc_B:\n"
3rd log_fwt_late capture 0x107c4 four instructions past "loc_B:\n"
-----------------------------------------------------------------
I see debug log results from log_fwt_mid and log_fwt_late IN EVERY TEST CASE.
I see NO RESULTS, EVER, from log_fwt_erly.

I saw log_fwt_erly results way back when loc_A was "in the wrong place", eg
topic=12418.msg133693#msg133693 date=1498887788 but I have not seen any since.

I wonder if loc_A code path is not ever being taken? Which means 'skip creating directory' is not happening?

If no \DCIM exists on sdcard, and remoteshoot is run, is the expected behavior to NOT create dir on sdcard?

Because \DCIM directory *is created anyway*, along with \CANONMSC containing MO105.CTG

Does this mean the 'skip creating directory' jump code did not execute? If so, could the loc_B code path also be being skipped by the same mechanism?

Logged

reyalp

14080

Re: Porting a camera sx530hs

« Reply #274 on: 20 / July / 2017, 01:17:06 »

Quote from: axman on 20 / July / 2017, 00:10:06

The above -full.zip is what is reported on the camera using 'build info'. I can post a screenshot, if useful.

There's no need to post a screenshot. I suggested to you the kind reasons I've seen for something like this happening. You don't have to convince me, you have to figure out what's actually happening.

An easy way to verify that you are running the code you think you are is to make a trivial change to one of the log messages. This catches cases where your build is updated, but isn't the code you think it is (More than once I've wondered why my changes weren't doing anything, only to realize I was building in the wrong source tree

)

Quote

About point 4); If I assume 'ignore_current_write' is not being set at that point - even though it seems to log when it passes through that section - what could cause that?

The log would be hit regardless. if the BNE isn't taken, the code reaches the same point. Maybe I didn't understand the question.

You can easily log the value of ignore_current_write, just do something like

Code: [Select]

void log_fwt_mid(int arg2)		{
		_LogCameraEvent(0x60,"fw mid:%08x arg2:%d icw:%d", *(int *)(0x107BC),arg2,ignore_current_write);
}

Quote

Compiler optimizing it away?

The compiler shouldn't touch inline asm. You can check what was actually generated by examining the main.bin.dump in your platform/sub/<firmware> directory. Just search for the name of the function you want to look at. The inline asm should be very recognizable, although there are some cosmetic differences.

This really isn't something I'm likely to figure out looking at your code and descriptions. If you want to understand it, you need to debug.

Quote

If no \DCIM exists on sdcard, and remoteshoot is run, is the expected behavior to NOT create dir on sdcard?

Because \DCIM directory *is created anyway*, along with \CANONMSC containing MO105.CTG

I don't remember specifically testing those, but I'd expect them to be created separate from the individual image directories.

Logged

Don't forget what the H stands for.

innie10032

7

Re: Porting a camera sx530hs

« Reply #275 on: 24 / May / 2018, 08:48:46 »

Hello,

I'm trying to port the preview to use it on an application, i've made the dissasembly with IDA and i've found memory adresses for active_viewport_buffer and viewport_buffers.

DEF(viewport_buffers, 0xFF63DFF0) , made by comparison with 520 since their firmware is the same (firmware dump is the same)
DEF(active_viewport_buffer,0x00004BD4)

My problem with the current active_viewport_buffer is that i lose some frames (my FPS is ~6), but i get no noise if i use an alternative adress for active_viewport_buffer

DEF(active_viewport_buffer,0x0000301C)

My preview is much better with a higher FPS(~20) but i get a frame with noise (random dots withs colors like a TV)

I'm stuck on it right now, anyone can help me ?

Cheers

Logged

srsa_4c

4451

Re: Porting a camera sx530hs

« Reply #276 on: 24 / May / 2018, 16:16:41 »

Quote from: innie10032 on 24 / May / 2018, 08:48:46

My problem with the current active_viewport_buffer

By 'current', you mean the one in the official CHDK source?

Can you please name the exact model and the firmware version of your camera?

Quote

i lose some frames (my FPS is ~6)

In most shooting modes, the frame rate of live view is reduced significantly when there is not enough light. Could this be the cause of your problem?

If not, try sampling active_viewport_buffer and see how often it changes and what set of values you see there.

Quote

i get a frame with noise (random dots withs colors like a TV)

Those frames come from invalid buffers and show random memory content.

Logged

innie10032

7

Re: Porting a camera sx530hs

« Reply #277 on: 25 / May / 2018, 07:37:14 »

Câmera Model : sx530hs
Firmware version : 100c

The active_viewport_buffer that came with the current trunk wans't good. So i've found some good candidates (looked for values that changed from 1 to 7 since on older posts it was said this camera works with 4 or 7 buffers) with memory browser with the tools on CHDK. The current one is

0x00004BD4

Quote

not enough light. Could this be the cause of your problem?

I'm pretty sure it isn't, if i use my preview on the same conditions (good light, etc,etc) with different active_viewport_buffers my preview FPS change dramatically. I've one adress with a low FPS but no noise ( it's skipping some frames) and one with a good FPS but noise (it's probally poiting to some adress with random data)

Maybe it's my active_viewport_buffer or my viewport_buffers, my guess is active_viewport_buffer, has anyone found a good active_viewport_buffer ? Or maybe i could filter this frame with noise idk, suggestions ?

Cheers

Innie

« Last Edit: 25 / May / 2018, 10:43:46 by innie10032 »

Logged

reyalp

14080

Re: Porting a camera sx530hs

« Reply #278 on: 25 / May / 2018, 13:29:06 »

Quote from: innie10032 on 25 / May / 2018, 07:37:14

I'm pretty sure it isn't, if i use my preview on the same conditions (good light, etc,etc) with different active_viewport_buffers my preview FPS change dramatically.

How are you measuring FPS?

Have you examined the actual values that are produced?
viewport_buffers should be a list of viewport address in ROM
active_viewport_buffer is an index, which may point to the next/previous buffer rather than the current one.
The current trunk code is:

Code: [Select]

void *vid_get_viewport_live_fb()
{
    return viewport_buffers[(active_viewport_buffer-1)&3];
}

By inspecting the ROM around viewport_buffers and watching the value of active_viewport_buffer you may get a better understanding of what is actually happening.

Maybe there are more or less than 4 buffers. Maybe the actual buffers used aren't the same as whats in viewport_buffers

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: Porting a camera sx530hs

« Reply #279 on: 25 / May / 2018, 15:16:18 »

Quote from: reyalp on 25 / May / 2018, 13:29:06

Maybe there are more or less than 4 buffers.

In a RAM dump I got from blackhole, I see 8 consecutive liveview buffers (y411, 720x480). It's therefore possible that doing the following

Code: [Select]

void *vid_get_viewport_live_fb()
{
    return viewport_buffers[(active_viewport_buffer-1)&7];
}

may improve things.
The port's viewport_buffers seems correct (8 buffer addresses are there, matching the real ones I mentioned above).

Logged