Bypassing micropython

I’ve been tinkering with my H7 for a while, and it’s been working quite well, but my only issues are with low framerates and an inability to process images with the granularity I’d ideally like to have. My idea was that I could speed up the programs by cutting out micropython overhead and gain the control I want by writing my programs directly as C for the firmware level. The custom firmware build tutorial appears to be purely for micropython, so is there any precedent for what I’d like to do? Or would I just have to forgo treating it as an OpenMV and write code directly for the STM32, flashing it with DFU?

That overhead is minimal, basically everything is implemented in C, the Python modules are thin wrappers, you’re Not going to see that much of an improvement by replacing MicroPython with direct calls… That said, you can just start commenting out things in main, and instead call whatever you want in there directly, the linker will drop all the “dead” code that’s Not called… keep in mind though that a lot of peripheral drivers are implemented in MicroPython.

Ah I see, the other thing that I think I could benefit from is that it would allow me to more precisely look at images, since the builtin openmv algorithms don’t do what I want, which is to find areas with higher contrasts, and I was told that individual pixel analysis on the OpenMV is a bad idea.
If I did comment things out, how would it treat whatever python code I upload? main.c didn’t seem to include any references to uploaded python code, so I assumed that was just all handled by micropython - or am I misinterpreting the role of mpy-cross?

It will Not have any Python support this way, you specifically asked for this:

Oh ok, that makes sense. In that case, how would I go about adding new methods (like the img.findblobs) to the firmware? I was not able to find the appropriate files in the openmv/openmv tree on github.

We don’t have any tutorials for this, you have to know what you’re doing, but it shouldn’t be hard to figure out how to do this, the firmware is full of examples also search the forums.

Hi, what exactly is slow for you? Yes, anything above 320x240 is likely slow. But, at that resolution or lower is should be quite speedy.

Hi, so currently I am working on implementing draw_rectangle but with support for angles. I am excited to see if I can do something similar for contrast detection and things like that.
As to what is slow for me, I am using 320x240 and was curious to see if it would be possible to do things like the laplacian or mode filters which drop me to 10 fps currently, while retaining something reasonable like the 25 or so that I usually get with minimal processing.

Ah, yes, once I get double buffering out this should bring your FPS back up. You’re likely just dropping every other frame. You are using the OpenMV Cam H7 Plus? It has a rather low frame drop tolerance.

As for draw_rectangle with angles. You can do this with draw_line in python. Just compute the coordinates of the corners of the rect which should be easy and then draw a line between the 4 corners.

I’m using the old H7; I will upgrade soon, probably. I look forward to double buffering though! I tried the draw_line method, but I need it to be filled (I am blocking things out in frame buffer), and increasing the thickness rounds it off.

Basically you want a draw_polygon method. Will keep that in mind.

Essentially yeah, the only reason this particular shape is something I wanted to build is because I needed to cover blobs, which can be angled.

Okay, a drawing overhaul will be done this year. Probably later in it. I’ll be making things faster and support anti-aliasing by default.

E.g. will be copying methods from here: Copy of · GitHub