names_r_hard

I don't believe they did. Where did they say that?

Over the years, a few devs have temp soft bricked cams, requiring various non-standard methods to restore them to working order. I think all attempts succeeded so far! I don't think any permanent physical damage has been triggered by devs. It is definitely a real risk, but we try to work with the OS when possible, and the OS was written to try to make these things hard.

I don't think I'd want to learn the ropes on a cam too expensive to psychologically say goodbye to. Maybe save that for the second port.

I don't know of a way to do that. I don't think the cam will ever display an image on LV while a capture is in progress. The readout process from the sensor is fundamentally decoupled from the capture. You could probably interleave long exposures with short ones at greatly boosted ISO, and display only the short ones on LV.

I was assuming it would be possible to quite accurately model the drift over time, and adjust the model based on the last image. The model continuously guides the mount, and the lag in updates hopefully wouldn't matter - so you can use saved images, not LV. In fact, we can trigger actions to occur on the in memory image just before writing out.

I am definitely an astro noob :) LV sampling was just the first idea I thought of. We could also load the last image while the next was being taken, and extract guide points from that (assuming an individual frame has enough distinct bright points... which it might not... you could of course sum a few in software). It's a larger image, but your time constraints shouldn't be tight. That way you're not getting any extra sensor heat. Some CPU heat though, dunno if that would be noticeable.

For networking, this module demonstrates the principles: https://github.com/reticulatedpines/magiclantern_simplified/...

A simple python server, that accepts image data from the cam, does some processing, sends data back. The network protocol is dirt simple. The config file format for holding network creds, IP addr etc is really very ugly. It was written for convenience of writing the code, not convenience of making the config file.

You would need to find the equivalent networking functions (our jargon is "stubs"). You will likely want help with this, unless you're already familiar with Ghidra or IDA Pro, and have both a 6D and 200D rom dump :) Pop in the discord when you get to that stage, it's too much detail for here.

There's no real list of things people want (well, they want everything...). The issues on the repo will have some good ideas. In the early days of setting that up I tagged a few things as Good First Issue, but gave up since it was just me working on them.

I would say it's more important to find something you're personally motivated by, that way you're more likely to stick with it. It gets a lot easier, but it doesn't have a friendly learning curve.

Nearly all Canons have a small access port as part of the battery door, which you can put a power supply cable / through, by design. Don't buy too cheap a dummy battery, the really cheap ones may have very bad voltage regulation. You can get ones designed to work from a USB power bank, or mains.

Ah I'd love an astro conversion.

I've had a fun idea knocking around for a while for astro. These cams have a fairly accessible serial port, hidden under the thumb grip rubber. I think the 6D may have one in the battery grip pins, too. We can sample LV data at any time, and do some tricks to boost exposure for "night vision". Soooo, you could turn the cam itself into a star tracker, which controlled a mount over serial. While doing the photo sequence. I bet you could do some very cool tricks with that. Bit involved for a first time project though :D

The 6D is a fairly well understood and supported cam, and your compiler background should really help you - so really the question is what would you like to add? I can then give a decent guess about how hard various things might be. I believe the 6D has integrated Wifi. We understand the network stack (surprisingly standard!) and a few demo things have been written, but nothing very useful so far. Maybe an auto image upload service? Would be cool to support something like OAuth, integrate with imgur etc?

It's slow work, but hopefully you don't mind that too much, compilers have a similar reputation.

You're a better photographer than I am. I'm glad if ML helped you.

Please recruit your programmer friends to the cause :) The R7 is a target cam, but nobody has started work on it yet. There is some early work on the R5 and R6. I don't remember for the R7, but from the age and tier, this may be one of the new gen quad core AArch64.

I expect these modern cams to be powerful enough to run YOLO on cam, perhaps with sub 1s latency. Could be some fun things to do there.

Yes, it gets a bit blurry, especially given how fast solid-state storage is these days.

