MicroPython Forum

Upon a closer look it turns out all of these essentially come down to valgrind thinking that the global mp_state_ctx.mem.xxx values are not initialized, which is demonstrably false because one of the first things done in main() is calling gc_init() which initializes all of that. So unless I'm missin...

For reference, this is the relevant part of the output for debug builds of v1.15, I just excluded some of the traces which occur multiple times: ==3803== Conditional jump or move depends on uninitialised value(s) ==3803== at 0x120435: gc_collect_root (gc.c:347) ==3803== by 0x192126: gc_helper_collec...

ikkeT wrote: ↑

Mon Apr 19, 2021 6:41 pm

Or should such import be in __init__ function of the class?

Yes, or in any other function. I honestly don't know what the effect is of putting it at class level, just that it doesn't import the names into an available scope..

ikkeT wrote: ↑

Mon Apr 19, 2021 6:15 pm

Is it so that one can't do the import from within the class?

No that's not a problem (assuming you mean 'in a function in a class' or so, not sure what importing at class level does but if it's wrong it'll be a syntax error, it won't just silently mess up)

Sorry forgot about this thread. The output now doesn't have file/line numbers in the stacktraces anymore so it's impossible to see what the errors are about. Compile again in debug mode (make DEBUG=1). Debug mode will also fix the reported memory leak: for some reason the release builds of the unix ...

Bit hard to answer without more concrete information; essentially in C every MicroPython variable is going to be of type mp_obj_t. But how to best get to them depends on what/how you want to use this. I.e. are you implementing a custom type in C which getts exposed via a module? Then look at example...

Have you tried running it without the display part and just printing to the console or a text file? Could very well be the fonts etc just hit the memory limit of your device. Underscores aren't going to change much as far as memory usage go. What you can do to figure out which component uses most me...

By default anything which isn't part of the public API, i.e. doesn't get exposed and remains local to a source file, is declared static. This is cleaner, plus as fas as I'm aware it allows certain optimizations both with respect to performance and code size. You're not the first one with this questi...

I can access the bridge (from debian linux) via the usual device file /dev/ttyUSB0. Have you tried standard open("/dev/ttyUSB0") in MicroPython? If it's a driver where you can set baud rate etc on the diriver, that might just work, if you're lucky. Otherwise you'd be looking at porting the relevant...

Pretty sure you can just run valgrind on a 'normal' micropython build from the unix port? Assuming that reproduces the issue.