Flash strobing fire with long exposure

[scherbakoff.dima]

I've got Canon 100D/SL1 DSLR and after reading some photos books I've got an nice idea -- my internal flash recharge time is about 3 seconds, and I can use long exposures like 10 seconds. Can I program flash firing as-fast-as-possible while shooting image with LUA API for multiply position freezing of persons?
I've checked through documentation of LUA.MO and didn't find any function to fire flash. I've seen only flash EC setup.
Thanks in advance Enjoy picture from Russia 

[knoodrake]

Just replying to say that I have no Idea 
I looked up a bit in lua doc and indeed, coulnd't find any function to fire strobe.
The only place I saw strobes mentioned is in the Canon properties, and, apparently you can set them, but

• I don't know if changing the property will imply any action at all
• property:request_change (...) have a huge warning about briking your camera.

So I'm not sure it is yet exposed in Lua (if possible at all).
But I just discovered ML scripting a few days ago, so don't take my word !

[a1ex]

This one needs some reverse engineering; at this point I don't know how to trigger the flash arbitrarily, but didn't really look into it.

Might be useful: http://www.magiclantern.fm/forum/index.php?topic=3920.0

Understanding the MPU code should be also useful, but it's quite difficult. I'm not sure who initiates the flash command when taking a picture, but it's likely to be the MPU, because it needs to sync with the mechanical shutter (also handled by the MPU).

[knoodrake]

Any way I can help while not understanding anything (for instance, I don't even know what MPU means), just by giving infos/dump/things, doing some tests ?

I've a 5D3, a 580EXII, 480EXii a yongnuo copy of the 580, some youngnuo transmitter/receiver, ML, and java dev, so can find my way arround bash, git, VMs, IDEs, etc... but anything too close to the hardware I think I won't understand any bit

EDIT: My bad, just a quick google told me what MPU means. sorry

[a1ex]

Logging the MPU communication when the flash is enabled and looking for patterns should be a good starting point.

You will need to compile the dm-spy-experiments branch with CONFIG_DEBUG_INTERCEPT=y, then either place the testing code (e.g. taking a picture with flash) in "don't click me" (currently, the test code is taking a full-res silent picture, without the shutter actuation, CR2/JPG conversion and file saving), or run it manually (Debug -> DebugMsg Log before/after the test action).

Some details about this tool:
http://www.magiclantern.fm/forum/index.php?topic=2388.msg113154#msg113154

This thread should be also helpful (maybe you can get started by recognizing some patterns from there):
http://www.magiclantern.fm/forum/index.php?topic=17596.0

[knoodrake]

Thanks a1ex. I'm trying to make the whole stuff compile in an ubuntu vm (vim, makefiles, ... no more Eclipse and gradle stuff, I'm feeling young again    ) but after fetching dm-spy-experiments I realized that the branch came from unified and does not have (yet?) support from 5D3.123 ? ( that is the one I use ). So I guess I would need to downgrade ?..  Correct ?

[a1ex]

You can merge both branches, just be careful: some stubs in the dm-spy branch are for 1.1.3 and others for 1.2.3 (easy to tell). The RAM ones are usually common in both versions, but the ROM ones are not.

Indeed, your best bet is to downgrade.

[knoodrake]

I was thinking at merging 5D3-113-and-123 in dm-spy-experiments.
Quick online overview of the diffs https://bitbucket.org/hudson/magic-lantern/branches/compare/5D3-113-and-123%0Ddm-spy-experiments#diff
didn't look that scary to me, but since I don't understand much... ?

[a1ex]

That one should work as well, but the branch including both models is pretty much untested.

Just be careful with the config definitions in dm-spy-extra.c (replace them with CONFIG_5D3_113 and CONFIG_5D3_123 as needed). Currently, the CONFIG_5D3 definitions are for 1.1.3.

[knoodrake]

Thanks, I'll try that !
Now I just have to find how to git merge/pull with hg  (never used)

_{EDIT okay that was easy: git hg merge xxxxx} 

[knoodrake]

Sorry for the many questions and ignorance, but there's already definitions for CONFIG_5D3_123 in dm-spy-experiments' file. Should I nevertheless overwrite CONFIG_5D3 definitions with them ?

[knoodrake]

too hardcore for me I think. Can't make it to compile.

