Add preliminary support for adding a main.py file to the fs.

[carlosperate]

This PR currently only adds a function and its tests for initial fs support. It will convert a Python script into a main.py file in the micro:bit MicroPython filesystem. However, this function is not called anywhere (only the tests), as we should discuss how we want to support this feature within uFlash (cc @ntoll).

My initial impression is that we should uprev uFlash to v2, and only support adding a main.py file. Not adding support to add more files, or to be able to read files back from the hex file.

This simple filesystem implementation will be useful for V2 support, as a replacement to the "attach a script to a known flash location" which is deprecated and not supported in V2. This is because the "add files to the hex and flash the hex" method is used in Mu as a fallback if microFS doesn't work.

Adding more fs support to uFlash would require a lot more code and tests, which we probably won't need. It is also a lot of work that we should probably route to something else, like getting Mu feature ready for the next release.

Just as reference, even the current small use-case already has to make a lot of assumptions:

• These things are not checked in bytes_to_ihex() (these assumptions are from the original implementation):
  • Doesn't check for addresses larger than 0xFFFFFFFF
  • Doesn't adapt to data records that could be 16 or 32 bytes (technically they could be any size, but these are the most common)
  • Doesn't ensure addresses for data records are aligned to 16 (or 32) byte boundary
• Things not checked in the new script_to_fs():
  • Filename length is not larger than 255
    • As the filename right now is hardcoded
  • Doesn't take into consideration there might be other things (like compass calibration data) in the hex file, or other files into the filesystem (like frozen modules)
    • This will never be the case in hex files generated from the MicroPython project repo without modification, but there are people that have made their own hex files with extra stuff
  • The filesystem boundaries are hardcoded.
    • This data is actually present in the UICR memory area in the hex file (and in V2 in a table placed after the MicroPython runtime), so uFlash could read it from the hex, but it's a lot easier to just add this data for now, specially since the hex files won't be updated that often

[carlosperate]

Test are failing on formatting, I'll resolved that a bit later today.

---

Edit: formatting resolved but there are Python 2 compatibility issues

---

Edit 2: All resolved now.

[ntoll]

@carlosperate let's talk about this at the Mu-moot this evening. I understand what's going on but, as you suggest, we need to work out how to support v2 fs copy in uFlash.

[carlosperate]

This PR has been updated with support for adding files to a Universal Hex and is ready for merge.

Things are not yet wired here, but I've done that in a different PR to simply review. It's in my fork to be able to show only the breaking changes: https://github.com/carlosperate/uflash/pull/1

[ntoll]

LGTM :+1:

Also, I've looked at the changes on your https://github.com/carlosperate/uflash/pull/1 branch. They also look fine. The remaining work (before a new release) is to revise the docs.