EOS M3 porting - page 48 - DryOS Development - CHDK Forum supplierdeeply
« previous next »
Pages: 1 ... 43 44 45 46 47 [48] 49 50 51 52 53 ... 75   Go Down

EOS M3 porting

  • 746 Replies
  • 394446 Views
*

Offline srsa_4c

  • ******
  • 4451
Re: EOS M3 porting
« Reply #470 on: 29 / April / 2018, 15:09:13 »
Advertisements
Quote from: Ant on 29 / April / 2018, 13:33:57
I found that some names of exceptions(for example at 0x00E0A1D8) are similar to:
https://github.com/espressif/esp-idf/blob/master/components/esp32/include/xtensa/corebits.h
That was first noticed by reyalp - and that helped me discover the Xtensa graphic core. It turned out later that the strings belong to a different core's firmware.
Quote
There are strings containing "bitrate" at aria 0x00E00000. Maybe bitrate information can be taken from there?
Yeah, the strings are there, but I can't produce a disassembly, so they don't help much.
Logged
*

Offline Ant

  • *****
  • 509
Re: EOS M3 porting
« Reply #471 on: 07 / May / 2018, 16:55:24 »
I found interesting event procedure(FC431D74) on M3:
Quote
Usage: SubCPURebootRequest [NextBootReason] [RebootTime]
       [NextBootReason] 1:POWER 2:PLAY 4:MyDevice 8:NFC
                       16:LENS_DETECT 32:LENS_SW 64:BATTERY_COVER 128:MEDIA_COVER
       [RebootTime] after millisec reboot.  0==>(no wait)

It also present on EOS M5, M6, M10 cameras and can be used for reboot(automaticaly turning on the power after shutdown) and maybe for intervalometer
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: EOS M3 porting
« Reply #472 on: 08 / May / 2018, 14:17:51 »
Quote from: Ant on 07 / May / 2018, 16:55:24
I found interesting event procedure(FC431D74) on M3:
Quote
Usage: SubCPURebootRequest [NextBootReason] [RebootTime]
       [NextBootReason] 1:POWER 2:PLAY 4:MyDevice 8:NFC
                       16:LENS_DETECT 32:LENS_SW 64:BATTERY_COVER 128:MEDIA_COVER
       [RebootTime] after millisec reboot.  0==>(no wait)

It also present on EOS M5, M6, M10 cameras and can be used for reboot(automaticaly turning on the power after shutdown) and maybe for intervalometer
Another useful observation.

Tried SubCPURebootRequest on my M10 and found the following:
- the timer appears to activate when the camera is switched off (+ approx. 2 seconds, not sure why)
- therefore, executing SubCPURebootRequest(2, 10000) and leaving the camera on does nothing until the cam is powered down plus ~12 secs

This would be a nice addition for long running intervalometer scripts (as a script command). But, unfortunately, it would be limited to the supported EOS M models.
Side note: there are some old PowerShots with a subcpu, but this specific eventproc does not exist in their fw. It would require some reverse engineering to find similar functionality (used by built-in Canon intervalometer).
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: EOS M3 porting
« Reply #473 on: 08 / May / 2018, 14:25:57 »
To M3 users:

I have enabled movie mode support for both supported fw versions.
Since 120f is untested, that port might be broken starting at revision 5013. Please leave a note in this thread if that happened, so that we can fix it.

Important: maximum achievable video bitrate is approx. 41000 kbit/s.
« Last Edit: 08 / May / 2018, 16:00:27 by srsa_4c »
Logged
*

Offline c_joerg

  • *****
  • 1248
Re: EOS M3 porting
« Reply #474 on: 09 / May / 2018, 03:47:45 »
Quote from: Ant on 07 / May / 2018, 16:55:24
It also present on EOS M5, M6, M10 cameras and can be used for reboot(automaticaly turning on the power after shutdown) and maybe for intervalometer

Quote from: srsa_4c on 08 / May / 2018, 14:17:51
Tried SubCPURebootRequest on my M10 and found the following:
- the timer appears to activate when the camera is switched off (+ approx. 2 seconds, not sure why)
- therefore, executing SubCPURebootRequest(2, 10000) and leaving the camera on does nothing until the cam is powered down plus ~12 secs

Interesting discovery ...
Logged
M100 100a, M3 121a, G9x II (1.00c), 2*G1x (101a,100e), S110 (103a), SX50 (100c), SX230 (101a), S45,
Flickr https://www.flickr.com/photos/136329431@N06/albums
YouTube https://www.youtube.com/channel/UCrTH0tHy9OYTVDzWIvXEMlw/videos?shelf_id=0&view=0&sort=dd
*

Offline srsa_4c

  • ******
  • 4451
Re: EOS M3 porting
« Reply #475 on: 13 / May / 2018, 11:21:25 »
I decided to make the above discussed automatic reboot available for scripting, as a Lua function (to be used directly in a script or included as module). Supports the M3 and M10 (all current ports).
Code: [Select]
--[[
Utility function providing scheduled camera start for use on EOS M3 and M10 cameras
Lua native calls are required.
]]

function power_down_for_seconds(delay)
    bi=get_buildinfo()
    cam_name=bi.platform
    cam_ver=bi.platsub
    func=0
    if cam_name=="m3" then
        if cam_ver=="101a" or cam_ver=="120f" then
            func=0xFC0F824F
        end
    elseif cam_name=="m10" then
        if cam_ver=="110d" or cam_ver=="110f" or cam_ver=="110g" then
            func=0xFC13207F
        end
    end
    if func~=0 then
        -- schedule power-on event, '2' is for playback mode
        call_func_ptr(func,2,delay*1000)
        -- power off immediately
        post_levent_for_npt("PressPowerButton")
    else
        -- returns false and does nothing on unsupported cameras
        return false
    end
    -- does not really return when successful
    return true
