Messages

1

Camera-specific discussion / Re: Canon EOS R / RP

« on: Yesterday at 09:18:35 AM »

Thats why I asked my question - in Polish (I understand German enough for his post)
For 'when' question no wonder answer was rude. For donations, it was short but not rude.
Maybe it's better to remove those posts asking for dates, instead of replying like this every time...

2

Camera-specific discussion / Re: Canon EOS R / RP

« on: Yesterday at 07:45:04 AM »

Warum so eine unfreundliche Antwort auf eine gute Frage?

Która odpowiedź jest niegrzeczna?*

English, please. 

Sorry, had to.

3

Camera-specific discussion / Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)

« on: July 14, 2019, 08:10:35 AM »

Now that's what i call progress!
Need to find some time and finally dig into your repository.

Inb4 "so when download be available?" -> answer from a few posts ago apply exactly the same now.

4

Camera-specific discussion / Re: Canon EOS M

« on: July 12, 2019, 08:20:42 AM »

durability working in overclocking

Overclocking and durability, choose one. It's all about silicon lottery. Info that somebody's card survives OC means nothing about other cards even from the same batch.

5

Camera-specific discussion / Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)

« on: July 10, 2019, 08:18:40 AM »

kitor: I don't think bmp_putpixel_fast() is called with rgb values at all.  Look at the values when it's called, and the constants in bmp.h, eg, COLOR_WHITE is 1, COLOR_BLACK is 2.  Indexed colour maybe.  I need to understand this better before I can change it.  Probably won't have much time to work on it before the weekend.

You are right! I looked at uint_8t, saw color definitions and just assumed it without looking at the numbers. Lesson learned once again: don't assume things 
https://magiclantern.fandom.com/wiki/VRAM/BMP
https://chdk.fandom.com/wiki/Frame_buffers -> "Bitmap (or Overlay)"
https://chdk.fandom.com/wiki/Palette
Indeed that's an indexed palette, i guess that it was more consistent between EOS cameras than on PowerShot models, but this apply:

Code: [Select]

#define COLOR_TRANSPARENT_GRAY  0x14 // not portable, old cameras show it as magenta
Since CHDK is running on D6+ cameras, I checked their code (on dev trunk) and while their functions have a bit different definitions, core/gui_draw.c seems to have all the magic implemented that needs to be ported here.

6

Camera-specific discussion / Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)

« on: July 09, 2019, 08:34:29 AM »

I see some discussion about YUV stuff on chdk forum -> https://chdk.setepontos.com/index.php?topic=11316.120

As for "simply replacing" - from what I understand now, YUV buffers have also alpha channel, so replacing rgb values with yuv ones will produce werid results (mentioned in chdk thread too). And Canon seemed to change this twice - once to UYVY + separate opacity data that's in 200D (according to comments in minimal.c - and by "adapted from names_are_hard" i believe you are aware of that ) and then to UYVYAA (5D4, M50, R...)

For now I would just replace bmp_putpixel_fast with implementation based on CONFIG_DIGIC_678 part of disp_set_pixel in digic6-dumper/minimal/hello-world/minimal.c, completly ignoring bvram and converting 8 bit input into 32 by some bitwise operations (?, i was never good at optimizing low-level stuff) since now it's hardcoded to white. This surely will be order of magnitude slower, but if that takes us into ML menu, i guess that's good idea to fix/optimize it after we know that we can do GUI stuff.

As for

disp_set_pixel() also wants fixing in unified, which isn't as simple as I expected, a bunch of symbols are in different places in unified vs digic6-dumper.

I thought that this is used only from BL context, so not required at this stage:

Code: [Select]

grep -irw disp_set_pixel ./
./src/font_direct.c:    disp_set_pixel(x, y, c);
./src/disp_direct.c:void disp_set_pixel(uint32_t x, uint32_t y, uint32_t color)
./src/minimal.c:void disp_set_pixel(int x, int y, int c)
./src/disp_direct.h:void disp_set_pixel(uint32_t x, uint32_t y, uint32_t color);


