EOS M100 porting

Caefix

Caefix
A lovely lens is 7artisans 35 1:1.2. Looks nostalgic, boots fine.
Could we have focus magnifier with manual lenses?

🙁 Well, now I have another nice magnifier, but due to missing contacts it isnÂ´t recognized as an attached lens.
Is there a CHDK-way to make cam shooting without any lens?

srsa_4c

CaefixIs there a CHDK-way to make cam shooting without any lens?

No and there is no need. Check out the C.Fn section of the Canon menu (only available in rec mode).

c_joerg

srsa_4c
0xE03E644F for firmware 100a.

Thanks, power down worksâ€¦
But the script didnâ€™t shoot after power down.
I have to set

set_record(true)

before I shoot. On my M3, it is not necessary.
Is this something with the port or is the M3 different in the way to shoot?

Is there any reason, why cam comes back in playback mode?

-- schedule power-on event, '2' is for playback mode
 call_func_ptr(func,2,delay*1000)

srsa_4c

c_joerg
Is there any reason, why cam comes back in playback mode?
[code]-- schedule power-on event, '2' is for playback mode
call_func_ptr(func,2,delay*1000)[/code]

The answer is in the comment. If you replace 2 with 1, the cam should restart in rec mode. Those constants are the same for M100 and M3 (and probably the rest).

Caefix

c_joerg

Caefix
??? Seen in other EOS-M topics,too: some lenses avoid to write their dist_values at the expected addresses,
even Canon EF28-90 &EF70-210.

Older lenses probably do not offer this interface...

EF35-80(II) & EF35-80-Ultrasonic, EF28-80(IV)-Ultrasonic & Cosina AF 100-400 same,
fine dist_values from EF70-300-IS-USM.
~~Seems, that we need Canon EF not without STM or USM.~~ 😳
DonÂ´t know the most important letter here, but Tamron 18-270 Di2 VC PZD is all fine, too.
Edit:
Can EFS18-55: ~~DonÂ´t know,~~ AF Hardware faulty,random&blocking, always fdl=25 and fdu=25.

Edit2: CanonÂ´s EFS 18-55 (II), EFS 18-55 IS (II) & EFS 18-200 IS have fine returns. :😀
Now it seems, that lens needs image stabilizer...

c_joerg

Caefix
but Tamron 18-270 Di2 VC PZD is all fine,

My friend has the lens. Image quality is really badâ€¦

srsa_4cThe answer is in the comment. If you replace 2 with 1, the cam should restart in rec mode. Those constants are the same for M100 and M3 (and probably the rest).

Yes of course. So far, I have never paid attention to this parameter and asked myself why it is set to playback mode.
With the M3 the shoot seems to work from playback mode. If that wasn't the case, then I would have thought about the parameter more.

I changed now PowerDown.lua record mode. It looks like, that I have now less time jitter.

Caefix

😁~~Here I used the NPP++ Compare plugin to get M100.100a compiled with r5637.~~
Edit : Removed, probably as outdated as conf.c in the last 'testzip'.
All gccs seem to work, if this files are deleted before dropping into trunk.

&& DonÂ´t touch thjs switch here, no, donÂ´t!!! [ ]>🤣
// CHDK Compiler GUI switch, doesnÂ´t match all cams.
#ifdef OPT_EXMEM_MALLOC

c_joerg

Not that important to me, but maybe this information is interesting.
Bracketing (TV) and Custom Timer:
If TV is > 1s, then it doesnâ€™t work all the time. Sometimes itâ€™s startâ€™s only once after restart.
I didnâ€™t see the problem with TV < 1s.

Caefix

[unknown]

[unknown]

[unknown]
Also EOS M100 with Firmware 1.2.1
If there's no typo here, I'd like to see a dump of that firmware. The latest official upgrade is 1.1.0 (110b), from October last year.

I'm (slowly) working on a 110b port, but I don't know when it will be ready. The published source only works on the original 100a firmware (downgrading to that is not possible).

I have another M100 camera with V.1.0.0 also, I will give it a go.

