mem_info(True) : What does it all mean?

[TrainsWithLights]

So I have come to the conclusion that the memory map is meaningless because I cannot find an explanation of what all the terms mean. Realistically, I only need to know how much free space exists for Variables and CODE space in the CityHub.

As an example, my 1000+ lines of code produced this...
GC: total: 6912, used: 5232, free: 1680 No. of 1-blocks: 147, 2-blocks: 3, max blk sz: 39, max free sz: 54

Then I added one additional function call with no parameters and suddenly I have
GC: total: 6912, used: 6912, free: 0 No. of 1-blocks: 248, 2-blocks: 5, max blk sz: 39, max free sz: 0

I expected the program to not run due to insufficient memory, but it works fine.

Then I turned on the Bluetooth as a program option = no code change, and this happened...
GC: total: 6912, used: 6048, free: 864 No. of 1-blocks: 167, 2-blocks: 5, max blk sz: 64, max free sz: 28

The stack remains unchanged through all scenarios stack: 588 out of 5180

A detailed explanation of Code space and Variable space would be really handy, especially when trying to compress code!
(I have no idea of the free resources, which as a developer is not ideal)

stack: 588 out of 5180
GC: total: 6912, used: 6912, free: 0
 No. of 1-blocks: 248, 2-blocks: 5, max blk sz: 39, max free sz: 0
GC memory layout; from 20004cc0:
00000000: h=ThhDh======LhLhhh======================================h=====h
00000400: ========h================h===============================SSSSSSS
00000800: SSSSSTSSSSSSSSSSSSSSh==========hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
00000c00: hhhhhhhhhBh=====TTT=TTTTLh=DLTTh====hh=hBBBBBBBBBBBBhhBBBBBBBBBB
00001000: BBBBBBBBBBBBBBBBBBBShShSShShShShShShShShShShT=ShShThShShShShShSh
00001400: ShShShShShShShSh====================================hShShShShShS
00001800: hShShShShShShShShShShShShShShShShShShShShShh====
None

[dlech]

Here is a nice explanation of how to interpret all of the symbols in the output: https://www.adafruitdaily.com/2017/03/31/measure-your-memory-usage-with-mem_info/

Unless you run the garbage collector manually (gc.collect()) right before mem_info(), then you are seeing a random snapshot. The garbage collector only runs when there isn't a large enough block free and something needs to allocate memory. So you seem to have managed to catch it right before the GC ran when the memory was 100% full. But there were plenty of unused objects that could be freed in order to allocate more memory later, so you didn't get any errors.

[TrainsWithLights]

I included the gc.collect() prior to mem_info() but got an error message = gc isn't defined.
Tried adding 'from micropython import mem_info, gc' but that didn't work.
More info please...

How can you tell there are 'plenty of unused objects that could be freed'?

Now the program completes the entire startup sequence, then fails when connecting (power-up) the remote control handset.

stack: 588 out of 5180
GC: total: 6912, used: 5168, free: 1744
No. of 1-blocks: 144, 2-blocks: 3, max blk sz: 38, max free sz: 54

Traceback (most recent call last):
File "HUB05051616.py", line 1146, in
MemoryError: memory allocation failed, allocating 1016 bytes

[BertLindeman]

I think it is:

import gc
gc.collect()

[dlech]

MemoryError: memory allocation failed, allocating 1016 bytes

Now you have hit the problem of memory fragmentation. Even though there might be enough total free memory, you are tying to allocate a rather large continuous block, which isn't available.

If you want to share your program we might be able to offer some tips on how to not use so much memory.

[TrainsWithLights]

Thanks Bert and David,

Turns out that by placing the gc.collect() just before calling the 'remote control handset' freed up plenty of space - free: 2000 in fact.
This also allowed the version() and mem_info() to be included in the complete code, so the full package now works!
(Previously culled the SLAVE section (100 lines of code) to get mem_info() and version() to work)

In essence - ALL GOOD.

here's a tip -> add the gc.collect() info to the pybricks documentation package!

Pre 'remote' call

stack: 588 out of 5180
GC: total: 6912, used: 4912, free: 2000
 No. of 1-blocks: 127, 2-blocks: 3, max blk sz: 39, max free sz: 63
