111–120 of 170 posts
Earlier quoted context omitted.
The analogy is completely invalid. Languages with small specifications are easier to learn. It's sad that the dev, who has done great work, has to spend time defending the C language from critters living under a bridge when it's a fixed element that isn't going to change.
Accusing people who disagree w/ you of being trolls doesn't bolster your argument.
Earlier quoted context omitted.
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 dec…
Oh, don't worry about the downvotes. Happens every time someone starts talking about improving software Quality around here. Unpopular topic. I talk about it anyway, as it's one of my casus belli . I can afford the dings. BTW: I used to work for Canon's main [photography] competitor, and Magic Lantern was an example of the kind of thing I wanted them to enable, but they were not particularly open to the idea -control…
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.
Earlier quoted context omitted.
Oh, don't worry about the downvotes. Happens every time someone starts talking about improving software Quality around here. Unpopular topic. I talk about it anyway, as it's one of my casus belli . I can afford the dings. BTW: I used to work for Canon's main [photography] competitor, and Magic Lantern was an example of the kind of thing I wanted them to enable, but they were not particularly open to the idea -control…
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 Qe…
But I put as much effort into my mobile apps, as I did, into my firmware projects (it’s been decades since I wrote firmware, BTW. The landscape is quite different, these days -This is my first ever shipped engineering project[0]. Back then, we could still use an ICE to debug our software).
It just taught me to be very circumspect about Quality.
I do feel that any software (in any part of the stack) I write that affects moving parts, needs to be quite well-tested. I never had issues with firmware, but drivers are another matter. I've fried stuff that cost a lot.
[0] https://littlegreenviper.com/TF30194/TF30194-Manual-1987.pdf
What would be something you can achieve using ML that you couldn't do with the stock firmware and postprocessing?
Frankly: I once tried to maintain a help file and browsed through a lot of lesser known features. Took me days and I didn't even test RAW/MLV recording.
Earlier quoted context omitted.
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,…
> Could this be a conflict with long exposures? I've done lots of 1/2 second exposures with 3s interval, and it shoots some at much shorter interval than 3 and some 3+??? At one point, the docs said 5s was a barrier. Maybe it was the 5dmkii specifically. All of my cards are rated higher than the 5D can write (but makes DIT much faster) so I doubt it is write speed interfering. What makes me think it is not the camera…
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.
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 AA…
> I'm the current lead dev, so please ask questions.
Well, you asked for it!
One question I've always wondered about the project is: what is the difference between a model that you can support, and a model you currently can't? Is there a hard line where ML future compatibility becomes a brick wall? Are there models where something about the hardware / firmware makes you go 'ooh, that's a good candidate! I bet we can get that one working next'?
Also, as someone from the outside looking in who would be down to spend $100 to see if this something I can do or am interested in, which (cheap) model would be the easiest to grab and load up as dev environment (or in a configuration that mimics what someone might do to work on a feature), and where can I find documentation on how to do that? Is there a compendium of knowledge about how these cameras work from a reverse-engineering angle, or does everyone cut their teeth on forum posts and official canon technical docs?
edit: Found the RE guide on the website, gonna take a look at this later tonight
I should give this a shot. I used to use CHDK so I could use my old crappy Canon into something that would take good time-lapse videos by snapping a photo every X seconds; I miss doing that, though now it's harder because I live in the 'burbs, and there's no particularly spots for that nearby, and anywhere that is a good spot likely doesn't have a power outlet for me to use. I wonder how long I could power my camera…