A800 Porting Thread

mlands

32

Re: A800 Porting Thread

« Reply #10 on: 21 / January / 2012, 00:04:27 »

Advertisements

I am new in this forum. I have made a porting to the A800 firmware version 100C. As far as I can I can test things are working (native features + some features from the menus). I have also some doubts and some reports concerning the porting. What are the steps to continue the tests till it can be shared (by the way, is there any test routine specification with the expected results?). So, first of all I would like to know if this is the appropriate place or someone could redirect me.

Logged

waterwingz

12140

Re: A800 Porting Thread

« Reply #11 on: 21 / January / 2012, 00:09:49 »

Quote from: mlands on 21 / January / 2012, 00:04:27

I have made a porting to the A800 firmware version 100C.

Awesome !!! Good for you - especially as you have done so with no help from here.

Quote

As far as I can I can test things are working (native features + some features from the menus). I have also some doubts and some reports concerning the porting. What are the steps to continue the tests till it can be shared (by the way, is there any test routine specification with the expected results?).

Post a loadable file here and report on your findings ( doubts etc ). You might also post your source. At some point it needs to be in a diff file against the svn but that can wait.

Quote

So, first of all I would like to know if this is the appropriate place or someone could redirect me.

You are absolutely in the right place.

Logged

Ported : A1200 SD940 G10 Powershot N G16

mlands

32

Re: A800 Porting Thread

« Reply #12 on: 21 / January / 2012, 00:46:54 »

Ok.
I have worked alone for I have no previous knowledge of the chdk Software or the assembly for the Arm processors. So I have to study it before I could be of any help.

Doubts:
I used as references ports the A495 100f and the IXUS220 100C. The first seems similar in functionality and the other has the same DrysOs version. In the file captseq.c a firmware variable – nrflag – but I can’t find anything I feel comfortable with. The routine seems more like the IXUS220 version where, in spite of its definition, this version looks like making no use of it.
Another doubt the parameter PARAM_EXPOSURE_COUNTER in shooting.c. I have tried to monitor the param pages – starting 0 - and trying to alter camera (long shutter, exp) and I see no variation. I am altering wrong camera parameters or this model does not support it?

The other concerns some possible minor bug in the IXUS220 version. When I was searching a routine, it looks like a transcription error.

The version attached is based on trunk1487 and is for A800 version 100C.
There is any testing procedure to check if the behavior is correct?

a800-100c-0.9.9-r1487.zip (109.41 kB - downloaded 93 times.)

Logged

waterwingz

12140

Re: A800 Porting Thread

« Reply #13 on: 21 / January / 2012, 01:10:43 »

Quote from: mlands on 21 / January / 2012, 00:46:54

I used as references ports the A495 100f and the IXUS220 100C. The first seems similar in functionality and the other has the same DrysOs version.

Good choices from what I know.

Quote

In the file captseq.c a firmware variable – nrflag – but I can’t find anything I feel comfortable with. The routine seems more like the IXUS220 version where, in spite of its definition, this version looks like making no use of it.

I don't know either - sorry. But its a minor function and you can get a pretty good alpha CHDK port without it.

Quote

Another doubt the parameter PARAM_EXPOSURE_COUNTER in shooting.c. I have tried to monitor the param pages – starting 0 - and trying to alter camera (long shutter, exp) and I see no variation. I am altering wrong camera parameters or this model does not support it?

You need to actually take a picture to see this value change.

Quote

The other concerns some possible minor bug in the IXUS220 version. When I was searching a routine, it looks like a transcription error.

Need more details here.

Quote

There is any testing procedure to check if the behavior is correct?

Not really. But there is a test script on the wiki but that mostly tests scripting language functionality (which needs the underlying code to work so is a good place to start). http://chdk.wikia.com/wiki/Testing

« Last Edit: 21 / January / 2012, 01:37:24 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

mlands

32

Re: A800 Porting Thread

« Reply #14 on: 21 / January / 2012, 01:29:40 »

Thanks,
I think I can follow these steps: I will check the parameter as you told me; make some adaptation for the present trunk version; translate any relevant comments I have put (I speak Portuguese) and contact the forum again to send the source code so that you can decide what is better to do. What do you think ? And where I can find the script you have mentioned?
As I am particularly interested in the remote shooting, I will also begin to check this.