I think IoT has seen a resurgence in firmware devs... but regrettably not so much in quality. Too cheap to be worth it, I suppose. I can imagine a microwave could be quite a concerning product to design - there's some fairly obvious risks there!

Certainly, whatever you class ML as, we could damage the hardware. The shutter in particular is quite vulnerable, and Canon has made an unusual design choice that it flashes an important rom with settings at every power off. Leaving these settings in an inconsistent state can prevent the cam from booting. We do try to think hard about contingencies, and program defensively. At least for anything we release. I've done some very stupid tests on my own cams, and only needed to recover with UART access once ;)

I haven't use ICE, but I have used SoftICE. Oh, and we had a breakthrough on locating JTAG pinouts very recently, so we might end up being able to do similar.

5D3 is perhaps the best currently supported ML cam for video. It's very capable - good choice. Using both CF and SD cards simultaneously, it can record at about 145MB/s, so you can get very high quality footage.

Re what we can support - it's a reverse engineering project, we can support anything with enough time ;) The very newest cams have software changes that make enabling ML slightly harder for normal users, but don't make much difference from a developer perspective. I don't see any signs of Canon trying to lock out reverse engineers. Gaining access and doing a basic, ML GUI but no features port, is not hard when you have experience.

What we choose to support: I work on the cams that I have. And the cams that I have are whatever I find for cheap, so it's pretty random. Other devs have whatever priorities they have :)

The first cam I ported to was 200D, unsupported at the time. This took me a few months to get ML GUI working (with no features enabled), and I had significant help. Now I can get a new cam to that standard in a few days in most cases. All the cams are fairly similar for the core OS. It's the peripherals that change the most as hardware improves, so this takes the most time. And the newer the camera, the more the hw and sw has diverged from the best supported cams.

The cheapest way for you to get started is to use your 5D3 - which you can do in our fork of qemu. You can dump the roms (using software, no disassembly required), then emulate a full Canon and ML GUI, which can run your custom ML changes. There are limitations, mostly around emulation of peripherals. It's still very useful if you want to improve / customise the UI.

https://github.com/reticulatedpines/qemu-eos/tree/qemu-eos-v...

Re docs - they're not in a great shape. It's scattered over a few different wikis, a forum, and commit messages in multiple repos. Quick discussion happens on Discord. We're very responsive there, it's the best place for dev questions. The forum is the best single source for reference knowledge. From a developer perspective, I have made some efforts on a Dev Guide, but it's far from complete, e.g.:

https://github.com/reticulatedpines/magiclantern_simplified/...

If you want physical hardware to play with (it is more fun after all), you might be able to find a 650d or 700d for about $100. Anything that's Digic 5 green here is a capable target:

https://en.wikipedia.org/wiki/Template:Canon_EOS_digital_cam...

Digic 4 stuff is also easy to support, and will be cheaper, but it's less capable and will be showing its age generally - depends if that bothers you.

Yeah, the external timer behaviour is fairly strong evidence. Curious though. These cams all seem to have a milli- and micro-second hw clock, and can both schedule and sleep against either. But it's also true that every cam has some weird quirks. And I don't know the 5d2 internals well.

From what I've seen, the image capture process is state machine based and tries to avoid sleeps and delays. Which makes sense for RTOS and professional photography.

If you care enough to debug it, pop into the discord and I can make you some tests to run.

Okay, good, just making sure :) Fun to hear that at least some photo gear places are aware of ML!

I have done a stint in QA, as well as highly aggressive security testing against a big C codebase, so I too care a lot about quality. And you can do it in C, you just have to put in the effort.

I'd like to get Valgrind or ASAN working with our code, but that's quite a big task on an RTOS. It would be more practical in Qemu, but still a lot of effort. The OS has multiple allocators, and we don't include stdlib.

