eos M10 port - page 29 - DryOS Development - CHDK Forum
« previous next »
Pages: 1 ... 24 25 26 27 28 [29] 30 31 32 33   Go Down

eos M10 port

  • 326 Replies
  • 218894 Views
*

Offline aloniv

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

Offline aloniv

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

Offline IvanPadalka

  • *
  • 2
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???
Logged
*

Offline srsa_4c

  • ******
  • 4450
Re: eos M10 port
« Reply #283 on: 15 / April / 2020, 16:20:52 »
Quote from: IvanPadalka on 15 / April / 2020, 15:42:31
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.
Logged
*

Offline IvanPadalka

  • *
  • 2
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.
Logged
*

Offline philmoz

  • *****
  • 3411
    • 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.

Logged
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

  • ******
  • 4450
Re: eos M10 port
« Reply #286 on: 10 / November / 2020, 18:52:14 »
Quote from: philmoz 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.
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.)
Logged
*

Offline reyalp

  • ******
  • 13729
Re: eos M10 port
« Reply #287 on: 11 / November / 2020, 00:02:05 »
Quote from: srsa_4c on 10 / November / 2020, 18:52:14
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.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4450
Re: eos M10 port
« Reply #288 on: 11 / November / 2020, 13:36:19 »
Quote from: reyalp on 11 / November / 2020, 00:02:05
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.
Logged
*

Offline reyalp

  • ******
  • 13729
Re: eos M10 port
« Reply #289 on: 11 / November / 2020, 14:01:39 »
Quote from: srsa_4c on 11 / November / 2020, 13:36:19
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.
Logged
Don't forget what the H stands for.
Pages: 1 ... 24 25 26 27 28 [29] 30 31 32 33   Go Up
« previous next »
 

Related Topics