SX60HS Porting - page 44 - DryOS Development - CHDK Forum

SX60HS Porting

  • 915 Replies
  • 297822 Views
Re: SX60HS Porting
« Reply #430 on: 14 / June / 2016, 13:28:31 »
Advertisements
I tried to lock the card and to boot like that but it give me the error every time
Quote
Please give more details. What error? Is it from the camera, or when you are tying to make the card bootable?

I had card error message on screen when I tried to boot. That was it. But, in fact I didn't prepared the card for booting at all, all I did was just to copy CHDK file on card and that's it. I suppose that was the reason why I had that error.

Quote
When I want to use chdk I push the play button and then go to upgrade via Menu button. In fact, I don't use writelock at all.
Quote
Firmware update is known to have problems on digic 6 cameras. I would not recommend using it for shooting.

I am afraid that I didn't quite understand this. The purpose of CHDK is to shoot pictures with some advanced features. I can tell that intervalometer script is working excellent (problem with rotated pictures remains) and it is working much better then option without CHDK and with intervalometer device (plugged into the  camera).



Re: SX60HS Porting
« Reply #431 on: 14 / June / 2016, 14:22:40 »
I suspect the error is that canon boots and complains with a message about write lock because Giles has not executed  makesdcard bootable.
« Last Edit: 14 / June / 2016, 14:30:25 by 62ndidiot »

*

Offline reyalp

  • ******
  • 13621
Re: SX60HS Porting
« Reply #432 on: 14 / June / 2016, 15:39:40 »
I had card error message on screen when I tried to boot. That was it. But, in fact I didn't prepared the card for booting at all, all I did was just to copy CHDK file on card and that's it. I suppose that was the reason why I had that error.
You should be able to copy the files, then use "firmware update", and the execute "make card bootable" in miscellaneous-> SD Card

Edit: But first, which *specific" error message? "Card locked" or something else?

Note if your card is formatted exFAT (default for 64GB and greater, AFAIK) it will need to be reformatted fat32 first.

Quote
I am afraid that I didn't quite understand this. The purpose of CHDK is to shoot pictures with some advanced features.
On all current Digic 6 ports, when the camera is booted with "Firmware update", attempting to use some modes (hybrid auto, at least) shuts down with a Canon hardware error message. This probably means something isn't being initialized correctly when CHDK is booted with this method. Other modes appear to work, but it's quite likely there could be other, subtler problems in other modes. So I personally would not recommend using the firmware update method for anything other than making the card bootable.
« Last Edit: 14 / June / 2016, 15:45:12 by reyalp »
Don't forget what the H stands for.