Re firmware / software, doesn't all software run on a device? So I suppose it depends what you mean by a device. Is a Windows exe on a desktop PC firmware? Is an app from your phones store firmware? We support cams that are much more powerful than low end Android devices. Here the cam OS, which is on flash ROM, brings the hardware up, then loads our code from removable storage, which can even be a spinning rust drive. It feels like they're firmware, and we're software, to me. It's not a clearly defined term.

The main reason I make the distinction is because we get a lot of users who think ML is like a phone rom flash, because that's what firmware is to most people. Thus they assume it's a risky process, and that the Canon menus etc will be gone. But we don't work that way.

Canon have never had any contact with ML project for any reason, to the best of my knowledge. The decision to stay away from 1D series was made by ML team, I would say out of an abundance of caution to try not to annoy them.

Strange, it certainly can do sub 5s on some bodies. But I don't have a 5d2 to test with.

Could this be a conflict with long exposures? Conceivably AF, too. The intervalometer will attempt to trigger capture every 5s wall time. If the combined time to AF seek, expose, and finish saving to card (etc) is >5s, you will skip a shot.

When the time comes, compare the price of a used 5d3 vs a shutter replacement on the 5d2, maybe you'll get a "free" upgrade :) Thanks for the kind words!

Thanks, and for what it's worth, I didn't downvote you (account is too new to even do so :D ), and I agree with your main point - it's not that hard to avoid all compiler warnings if you do it from the start, and make sure it's highly visible.

You only add one at a time, so you only need to fix one at a time, and you understand what you're trying to do.

It is, however, a real bitch to fix all compiler warnings in decade old code that targets a set of undocumented hardware platforms with which you are unfamiliar. And you just updated the toolchain from gcc 5 to 12.

I've taught several different languages to both 1st year uni students, and new joiners to a technical company, where they had no programming background.

Honestly, C seems to be one of the easier languages to teach the basics of. It's certainly easier than Java or C++, which have many more concepts.

C has some concepts that confuse the hell out of beginners, and it will let you shoot yourself in the foot very thoroughly with them (much more than say, Java). But you don't tend to encounter them till later on.

I have never said getting good at C is easy. Just that it's easy to pick up.

6D2 is a nice cam, and one I happen to own. This cam is under active development. Locally I have ~FHD raw video working.

The entire copyright and patent system is built on the principle of forcing the release of IP; it is time delayed in exchange for the legal protections you gain if you opt in to the system. That is the encouragement!

Extending this to enable software access by 3rd parties doesn't feel controversial to me. The core intent of copyright and patent seems to be "when the time limit expires, everyone should be able to use the IP". But in practice you often can't, where hardware with software is concerned.

They were trendy at the time :D

I think possibly someone thought it sounded a bit like firmware?

Canon's legal team have never said anything about Magic Lantern in any context that I'm aware of.

The high end cams need ML less, they have more features stock, plus devs need access to the cam to make a good port. So higher end cams tend to be less attractive to developers.

I wouldn't recommend the 600D if you want to do video. For stills it's perfectly acceptable. Auto-focus will feel slow compared to a modern cam. If you're going for an old / budget cam, try and reach to the 650D or 700D, those are a newer generation of hardware.

200D is much newer, but less well supported by ML. I own this cam and am actively working on improving it. 200D has DPAF, which means considerably improved auto-focus, especially for video. Also it can run Doom.

Are there any ML features in particular you're interested in?

That would have been only a little before a1ex left. Getting code running on real hardware is easy, maybe I'll talk to you in discord in a few months when you find this fabled free time we are all looking for ;)

The 4000D is an interesting cam, we've had a few people start ports then give up. It has a mix of old and new parts in the software. Canon used an old CPU / ASIC: https://en.wikipedia.org/wiki/Template:Canon_EOS_digital_cam...

So it has hardware from 2008, but they did update the OS to a recent build. This is not what the ML code expects to find, so it's been a confusing test of our assumptions. Normally the OS stays in sync with the hardware changes, which means when we're reversing, it's hard to tell which changes are which.

