micropython: running PASM code on another COG
ersmith
Posts: 5,909
in Propeller 2
@rogloh, have you addressed how to start COGs in your version of micropython? If not, I'd like to propose that we have a Cpu type to encapsulate some COG code and data. Cpu(N) allocates COG N for use (actually N can have any set of bits that are passed to coginit). Cpu() on its own is the same as Cpu(0x10), that is, it will allocate the next free COG when it's time to start.
The methods on Cpu objects are:
start(code, data): starts a binary blob (compiled COG program) running in the allocated Cpu, or in the next free CPU if one is available. "code" is a bytearray of the PASM instructions to run. "data" is a bytearray or other buffer protocol object which contains the initial data. "code" is read only, but "data" is read/write so the running COG may update it.
On the COG side, "code" is what is passed to PTRB (the code loaded into the COG), and "data" is what is passed to PTRA.
stop(): stops the COG
So for example to start up the binary in the "cogcode.bin" file, with 3 longwords $00000001, $00000002, and $00000003 passed in its mailbox, do:
How does this sound?
@ozpropdev, you've done some very cool python tools for the P2. Any chance you've written an assembler in python?
It could come in pretty handy. I've actually looked at linking the p2asm assembler in, but it's fairly large by P2 standards and we're already a bit tight on memory in the micropython environment.
The methods on Cpu objects are:
start(code, data): starts a binary blob (compiled COG program) running in the allocated Cpu, or in the next free CPU if one is available. "code" is a bytearray of the PASM instructions to run. "data" is a bytearray or other buffer protocol object which contains the initial data. "code" is read only, but "data" is read/write so the running COG may update it.
On the COG side, "code" is what is passed to PTRB (the code loaded into the COG), and "data" is what is passed to PTRA.
stop(): stops the COG
So for example to start up the binary in the "cogcode.bin" file, with 3 longwords $00000001, $00000002, and $00000003 passed in its mailbox, do:
# read in the code
f=open("cogcode.bin", "rb")
code=f.read()
f.close()
# prepare the data as an array of integers
data=array.array('i', [1, 2, 3])
# set up the cog; just allocate the next free one
cog =pyb.Cpu()
cog.start(code, data)
# the cog will update data as necessary
...
cog.stop()
How does this sound?
@ozpropdev, you've done some very cool python tools for the P2. Any chance you've written an assembler in python?
It could come in pretty handy. I've actually looked at linking the p2asm assembler in, but it's fairly large by P2 standards and we're already a bit tight on memory in the micropython environment.
Comments
Having the ability to launch arbitrary COG code especially from SD will be very handy and important. In time I think we might need a way to have it also sourced from the built in memory image or from flash as well as SD files but your proposal is general and won't preclude that.
A while back I was vaguely wondering about having COGs triggered from their own import command as well, like how the frozen module commands do, but that may be independent (or an alternative) to this. I haven't really gone into depth but quite like the idea of having some type of Python library or object bundle, that has its own set of python functions as well as binary code block including it's code (which could be SPIN2 or PASM underneath). Something that could be shared in an OBEX for example. Have you had any similar thoughts?
I think that could be built on top of the .Cpu proposal. I've thought of creating a "spin2python" similar to "spin2cpp" which would convert a .spin file to a .py, and put the assembled PASM code into a binary blob. So many things to do, so little time... as I'm sure you find too!
I do have a simple line assembler built into my P2 Debugger.
I could look at what's required to isolate it from the debugger and hotrod it a bit.
Launching other cogs from micropython would be great!
I'd like to see micropython hooked up to hyperram/flash someday.
Then we can park library stuff in flash and use hyperram for editor/assembler buffers,etc.
Yes. I think given how Micropython already translates its data structures for native accesses, it might be possible to have some items hosted in external memory. Individual byte/long level accesses would not be fast, but block transfers of file/editor buffers, code etc from HyperRAM could be rather fast. Of course we need that matching memory arbiter COG for it.
Back in the pre-silicon days I asked ozpropdev how to load the lut with a binary over serial. I don't where I put the code, but it took him about a 10ms to answer:)
At about the same time Chip clocked P2->P2 serial at 8MBaud... at 80MHz system clock.
You would never want to load up a Cog if it didn't want to be loaded. So... a simple serial routine running in the cog would give permission and do the work of loading the binary into the LUT... which would then run in LUT Mode.
It sounds a lot easier than expanding the language
OR you could figure out how to do it as a module that you would then Import. I have no idea about this.
Rjo what you're proposing is find where you have a PC to command whats going on, but what about stand-alone operation?
I was just making a comment over the great divide that separates experts from amateurs like me ... knowing that my imprecise language might very well offend an expert.
So far: no harm no foul, but I want to be very clear about who we are and the exact nature of the comment.
For example... I could say: "I don't see why we couldn't___________" but then ersmith et al. might have to give a lengthy explanation as to why that won't work or find a polite way to tell me to go back where I came from.
And my comment was off topic to boot:)
Worth a glance.
And I am quite sure none of the major players here would even think about stating this, keep calm @rjo__.
It is more the opposite. Your findings and questions are important to get the documentation right. I am in this P2 game a lot and could do some nice stuff, but I bow deep to @ersmith, @rogloh, @ozpropdev, @evanh and many others who have way more understanding then I have.
And I do ask stupid questions, a lot of times, but get them solved by this forum, it is just amazing.
Early on I wrote some code to invoke ROM TAQOZ on the P2A as a Sub Object to be accessible form Spin/C/Basic short flexgui. Very complicated, yet possible.
I had to build a loader to patch the ROM start TAQOZ and then start the flexgui compiled binary, neither nice nor usable for everyone.
Now @ersmith added some features to P2load making this way more easy. You can load multiple files at given Hub addresses and decide where to start the execution. He even added some - still raw but useful - serial scripting. So with some help from @"Peter Jakacki" I might be able to rebuild this way more easy by using the new addition of a serial startup script. At least I hope I can.
Having MicroPython able to run some PASM in another COG and reserve some memory in HUB would be a GREAT extension. @RossH is thinking along the same way 'partitioning' the system to allow a XMM kernel to run concurrently with a CMM kernel in the same program. Flexgui/fastspin already allows to mix objects with different source languages in one application.
Sure all of this is still experimental, but it seems to go in the right direction.
There was a big effort on the P1 side to integrate Catalina, Spin and gcc to adhere to common standards for mailboxes, drivers and common used stacks but they never got finalized. Too much existing code in danger of breaking.
On th P2 this seems to be different. Erick and Ross and Peter agreed already on a common memory usage for clock settings, I hope very much that this collaboration will extend a bit to have some common mailbox schema, but what we have right now is pretty cool, already.
And the beast is not even released to the wild open public yet.
Good times are coming...
Mike