Re: SX60HS Porting
« Reply #433 on: 18 / June / 2016, 14:13:10 »
Experimenting with motion detection (motion.bas) because I don't understand why it should work at all on Digic 6 at this stage.  Setup the camera pointing at a wall, Tv mode 1/60. 17 as a threshold for detection (I think this is in percent?).
I definitely trigger a picture everytime I move the swivel to point forward (so I can see what's happening as I move into the picture).  The LCD has to blank an adjust to the new orientation, essentially upside down, swap left and right.
I can sometimes trigger a shot it seems by moving massively into the picture but sometimes not at all.

Changing the shutter setting triggered a shot...but again that changed some of the Canon display and overall brightness I think.

In AUTO mode, it seems to trigger more or less continuously, maybe because the camera adjusts to changing light and focus.

So maybe this is related to the on screen information displayed and not the actual image being captured? 

With regard to the auxiliary processors used in Digic 6 cameras (Xtensa), I'm sure others have thought far more deeply than I have. Ultimately, the image info reaches the LCD, either directly from the Xtensa memory area or indirectly by copying. Has anyone searched the Xtensa addressing space for possible image buffer candidates?




*

Offline reyalp

  • ******
  • 13621
Re: SX60HS Porting
« Reply #434 on: 18 / June / 2016, 15:45:02 »
Experimenting with motion detection (motion.bas) because I don't understand why it should work at all on Digic 6 at this stage. 
There is no reason to do this unless you've actually re-written the code to handle d6 frame buffer formats.
Quote
I definitely trigger a picture everytime I move the swivel to point forward (so I can see what's happening as I move into the picture).
If the live buffer addresses and dimensions are correct, motion detection may trigger because it will see changes in the values. However, interpretation of the values (what is Y or U or V) will be incorrect so the threshold values etc won't work.

edit: It is also possible it will sort of work even if the dimensions aren't totally right, e.g. even if it's only looking at half the actual data, it will still trigger when that part changes.
Quote
With regard to the auxiliary processors used in Digic 6 cameras (Xtensa), I'm sure others have thought far more deeply than I have. Ultimately, the image info reaches the LCD, either directly from the Xtensa memory area or indirectly by copying. Has anyone searched the Xtensa addressing space for possible image buffer candidates?
I am quite certain both processors share the same memory. Suitable buffers are accessible to regular ARM core. The issue is the format of the data being different, and determining the most recent buffer.

edit 2:
For MD to have reasonable reaction time, you also need to implement vid_get_viewport_live_fb to return the most recent buffer. On g7x, the live view appears to have 4 different buffers for the UYVY_d6, or 8 for the UYVY_old 640x480 ones.
« Last Edit: 18 / June / 2016, 16:51:58 by reyalp »
Don't forget what the H stands for.

Re: SX60HS Porting
« Reply #435 on: 22 / June / 2016, 16:59:04 »
Wasting time... ;)
Just checking how this liveview hack (I think thanks to srsa_4c) works for the SX60HS...I rebuilt hacked versions of chdkptp and my firmware (without the hacked version of chdkptp trying liveview crashes chdkptp). I modified sx60hs/lib.c to be  similar to that for the sx280hs and return different display sizes depending on the value of display type which ranges from 0 to 7.

https://chdk.setepontos.com/index.php?topic=6231.msg125041#msg125041

So far two issues:
1. the color of the liveview image is wrong (but it's viewable) (in rec mode), see attached image of my computer monitor....I think I applied the patches correctly.
In play mode, the window is pinkish garbage except where chdk displays the temp, and battery voltage...

2. my camera cycles through displaytype cases (0,1,...7) in lib.c, changing the resolution as is coded and apparently working in the sx280hs port. This produces ghosts of wrong rez images (from chdk) on the LCD, and frequent resizing of the liveview chdkptp display, even when I code a default of 640x480 for cases which are unspecified (which the SX280HS code (lib.c) appears not to need)...forcing 640x480 for all of them  stablizes things.  Obviously, I am missing something here that is present in the sx280 case.....

*

Offline reyalp

  • ******
  • 13621
Re: SX60HS Porting
« Reply #436 on: 22 / June / 2016, 17:28:33 »
1. the color of the liveview image is wrong (but it's viewable) (in rec mode), see attached image of my computer monitor
The sx280 uses a live view buffer with a different YUV format than the buffer being used on g7x.
I found equivalent buffers on g7x using a RAM dump, but they are 640x426 rather than 720x480.
Quote
In play mode, the window is pinkish garbage except where chdk displays the temp, and battery voltage...
For playback mode, the buffers are different. In CHDK, they should be returned by vid_get_viewport_fb_d()

I found these buffers on g7x in RAM dumps, but have not yet figured out how to find the active one. Comments from my code
Code: [Select]
playback viewport
TODO - 3 buffers 0x5e608000 0x5ea08000 0x5ee08000
initially found by RAM dumping
0x5e608000 ref sub_fc1ba3f0 "ImgDDev.c"
0x5ee08000 ref DispCon_ShowColorBar and other DispCon_* functions

Quote
2. my camera cycles through displaytype cases (0,1,...7) in lib.c, changing the resolution as is coded and apparently working in the sx280hs port.
This almost certainly (like 99.99% certain IMO) means your displaytype variable is incorrect. The resolution should only change if the actual display type changes e.g. camera LCD to HDMI etc. If the variable you are using cycles randomly, it's wrong.

Unless you have cases where the actual resolution changes, just hard code the correct values and don't implement CAM_SUPPORT_BITMAP_RES_CHANGE

edit:
Also note that _GetVRAMVPixelsSize and _GetVRAMHPixelsSize only return valid values in rec mode, so if you implement playback support, you will have to make the viewport size functions return appropriate values.
« Last Edit: 22 / June / 2016, 17:34:20 by reyalp »
Don't forget what the H stands for.

*

Offline Ant

  • ****
  • 497
Re: SX60HS Porting
« Reply #437 on: 22 / June / 2016, 17:44:33 »


Re: SX60HS Porting
« Reply #438 on: 22 / June / 2016, 18:19:59 »
Quote
try this version https://chdk.setepontos.com/index.php?topic=6231.msg125049#msg125049

may be my M3 port uses the same buffer type...
https://app.assembla.com/spaces/chdk-m3/subversion/source/HEAD/trunk/core/live_view.c
Nice!  :) It works, just reversed YUV8C and YUV8B. It also correctly displays a black background in play mode. See attached png.
Now searching the displaytype variable....the one I have cycles randomly, 0 thru 7 @0x95e4 . The one I want should be a constant value of 5.  I see such a value at 0x9504...but how to check?   Should it change when I close the LCD and use the EVF? Doesn't seem to.

Edit 1:  I compiled a version with fixed resolution for HDMI, connected it to a TV and looked at memory, the value at 0x9504 is still 5, so that's not it....hmmm, how to find the right location?
Edit 2: looked at M3 code. I think I need to revise how I am looking for displaytype. And it may not be a value of 5 which indicates LCD . Tomorrow.
« Last Edit: 23 / June / 2016, 16:30:06 by 62ndidiot »

Re: SX60HS Porting
« Reply #439 on: 23 / June / 2016, 16:30:48 »
Finally found displaytype for 100f:

DEF(displaytype,                              0x9284) // 0x923c + 0x48 found @0xfc304708 (42 refs)

It is 4 for LCD and 6 for HDMI, don't yet know the other values. Also found an indicator flag at 0x9244 which is 1 when the LCD is open/active, and 0 when closed so the EVF is active.

Quote
my camera cycles through displaytype cases (0,1,...7) in lib.c
This ocurred for the old value of displaytype 0x95e4....I am wondering if this variable is indexing one of eight buffers?

 

Related Topics