That said, 4000D is probably a relatively easy port.

I agree with some of what you're saying; some of the well known risks of working in C are because it's a small standard. But much of the undefined behaviour was deliberately made that way to support the hardware of the time - it's hard to be cross-platform on different architectures as a low-level language.

C genuinely is easy to pick up. It is harder to master. And you're right, for many domains, there are better options now, so it may not be worth while mastering it.

Because it's an old language, what it lacks in built-in safety features, is provided by decades of very good surrounding tooling. You do of course need to learn that tooling, and choose to use it!

In the context of Magic Lantern, C is the natural fit. We are working with very tight memory limitations, due to the OS. We support single core 200Mhz targets (ARMv5, no out-of-order or other fancy tricks). We don't include C stdlib, a small test binary can be < 1kB. Normal builds are around 400kB (this includes a full GUI, debug capabilities, all strings and assets, etc).

Canon code is probably mostly C, some C++. We have to call their code directly (casting reverse engineered addresses to function pointers, basically). We don't know what safety guarantees their code makes, or what the API is. Most of our work is interacting with OS or hardware. So we wouldn't gain much by using a safe language for our half.

That must have been a few years back. I think you're talking about enabling "camera bootflag". We provide an automated way to do this for new installs on release builds, but don't like to make this too easy before we have stable builds ready. People do the weirdest stuff, including trying to flash firmware that's not for their cam, in order to run an ML build for that different cam...

Anyway, I can happily talk you through how to do it. Our discord is probably easiest, or you can ask on the forum. Discord is linked from the forum: https://www.magiclantern.fm/forum/

Whatever code you had back then won't build without some updates. 4000D is a good target for ML, lots of features that could be added.

I stand by my statement! Compare the length of the C standard to JS / ECMAScript, or C++! :)

Maaaaybe I'm hiding a tradeoff around complexity vs built-in features, but volunteers can work that out themselves later on.

You honestly don't need much knowledge of C to get started in some areas. The ML GUI is easy to modify if you stay within the lines. Other areas, e.g., porting a complex feature to a new camera, are much harder. But that's the life of a reverse engineer.

It's not firmware :) We use what is probably engineering functionality, built into the OS, to load and execute a file from disk. We run as a (mostly) normal program on the cam's normal OS.

We build with: -Wall -Wextra -Werror-implicit-function-declaration -Wdouble-promotion -Winline -Wundef -Wno-unused-parameter -Wno-unused-function -Wno-format

Warnings are treated as errors for release builds.

No time like the present :)

It is actually easier to get started now, as I spent several months updating the dev infrastructure so it all works on modern platforms with modern tooling.

Plus Ghidra exists now, which was a massive help for us.

We didn't really go on hiatus - the prior lead dev left the project, and the target hardware changed significantly. So everything slowed down. Now we are back to a more normal speed. Of course, we still need more devs; currently we have 3.

There's a fun step you're missing - it's not firmware. We toggle on (presumably) engineering functionality already present in Canon code, which allows for loading a file from card as an ARM binary.

We're a normal program, running on their OS, DryOS, a variant of uITRON.

This has the benefit that we never flash the OS, removing a source of risk.

There is, but it's more limited: https://www.dslrbodies.com/cameras/general-nikon-camera-info...

Thanks to all who are sharing their appreciation for this niche but cool project.

I'm the current lead dev, so please ask questions.

Got a Canon DSLR or mirrorless and like a bit of software reverse engineering? Consider joining in; it's quite an approachable hardware target. No code obfuscation, just classic reversing. You can pick up a well supported cam for a little less than $100. Cams range from ARMv5te up to AArch64.

The 80D has Magic Lantern code available. We haven't released a build to the public as it has such minimal features available there's no real point yet. But if you were thinking of doing dev work for it, it's in a good place to start: ML GUI works, debug logging works.