end
When power_down_for_seconds() is called, the camera switches off and then turns back on (in playback mode) after the specified number of seconds (plus 1...2 seconds).

Warning: the reboot event survives shorter power cuts (battery out for a few seconds). When the battery is removed for longer (and a reboot is scheduled), the cam switches quickly on/off after the battery is re-plugged.

edit:
(M10) Tested successfully with a 2 hour delay.

edit2:
To cancel a scheduled reboot, simply start the camera manually.

edit3:
(M10) Tested an exact 12-hour delay: camera woke up 12 hours 3 minutes and 40 seconds later.
« Last Edit: 08 / July / 2018, 15:04:19 by srsa_4c »
Logged
*

Offline c_joerg

  • *****
  • 1248
Re: EOS M3 porting
« Reply #476 on: 14 / May / 2018, 05:17:11 »
Quote from: srsa_4c on 13 / May / 2018, 11:21:25
When power_down_for_seconds() is called, the camera switches off and then turns back on (in playback mode) after the specified number of seconds (plus 1...2 seconds).

Does it works in record mode as well?

Quote from: srsa_4c on 13 / May / 2018, 11:21:25
Tested successfully with a 2 hour delay.
Where is the limit? 32Bit value?
Logged
M100 100a, M3 121a, G9x II (1.00c), 2*G1x (101a,100e), S110 (103a), SX50 (100c), SX230 (101a), S45,
Flickr https://www.flickr.com/photos/136329431@N06/albums
YouTube https://www.youtube.com/channel/UCrTH0tHy9OYTVDzWIvXEMlw/videos?shelf_id=0&view=0&sort=dd
*

Offline srsa_4c

  • ******
  • 4451
Re: EOS M3 porting
« Reply #477 on: 14 / May / 2018, 11:33:55 »
Quote from: c_joerg on 14 / May / 2018, 05:17:11
Does it works in record mode as well?
The eventproc supports other operating modes, see the possible values in Ant's post. I chose playback mode, because changing to rec mode is a matter of issuing set_record().
Quote
Where is the limit? 32Bit value?
The firmware function takes a 32bit integer for its 'RebootTime' parameter. So, the maximum delay can - theoretically - be approx. 24 or 48 days. What I know is that the whole 32 bits are passed on to the subcpu. What happens inside the subcpu's firmware is unknown. To find out the real limit, one would have to test it. What I tried so far is 2 hours on my M10. The delay's accuracy is also unknown.
Logged
*

Offline Ant

  • *****
  • 509
Re: EOS M3 porting
« Reply #478 on: 14 / May / 2018, 11:53:28 »
Quote from: srsa_4c on 14 / May / 2018, 11:33:55
What happens inside the subcpu's firmware is unknown.
You can dump and disassemble it using SubCPUMemoryDump procedure.
RENESAS R5F101CAA used as SubCPU on EOS M3.
Logged
*

Offline derMart

  • *
  • 3
Re: EOS M3 porting
« Reply #479 on: 03 / June / 2018, 07:24:10 »
Hey all, first thanks for all your great work so far! I have bought an M3 and not a different model/brand because CHDK is running there :-)

@srsa_4c: I have build rev. 5021 for firmware 1.20f. The bitrate changing feature works like a charm without crashes there. One quirk however ist that the reported byterates for cbr mode are varying (ex.: at 0.25 modifier, byterates vary between 384KB/s and around 700KB/s), I have not checked the encoded video if it varies there too. But I guess this is expected behaviour and just really a minor issue.

I have one big problem with CHDK on my M3 and this is the menu flickering issue reported on the M10.
It is very strange that this issue is not present on the timelapse tutorial here: https://chdk.setepontos.com/index.php?topic=12542.msg135299;topicseen#msg135299
To eliminate any software differences I downgraded to 1.01a and used rev4794 as in the tutorial. In contrast to the video however, I am experiencing alot of flickering on my M3 even in manual record mode. Only in playback mode it is possible to go through the menus without. But this would mean that there are at least two hardware revision of the M3 with very different behaviour, which should however be usually controlled by the firmware. This is a big mystery to me, and I want to ask if anybody else is experiencing this flickering on their M3's?

Second question is if its possible to get rid of it (I would offer time / code to help here):
In the chdk code I have seen that for all DIGIT6 processors only draw to the active buffer is implemented.
Could a workaround be to implement drawing to both (or are there even more?) bitmap buffers simultaneously like for the older models done?
Of course this would be slow because redundant draw calls have to be done. A better strategy might be to blit one buffer after completed drawing a frame to the other or get to know when the active buffer changes? Do we have any information about such event?

I have not fully understand the rendering paths of the chdk osd, maybe someone can help me here out with more details?
Some questions:
I guess those bitmap_buffers are handled by the canon firmware and canon also uses exactly these to draw their osds, is that correct? Does canon clear the whole buffer before redraw? It seems some chdk osd items like the battery indicator flicker faster, because maybe they are overwritten by the canon osd before being redrawn. However some items like the chdk menu is only flickering between two states (because of the active buffer switch) but is not cleared at all.
How/when does chdk decide to redraw their osd stuff?
If in record mode, I can workaround the active buffer menu flickering if I half press the shutter. After a few frames the menu does not flicker anymore. Flickers again if I move the cursor in the menu. Is chdk responing to the half press and does a redraw or is this handled internally by the canon firmware?

EDIT: What is the buffer setup for the canon firmware / chdk? How do all the buffers work together?

best
Martin
« Last Edit: 03 / June / 2018, 07:36:57 by derMart »
Logged
Pages: 1 ... 43 44 45 46 47 [48] 49 50 51 52 53 ... 75   Go Up
« previous next »
 

Related Topics