Running script from memory question

[johnmc...@gmail.com]

Hello,

I've been experimenting with your code at:
https://code.google.com/p/python-on-a-chip/

I would like to use it to run scripts in an embedded CPU environment
where the python scripts are uploaded to the device via ethernet.
The device does not have a file system,
so I need the ascii script to load from memory into
the pymite interpreter and run.

At various times other scripts will be loaded onto the device and also need
to run.

Here below is what I need to function in its simplest form,
however the function 'pm_run' assumes the passed in string
is a tag to an image made by 'pmImgCreator', which is not the situation I
have.

Can this be done? It seems it should, but I am struggling finding the right
pymite API.
Let me know of a way to accomplish what I need.
Any help would greatly be appreciated.

Thanks

-

#include "pm.h"


int main(void)
{

const char* script = "for letter in 'Python': print 'Current Letter :',
letter";

PmReturn_t retval;
retval = pm_init(MEMSPACE_PROG, C_NULL);

if (retval == PM_RET_OK)
{
retval = pm_run((uint8_t *)script);
}

return (int)retval;

}

[Dean Hall]

Sorry, there is no compiler built into the PyMite VM.
The script must be compiled to an image to be used by the VM.

The micropython project has an on-board lexer/parser:
https://www.kickstarter.com/projects/214379695/micro-python-python-for-microcontrollers/posts/669549

!!Dean

> --
> --
> You are subscribed to the "python-on-a-chip" (or p14p for short) Google Group.
> Site: http://groups.google.com/group/python-on-a-chip
>
> ---
> You received this message because you are subscribed to the Google Groups "python-on-a-chip" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to python-on-a-ch...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Steve Morris]

I don't know much about Python-on-a-chip but I'm an embedded type of guy. Whenever I have code that needs a disk I just create a simple ram based file system. For a single read only file with no seek (modeling pipe input etc) this can usually be done with less than 20 lines of code. Most interpreters can handle the simplest I/O interface, no seek etc. Open just initializes the current point to zero and read is just a mem copy that advances the current pointer. write and seek return errors. If malloc is available it is not much more difficult to bring up a dynamic multiple file system where the directory is a linked list  of structs with name, pointer to start address, file size and pointer to the next struct. Put each "file" in its own malloced buffer. Read code is the same as with a single file but open is slightly more complex. I've brought up perl and emacs and a few other apps in a spectrometer that way. The file system was the simplest part of the effort. Simple single threaded read only file systems are cheap to implement. Simple read/write file systems are not far behind. Most of the complexity of modern file systems is for features you don't need in embedded. I generally find it easier to give tools like Python a primitive version of the interfaces it expects than hacking the tool to use different interfaces.