Micropython ported to the TI nspire calcs

[Vogtinator]

Hi,
Quite a while ago (I didn't know that this forum exists, otherwise I'd have posted here earlier) I started working on a port of µP to the TI-Nspire series of calculators using ndless. Initiated by tiplanet.org, a mostly french calculator community focusing on education and programming, I implemented some useful features in ndless to make porting more easy. The port's code is on GitHub and there are already some other projects somehow connected to it, like two text editors. I added some minimal routines to interface with the hardware, for example to run mandelbrot:



Of course it can also run the CLI:


Some links:
TI-Planet article focused on micropython
French TI-Planet article focused on teaching with python
More technical article about the port on cemetech
Forum thread on omnimaga

Now, there is a small problem: The core functions work fine, but the nspire has a big issue with large folders, every file makes the device slower.
Is there any way to use micropython-lib as a kind of archive? If not, what would be the best/easiest way to implement it?

[pfalcon]

Really cool! Did you have to touch underlying Nucleus RTOS to do the port, or Nspire OS wraps it completely into own API?

Is there any way to use micropython-lib as a kind of archive?

I assume you mean https://github.com/micropython/micropython/issues/736 . Well, there's now also https://github.com/micropython/micropython/pull/1005 , but someone should really implement space-efficient R/O filesystem some time .

[dhylands]

I implemented memzip, a read-only filesystem used on the teensy.

It basically takes a zip archive containing uncompressed files and saves it in memory. Currently, it's only hooked into import, and not general file I/O (so you can import python modules, but not open files).

[Vogtinator]

Really cool! Did you have to touch underlying Nucleus RTOS to do the port, or Nspire OS wraps it completely into own API?

It's actually a third layer TI tries to lock down the calcs further everytime they release a new OS, Ndless is basically a jailbreak with its own API.

Is there any way to use micropython-lib as a kind of archive?

I assume you mean https://github.com/micropython/micropython/issues/736 . Well, there's now also https://github.com/micropython/micropython/pull/1005 , but someone should really implement space-efficient R/O filesystem some time .

Hm, deflated CPIO or tar archive inflated into memory?
The advantage is that it's a standardized format and easy to create on every platform.

I implemented memzip, a read-only filesystem used on the teensy.

It basically takes a zip archive containing uncompressed files and saves it in memory. Currently, it's only hooked into import, and not general file I/O (so you can import python modules, but not open files).

Is it working and tested? There are some people around wanting to use SymPy with micropython, it's a rather large CAS lib and that would be quite a good test.
Does it support other platforms as well? 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.

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, simply appending a binary won't work with ELF or other formats.

[Damien]

If you just want read-only access to the files, then a single tar file mounted as a block device (using new mount feature) would be the best way to do it.

[dhylands]

If you just want read-only access to the files, then a single tar file mounted as a block device (using new mount feature) would be the best way to do it.

@dpgeorge - I don't think that will work. Right now, you can only mount FATFS filesystems. Or did you mean something different?

[Damien]

@dpgeorge - I don't think that will work. Right now, you can only mount FATFS filesystems. Or did you mean something different?

Ah, yes, you ar correct!

Let me start again: you can do a loopback device by creating a file which contains a full fatfs filesystem. You can then write a simple block driver that reads from (and potentially writes to) this file in chunks of 512 bytes. Something like:

Code: Select all

class Loopback:
    def __init__(self, file):
        self.file = open(file, 'rb')
    def readblocks(self, blnum, buf):
        self.file.seek(blnum*512)
        self.file.readinto(buf)
    def count(self):
        self.file.seek(0, 2)
        return self.file.tell() // 512

os.mount(Loopback('disk.img'), '/disk')

You can easily create "disk.img" on a PC and write your files to it, and then copy it to the calculator.

[Vogtinator]

Looks good, does it also work for imports or just for fopen and friends?

[Damien]

Looks good, does it also work for imports or just for fopen and friends?

It'll work for anything file related, including import.

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.

There's some ideas to make our own minimal, read-only filesystem driver, but that's a while in the future

[pfalcon]

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.

The advantage is that it's a standardized format and easy to create on every platform.

Running simple Python script which creates unbloated archive is also easy on every platform .

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).

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 .

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.

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.