😀 The latest diskboot.bin I got working ~~today~~ is 5670.
(My next reserve 5678 failed,
(since then one green LED left, after any power on ~ every ~15secs, 32Gb Sandisk ultra).

But everything seems to work fine as usual with my latest modules (5779)
(Latest Romlog: Occured Time 2020:11:17 18:18:46 : Exception!! [data abort] (562😎)
No ~~time~~ need to look deeper in code next days, so for first pictures before official solution ...
Edit: (M100_100a)
Just to have a full setup available for some extended fun with the cam.

M100-SoFarSoGoodFull 2.zip

784.15KB

M100-diskboot5670Modules5779.zip

301.05KB

Caefix

😳 How to avoid...

d:/hostluaportable/chdk-shell/trunk/gcc1021_host920/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld.exe: ../../../../platform/m100/libplatform.a(wrappers.o): in function `GetFreeCardSpaceKb':
wrappers.c🙁.text+0x30😎: undefined reference to `live_free_cluster_count'
collect2.exe: error: ld returned 1 exit status

reyalp

Caefix
😳 How to avoid...

d:/hostluaportable/chdk-shell/trunk/gcc1021_host920/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld.exe: ../../../../platform/m100/libplatform.a(wrappers.o): in function `GetFreeCardSpaceKb':
wrappers.c🙁.text+0x30😎: undefined reference to `live_free_cluster_count'
collect2.exe: error: ld returned 1 exit status
?

finsig_thumb2 finds this value, so you could make rebuild-stubs

Caefix

😀 Fine, found

stubs_entry.S:  line 141
DEF(live_free_cluster_count           ,0x00125b50) // (0x125b18+0x3😎 Found @0xe002d03e
old line 200 deleted:
NHSTUB(GetDrive_FreeClusters                  ,0xe033b889) //  0

and 4kb plus in funcs_by_*
Compiles successfully but still fails on cam.

/* Last working with #5670. 😐: Since then seems to happen...

// core/main.c line 147
    while((i++<100[0]) && !spytask_can_start) msleep(10);
// Edit: NO, not that, if commented out or modified then also nothing happens but 1*green LED every ~15secs +keypress.

before cam turns off without romlog. */

m100_stubs_funcs5779.zip

65.57KB

m100_stubs_funcs5805.zip

60.83KB

c_joerg

I don't know if it makes sense to post it, just want to inform.

I ran the M100 with the PowerDown script. Interval was 60s. https://chdk.setepontos.com/d/13956

The first 550 recordings were made without any problem. Then one shot was left out of one cycle. You can recognize it by the 'exp' column in the log file. It is also interesting that in this case the 'tick' value is quite large. These dropouts grew more and more towards the end.

PowDownInt_M100_60s.csv

284.77KB

srsa_4c

c_joerg
Then one shot was left out of one cycle. You can recognize it by the 'exp' column in the log file. It is also interesting that in this case the 'tick' value is quite large. These dropouts grew more and more towards the end.

There are even more anomalies, sometimes exp goes back and forth. You're instructing the camera to wake in rec mode, but is it in rec when it fails to shoot? Observing the camera's behaviour toward the end would probably be useful.

c_joerg

The problem occurs the first time after 547 shots. Before that everything is fine. In the end, it just keeps getting worse. The RAW files count up continuously. None is missing. I haven't seen that with the M3 before.

srsa_4c
There are even more anomalies, sometimes exp goes back and forth

Yes, this case occurs when many errors come together. I suspect that the file counter is not correct in this case.

srsa_4c
You're instructing the camera to wake in rec mode, but is it in rec when it fails to shoot?

Yes, the script wakes up in rec mode.
But I don't know if that was really the case. The script ran with display off. Maybe I should write the mode into the logfile. The longer tick value suggests that it was not the rec mode.
But why should the mode change?

srsa_4c
Observing the camera's behaviour toward the end would probably be useful.

How? In the end, I just noticed that the camera no longer triggers as often.

srsa_4c

c_joerg

srsa_4c
Observing the camera's behaviour toward the end would probably be useful.

How? In the end, I just noticed that the camera no longer triggers as often.

I'd guess the condition is triggered by either a large number of files on card or lower voltage (less likely).

The RAW files count up continuously. None is missing.

Is that CHDK DNG? If so, you could try adding a delay before the script turns the camera off.
I don't have a good explanation for the odd exposure data you get when the jpeg is missing. Perhaps hooks fail for some reason. You could also check for possible camera crash (make a romlog and look at the timestamp).

c_joerg

srsa_4c
I'd guess the condition is triggered by either a large number of files on card or lower voltage (less likely).

550 is not really a large number of files and voltage was at first time 7709mV (6439mV on the end).

srsa_4c
Is that CHDK DNG?

No. I used only Canon native RAW.

srsa_4c
Perhaps hooks fail for some reason. You could also check for possible camera crash (make a romlog and look at the timestamp).

No crash happens. The timestamp in romlog is from last year.

It must be some timeout. The â€˜startâ€™ value in the logfile is get_tick_count() just before shoot. The â€˜tickâ€™ value just after shoot. Only get_dofinfo between.

Normal condition 1550/2260
When it fails 1390/6390
Average M3 2900/4250 (Needs much longer for start)

Caefix

Caefix
😀 The latest diskboot.bin I got working ~~today~~ is 5670.
(My next reserve 5678 failed,
(since then one green LED left, after any power on ~ every ~15secs, 32Gb Sandisk ultra).

😛 There are 2 green Leds again, but worse, 🙁 since ~5811 ubasic & lua seem not compilable backward compatible; not too surprising the year after...

m100_stubs_funcs5904.zip

60.5KB

reyalp

You should use the modules built with whatever diskboot.bin you are using. There is no good reason to mix and match, and you should not expect to work.

As for the rest of your comment, I really have no idea what you are trying to communicate.

koshy

reyalp
As for the rest of your comment, I really have no idea what you are trying to communicate.

Some things never change it seems. Judging from the time it has been this way though I am inclined to think it is not so on purpose 😉. Why this cycle repeats on and on I have no clue though. What does amaze me however is that productive things seem to come out of it more or less regularly.

« Previous Page Next Page »