Logged

waterwingz

12140

Re: A800 Porting Thread

« Reply #15 on: 21 / January / 2012, 01:39:29 »

Quote from: mlands on 21 / January / 2012, 01:29:40

And where I can find the script you have mentioned?

http://chdk.wikia.com/wiki/Testing

Quote from: mlands on 21 / January / 2012, 01:29:40

As I am particularly interested in the remote shooting, I will also begin to check this.

This thread might be of interest http://chdk.setepontos.com/index.php?topic=7127.0

Logged

Ported : A1200 SD940 G10 Powershot N G16

Qanthelas

71

Re: A800 Porting Thread

« Reply #16 on: 21 / January / 2012, 22:05:31 »

Well how about that...I didn't expect much activity here, thanks for the pleasant surprise mlands! I just downloaded a800-100c-0.9.9-r1487.zip that you linked, put the DISKBOOT.BIN on my card, locked it, and it loads! I'm impressed! For being new to this, you did quite well, I think

I was still trying to figure out how I was going to get to the point that you're at now

Please post the source when you get the chance, I'd love to see what you did

EDIT: I tried running the scripts to test things, but sadly I can't seem to load scripts on this alpha build. <ALT> and Func./Set doesn't do anything and in the menu the area where it should be (above Miscellaneous Stuff) goes to Visual Settings with no scripting option.

« Last Edit: 21 / January / 2012, 23:12:00 by Qanthelas »

Logged

mlands

32

Re: A800 Porting Thread

« Reply #17 on: 22 / January / 2012, 00:46:29 »

I am sending the source code.
To compile it

1)Add in ./camera.csv
a800,100c,,,

2)Add in include/modelist.h
MODE_BLUR_REDUCTION , // A800

3)Compile Options used
OPT_DEBUGGING, OPT_CHD_IN_EXMEM, OPT_EDGEOVERLAY, OPT_EXMEM_MALLOC

As soon as someone make a revision ...

1593_Source_loader_a800.zip (4.12 kB - downloaded 82 times.)

1593_Source_platform_a800.zip (26.21 kB - downloaded 94 times.)

Logged

mlands

32

Re: A800 Porting Thread

« Reply #18 on: 22 / January / 2012, 00:49:07 »

In revising the work I have the following questions:

1) The constants defined in include/modelist.h - MODE_SCN_FIREWORK x MODE_FIREWORK, for example, both can be used? As new MODES were added in this new trunk, I used a mix. I have added MODE_BLUR_REDUCTION to the include\modelist.h.

2)EXMEM_BUFFER_SIZE - The porting procedure instructions recommends to use something between 2M / 4M. But the ixus220 porting use 640Kb (I used this). So what is better let memory to the camera or to chdk software?

3) unlocking zoom while filming - The way it is when press zoomIn and then zoomOut the zooming(optical and digital) gets locked - even after stopping registering. We have to go to review mode and return so that the zoom is again unlocked (zoom_status=ZOOM_OPTICAL_MEDIUM) - a strange behavior. On the other hand If we add in core\gui.c line 2020:
#if defined (CAMERA_s90) || defined (CAMERA_s95) || defined (CAMERA_g12) || defined (CAMERA_a3000) || defined (CAMERA_a800) everything seems to work fine with optical and digital zoomIn and zoomOut at will.

4) A suggestion: for using OSD change the printf format of memory content so that stable size patterns are displayed

