| It’s not too difficult, if you do it from the start, and by habit. I have an xcconfig file[0], that I add to all my projects, that turns on treat warnings as errors, and enables all warnings. In C, I used to compile -wall. I also use SwiftLint[1]. But these days, I almost never trigger any warnings, because I’ve developed the habit of good coding. Since Magic Lantern is firmware, I’m surprised that this was not already the case. Firmware needs to be as close to perfect as possible (I used to write firmware. It’s one of the reasons I’m so anal about Quality). [0] https://github.com/RiftValleySoftware/RVS_Checkbox/blob/main... (I need to switch the header to MIT license, to match the rest of the project. It’s been a long time, since I used GPL, but I’ve been using this file, forever). [1] https://littlegreenviper.com/swiftlint/ |
| |
| ▲ | ChrisMarshallNY 6 days ago | parent [-] | | Awesome! Great work, and good luck! | | |
| ▲ | names_r_hard 6 days ago | parent [-] | | 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. | | |
| ▲ | ChrisMarshallNY 6 days ago | parent [-] | | 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 freaks. Also, it's a bit "nit-picky," I know, but I feel that any software that runs on-device is "firmware," and should be held to the same standards as the OS. I know that Magic Lantern has always been good. We used to hear customers telling us how good it was, and asking us to do similar. I think RED had something like that, as well. I wonder how that's going? | | |
| ▲ | names_r_hard 6 days ago | parent [-] | | 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. | | |
| ▲ | ChrisMarshallNY 6 days ago | parent [-] | | Good point, and really just semantics. I guess you could say native mobile apps are “firmware,” using my criteria. 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 | | |
| ▲ | names_r_hard 6 days ago | parent [-] | | 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. | | |
| ▲ | ChrisMarshallNY 6 days ago | parent [-] | | You do need to be careful with the shutter. It is possible to do damage (and add dirt) from it. We had to add software dust removal, because the shutter kicked dirt onto the sensor. I’m assuming that, at some point, the sensor technology will progress to where mechanical shutters are no longer necessary. |
|
|
|
|
|
|
|
