Porting a camera sx530hs

blackhole

937
A590IS 101b

Re: Porting a camera sx530hs

« Reply #230 on: 11 / June / 2017, 17:41:48 »

Advertisements

You have disabled or removed the necessary items.
That's not a good idea.

Logged

http://astrofoto.pondi.hr

reyalp

14080

Re: Porting a camera sx530hs

« Reply #231 on: 11 / June / 2017, 23:50:18 »

Quote from: axman on 11 / June / 2017, 12:14:16

Attached tarball of my platform/sx530hs fw:100c :

Thanks for posting this.

Generally, a patch is preferred. If you use windows, tortoise create patch can be used from your working copy. From the command line, you can use svn diff.

It's also helpful if you submit changes for one thing at a time. Implementing filewrite for example is totally independent of the other changes you made. If you post small, self contained contained changes, it's a lot easier to review them.

Quote

I enabled filewrite, exp_drv_task and movie_rec tasks.

I disabled jogdial and liveview.

Why did you disable them? This camera does not appear to have a jogdial, but it does have a control wheel which I'd assume is hooked up to the jogdial code.

The taskHook function is an old style not used on this kind of camera. The task hook for this camera happens in taskhook.S

According to the comments, the liveimage task was used for video quality. movie_rec was also implemented in the existing code.

Quote

I also removed 'fix_writable_media_flag', as well as 'init_required_fw_features'. It was not clear from reading the port thread that those mods were actually required for the cam to run.. In basic tests, I saw no problems with power-On in play mode, using either button; and I had no problems with my (correctly prepared) bootable SD card.

The 'fix_writable_media_flag' flag fix was in part developed this specific port. For background, see this thread https://chdk.setepontos.com/index.php?topic=12795.0. Note that the symptom only affected certain SD cards, so the fact yours worked without it is not definitive.

init_required_fw_features is almost certainly also required for some specific overrides.

Generally speaking, I would not remove something unless I understand it enough to have high confidence it's not needed. Unfortunately, we do not have a comprehensive test suite and some workarounds are only needed in very specific cases. If in doubt, asking in the porting thread may save a lot of time and headache.

Quote

I wasn't sure how to test exp_drv_task, so beware, it may have bugs.

exp_drv_task is used to implement extra long exposures, generally over 64 seconds. So to verify it, you need to verify that exposure overrides still work, and that you can override > 64 seconds.

Note that if canon darkframe isn't disabled, the camera will be "busy" for the same length of time as the exposure.

Quote

Movie_rec was tested from CHDK scripts using cam/gui/buttons. Two small mp4's were made on the cam's SD card; ffplay identifies and plays them.

The movie_rec task is used to implement quality overrides on some cameras, but as mentioned above it appears to require stuff liveimage as well for this port (the old method stopped working for models released in the last few years)

To verify it, you need to verify that videos recorded with different quality settings have different compression levels. Very high compression should be pretty obvious. The defines in platform_camera.h also need to be set up to make the override accessible.

« Last Edit: 12 / June / 2017, 12:58:55 by reyalp »

Logged

Don't forget what the H stands for.

axman

145

Re: Porting a camera sx530hs

« Reply #232 on: 12 / June / 2017, 11:57:57 »

@blackhole, @reyalp

Thanks for the comments. I will try to re-enable what I had commented out, one element at a time. And will post 'svn diff' of changes instead of a tarball next time. It may take a few days..

Logged

reyalp

14080

Re: Porting a camera sx530hs

« Reply #233 on: 12 / June / 2017, 13:03:16 »

Quote from: axman on 12 / June / 2017, 11:57:57

@blackhole, @reyalp

Thanks for the comments. I will try to re-enable what I had commented out, one element at a time. And will post 'svn diff' of changes instead of a tarball next time. It may take a few days..

I really encourage you to do one thing at a time. Start with a clean working copy, do just the filewrite stuff, post that as a standalone patch. Then do expdrv, post a patch for that, and so on.

Logged

Don't forget what the H stands for.

axman

145

Re: Porting a camera sx530hs