5) I have made a change in platform\a800\kbd.c on the procedures kbd_key_press(long key), kbd_key_release(long key) and kbd_key_release_all(). The A800 seems to have the same behavior as the A495 (Menu,up,down and left) have an inverted 1 state for key pressed. The anding of KEYS_MASK2 with a new mask on a |= doesn`t reset the bit. Indeed I don't know if the values are really called. So I will try to test it.

6) When adapting for the new trunk I observed that if I don't use the option EDGEOVERLAY I get an "undefined module_save_edge" error on any compilation.

7) The problem I think I have seen on ixus220 porting is on the procedure sub_FF8B84D0_my() in captseq.c. Take a look.

void __attribute__((naked,noinline)) sub_FF8B84D0_my() {
//FF8B84D0 IXUS220: DONE
   asm volatile (
" STMFD SP!, {R4-R6,LR} \n"
" LDR R5, =0x3EE0 \n"
" MOV R4, R0 \n"
" LDR R0, [R5,#4] \n"
" CMP R0, #1 \n"
" LDRNE R1, =0x146 \n"
" LDRNE R0, =0xFF8B8308 \n" //aShutter_c IXUS220 at FF8B8308
" BLNE _DebugAssert \n"
" CMN R4, #0xC00 \n"
" LDREQSH R4, [R5,#2] \n"
" CMN R4, #0xC00 \n"
" MOVEQ R1, #0x14C \n"
" LDRNE R0, =0xFF8B8308 \n" //aShutter_c IXUS220 at FF8B8308 <<============
" STRH R4, [R5,#2] \n"
" BLEQ _DebugAssert \n"
" MOV R0, R4 \n"
" BL apex2us \n"     // patched
"             B       sub_FF8B8514 \n"   // IXUS220 continue in firmware at ff8b8510

);
}
The firmware version:
ff8b84d0:    e92d4070    push   {r4, r5, r6, lr}
ff8b84d4:    e51f51dc    ldr   r5, [pc, #-476]   ; ff8b8300: (00003ee0)
ff8b84d8:    e1a04000    mov   r4, r0
ff8b84dc:    e5950004    ldr   r0, [r5, #4]
ff8b84e0:    e3500001    cmp   r0, #1
ff8b84e4:    159f13d4    ldrne   r1, [pc, #980]   ; ff8b88c0: (00000146)
ff8b84e8:    124f0f7a    subne   r0, pc, #488   ; ff8b8308: (74756853) *"Shutter.c"
ff8b84ec:    1bfd99e5    blne   loc_ff81ec88
ff8b84f0:    e3740b03    cmn   r4, #3072   ; 0xc00
ff8b84f4:    01d540f2    ldrsheq   r4, [r5, #2]
ff8b84f8:    e3740b03    cmn   r4, #3072   ; 0xc00
ff8b84fc:    03a01f53    moveq   r1, #332   ; 0x14c
ff8b8500:    024f0c02    subeq   r0, pc, #512   ; ff8b8308: (74756853) *"Shutter.c" <<============
ff8b8504:    e1c540b2    strh   r4, [r5, #2]
ff8b8508:    0bfd99de    bleq   loc_ff81ec88
ff8b850c:    e1a00004    mov   r0, r4
ff8b8510:    eb060b1d    bl   loc_ffa3b18c

Logged

philmoz

3450

Re: A800 Porting Thread

« Reply #19 on: 22 / January / 2012, 01:14:24 »

Quote from: mlands on 22 / January / 2012, 00:49:07

In revising the work I have the following questions:

1) The constants defined in include/modelist.h - MODE_SCN_FIREWORK x MODE_FIREWORK, for example, both can be used? As new MODES were added in this new trunk, I used a mix. I have added MODE_BLUR_REDUCTION to the include\modelist.h.

Yes you can use whichever you want. Different modes are scene modes on some cameras; but direct modes on others. The names should probably have never been initially created with the 'SCENE' bit in them.

Quote

2)EXMEM_BUFFER_SIZE - The porting procedure instructions recommends to use something between 2M / 4M. But the ixus220 porting use 640Kb (I used this). So what is better let memory to the camera or to chdk software?

The instructions for determining the safe values for EXMEM are here - http://chdk.wikia.com/wiki/ExMem_-_enabling_and_loading_CHDK_into_extended_memory. Once you know if there's any memory that needs to be skipped for video buffers you can adjust the values to find the maximum size. Probably best not to use the max size in case the camera needs some.

If you haven't followed this process to get the values for your camera then it's probably not safe to use EXMEM.

Quote

3) unlocking zoom while filming - The way it is when press zoomIn and then zoomOut the zooming(optical and digital) gets locked - even after stopping registering. We have to go to review mode and return so that the zoom is again unlocked (zoom_status=ZOOM_OPTICAL_MEDIUM) - a strange behavior. On the other hand If we add in core\gui.c line 2020:
#if defined (CAMERA_s90) || defined (CAMERA_s95) || defined (CAMERA_g12) || defined (CAMERA_a3000) || defined (CAMERA_a800) everything seems to work fine with optical and digital zoomIn and zoomOut at will.

Adding your camera to special cases like this is fine - use whatever makes it work.

Quote

4) A suggestion: for using OSD change the printf format of memory content so that stable size patterns are displayed

Sorry, I don't understand this?

Quote

5) I have made a change in platform\a800\kbd.c on the procedures kbd_key_press(long key), kbd_key_release(long key) and kbd_key_release_all(). The A800 seems to have the same behavior as the A495 (Menu,up,down and left) have an inverted 1 state for key pressed. The anding of KEYS_MASK2 with a new mask on a |= doesn`t reset the bit. Indeed I don't know if the values are really called. So I will try to test it.