7

Camera-specific discussion / Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)

« on: July 08, 2019, 08:30:51 AM »

Won't bmp_putpixel_fast from bmp.h be a problem here? It's used by font_draw_char from frb_font.c:

Code: [Select]

inline void bmp_putpixel_fast(uint8_t * const bvram, int x, int y, uint8_t color)
{
    /* vxvorks skipped */
    bvram[x + y * BMPPITCH] = color;
    /* 500d skipped ;) */
}
It's definitely not YUV-aware.

What about replacing it with code based on disp_set_pixel from minimal.c in digic6-dumper?

8

General Help Q&A / Re: Automatic AEL/FE lock with half pressed shutter button

« on: June 28, 2019, 02:20:21 PM »

Try to learn back-button focus: reconfigure your half-shutter to AE lock, use AF-ON with your thumb for AF.
Takes a day to get used off it, but now you basically can keep your camera in AI-Servo, and you will never come back

You want to have your half-shutter to be "AF Start & AE lock on AF success". This indeed can't be achieved on stock FW, not sure if ML can help (is ML able to get "focus" event).

9

Camera-specific discussion / Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)

« on: June 22, 2019, 08:10:35 PM »

@kitor How did you measure the pitch of the FPC connector with that small size?

Caliper 

P.S there is a very slim chance of me opening up the camera and probing points as my parents will most likely evaporate me from existence if they found out.

And I disassembled mine. Still over a year to end loan payments, but that's the things you do for Science!

Very interesting, mine isn't FPC.  Jack's has a K2 label, I have K1 - and inside 3 exposed pads.  Serial port without ground?

Took me a moment to realize "K1" and "K2" is molded into case. I don't believe it's related to what's inside. More likely different factory code or something.

Side note: While RP on promo video had both debug connectors soldered (like my retail R does, 2nd we guess to be jtag), on photos from retail ones this 2nd connector is missing (pads only).
If those 3 pins are serial, then my bet is rx/tx/gnd, but IIRC all known cameras exposes both CPU and MPU serial ports, so this would be werid.

Since quality of picture is as visible, I see like three pads with solder on them just above those three, and something possibly hidden under sticker... like if connector just isn't soldered in.
That would fit as connector is 8 pin, soldered 4 pins on each side of connector.
I can't find any high res photo of the board to confirm those suspicions. Look at 2nd photo here: Aliexpress - that's best I found.

10

Camera-specific discussion / Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)

« on: June 22, 2019, 06:00:30 PM »

So at least location is right. As for this FPC pitch - I doubt you will find one, I measured it to be probably 0.4mm (maybe 0,35mm - hard to measure without desoldering connector), found just a single china source for matching parts... 
I don't think they are using different pinouts, as connector is already exotic (it's impossible to use standard 0.5mm cable as it will short pins to ground). But if you find anything (or want to disassemble camera - on R there are testpads near connector that I used for all of my work), please update thread I linked before with your findings 

@names_are_hard - debug connector is very useful. In R stubs you can find one for uart_printf, that was the only way I was able to debug R before I found out my RAM dump was wrong and I had 1-byte offset framebuffer location

11

Camera-specific discussion / Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)

« on: June 22, 2019, 03:13:36 PM »

By looking at the board photo from Aliexpress, it's the same style connector as on EOS R / RP, located under thumb rubber, near USB connector.
Just educated guess.

As connector is visually the same, pinout for R is here:
https://www.magiclantern.fm/forum/index.php?topic=7531.msg212071#msg212071

If that checks out - FPC that goes into it is less than usuall 0.5mm pitch.

12

Camera Emergency Department / EF 20-35 1:3.5-4.5 USM aperture problems

« on: June 19, 2019, 07:57:58 PM »

Not sure if this should go here or into general chat, since it's not camera and ML related.