Some problem with recent refactors related to tasks.
Now I miss "current_task" in 5D3.123 stub.S and I have no Idea what this value should be. I tried to find It (or it's equivalent) in other branches but I couldn't find.

I tried to revert ( called backout in hg ?) the commit  where you ( a1ex ) introduced an unknown (for the 5D3.123 at least) current_task variable use in boot-hack.c but that just moved the very same problem elsewhere, didn't change much that it was a missing get_the_value or the reference to the value itself since I don't know what it is.

Maybe I'll try another way (downgrading) but I enjoyed learning arround those problems so it would be a pitty (for me at least) to give up. Maybe you may have some hints ?

Regards,

knoodrake

[a1ex]

current_task is in stubs.S and it's the same in 1.1.3 and 1.2.3. Indeed, I recently made some changes to speed up finding task name, and there are a few bits missing on most cameras.

Will check later if there are more tricks required.

[knoodrake]

Thanks a1ex, copying the current_task from the 1.1.3 to 1.2.3 worked and now it compiles 


but about dm-spy-extra.c, quoting myself

there's already definitions for CONFIG_5D3_123 in dm-spy-experiments' file. Should I nevertheless overwrite CONFIG_5D3

?
Wouln't want to brick my camera for a stupid reason

[knoodrake]

Hi all,

I managed to build a non-bricking build of 5D3-113-and-123 with dm-spy-experiments merged, I set the CONFIG_DEBUG_INTERCEPT flag, etc.. et... but It crashes when I try to click Debug -> DebugMsg Log.

Also, I don't see interesting pieces of logs in the LOG000.log file.. so maybe I somehow missed the "extra" part of the spy stuff ? Or it just crashes before anything interesting happens ?
I'll try to look into it but I am absolutely not in my dev "comfort zone" (eg. I understand nothing).
Anyway, here's the (joined) 5 error log files I got on the CF:

Code: [Select]

# log file 0
ASSERT: hLvJob->hJpegMemSuite
at ./Epp/Vram/VramStage.c:891, task Epp
lv:1 mode:3

# log file 1
ASSERT: IsSuiteSignature( hSuite )
at ./PackMemory/PackMem.c:599, task Epp
lv:0 mode:3

# log file 2
ASSERT: IsSuiteSignature( hSuite )
at ./PackMemory/PackMem.c:599, task RscMgr
lv:0 mode:3

# log file 3
ASSERT: IsSuiteSignature( hSuite )
at ./PackMemory/PackMem.c:983, task RscMgr
lv:0 mode:3

# log file 4
ASSERT: fInitialize == TRUE
at ./System/PostPostman/PostPostman.c:243, task Epp
lv:0 mode:3

Magic Lantern version : Nightly.2016Nov09.5D3123
Mercurial changeset   : b11d59e725eb+ (dm-spy-experiments) tip
Built on 2016-11-09 13:50:31 UTC by knoodrake@knoodrake-VirtualBox.
Free Memory  : 163K + 3058K

and here is the useless (or so it look to me) LOG000.log file: https://zerobin.net/?fd19cf634217e25a#TvzzNUDB40vk9L0a2sxHvOLAdjIDtIDVuesQtfpwyF8=

Also, maybe I should move elsewhere on the forum to discuss (being helped trying to help really) that building/spying stuff ? or is it okay here ?

Thanks,   

[knoodrake]

More pieces of infos about my crashes..

I could note on console:

Code: [Select]

birthday paradox ff694a84 PathDrv_EekoAddRawPathCore.c-div8
    conflicts with : ff291200 UnLockEngineResources
Patch error at 5b90 ( TOO_MANY_PATCHES )
Also, the Memory patches entry is red (and I guess it's bad): 21 ROM, 11 RAM
And indeed, many of them are red dotted. ( but some are green  like "register_interr"

[a1ex]

Will take a look; meanwhile, you can just disable all the definitions from dm-spy-extra, except mpu_send/recv.

[knoodrake]

Thank you a1ex. Don't bother to look into it yet please, because you made me realize I messed up a bit while merging in the dm-spy-extra file.
I'll start simple and fellow your advice, and just leave the mpu definitions.
Thanks.

[knoodrake]

So I tried to comment every definition that was red on the camera, leaving only those not conflicting (whatever that means..) and the 2 mpu ones. Unfortunatly, the 2 mpu ones then are the only two "memory patches" still red..  So I did'nt even try.

Then I tried to comment absolutely everything beside the 2 mpus, and still, only 3 "memory patches", the only green one beeing dm-spy. the two mpu ones still red.
Don't knowing the exact meaning of the dot colors, I tried anyway, and clicked dump log before and after a shoot. It didn't "crash" and I can see some lines like

Code: [Select]

**INTERRUP:000af560:00:00: *** mpu_recv(06 05 03 38 9c 00), from ff2e87f8
in the DM.log file produced ! semi-victory ?
I also tried to look quickly into hack.c/hack.h files but that is beyond my skills.

Bottom line: let me know if I can target specific kind of test (with and without flash, 100ISO then 400ISO, ... I don't know ?), or, give me hints (or point me to where I can find hints) on how to find so-called patterns.

Here is the DM.log https://zerobin.net/?5480338d835281b0#KpbsWTydjK9nHoSeEvT7R+z3jNv2yQ4j51bff4zMMpE=

[a1ex]

Looks good. Red doesn't mean error - it just means ROM patch (they are a bit tricky - if two addresses fall in the same cache line, you can use only one of them; the ROM patches might also be reset in certain conditions, when other code plays with the cache). Green means RAM patch (you can have as many as you want).

To get cleaner logs, it helps if your test code is ran with display off (Canon GUI outputs lots of messages). Disabling ML beeps may also help.

Now, I'd say a good starting point is to compare logs while taking a picture with or without flash.

[knoodrake]

Oh, okay ! so red means more tricky, not bad  Thank you.
I guess I can start by just cleaning (grep) the log files to keep only mpu lines and diff the with and the without flash logs (for instance).

Thanks for the help.

[knoodrake]

I guess I'll need some extra logs ( or less aggressive grep more likely ) to understand anything in that mess  https://www.diffnow.com/?report=0pvlf

thoses two topics you linked above http://www.magiclantern.fm/forum/index.php?topic=17596.0
and http://www.magiclantern.fm/forum/index.php?topic=2388.msg113154#msg113154 are very informative, but still..

I'll continue learning, and, hopefully, one day soon I may be able to give some actually interesting bits 

[a1ex]

Indeed, there's too much noise in the logs.

I've tried to get similar logs from 60D, with and without internal flash.

Test code:

Code: [Select]

static void run_test()
{
    msleep(2000);
    debug_intercept();
    lens_take_picture(64, 0);
    msleep(2000);
    debug_intercept();
}

Logs:
DM-0000.LOG (no flash, first picture after powering on the camera)
DM-0001.LOG (no flash)
DM-0002.LOG (flash enabled)
DM-0003.LOG (flash enabled)

Diffs (MPU messages only; input files reordered to minimize differences):
diff01.html (no flash vs no flash)
diff12.html (no flash vs flash)
diff13.html (no flash vs flash)
diff23.html (flash vs flash)

None of those looks like the main CPU is telling the MPU to fire the flash...

I guess our only option is to understand the MPU code, which is a LOT more difficult. For most DIGIC 4 cameras, the microcontroller (TMP19A43CDXBG) is documented fairly well, and emulating it in QEMU is probably doable, but requires a lot of effort (I'm not exactly fluent in MIPS assembly code). Hopefully it won't be a pipe dream in the next few years.

For D5, the microcontroller appears to be some sort Fujitsu FR, and I know very little about it. But the communication is most likely compatible (the message format looks quite similar), so figuring out on D4 will probably be enough for D5.

[knoodrake]

Please excuses me my lack of knowledge about that or if the reasoning is dumb but since the "original" (non-ML) canon GUI have a dedicated panel to configuring the external speedlite (and including whether it should fire or not), it has to be a catchable message somewhere from the cpu to ...the mpu I guess ?

BTW, Is that guaranteed that this is same mpu that handles the shoe flash signals and not another micro-controller (genuine question) ?

[a1ex]

the "original" (non-ML) canon GUI have a dedicated panel to configuring the external speedlite (and including whether it should fire or not), it has to be a catchable message somewhere from the cpu to ...the mpu I guess ?

Do you have a way to trigger the flash manually without taking a picture?
My understanding is that our main CPU tells the MPU what are the flash settings, but the decision when to fire the flash is taken by the MPU (most likely in sync with the shutter actuation).

BTW, Is that guaranteed that this is same mpu that handles the shoe flash signals and not another micro-controller (genuine question) ?

This is my best guess. There are few flash-related strings in the MPU firmware, but since these two need to be in sync, and the main CPU doesn't seem to be designed for real-time operation, it's very likely for flash firing to be controlled from the MPU.

550D:

Code: [Select]

StroboPopUpButton             :
StroboPopEndSw                :
[MAIN]:<TIMEOUT>strobo func get
[MAIN]:<TIMEOUT>strobo func set
[MAIN]:<TIMEOUT>strobo func reset
[MAIN]:<TIMEOUT>strobo cfn get
[MAIN]:<TIMEOUT>strobo cfn set
[MAIN]:<TIMEOUT>strobo cfn reset
[MAIN]:extstrobo on ui
[MAIN]:extstrobo off ui
[MAIN]:strobo aux charge err
[MAIN]:strobo aux end