Are the bits actually active high in the phsyw_status array or just because of the special case code in kbd_is_key_pressed. There is code in gui_draw_debug_vals_osd you can enable to display the physw_status values and then watch them on screen as you press the buttons. It would be very unusual to have key status bits be normally low and go high when pressed.

Quote

6) When adapting for the new trunk I observed that if I don't use the option EDGEOVERLAY I get an "undefined module_save_edge" error on any compilation.

Thanks, I'll look at that. With the new module system in the trunk it does not cost very much memory to have edge overlay enabled as it is now stored in a module. It takes memory only when you turn it on.

Quote

7) The problem I think I have seen on ixus220 porting is on the procedure sub_FF8B84D0_my() in captseq.c. Take a look.

void __attribute__((naked,noinline)) sub_FF8B84D0_my() {
//FF8B84D0 IXUS220: DONE
   asm volatile (
" STMFD SP!, {R4-R6,LR} \n"
" LDR R5, =0x3EE0 \n"
" MOV R4, R0 \n"
" LDR R0, [R5,#4] \n"
" CMP R0, #1 \n"
" LDRNE R1, =0x146 \n"
" LDRNE R0, =0xFF8B8308 \n" //aShutter_c IXUS220 at FF8B8308
" BLNE _DebugAssert \n"
" CMN R4, #0xC00 \n"
" LDREQSH R4, [R5,#2] \n"
" CMN R4, #0xC00 \n"
" MOVEQ R1, #0x14C \n"
" LDRNE R0, =0xFF8B8308 \n" //aShutter_c IXUS220 at FF8B8308 <<============
" STRH R4, [R5,#2] \n"
" BLEQ _DebugAssert \n"
" MOV R0, R4 \n"
" BL apex2us \n"     // patched
"             B       sub_FF8B8514 \n"   // IXUS220 continue in firmware at ff8b8510
);
}
The firmware version:
ff8b84d0:    e92d4070    push   {r4, r5, r6, lr}
ff8b84d4:    e51f51dc    ldr   r5, [pc, #-476]   ; ff8b8300: (00003ee0)
ff8b84d8:    e1a04000    mov   r4, r0
ff8b84dc:    e5950004    ldr   r0, [r5, #4]
ff8b84e0:    e3500001    cmp   r0, #1
ff8b84e4:    159f13d4    ldrne   r1, [pc, #980]   ; ff8b88c0: (00000146)
ff8b84e8:    124f0f7a    subne   r0, pc, #488   ; ff8b8308: (74756853) *"Shutter.c"
ff8b84ec:    1bfd99e5    blne   loc_ff81ec88
ff8b84f0:    e3740b03    cmn   r4, #3072   ; 0xc00
ff8b84f4:    01d540f2    ldrsheq   r4, [r5, #2]
ff8b84f8:    e3740b03    cmn   r4, #3072   ; 0xc00
ff8b84fc:    03a01f53    moveq   r1, #332   ; 0x14c
ff8b8500:    024f0c02    subeq   r0, pc, #512   ; ff8b8308: (74756853) *"Shutter.c" <<============
ff8b8504:    e1c540b2    strh   r4, [r5, #2]
ff8b8508:    0bfd99de    bleq   loc_ff81ec88
ff8b850c:    e1a00004    mov   r0, r4
ff8b8510:    eb060b1d    bl   loc_ffa3b18c

Yes, looks like a mistake to me.

Nice job on the port.

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)