Recently I got old EF 20-35 3.5-4.5 USM lens. Pretty good external and internal condition, focuses fast, shoots OK, but...
Shoots OK only wide open. Trying to shoot with lower aperture ends in err01 both on R and 5d3.

After some guessing I noticed that lens reacts randomly to aperture changes - this is best noticeable in movie mode where aperture should be kept at selected step all the time.
General rule is that closing from 3.5 in direction of f/29, step after step - it will close two steps, then open by one, then close by a few, then open a few and so on. When camera says it should be f/29, lens is really at about f/16 maybe. Behavior is inconsistent - most of the time it will change aperture in proper direction, sometimes it won't react at all and sometimes goes into opposite than requested.

I disassembled it twice - checked aperture ribbon - seems ok (both visually and using multimetr), disassembled even aperture itself - i can move it in both directions as freely as stepper motor allows me to do.
With each aperture "step" motor is making noises.

I wonder if the problem is in lens controller, ribbon or motor itself. Will use it wide open (as there are no hopes for parts for ~$150 lens, unless someone sells me dropped one with broken glass), but maybe someone had similar problem with any of Canon lenses?

13

Camera-specific discussion / Re: Canon 7D Mark I

« on: May 24, 2019, 09:05:29 AM »

I don't see any info what card are you using, only this:

Card Warm Up: 128 MB (I have 128GB CF Card)

Have you tried with different cards?

14

Magic Lantern Forum and Site Discussion / Re: New server - Please report any problems with the site here

« on: May 22, 2019, 06:25:50 PM »

For RWD 16:9 videos I always used this CSS, don't remember original source now:

Code: [Select]

.embed-container {
    position:       relative;
    padding-bottom: 56.25%;   /* 16/9 ratio */
/*  padding-top:    30px; /* IE6 workaround*/
    height:         0;
    overflow:       hidden;
    margin-bottom:  10px;
    border-radius:  2px;
    z-index:        1;
    }

.embed-container iframe,
.embed-container object,
.embed-container embed,
.embed-container div.embed {
    position:       absolute;
    top:            0;
    left:           0;
    width:          100%;
    height:         100%;
    }
Of course whatever is inserted inside has to have no width/height set. This worked at least for YT, FB and I think Vimeo videos.
And you may add max-width to .embed-container since it will fill parent (which was expected in my case)

15

General Help Q&A / Re: single frame 'video' file?

« on: May 21, 2019, 06:01:33 PM »

https://www.magiclantern.fm/forum/index.php?topic=12523.0

16

Camera-specific discussion / Re: Canon EOS R / RP

« on: May 18, 2019, 11:17:17 PM »

Hello,
is there somebody, who is still working on ML for Canon EOS R? 

Refer to this. No posts = no news.

f. e. Intervalometer, Motion detection,

So we have something in common (had to bring notebook with me last time I suddenly needed intervalometer). However I risked a lot to my camera (as seen in this thread) to at least try to make it happen.

17

General Development Discussion / Re: 3K/UHD 5D2 Raw development and Other Digic IV Cams

« on: May 07, 2019, 08:23:38 AM »

Change PAL/NTSC region in camera.

18

Camera-specific discussion / Re: Canon EOS R / RP

« on: May 05, 2019, 07:26:20 PM »

Up to now, mostly like you described.

Is it a hunt for the memory addresses than respond to the things we need. LED at address xxxxxxx, memory for sensor data at xxxxxx ??

But not only for hardware memory addresses, but also for location of needed DryOS functions that we need to call. In 'normal' programming you just include headers for some library and use it. Here you need to find that stuff in disassembled ROM first, understand how it works, what parameters it can take (and thus how to call it). This is already mostly done with previous cameras, so you just need to find proper memory location that holds your needed function. Later also find how to 'hook' into Canon tasks to get data from them, etc.

And DryOS (and low level stuff - new Digic processors) changes with time. That's why Alex did 'fishy' M50 port that allows ML menu access, but it breaks things for older devices so he decided not to push code until he sorts this out.

