Micropython ported to the TI nspire calcs

Showroom for MicroPython related hardware projects.
Target audience: Users wanting to show off their project!
User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Micropython ported to the TI nspire calcs

Post by dhylands » Sat Dec 27, 2014 5:22 pm

pfalcon wrote:
dhylands wrote:I implemented memzip, a read-only filesystem used on the teensy.
Does it support other platforms as well?
Exactly my question when the teensy port was contributed - it appears to be generic feature, why it is made port-specific? No changes to that situation for half-year, so I assume there're indeed reasons why it can't be reused for other platforms. I may imagine at least one though - again, high overhead of ZIP headers. That makes it non-portable for example to Leaflabs Mapple, proof of concept port to which I did lately. There's whole 700 bytes of flash left, and it won't do to spend them on storing useless archive headers. (Btw, shows that my conservatism regarding adding more bytes to uPy was grounded - there's indeed nothing else to add without raising minimum 128K flash requirement).
There is absolutely nothing teensy specific about the code. There never has been. It's always been generic code.

At the time I wrote it, there was no place in the tree to put any kind of generic code, and all of the attempts I made at the time got pushback, so I gave up and only put it in the teensy tree. At the time, the prevalent attitude was that if it wasn't stmhal or unix related feature - then there was no interest.

I knew that eventually there would be a place to put it, and now there is. I don't think that there is quite enough infrastructure yet to support it as a generic thing yet, so I'll probably wait until we have file-based pluggable filesystem and then move it/rework it.

Vogtinator
Posts: 4
Joined: Fri Dec 19, 2014 6:33 pm

Re: Micropython ported to the TI nspire calcs

Post by Vogtinator » Sat Dec 27, 2014 5:48 pm

Damien wrote:
Vogtinator wrote:Looks good, does it also work for imports or just for fopen and friends?
It'll work for anything file related, including import.
Great, I'll make some tests. SymPy doesn't work with µPy ootb, so I'll have to test using something else, probably micropython-lib at first.
But for it to work your uPy implementation needs to have low-level access to the file I/O interface. It won't work if you are relying on the calculator OS for high-level file operations like f_open. For it to work you'll also need to make sure the fatfs driver is compiled into uPy.
Although the posix functions are present, only fopen and friends should be used for backwards-compatibility. There's a compatibility layer between, though.
pfalcon wrote:
Vogtinator wrote: Hm, deflated CPIO or tar archive inflated into memory?
tar has 51200% overhead for storing 1-byte file. Also, what memory? There's no memory, MicroPython runs on 2KB of heap, and all of it is needed to do something useful like blinking LED.
Yes, on microcontrollers. There are other machines as well which do not run cpython, only micropython and are thus right in-between. On the nspire, µP has 30MB of heap.
dhylands wrote:I implemented memzip, a read-only filesystem used on the teensy.
Does it support other platforms as well?
Exactly my question when the teensy port was contributed - it appears to be generic feature, why it is made port-specific? No changes to that situation for half-year, so I assume there're indeed reasons why it can't be reused for other platforms. I may imagine at least one though - again, high overhead of ZIP headers. That makes it non-portable for example to Leaflabs Mapple, proof of concept port to which I did lately. There's whole 700 bytes of flash left, and it won't do to spend them on storing useless archive headers. (Btw, shows that my conservatism regarding adding more bytes to uPy was grounded - there's indeed nothing else to add without raising minimum 128K flash requirement).
If it's really that bad, compiling the standard libs (libm, libc and libgcc) with -flto, -ffunction-sections and -fdata-sections like µPy could save some bytes. Also, 700 B aren't really enough to include modules, it's probably easier to replace every "import" with a C-like "#include", although that wouldn't support arbitrary file IO.
Also, it would be quite useful to be able to load extern archives, not only ones appended to the binary. Having to recompile micropython everytime someone wants to try an updated module isn't the best way.
Hey, let's remember how it all started - "nspire has a big issue with large folders, every file makes the device slower". Have a decent filesystem, and you don't need all those tricks at all ;-).
Tell that TI and DataLight with their proprietary FlashFX and Reliance bulls**t. It's basically a FAT-like FS on a wear-leveling block device emmulation layer on a really slow NAND... Everytime the system boots or you change a file it rescans the whole NAND for files, takes more than a minute.
BTW: There are less ugly ways than to include extern binaries inside an object file: objcopy can copy a binary file into a section in an object file. You can then address it directly and it's platform independant,
It requires build platform with objcopy available, whereas including binary data as source-level C arrays work everywhere C works.
It's not any different with
https://github.com/micropython/micropyt ... -memzip.sh
simply appending a binary won't work with ELF or other formats.
You either mean some very particular ELF-using system, or imply that these Lua folks lie: https://github.com/LuaDist/srlua . But they don't, it works ;-). Doing similar thing for uPy is on my long list of TODOs.[/quote]

Appending to a binary has some issues: Where does it start? Supported on every platform? Can the binary be found? With objcopy into a section it's directly supported by every file format, even binary .hex files and it won't get lost by conversion to other file formats (like the nspire's toolchain does, ELF directly is too slow somehow) or similiar tools. It's basically xxd without the C step in between. Recompiling is not requried, just the final link-stage has to be run again.

Damien
Site Admin
Posts: 647
Joined: Mon Dec 09, 2013 5:02 pm

Re: Micropython ported to the TI nspire calcs

Post by Damien » Mon Dec 29, 2014 10:47 pm

User mountable block device feature is now available in latest version. And it's documented, see pyb.mount().

pfalcon
Posts: 1155
Joined: Fri Feb 28, 2014 2:05 pm

Re: Micropython ported to the TI nspire calcs

Post by pfalcon » Wed Jan 21, 2015 11:45 pm

Basic support for frozen modules is now implemented too: https://github.com/micropython/micropyt ... a93c18f0ec

Overhead is 3 bytes beyond size of module contents and its name. Only modules, not packages are supported so far.
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/

Post Reply