EOS M3 porting - page 20 - DryOS Development - CHDK Forum  

EOS M3 porting

  • 746 Replies
  • 393239 Views
*

Offline Ant

  • *****
  • 509
Re: EOS M3 porting
« Reply #190 on: 23 / November / 2016, 02:13:53 »
Advertisements
I would like to see that script. Will you post it?
I not sure that it's safe for normal users...
Code: [Select]
--[[
@chdk_version 1.3
@param a Language number
@range a 0 30
@default a 0
--]]

if (type(call_event_proc) ~= "function" ) then
    error("ERROR: requires CHDK build with native function call support.")
end

buf=call_event_proc("AllocateMemory",64)

if not buf then
error("Cannot continue!\n")
return
end

if not (peek(0xfff20040,2) == 12953)then
error("Wrong camera product ID!\n")
return
end

if not( (peek(0xfc1fcea4,4) == 0x314D4720) and (peek(0xfc1fcea8,4) == 0x4131302E) ) then
error("Wrong camera firmware version!\n")
return
end

call_func_ptr(0xFC278531, 0x4005, buf, 16)
i = peek(buf+1,1)
print(string.format("Old value:%02d ",i))
poke(buf+1,a,1)
call_func_ptr(0xFC2784BD, 0x4005, buf, 16)
call_func_ptr(0xFC278531, 0x4005, buf+32, 16)
i = peek(buf+33,1)
print(string.format("New value:%02d ",i))
call_event_proc("FreeMemory",buf)
print(string.format("Now reboot your camera "))

Quote
Did you really mean to say that your camera "crashed"?  ( i.e. stopped working until you removed the battery and restarted).
Every time camera trying to start Canon GUI it causes Assert. So camera becomes useless for normal user.

Quote
you are changing the menu language for the Canon menus - not the CHDK menus.  Is that correct?
yes

In addition to the answer posted by WW, you could also use module(s). Modules can be made model specific (see modules/flt.h), and can also implement a submenu (the eyefi module does that).

For me modules are parts of core. Maybe it's better to add M3 platform to main CHDK repository?
« Last Edit: 23 / November / 2016, 13:14:24 by Ant »

*

Offline reyalp

  • ******
  • 14080
Re: EOS M3 porting
« Reply #191 on: 23 / November / 2016, 20:42:36 »
For me modules are parts of core. Maybe it's better to add M3 platform to main CHDK repository?
I would definitely like to get the M3 source in the main svn before it diverges too far. If your repository is up to date, I can look into this.
Don't forget what the H stands for.

*

Offline Ant

  • *****
  • 509
Re: EOS M3 porting
« Reply #192 on: 24 / November / 2016, 02:01:16 »
If your repository is up to date, I can look into this.
I will update my repository later, maybe today. But we need to reserve new propset number for M3 (for example propset9.h) and new names for keys("M-Fn", "INFO").

*

Offline Ant

  • *****
  • 509
Re: EOS M3 porting
« Reply #193 on: 24 / November / 2016, 13:31:28 »
My repository was updated to r4723.
propset9.h was added for EOS M3
These files were changed:
Code: [Select]
CHDK\CHDK\Makefile
CHDK\core\shooting.c
CHDK\include\properties.h
CHDK\CHDK\LUALIB\propcase.lua
CHDK\camera_list.csv
CHDK\include\propset9.h
« Last Edit: 25 / November / 2016, 05:37:46 by Ant »


*

Offline Ant

  • *****
  • 509
Re: EOS M3 porting
« Reply #194 on: 26 / November / 2016, 12:24:53 »
I would definitely like to get the M3 source in the main svn
After two days, it doesn't look so...

*

Offline reyalp

  • ******
  • 14080
Re: EOS M3 porting
« Reply #195 on: 26 / November / 2016, 15:51:18 »
I would definitely like to get the M3 source in the main svn
After two days, it doesn't look so...
I'm sorry, "I would like to" !=  "I'm going to drop everything else and do it right now"

I do hope to spend some time on it this weekend.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14080
Re: EOS M3 porting
« Reply #196 on: 26 / November / 2016, 23:03:34 »
I checked in the code from https://subversion.assembla.com/svn/chdk-m3/trunk r30 into the CHDK trunk, r4724. Thanks for all you work on this port, Digic 6 and the first CHDK interchangeable lens model is a big challenge :D

