Closed microbit-carlos closed 2 years ago
I think the implementation is pretty much there already @microbit-carlos. We would just need to replicate this call I think (and ideally associated #ifdef guard): https://github.com/lancaster-university/codal-microbit-v2/blob/master/model/MicroBit.cpp#L394
We can also factor that out into a function CODAL side to avoid duplication if you prefer though.
Triggering the operation might be a bit trickier though. Is there any code on the micropython side that is only executed when such new program is injected by an editor like mu? Maybe something in the filesystem?
Triggering the operation might be a bit trickier though. Is there any code on the micropython side that is only executed when such new program is injected by an editor like mu?
There isn't anything currently, and I'm not sure how to make that work.
Maybe mu can run a command on the board after writing a new main.py, eg log.clear()
?
Maybe mu can run a command on the board after writing a new main.py, eg log.clear()?
This would be the simplest solution, but it'd only be applied to any editor we remember to alert of this change, or that carefully reads the release notes.
Ideally I would prefer if this was automatically managed by MicroPython/CODAL, as it ensures consistent behaviour across any micro:bit editor. It doesn't feel quite right that an editor would have to become responsible for things like erasing the log.
Options that we have:
main.py
file.
main.py
and not other files main.py
log.clear()
after serial flashing.
Somehow hook into the Python file system functions or microbit-fs low level filesystem to run additional actions when writing to a
main.py
file.
I think this is the most robust approach that would give the desired behaviour.
No need to modify upstream MicroPython, can just make a local copy of the microbit-filesystem code and modify it.
Implemented in 6ade36b3cb26f6b945606a61763422ed630155f5
If I remember correctly, the way CODAL determines if a new programme has been flashed to the micro:bit is something like this:
This works well for the MakeCode and Python online editors because the users either download a hex file that does a full flash erase (clearing the flag) and then flashes the hex content, or via WebUSB which also clears the flag if it does a full flash or partial flashing (as it compares the flash contents with the hex contents, and any flash page not included in the hex is erased).
However, for programmes like Mu, the user code is flashed via the REPL by sending a main.py file via serial and writing it via the filesystem API.
Could we figure out a way in which flashing a user programme via serial could invalidate the DAPLink storage as well?
@finneyj @JohnVidler This could end up needing an update to CODAL, but opening the issue here first as this is a use-case specific for MicroPython.