Use separate heap for image data on EV3 #344
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
laurensvalk
approved these changes
Jul 17, 2025
Member
laurensvalk
left a comment
laurensvalk
left a comment
There was a problem hiding this comment.
Thanks!
(Nice one pulling @rhempel into this 😄)
Member
|
|
You were probably running out of contiguous heap space for large objects on the MicroPython heap :-)
umm_malloc() has the same problem, so a simple pool of image buffers would have been fine, but less general.
Of course I'm happy that you were able to find umm_malloc useful - it's surprising where that project ends up sometimes.
I think the OpenMV cameras used it for a while.
…--
Ralph Hempel
|
Contributor
|
Looks good, thanks! |
Add support for a new memory allocator (umm_malloc) that is better for allocating large blocks of memory. Since MicroPython's garbage collector has to scan every single byte of memory it manages, to check for pointers, it is not efficient for large blocks of memory that are not expected to contain pointers. This is especially true for image data. So to avoid slow garbage collection/allocation times and filling up the MicroPython heap, we can use a separate allocator with a separate heap for image data.
Pull in a change to support %i in printf format strings. This is needed by the umm_malloc library.
Add a umm_info() to print debug info about umm memory usage similar to micropython.mem_info(). This is used on EV3 for allocating memory for images.
This was left over from when we had the u-boot.bin binary committed to the repo, so we don't need it anymore.
Mechanically sort lists of source files in makefiles using VS Code. Some of these were starting to get out of order.
Member
Author
I'm not really sure what sensible values would be at this time. I think we should figure out how we plan to use all of the flash and RAM (make a complete map of both), then we can make a better educated guess.
Done. |
Move pb_type_image from media to parameters to be consistent with Pybricks v3.x (media module was a 2.x thing for ev3dev).
Fix the alignment of the (x) in #defines in mpconfigvariant.h for virtualhub. This was the only file that has a different alignment which made copy/paste with other config files annoying.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In pybricks/support#2154 (comment) (cc: @schodet), it came up that we were running out of MicroPython heap space on EV3 when trying to allocate full-screen sized images. We really don't want to use MicroPython heap for this because the image data will contain no pointers to MicroPython objects (other than false positives) and will make allocating and collecting memory in MicroPython much slower than it needs to be.
Instead, we can add a new memory allocator that doesn't use garbage collection. I've picked one created by our old MINDSTORMS pal @rhempel that seem well suited to the task. In addition to being designed for microcontrollers, it also has a nice debug print feature which I have wired up to
hub.system.umm_info()that works similar tomicropython.mem_info()that will help us debug memory issues if needed.The block size and heap size was just an educated guess, but we can tune those as needed based on real-world usage.