chdk in the DIGIC6 world

jonathan.holvey

7

Re: chdk in the DIGIC6 world

« Reply #40 on: 04 / January / 2015, 00:38:32 »

Advertisements

Hi,

I've been popping back to this thread over the last couple of months, as I'm interested in purchasing an S120 for use on an aerial photography platform.

Can you give a little explanation of the progress of this project so far, and an idea of how long it may be before it's in a semi-stable usable state? The discussion seems to mostly cover very basic principles, so I'm thinking it may be a while yet, but can't be sure. I certainly appreciate the amount of work that's involved in getting CHDK to work with the Digic6 cameras.

In the mean time I may end up getting an SX270 (if the CHDK features I require are supported), however the S120 seems to be a much nicer model for the same weight (smaller dimensions, bigger sensor, wider aperture and a more sensible zoom range).

Thanks for your efforts.

Cheers,
Jon

Logged

reyalp

14034

Re: chdk in the DIGIC6 world

« Reply #41 on: 04 / January / 2015, 02:02:17 »

Quote from: jonathan.holvey on 04 / January / 2015, 00:38:32

Can you give a little explanation of the progress of this project so far, and an idea of how long it may be before it's in a semi-stable usable state?

My impression is srsa's sx280/sx270 port is at least fairly usable now.

Quote

The discussion seems to mostly cover very basic principles, so I'm thinking it may be a while yet, but can't be sure. I certainly appreciate the amount of work that's involved in getting CHDK to work with the Digic6 cameras.

There's two distinct things going on
1) Making the current main CHDK source, build system etc support Digic 6 in a way that doesn't break the existing code and processes. That is primarily what is being discussed here.
2) Porting individual cameras. Currently, sx280 is the only port. Even after we get Digic 6 support in the trunk, porting Digic 6 cameras is likely to be significantly more difficult than previous generation cameras.

As far as schedule goes... there isn't one, for either. I would like to have Digic 6 support in CHDK 1.4, and I would like to get 1.4 released before the end of 2015, but that's just my personal wish, not some hard deadline.

For ports, there is no master plan of what gets ported, it's just a matter of someone with the required skill set having the camera and wanting to spend the time on it.

Logged

Don't forget what the H stands for.

jonathan.holvey

7

Re: chdk in the DIGIC6 world

« Reply #42 on: 04 / January / 2015, 02:39:46 »

Thanks fro the detailed explanation reyalp. It's handy to be able to understand the sort of development timescales we're talking about here.

I guess I'll be going with the SX270 for the time being. Here's to a successful 2015 for CHDK.

Cheers,
Jon

Logged

srsa_4c

4451

Re: chdk in the DIGIC6 world

« Reply #43 on: 29 / August / 2015, 14:33:19 »

Some information about the ARM core that runs CHDK (sx280).
Cortex-R4, 16k D + 16k I cache, no MMU.
Source.

CPUINFO.TXT (8.6 kB - downloaded 96 times.)

Logged

reyalp

14034

Re: chdk in the DIGIC6 world

« Reply #44 on: 30 / August / 2015, 21:00:30 »

Re division by 0

Quote from: reyalp on 03 / January / 2015, 17:53:48

Quote
Does scripting have protection against division by zero?
Lua doesn't, not sure how hard it would be to retrofit. Normal Lua on a PC gives gives me 1.#inf or similar.

Ubasic doesn't either, looks like it would be pretty easy to add. Terminating the script with divide by 0 would be a good thing.

It looks like Lua handles this using the define
#define luai_numdiv(a,b) ((a)/(b)) in luaconf.h, so providing our own should be relatively easy.

What it should do isn't entirely clear. As mentioned above, on a PC it gives a special FP value. On pre-digic6, it seems to return MAXINT, or 0 if the numerator is 0.

I'm not sure if we can just throw a Lua error at the point this macro is used (judging from other code, I suspect not), but if so, that would seem reasonable for all platforms, even if it isn't standard Lua.

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: chdk in the DIGIC6 world