« Reply #234 on: 12 / June / 2017, 15:39:36 »

Quote from: reyalp on 12 / June / 2017, 13:03:16

I really encourage you to do one thing at a time. Start with a clean working copy, do just the filewrite stuff, post that as a standalone patch. Then do expdrv, post a patch for that, and so on.

Good advice, I will proceed this way in the future. It's challenging to restrain myself from running as fast as possible to the end goal.. I was very happy to have remoteshoot work, and did not think or care about the 'bigger picture.' I cut those functions out because they were preventing me (at the time) from getting exp_drv_task and filewrite working. Now I see a bit better.

Meanwhile, I've re-enabled everything that was dis-abled, all at once. Worked my way through the fresh changes. It builds and boots CHDK..

I was just about to test the JogDial stuff using some chdkptp devutils "dpget" etc to see if it was working. I would read props, move the dial, compare props, etc. I thought this function was commented out in the orginal build, so I guess it's untested?

Then, test exp_drv_task with a manual long exposure.

Filewrite and movie_rec were tested before, will re-test.

If there are other specific or general tests I should exec, please say.

Umm.. I could take it all apart and submit one func at a time. I don't know svn that well (only enough to pull CHDK & chdkptp, otherwise a git user), so I will read about svn and see what's up.

Thanks again for the advice.

Logged

reyalp

14080

Re: Porting a camera sx530hs

« Reply #235 on: 12 / June / 2017, 16:26:04 »

Quote from: axman on 12 / June / 2017, 15:39:36

I was just about to test the JogDial stuff using some chdkptp devutils "dpget" etc to see if it was working. I would read props, move the dial, compare props, etc. I thought this function was commented out in the orginal build, so I guess it's untested?

You're right, it appears to be commented out in SVN. I had assumed it was previously enabled since you said you had disabled it, and missed that hook was commented out. I see comments I left when the port was added that there was conflict between the code-gen file and the provided boot.c

I'm not clear what you expect to test with propcases. The jogdial hook in CHDK has two main purposes:
1) Allow the use of the dial to navigate CHDK menus
2) Prevent use of the dial in alt mode from being seen by the Canon firmware

Additionally, CHDK supports sending wheel_left and wheel_right from script, but these are implemented using logical events, and do not depend on the task being hooked.

The port has CAM_HAS_JOGDIAL set, which should not be the case if it doesn't have a jogdial support.

As far as I can tell from the manual, this camera does not have a traditional jogdial (wheel combined with the directional keys) but does have a separate control dial. Treating the control dial as a jogdial in CHDK is probably worthwhile. This approach was used for the sx60 port.

Quote

Umm.. I could take it all apart and submit one func at a time. I don't know svn that well (only enough to pull CHDK & chdkptp, otherwise a git user), so I will read about svn and see what's up.

My general approach would be to check out a new working copy, and then copy of the files relevant to one of the individual changes (e.g. filewrite) and then undo any unrelated changes in those files.

If you use windows, the tortoise diff interface makes it really easy to do this kind of thing.

Logged

Don't forget what the H stands for.

axman

145

Re: Porting a camera sx530hs

« Reply #236 on: 12 / June / 2017, 18:20:18 »

Quote from: reyalp on 12 / June / 2017, 16:26:04

You're right, it appears to be commented out in SVN. I had assumed it was previously enabled since you said you had disabled it, and missed that hook was commented out. I see comments I left when the port was added that there was conflict between the code-gen file and the provided boot.c

I'm not clear what you expect to test with propcases. The jogdial hook in CHDK has two main purposes:
1) Allow the use of the dial to navigate CHDK menus
2) Prevent use of the dial in alt mode from being seen by the Canon firmware

I'm not 100% clear on what I'm doing, that's why I thought propcases would show the effects of moving the wheel. After your explanation, I think I'm on track.

Quote

As far as I can tell from the manual, this camera does not have a traditional jogdial (wheel combined with the directional keys) but does have a separate control dial. Treating the control dial as a jogdial in CHDK is probably worthwhile. This approach was used for the sx60 port.