If you want to submit additional changes, svn diffs against chdk trunk are preferred. I would prefer to get multiple patches with small, well defined changes rather than big code dumps that change a lot things at once.

In r4725-r4735 I cleaned up a few things. I think most of them were safe, but I don't have an M3 to test, so please make sure the current trunk code still boots and runs. Let me know if you have question about any of the changes.

Some additional comments

The notes mentioned edge overlay working, but the updated module was not in the latest rev of your svn (it looks like it was overwritten when you updated). I would be happy to consider including it if you want to post your latest code.

I ran finsig_thumb2 on your platform and checked in the resulting files. The generated files should always match the current finsig version, with overrides in stubs_entry_2.s or stubs_min.S as needed. The exact and veneer matches could be removed from stubs_entry_2 for consistency with other ports, but this isn't a big deal. Other mismatches should probably be investigated.

According to finsig, the modemap in shooting.c seems to be incorrect. CHDK doesn't currently have a way to handle "C" modes, but the others should be fixed.

uiprop_count in stubs_min.S appeared to be copied from sx280, so I used the finsig value (I need to investigate why finsig didn't comment the stubs_entry.S value when an override existed).

In propset9.h, it would be helpful to identify which values have been verified. Values that aren't verified, and are not used in the C code should generally be commented out. (e.g. if you camera doesn't have the "my colors" function you can just comment out all the custom color propcase IDs)
If there are values which are required by the C code, but are not found, this should be noted in the comments.

In boot.c

The CreateTask_spytask code and SpyTaskMY stuff is unclear. Why is spytask only created conditionally? What is the condition?

main.c
In CHDK, get_focal_length / get_effective_focal_length return the focal length *for a specified zoom value* while it looks this code returns the *current* focal length. I know more work in the core is required to support interchangeable lenses, but it would be helpful to at least comment what it actually does, and remove extraneous things.

Why are the vbatt values 2* ? The values should match the values returned by the battery voltage function.

platform_camera.h has
#define CAM_HAS_JOGDIAL 0

This should either be define 1 to enable jogdial code, or #undef to disable it. Our code mixes #if and #ifdef so #define 0 is ambiguous.

kbd.c
Comments on the zoom buttons say one is slow and one is fast. This seems undesirable if true.
If there are additional keys that don't have names in the core, they can be added.

core shooting.c
propset 9 was added to cases for shooting_get_digital_zoom_mode  + shooting_get_digital_zoom_state. Have these been verified?

Finally:
Copy / pasted comments from the wrong platform drive me crazy. If you can take some time to go through the platform code, and note what is actually verified *ON YOUR CAMERA* and what is copied without being verified, that would help everyone who touches this code in the future.
Don't forget what the H stands for.

*

Offline Ant

  • *****
  • 509
Re: EOS M3 porting
« Reply #197 on: 27 / November / 2016, 03:30:25 »
so please make sure the current trunk code still boots and runs.
Yes, it still boots and runs.

Quote
The notes mentioned edge overlay working, but the updated module was not in the latest rev of your svn (it looks like it was overwritten when you updated). I would be happy to consider including it if you want to post your latest code.
Edge overlay was taken from your svn. I was thinking that it was already updated.

Quote
The CreateTask_spytask code and SpyTaskMY stuff is unclear. Why is spytask only created conditionally? What is the condition?
For testing purposes. The condition is pressed "M-Fn" button.

Quote
Why are the vbatt values 2* ? The values should match the values returned by the battery voltage function.
Because LP-E17 is 7.2V battery, like all other EOS battaries.

Quote
Comments on the zoom buttons say one is slow and one is fast. This seems undesirable if true.
If there are additional keys that don't have names in the core, they can be added.
It was copied from SX280 to be compatible with CHDK core.

Quote
propset 9 was added to cases for shooting_get_digital_zoom_mode  + shooting_get_digital_zoom_state. Have these been verified?
No. It was added for preventing compilling error.
« Last Edit: 27 / November / 2016, 04:41:42 by Ant »


*

Offline Ant

  • *****
  • 509