« Reply #45 on: 01 / September / 2015, 12:53:11 »

Quote from: reyalp on 30 / August / 2015, 21:00:30

What it should do isn't entirely clear. As mentioned above, on a PC it gives a special FP value. On pre-digic6, it seems to return MAXINT, or 0 if the numerator is 0.

I guess we could do the same (are there scripts that rely on this?)

Quote

I'm not sure if we can just throw a Lua error at the point this macro is used (judging from other code, I suspect not), but if so, that would seem reasonable for all platforms, even if it isn't standard Lua.

If throwing an error isn't possible, perhaps setting an internal flag should still be possible? Not sure what could be done with that; evaluating it later and take action somehow, or just provide a function to read it? (The latter seems rather useless, who would use a function like that...) Note that I'm not familiar with Lua internals.

Independent from the above, I found out that "cache hacks" are not possible on Cortex-R (or perhaps on any Cortex), wonder how hard this will hit ML development.

« Last Edit: 01 / September / 2015, 12:55:32 by srsa_4c »

Logged

reyalp

14034

Re: chdk in the DIGIC6 world

« Reply #46 on: 01 / September / 2015, 15:59:50 »

Quote from: srsa_4c on 01 / September / 2015, 12:53:11

I guess we could do the same (are there scripts that rely on this?)

I doubt there are scripts that intentionally rely on it, but there are probably some that divide by zero.

Quote

If throwing an error isn't possible, perhaps setting an internal flag should still be possible?

Yes.

Quote

Not sure what could be done with that; evaluating it later and take action somehow, or just provide a function to read it? (The latter seems rather useless, who would use a function like that...) Note that I'm not familiar with Lua internals.

We could probably check it and generate an error at the end of the kbd_task script iteration, but it might be hard to provide useful debugging information.

Quote

Independent from the above, I found out that "cache hacks" are not possible on Cortex-R (or perhaps on any Cortex), wonder how hard this will hit ML development.

It's a pity Canon didn't go for a full MMU

It looks like the MPU supports region sizes down to 32 bytes, and also supports protecting up to 8 sub regions per region (again to 32 bytes), so you could potentially play tricks by protecting a region and then diverting access in the exception handler. Of course, you could only do this a very small number of places.

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: chdk in the DIGIC6 world

« Reply #47 on: 01 / September / 2015, 18:10:58 »

Quote from: reyalp on 01 / September / 2015, 15:59:50

It's a pity Canon didn't go for a full MMU

Sooner or later they will have to, the 32bit address space will soon become tight - even their compacts get 512MB of RAM nowadays.

Quote

It looks like the MPU supports region sizes down to 32 bytes, and also supports protecting up to 8 sub regions per region (again to 32 bytes), so you could potentially play tricks by protecting a region and then diverting access in the exception handler. Of course, you could only do this a very small number of places.

That's a smart idea. But it's a lot less convenient than just patching out single words you don't like in the ROM

Logged

reyalp

14034

Re: chdk in the DIGIC6 world

« Reply #48 on: 04 / October / 2015, 23:05:31 »

Here's a patch that should make Lua division behave like it does on pre-d6 CPUs. I'm not sure this is the best solution, but it's probably better than letting the script crash the cam, and it's consistent with current behavior.

I think a lua_error would be preferable (for both D6 and old CPUs), but I don't see a simple way to do that in the lua code.

d6-lua-div-work-1.patch (1.43 kB - downloaded 50 times.)

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: chdk in the DIGIC6 world

« Reply #49 on: 05 / October / 2015, 17:07:15 »

Quote from: reyalp on 04 / October / 2015, 23:05:31

Here's a patch that should make Lua division behave like it does on pre-d6 CPUs.

That fixes division, thanks. However...
Remembering that ARM firmwares use a single function to compute division and modulo, just tried the latter (=return 0%0), only to find that it crashes the camera as well. Will it be possible to find the rest of unsafe operations (if there's more) and fix them?

Logged