optimized firmware for different models?

Is OpenMV firmware install optimized for different cameras at all? In other words, when it’s installed, does everything get installed?

I have OpenMV Cam 2 and recently installed 3.5.0 to take advantage of the SSL support. But doing anything more complicated than the included https example, my code quickly runs out of memory. Just factoring out wifi, socket & http operations into their own convenience functions and adding simple URL parsing is pretty much all that’s needed.

Could this be alleviated by creating a custom build that only includes what the cam actually supports? Or, even, just what my code requires?

What would this entail, any pointers? Might this be worth the effort?

Thanks!

Um, for the OpenMV Cam M4 we just ran out of resources. We had to turn off firmware features in the flash and the RAM is just so limited. Please upgrade. We have tried to keep that model working but the RAM limits are just too much.

Well, thanks for the effort, I guess. If e.g. removing stuff from the main Makefile would help reduce the RAM footprint, I’d be happy to try that if there were some instructions provided on how to cross-compile. Would that be a feasible possibility?

Otherwise, you might as well (should?) openly warn people that upgrading Kickstarter M4 cams with new firmwares will likely result in programs running out of RAM, right? Given this camera came out late 2016, that effectively makes for 3 years of software upgrades. Is that indicative for the life cycle of other OpenMV cams as well, current and new? Just asking.

Apart from running out of RAM with the new firmware, the cam is of course still a fine piece, so I am sure you can understand my reluctance to “upgrade” by buying a newer one just because of that. Seems waste of good hardware :slight_smile:

Sorry, I wrote the above hastily. The RAM isn’t what we are out of. It’s the flash. The H7 and M7 have 2 MB of flash. The M4 has 1 MB. Because if this we had to remove a lot of features from the M4.

Regarding RAM onboard. That’s basically been static but we’ve had to slightly reduced the size of heap/stack because a lot of the code we use has static variables in it that eat .data space that the heap/stack can use.

Anyway, we have tried to keep the M4 working however.

As for the comment on updating the firmware… I mean, would not having any updates be preferred? We tried doing that and got yelled at by one customer. So, we just support the system now, whatever that means for performance.