19

Camera-specific discussion / Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)

« on: May 05, 2019, 10:37:37 AM »

Build a development environment, startup QEMU, dump ROM files and make your first steps inside the emulator.
Tutorials how to make QEMU run are available.

Walter, I see a similar post from time to time.
Unfortunately (from few years experience working with developers (!, so people who should know the drill) in quite large project), I don't think people who ask those questions does understand problem at all.

For average person installing software on new PC is like... download it and install. They think that the problem is that with their new camera no one yet tried to download and install ML and provide feedback that it works (yup, I'm oversimplifying, but again, experience tells me to expect low unless proven wrong).

We know that ML code doesn't grow on trees. (great quote btw!). But this means nothing even for pro photo/videographers who used ML for living, if they don't have any computer engineering background.

IMO, the real answer should be like:

Unless you know or want to learn how to do any of this, wait patiently for news containing download links, or grab a camera that is supported now.

Sorry for OT, but something tells me this post may be much better answer for all people asking.

20

Camera-specific discussion / Re: Canon EOS R / RP : new FIR version

« on: May 04, 2019, 02:39:32 PM »

As soon as debugging EOS R or RP will be possible within QEmu, I'll continue my investigations started with Alex. He owns holidays after giving years of time to ML.

https://www.magiclantern.fm/forum/index.php?topic=2864.msg215604#msg215604

There is a patch for M50 here; IIRC it worked on R with minimal changes. Will clean them up for committing, but I think it will happen after bringing the current state into mainline.

I'm not competent enough to do those 'minimal changes' myself unfortunately, at least not without any hints where to look.

21

Camera-specific discussion / Re: Canon EOS R / RP

« on: May 04, 2019, 02:15:42 PM »

A bit of ML offtopic:

1.2.0 seems to remove banding issues:
https://www.canonrumors.com/firmware-v1-2-0-seems-to-have-solved-a-banding-issue-that-was-present-in-the-canon-eos-r/

Ladies and Gentlemen! WE HAVE DONE IT!! Thank you so much to the many of you who gave feedback, shared my videos, posted in forums and relayed the information you received from Canon, I can confirm that Firmware update 1.2.0 resolves the banding issue I reported back in November on the Canon EOS R!

Tamron 70-200 G2 works great with R
Tired of waiting for RF 70-200 (and in need for one soon) I wanted to pick used 2.8L IS II USM. But found that Tamron presented not so long ago 2nd gen of their lineup (and new SP 70-200mm F/2.8 Di VC USD G2 is roughly the same price as used 2.8L IS II). As I have good contact with one camera store, I played a little with this lens via basic EF-RF adapter and it worked flawlessly, AF was fast and accurate, no problems with VR (shots like 1/30 on 200mm).
Interesting (and not found in manual) feature is that tripod mount will mount directly to Arca Swiss compatibile Quick Releases, what I found by accident.

Sample full-res jpeg (from raw, without LR lens corrections; 200mm/2.8 ISO 100): https://kitor.pl/eos_r/tamron.jpg
This is how this combo looks:


As for missing control ring on EF lenses, I'm using back-button focus, thus I have exposure lock on half-shutter. So i set exp-lock button + upper dial as ISO change. Works much better than fighting with touch bar and saves a lot of money on adapter with control ring.

22

Reverse Engineering / Re: Battery grip pins / UART

« on: May 01, 2019, 01:00:42 PM »

For upcoming RP I expect the same.
Note that R (and RP on mentioned photo) has 2nd similar connector next to this one. No communication was visible, something tells me this may be JTAG. However not accessible without disassembling camera.

https://www.mirrorlessrumors.com/the-canon-eos-rp-disassembly-and-teardown/

After

A few more hide behind the button pad rubber which needs to peeled away, also like the EOS R.

Hole to UART connector is clearly visible. From board photos seems that only one of two connectors was left (lower one), unfortunately testpads positions suggests they may be hardly/not accessible through that hole, so proper FPC cable will be needed.

23

Camera-specific discussion / Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)