Re: EOS M3 porting
« Reply #198 on: 27 / November / 2016, 08:00:10 »
This need to be added for motion detection:
Code: [Select]
Index: /platform/generic/wrappers.c
===================================================================
--- /platform/generic/wrappers.c (revision 4737)
+++ /platform/generic/wrappers.c (working copy)
@@ -67,7 +67,7 @@
 long get_property_case(long id, void *buf, long bufsize)
 {
 // workaround for missing PROPCASE_SHOOTING
-#if CAM_PROPSET == 7
+#if CAM_PROPSET == 7 || CAM_PROPSET == 9
     if(id==PROPCASE_SHOOTING) {
         int r=_GetPropertyCase(PROPCASE_SHOOTING_STATE, buf, bufsize);
         // 1 50ms after half press, 2 after exp hook, 3 while shooting
@@ -88,7 +88,7 @@
 long set_property_case(long id, void *buf, long bufsize)
 {
     // ignore set on fake prop
-#if CAM_PROPSET == 7
+#if CAM_PROPSET == 7 || CAM_PROPSET == 9
     if(id==PROPCASE_SHOOTING) {
         return 0;
     }

Quote
If you can take some time to go through the platform code, and note what is actually verified *ON YOUR CAMERA* and what is copied without being verified, that would help everyone who touches this code in the future.

If you are talking about comments in stubs_min.S, now I don't remember where I found addresses of variables. I can only specify addresses which access to these variables
« Last Edit: 27 / November / 2016, 10:44:52 by Ant »

*

Offline reyalp

  • ******
  • 14080
Re: EOS M3 porting
« Reply #199 on: 27 / November / 2016, 15:46:04 »
Edge overlay was taken from your svn. I was thinking that it was already updated.
Nope. In general, I only add things if someone submits a patch. Is https://app.assembla.com/spaces/chdk-m3/subversion/source/23/trunk/modules/edgeoverlay.c the most recent version?

Quote
Quote
The CreateTask_spytask code and SpyTaskMY stuff is unclear. Why is spytask only created conditionally? What is the condition?
For testing purposes. The condition is pressed "M-Fn" button.
So spytask only starts if you hold this button while the camera is booting? CHDK will still be running (physw, capt_seq etc) but quite broken without spytask.

Or do you mean only the romlog code depend on M-Fn ? In that case, what is *(int*)(0x9e5c) & 0x00600000 around spytask?

Quote
Quote
Why are the vbatt values 2* ? The values should match the values returned by the battery voltage function.
Because LP-E17 is 7.2V battery, like all other EOS battaries.
What values does get_vbatt in Lua return, actual voltage (like 7200) or some other value?

Quote
Quote
Comments on the zoom buttons say one is slow and one is fast. This seems undesirable if true.
If there are additional keys that don't have names in the core, they can be added.
It was copied from SX280 to be compatible with CHDK core.
In SX280, the zoom keys are

Code: [Select]
    { 1, KEY_ZOOM_OUT        ,0x00000008 }, // full speed
    { 1, KEY_ZOOM_OUT        ,0x00000018 }, // middle speed
    { 1, KEY_ZOOM_OUT        ,0x00000010 }, // low speed
    { 1, KEY_ZOOM_IN         ,0x00000002 }, // full speed
    { 1, KEY_ZOOM_IN         ,0x00000006 }, // middle speed
    { 1, KEY_ZOOM_IN         ,0x00000004 }, // low speed
AFAIK, this means that any speed will be detected as a zoom click, and sending a press will send the full speed.

M3 has:
Code: [Select]
    { 1, KEY_ZOOM_OUT        ,0x00001000 }, // full speed
    { 1, KEY_ZOOM_IN         ,0x00000800 }, // low speed
Does it actually use different speeds for zoom in / zoom out? From the manual, it looks like the zoom controls are on the lens, not the body. Can CHDK even detect or send zoom controls on this camera? If not, it should not have zoom keys at all (It's possible we could synthesize them later using other functions or levents)

Quote
Quote
propset 9 was added to cases for shooting_get_digital_zoom_mode  + shooting_get_digital_zoom_state. Have these been verified?
No. It was added for preventing compilling error.
Is there any digital zoom functionality on this camera at all?  The manual doesn't seem to mention any. If not, these functions should be configured to return the no-zoom state, not random propcase values as the are now. I can add suitable code if you confirm there is no digital zoom.
« Last Edit: 27 / November / 2016, 16:11:13 by reyalp »
Don't forget what the H stands for.

 

Related Topics