Porting MicroPython to SwissMicros DM42 / DMCP
Re: Porting MicroPython to SwissMicros DM42 / DMCP
First signs of life
- Attachments
-
- dmpy_first.jpg (149.95 KiB) Viewed 6181 times
Re: Porting MicroPython to SwissMicros DM42 / DMCP
Seems fine for now. You can probably find something in the DMCP SDK to use for this.
Oh that's awesome!!!! Made my day, I hope the libmicropython.a PR helped, if so it was definitely worth it
Re: Porting MicroPython to SwissMicros DM42 / DMCP
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.
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.
Re: Porting MicroPython to SwissMicros DM42 / DMCP
You'll want to look at how the Unix port does this.fnord wrote: ↑Tue Apr 28, 2020 8:01 pmThe 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.
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?).
Re: Porting MicroPython to SwissMicros DM42 / DMCP
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.
I can read and execute .py files and also import modules from the DMCP filesystem.
Also, I have an error screen for uncaught exceptions.
Re: Porting MicroPython to SwissMicros DM42 / DMCP
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
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:
Code: Select all
for i in range(100):
s = "%d"%i
Code: Select all
for i in range(1000):
s = "%d"%i
Is it possible that the garbage collection is not working properly and I'm just filling up the heap with unused string objects?
fnord
Re: Porting MicroPython to SwissMicros DM42 / DMCP
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?
Re: Porting MicroPython to SwissMicros DM42 / DMCP
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.
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.
Re: Porting MicroPython to SwissMicros DM42 / DMCP
Okay, here it is: https://github.com/fnordsh/dmpy
If you have any questions, let me know!
If you have any questions, let me know!
Re: Porting MicroPython to SwissMicros DM42 / DMCP
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.
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.