I'm looking at embedding micropython in an application because it appears to be nicely lightweight.
I'm still reading code and figuring out how things are arranged; I might be misunderstanding stuff.
Does anyone have any recommendations on how to handle micropython memory management on a non-embedded system?
For instance, the unix port does stack checking by marking the application stack. That seems ok for a standalone REPL app but I'm worried that this approach does not work in a big application where the stack may be deep but I still want to handle python stack issues. Is that correct? Is the only way to turn off stack checking? (I seem to hit the bottom of the stack quite often when I write python code so this makes me nervous).
I'm not understanding the MICROPY_ENABLE_GC switch fully either. The unix port seems to be allocating a special heap for uPy. Does this mean the GC is not able to work with the natural heap? If I don't enable the GC does memory just continuously fill up?
Embedding micropython in applications.
Re: Embedding micropython in applications.
hauptmech, to get people interested, feel free to share details about your application, e.g.: Is it open-source? Does it benefit community?
Awesome MicroPython list
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/
Re: Embedding micropython in applications.
MicroPython was really designed to run on a microprocessor where it owns the entire heap. When running under unix, since the regular heap doesn't use garbage collection, the entire micropython heap is allocated out of the main heap. MicroPython then manages its chunk of memory by using garbage collection.hauptmech wrote:I'm not understanding the MICROPY_ENABLE_GC switch fully either. The unix port seems to be allocating a special heap for uPy. Does this mean the GC is not able to work with the natural heap? If I don't enable the GC does memory just continuously fill up?
Re: Embedding micropython in applications.
[quote="dhylands"]MicroPython was really designed to run on a microprocessor where it owns the entire heap. [/quote]
This makes sense.
I'm trying to get an idea of what happens when the GC is not used. For instance, are local objects at the end of a function call deleted? Or are they left for the GC to collect and constitute a memory leak when there is no GC? The CPP switch ENABLE_GC implies to me that someone was thinking about how to operate without a GC and may have practiced good (enough) memory discipline. I'm hoping.
A more involved solution (to not having a predifined heap) would be for me to extend the gc so it allocates and manages a list of chunks from the system heap.
This makes sense.
I'm trying to get an idea of what happens when the GC is not used. For instance, are local objects at the end of a function call deleted? Or are they left for the GC to collect and constitute a memory leak when there is no GC? The CPP switch ENABLE_GC implies to me that someone was thinking about how to operate without a GC and may have practiced good (enough) memory discipline. I'm hoping.
A more involved solution (to not having a predifined heap) would be for me to extend the gc so it allocates and manages a list of chunks from the system heap.
Re: Embedding micropython in applications.
I think that if you disable the GC you get no frees at all (i.e. it massively leaks memory). I think that disabling the GC is only useful for testing.
Re: Embedding micropython in applications.
ok, good to know.