MicroPython Forum (Archive)

First signs of life

fnord wrote: ↑

Sun Apr 26, 2020 11:53 am

to my main.c, the build succeeds, but that's probably not the right way to do it

Seems fine for now. You can probably find something in the DMCP SDK to use for this.

fnord wrote: ↑

Sun Apr 26, 2020 12:50 pm

First signs of life

Oh that's awesome!!!! Made my day, I hope the libmicropython.a PR helped, if so it was definitely worth it

Yes, it really helped a lot, thank you!

The current status is:
My main program reads a file called test.py from the calculator's FAT filesystem into a buffer and then calls execute_from_str(buffer).
I have started working on a module called dmcp that tries to match the DMCP c api as closely as possible, and another module called dmpy that contains everything that I might find useful to have but is not strictly part of the DMCP api.

The next thing would probably be the file functions, so that I can access DMCP's FAT filesystem from python code.
How would I go about teaching libmicropython to use DMCP's file functions? I could add these functions to the dmcp or dmpy module, but it would be much nicer if I could use the native python functions like open() and import.

fnord wrote: ↑

Tue Apr 28, 2020 8:01 pm

The next thing would probably be the file functions, so that I can access DMCP's FAT filesystem from python code.
How would I go about teaching libmicropython to use DMCP's file functions? I could add these functions to the dmcp or dmpy module, but it would be much nicer if I could use the native python functions like open() and import.

You'll want to look at how the Unix port does this.

A quick summary though (sorry I haven't looked into this in detail recent, so this is sort of off the top of my head memory of how this works):
- MicroPython provides a VFS layer that allows filesystems to be mounted from block devices. This is really useful on bare-metal ports, but on an RTOS port you're more likely to want to use the OS's filesystem abstractions.
- A port is also able to provide default implementations of open() and import (you've already seen mp_import_stat). From Python, these are really the only two ways of accessing the filesystem (other than then subsequently reading/writing the files via the stream interface), so there's not a lot more you need to provide other than a way to produce a stream from a path+flags.
- The unix port can do either approach, but it sounds like the second approach is more useful for you. You might even be able to use most of the unix implementation (see mp_builtin_open in unix/main.c), and the mp_vfs_posix_file_open implementation it uses and the related VfsPosix code. (I assume DMCP provides something similar enough that it might just work?).

Status update:
I can read and execute .py files and also import modules from the DMCP filesystem.
Also, I have an error screen for uncaught exceptions.

Hi again,

I found a reliable way to crash my program, but I'm not sure what do do about it.
The following python code does nothing interesting but works: Whereas the following code causes the program to crash: Note that the error message is not coming from my program but from the DMCP OS. I can increase the number of iterations that work without crashing by increasing the amount of heap I allocate for MicroPython.
Is it possible that the garbage collection is not working properly and I'm just filling up the heap with unused string objects?

fnord

fnord wrote: ↑

Wed May 06, 2020 8:37 pm

Whereas the following code causes the program to crash:

It sounds like the GC is crashing. I initially wondered if it was filling up the entire heap with QSTR pools, but I don't think that exact code will result in any QSTRs being created (only strings which can be GC'ed).

Any chance you can post what you've got so far to github so I can take a look?

Yes, I intend to put what I have so far on github, just haven't found the time to do so yet.
I'll probably need to fork micropython so I can include it as a git submodule with my changes to the micropython code.
I hope I'll be able to do make my code available in the course of this week; sorry for the delay.

Okay, here it is: https://github.com/fnordsh/dmpy
If you have any questions, let me know!

Okay, I looked a bit more into the hard fault issue I described above.
The crash does indeed happen when I run out of heap space, or whenever I call gc.collect().
When I disable the garbage collector with gc.disable(), I get a MemoryError exception instead of the hard fault, when I run out of heap.
So it seems something goes wrong when the GC tries to reclaim unused memory.