eos M10 port - page 29 - DryOS Development - CHDK Forum supplierdeeply

eos M10 port

  • 289 Replies
  • 125678 Views
Re: eos M10 port
« Reply #280 on: 21 / March / 2020, 21:30:50 »
Advertisements
Thanks! I'll test it tomorrow.

Re: eos M10 port
« Reply #281 on: 22 / March / 2020, 03:15:51 »
Two images: one at 1/4000, the other at 1/8000.

Re: eos M10 port
« Reply #282 on: 15 / April / 2020, 15:42:31 »
how to install this update(with shutter open to 1/8000-1/16000???

*

Offline srsa_4c

  • ******
  • 4302
Re: eos M10 port
« Reply #283 on: 15 / April / 2020, 16:20:52 »
how to install this update(with shutter open to 1/8000-1/16000???
If you currently have CHDK installed on one or more cards: just download the current release from http://mighty-hoernsche.de/trunk/ (listed as Powershot M10 there) and extract the zip to the root directory of those cards.
If you don't yet have CHDK installed, read https://chdk.fandom.com/wiki/Prepare_your_SD_card , especially what's in the blue box at the top.

Note that shutter speeds around and over 1/8000s are increasingly inaccurate.


Re: eos M10 port
« Reply #284 on: 06 / May / 2020, 07:12:23 »
I have good idea with working silent raw picture. For canon m3 are created firmware with working no-shutter mode. This mode work in Lua script. But firmware for canon m10 haven't firmware with frsp_shoot() function and this mode doesn't work. https://chdk.setepontos.com/index.php?topic=12754.30
Can anyone from this discussion add this feature to the firmware? In topic from link we have .diff file with changes in source code. Anyone (who have good skills in programming) can add  this changes to source code from CHDK and recompile firmware for canon m10.

*

Offline philmoz

  • *****
  • 3200
    • Photos
Re: eos M10 port
« Reply #285 on: 10 / November / 2020, 16:05:32 »
I noticed that the M10 port does not build with GCC5 - the movie_rec.c file fails due to slightly different instructions being generated that pushes some of the jump table offsets out of range.


Attached is a patch that builds with both GCC4 and GCC5; but as I don't have an M10 I can't test it.


Would appreciate it if someone with an M10 could verify that this version still runs and does not break the movie_rec task functionality.


Phil.

CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline srsa_4c

  • ******
  • 4302
Re: eos M10 port
« Reply #286 on: 10 / November / 2020, 18:52:14 »
I noticed that the M10 port does not build with GCC5 - the movie_rec.c file fails due to slightly different instructions being generated that pushes some of the jump table offsets out of range.
This issue has come up before but I can't find where. I had decided not to change the source at that time.

Comparing the output generated by gcc4 and gcc8, the newer compilers change some LDR instructions into MOVW due to the constant being 16-bit. This screws up code size expectations. I'd primarily prefer to avoid this optimization, but I couldn't find an obvious way to do that.

Quote
Attached is a patch that builds with both GCC4 and GCC5; but as I don't have an M10 I can't test it.


Would appreciate it if someone with an M10 could verify that this version still runs and does not break the movie_rec task functionality.
The reason I don't like this is that a small-ish part of the code is moved around. If the manual relocation of those trampolines has the potential of causing problems, I won't necessarily notice those problems if my testing conditions avoid those code paths.
I'd rather convert the jumptable from TBB to TBH, so that all code paths are affected. (I haven't done that yet.)

*

Offline reyalp

  • ******
  • 12795
Re: eos M10 port
« Reply #287 on: 11 / November / 2020, 00:02:05 »
Comparing the output generated by gcc4 and gcc8, the newer compilers change some LDR instructions into MOVW due to the constant being 16-bit. This screws up code size expectations. I'd primarily prefer to avoid this optimization, but I couldn't find an obvious way to do that.
Maybe
__attribute__((optimize("O0")))
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
on the relevant functions? Or maybe this is an assembler thing rather than an optimization. It seems like there should still be a way to turn it off though, given that assembly users often need to way to get exactly what they ask for.

Quote
I'd rather convert the jumptable from TBB to TBH, so that all code paths are affected. (I haven't done that yet.)
A capdis option to turn TBBs into TBHs should be fairly easy.
Don't forget what the H stands for.


*

Offline srsa_4c

  • ******
  • 4302
Re: eos M10 port
« Reply #288 on: 11 / November / 2020, 13:36:19 »
Maybe
__attribute__((optimize("O0")))
Has no effect, unfortunately.
Quote
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
on the relevant functions? Or maybe this is an assembler thing rather than an optimization. It seems like there should still be a way to turn it off though, given that assembly users often need to way to get exactly what they ask for.
It does seem like an assembler thing. I added -save-temps to the gcc command that compiles movie_rec.c and found that the asm blocks are still unchanged in movie_rec.s.
Browsing through the docs hasn't helped - gcc allows fine-tuning optimizations, but couldn't find anything that would affect the final outcome. GNU as doesn't seem to offer much control over the way it works.

Quote
A capdis option to turn TBBs into TBHs should be fairly easy.
That would probably be a rarely used feature, but it would be appreciated. Not that I can't do the transformation, but it's better if the disasm needs less manual adjustment.

*

Offline reyalp

  • ******
  • 12795
Re: eos M10 port
« Reply #289 on: 11 / November / 2020, 14:01:39 »
It does seem like an assembler thing. I added -save-temps to the gcc command that compiles movie_rec.c and found that the asm blocks are still unchanged in movie_rec.s.
Browsing through the docs hasn't helped - gcc allows fine-tuning optimizations, but couldn't find anything that would affect the final outcome. GNU as doesn't seem to offer much control over the way it works.
Yeah, https://sourceware.org/binutils/docs/as/ARM-Opcodes.html#ARM-Opcodes suggests it treats ldr Rn,=whatever as a psuedopcode and just picks the most efficient encoding.

I guess if you were hand writing ASM, you'd have the option of writing ldr Rn,[PC+whatever] if you wanted to force that encoding.


Quote
Quote
A capdis option to turn TBBs into TBHs should be fairly easy.
That would probably be a rarely used feature, but it would be appreciated. Not that I can't do the transformation, but it's better if the disasm needs less manual adjustment.
Agreed, I'll look into it.
Don't forget what the H stands for.

 

Related Topics