Add support for LocalFileSystem on mbed

[GoogleCodeExporter]

The mbed platform has the LocalFileSystem class in the API that allows access 
to a file system on the device.  This file system is also accessible as a USB 
mass storage device.  It would be very useful to be able to access pre-built 
code images stored in files.

Steps:
1. Design file-system abstraction layer
2. Implement LocalFileSystem layer for mbed platform
3. Adjust mbed build system so that pmImgCreator can create files from user 
.py files.

Original issue reported on code.google.com by dwhall...@gmail.com on 23 Sep 2009 at 4:34

[GoogleCodeExporter]

STarted on a local copy of trunk.  The first tricky issue is that an image file 
will be 
used at 2 times: (1) when a module is imported to read it into a code object 
and (2) 
when the code object is executed to fetch the bytecode.  So a method is needed 
to store 
the file name for (1) and (2) and to store an offset to the bytecode for (2).

The second tricky issue is that during VM execution, the pointer to the open 
file must 
be switched every time the frame pointer changes; unless the bytecodes are read 
into a 
RAM buffer.

Original comment by dwhall...@gmail.com on 5 Mar 2010 at 4:58

• Changed state: Started

[GoogleCodeExporter]

I've posted a question on the mbed forums asking about a feature that would 
greatly 
simplify solving this issue (http://mbed.org/forum/mbed/topic/567/).  I'm going 
to wait 
for a response.

Original comment by dwhall...@gmail.com on 5 Mar 2010 at 5:28

[GoogleCodeExporter]

How elua accesses the filesystem:
http://mbed.org/users/jsnyder/notebook/elua-preliminary-port/

Original comment by dwhall...@gmail.com on 8 Jul 2010 at 5:00

[GoogleCodeExporter]

Attached patch of partial work.  I do not like the direction the work was 
headed (it runs into the problems mentioned above).  Patch is against r441.

Original comment by dwhall...@gmail.com on 18 Oct 2010 at 4:12

Attachments:

• issue_47_mbed_localFileSystem_r441.patch

[GoogleCodeExporter]

I investigated this recently in order to bypass the need to recompile my code 
every time or load it from ipm.  I modified main.cpp to automatically load a 
fix-named compiled python file output from pmImgCreator into malloc'd RAM.  I 
use img_appendToPath() to make the code available.  I also read a name of a 
module to run from a file called autorun.txt.  If none of that works then it 
just runs "main" as before otherwise it runs whatever module was specified.  
Since the mbed has a pretty good chunk of RAM I figure that this will allow 
quite a bit of code to be loaded on the fly.

Ideally it would be nice if the filesystem could be part of the import search.  
So if the module is not found it would be loaded in a similar manner to this 
(but keep those names short, mbed has an 8.3 file name limit).  I poked around 
the code but my stumbling block for this is keeping it multi-platform 
compatible (to be rolled into the distribution).  I'm very hesitant to make 
changes deep into the code base for fear of having a mess of tracking updates.  

I'm attaching my new main.cpp in case anybody is interested in my kludge-fix.  
Obviously the concept could be extended to have a text file listing the names 
of python files to load rather than just having a fixed single name.

Original comment by j...@missioncognition.net on 8 May 2011 at 1:42

Attachments:

• main.cpp

[GoogleCodeExporter]

Unfortunately it looks like I left a few tidbits of information in my comment 
above.  Only one week away and I had forgotten how to make this work.

Use the pmImageCreator.py tool using the -f, -b, and -o options to generate a 
file called pslib.pbn (an arbitrary name I made up, change the main.cpp if you 
want a different name).  You can pass in as many .py file names to compile as 
you want when you run pmImageCreator.  Change the module name in autorun.txt to 
correspond with one of your .py files you compiled.  Don't compile a file with 
the name main.py since the standard p14p build already uses that name.

Original comment by j...@missioncognition.net on 15 May 2011 at 8:25