GC memory layout; from 20004cc0:
00000000: h=.hhDh======LhLhhh======================================h=====h
00000400: ========h================h===============================SSSSSSS
00000800: SSSSSTSSSSSSSSSSSSSSh==========hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
00000c00: hhhhhhhhhBh=====........TLh=D..h====Lhh=hhhBBBBBBBBBBBBBBBBBBBBB
00001000: BBBBBBBBBBBBBBBBBBBB........h====...............................
00001400: ............h====================================...............
00001800: ................................................

Post 'remote' call

stack: 588 out of 5180
GC: total: 6912, used: 5616, free: 1296
 No. of 1-blocks: 138, 2-blocks: 6, max blk sz: 64, max free sz: 30
GC memory layout; from 20004cc0:
00000000: h=.hhDh======LhLhhh======================================h=====h
00000400: ========h================h===============================SSSSSSS
00000800: SSSSSTSSSSSSSSSSSSSSh==========hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
00000c00: hhhhhhhhhBh=====h====...TLh=D..h====..h=hhhBBBBBBBBBBBBBBBBBBBBB
00001000: BBBBBBBBBBBBBBBBBBBB....hhhh..Sh..............................h.
00001400: .......h........h=Lhhh=hh=h=====================================
00001800: ==========================.........h............

[TrainsWithLights]

Hi David, Bert and Laurens, Over the past 3 months I have been developing a fully-featured 'product' for the CityHub, which addresses most of the shortcomings of the original Lego firmware and controlling trains... Here is a quick list of features - Supports full control of all motors - Wedo / Train / Large as well as the LED lights - Includes Master and Slave hub operation with super easy BLE pairing and automatic slave detection - Can run up to 12 Master hubs in a single room along with associated slave hubs - Handset configuration allows quick change of settings for Selectable Port A / B motor polarity for the Master and Slave hubs multiple slaves can be connected with automatic device determination and operation Selectable step size for motor control (10/15/25 steps for full range) Selectable 'Continue or Stop' motor operation when remote out of range Selectable Bluetooth Off / 6 / 12 channels (Off = faster start-up) - Handset operation includes automatic ramp down to stop for the motors (short press of the stop button) press and hold to continually increase motor speed, rather than repetitive pressing, or the repetitive pressing if preferred automatic ramp-up/down of the LEDs (short press of the stop button) user defined motor start setting overcomes start torque - results in 0, 30, 40, 50 etc operation handset blinks Red when the maximum +/- setting is exceeded. Double press the hub or handset centre button to start the PAIR function, then start the 'slave' hubs Press any hub or handset button to cancel the PAIRing function - Debug Mode displays the following on the console all BLE send and receive packets BLE search channels Master and Slave configurations The list goes on but you get the idea. So I had the idea of selling the code via ReBrickable, where many of my train designs are already being sold. However releasing source code is not ideal and likely to be quickly pirated. Are you able to offer any advice as to how to package and sell the code? Is there any interest in Pybricks offering the code as a purchased 'import' through your website, thus hiding the code? The code has been functionally tested, including an interference test and has excellent error recovery. I would be happy for the code to be reviewed by your team, but not in the public forum... Respectfully Peter Miller TrainsWithLight

…

On Fri, May 16, 2025 at 11:52 PM David Lechner ***@***.***> wrote: MemoryError: memory allocation failed, allocating 1016 bytes Now you have hit the problem of memory fragmentation. Even though there might be enough total free memory, you are tying to allocate a rather large continuous block, which isn't available. If you want to share your program we might be able to offer some tips on how to not use so much memory. — Reply to this email directly, view it on GitHub <#2194 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BQPX7BH3LOKNDOIA42GTG7T26XURVAVCNFSM6AAAAAB5HLWSNOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMJXGE2DMMQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[laurensvalk]

Over the past 3 months I have been developing a fully-featured 'product' (...) Are you able to offer any advice as to how to package and sell the code? (...) I would be happy for the code to be reviewed by your team, but not in the public forum...

We strongly encourage sharing code to allow others to play and learn. I think you'll find that you'd reach a far bigger audience that way, and get far more return in terms of happy comments or even code contributions to your project.

When complying with the various licenses you are legally allowed to repackage and sell our work. But you can probably see that we prefer to volunteer our time on helping other users learn rather than spend it on other people's commercial ventures. I guess we have already helped you solve your problem just in time.

This discussion will be closed.