I need a glossary update.

Cam has rotary dial with different shooting modes associated to each rotary knob detent position. Two of the knob selections, AUTO and auto-movie-hybrid? are silkscreened Green in color. This knob is immediately right of the power-On button.

Cam *also* has rotary dial behind the shutter, its plane of rotation is 90 deg from shutter, ie, holding cam normally, you rotate this dial ccw or cw with your right index finger.

Cam also has traditional<?> zoom in / zoom out control, it's the outer ring of the shutter.

What I assumed was JogDial in code was the rotary control behind shutter.

Since I've fully re-enabled JogDial function, I will try rotary-control-behind-shutter (don't know its proper name, is this what you called 'control dial' ?) to see if it causes CHDH menu navigation.

Logged

axman

145

Re: Porting a camera sx530hs

« Reply #237 on: 12 / June / 2017, 18:26:38 »

Here's svn diff (from assembla src to my current) of capt_seq.c, which seems to encapsulate the exp_drv_task.

tested the exp_drv_task by the following;

1) CHDK main menu-> Enh Photo Ops->
Disable overrides no
Override Tv type Long 1min30sec exposure
override iso = 70
no flash
CHDK dark frame subtraction off
Disable overrides on Startup un-ticked

Put camera in closet, Canon 10s delay, press shutter and watch LCD;
shutter stays open 1:30, closes and Canon osd returns (Program mode)
Picture looks ok, closet is not totally light-sealed either.
No CHDK osd warnings about "NO OVERRIDES" are seen.

I gather from nature of this test that exp_drv_task patch -> apex2us is the magic that allows super long (or short) exposures (beyond what Canon provided in factory firmware.)

Also did hdr.lua;
Light pic was very light, Dark pic very dark, and a medium pic; all seem ok.

Also did isoovr.lua Counted a few iso's up to 3200, ok.

I can provide link to the images captured by above tests, if useful. Anything else I could test re: exp_drv_task or capt_seq generally, let me know.

platform-sx530hs-100c-capt_seq.c-diff (18.92 kB - downloaded 14 times.)

Logged

srsa_4c

4451

Re: Porting a camera sx530hs

« Reply #238 on: 12 / June / 2017, 18:50:21 »

Quote from: axman on 12 / June / 2017, 18:26:38

Anything else I could test re: exp_drv_task or capt_seq generally, let me know.

Can you please test extra long (and extra short) exposures, using vanilla, unaltered svn? I had the impression that at least extra long ones are already working.

Quote from: blackhole on 31 / May / 2016, 16:56:11

After 15 consecutive exposures of 64 seconds, the battery temperature increases by 5 degrees and stays at that level the next 5 exposures.

If exposure times outside the range available from the Canon UI are working, implementing exp_drv_task is rather pointless.

Logged

axman

145

Re: Porting a camera sx530hs

« Reply #239 on: 12 / June / 2017, 20:17:06 »

Quote from: srsa_4c on 12 / June / 2017, 18:50:21

Can you please test extra long (and extra short) exposures, using vanilla, unaltered svn? I had the impression that at least extra long ones are already working.

I will check out existing source into separate dir, then will build vanilla unaltered-by-me svn and test.

I don't have a feel for what is extra long or extra short exposure. Long=5min? 60? Short=?
Please advise with your suggested time spans, and number of test repeats, if that matters.

Quote from: blackhole on 31 / May / 2016, 16:56:11

After 15 consecutive exposures of 64 seconds, the battery temperature increases by 5 degrees and stays at that level the next 5 exposures.

Quote from: srsa_4c on 12 / June / 2017, 18:50:21

If exposure times outside the range available from the Canon UI are working, implementing exp_drv_task is rather pointless.

Please explain why it is rather pointless - it will greatly help me understand what's going on. I will implement this cam with a battery eliminator and a large, well regulated power source. Battery temp is not an issue to me. But camera temp might be. Not sure what you mean, - not sure how battery temp after heavy use relates to the exp_drv_task . ? .

Thanks much for the feedback.

Logged