« on: April 29, 2019, 09:45:32 PM »

Code: [Select]

kitor@kitor-pc:eosr-120$ cat ROM0.BIN.strings | grep -i edmac | wc -l
121
kitor@kitor-pc:eosr-120$ cat ROM0.BIN.strings | grep -i pcie | wc -l
70


24

Camera-specific discussion / Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)

« on: April 29, 2019, 09:00:21 AM »

As for lime strings, from EOS R:

Code: [Select]

"NetDomain::LimeKick.c":
"LimeInit":
"Error : bad parameter(LimeClock).":
"Inport(CCLIME_TIC_WDLPS_ADDR) == val":
"Inport(CCLIME_TIC_WDLP_EN_ADDR) == val":

"LimeSdIo/SdDom/SdClk.c":
"LimeSdIo/SdDom/SdCmd.c":
"LimeSdIo/SdDom/SdCommon.c":
"LimeSdIo/SdDom/SdCon.c":
"LimeSdIo/SdDom/SdDebug.c":
"LimeSdIo/SdDom/SdDma.c":
"LimeSdIo/SdDom/SdDom.c":
"LimeSdIo/SdDom/SdIo.c":
"LimeSdIo/SdDom/SdLog.c":
"LimeSdIo/SdDom/SdReg.c":
"LimeSdIo/SdDom/SdResource.c":
"LimeSdIo/SdWlanIf/SdWlanIf.c":
"LimeSdIo/SdWlanIf/SdWlanIfConfig.c":
"LimeXdmac/XdmacApi.c":
"LimeXdmac/XdmacDrv.c":
"LimeIntc.c":
"LimeKick.c":
"CclimeSdIo/TsumSd/SdCmd.c":
"CclimeSdIo/TsumSd/SdCon.c":
"CclimeSdIo/TsumSd/SdDma.c":
"CclimeSdIo/TsumSd/SdIo.c":
"CclimeSdIo/SdWlanIf/SdWlanIf.c":

"[NWCOM] Lime Load Complete For XDmac(Ch=%d)":
"[NWCOM] Lime Load Complete For CPU":
"[NWCOM] LimePanic":
"[NWCOM] LimeExcept":
"[NWCOM] LimeAssert":
"[NWCOM] Lime WorkLoad CPU":
"[NWCOM] Lime WorkLoad (DMA)->CPU":
"[NWCOM] Lime Init":
"[NWCOM] Lime Uninit":and more. So seems to be related to WiFi / SDIO is used for WiFi card internally (that's interesting)

25

Camera-specific discussion / Re: Canon EOS R / RP

« on: April 28, 2019, 12:55:12 PM »

Oh, Hai!


https://twitter.com/_kitor/status/1122454369235079169

I don't understand this at all. Seems that dump_file shifts down ram offsets by 0X10?! explanation below
bmp_vram_info sits at 0xFB2C, not 0xFB1C. How I found this?

Code: [Select]

for(uint32_t * i = 0x40000000; i < 0x80000000; i+=1){
        if(*i == 0x412ff900) uart_printf("vram1 %p \n", i);
        if(*i == 0x414ff400 ) uart_printf("vram2 %p \n", i);
    }
and a few moments later

Code: [Select]

vram1 0x4000fb2c
vram2 0x4000fb30
vram2 0x4000fb34
But what's werid MARV structures sits exactly where I found them in a dump:

Code: [Select]

bmp_vram_info 0xfb2c
bmp_vram_info[0] 0x412ff900
vram1 0x412ff900
vram2 0x414ff400
back_vram 0x414ff400
yup, that's shows my desperation 

@dfort - new MR coming in a moment

[edit]
OK, now I know what happened. Our initial dump on 1.1.0 has been shifted. I got MARVs from new dump, bmp_vram_info I was checking on old one all the time... working on pointers at 2AM is a bad idea.