micropython: running PASM code on another COG

@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:
# 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.

FlexGUI, a GUI for programming the P1 and P2 in Spin, PASM, BASIC, and C.
Help support its development at Patreon or PayPal.

Comments

  • Sounds reasonable for now Eric. Because of the video stuff I've not been playing with Python too much myself lately apart from customizing it slightly with baud rate and startup clock changes to allow for standalone use for Tubular.

    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?
  • rogloh wrote: »
    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.
    Yes, I was originally thinking that we might want a built in assembler and be able to generate the bytearray using that. But while p2asm is very small by any reasonable standard, it would take up a significant chunk of the memory left over after micropython is loaded.
    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! :)

    FlexGUI, a GUI for programming the P1 and P2 in Spin, PASM, BASIC, and C.
    Help support its development at Patreon or PayPal.
  • Eric
    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.

    Melbourne, Australia
  • ozpropdev wrote: »
    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.
  • rjo__rjo__ Posts: 2,076
    edited 2019-12-01 - 06:02:39
    I had a thought!!!

    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
  • rjo__rjo__ Posts: 2,076
    edited 2019-12-01 - 06:01:25
    If you like the general idea... then there would seem to be two choices... you could call it MicroPython+ and when you invoke it through FlexGui it would actually run a Spin or Pasm program, which would do two things... allocated all of the cogs with serial watchdog code in them (except cog0) and then invoke MicroPython from that Spin or Pasm program.

    OR you could figure out how to do it as a module that you would then Import. I have no idea about this.




  • Yes Eric this would be really useful, and a logical next step

    Rjo what you're proposing is find where you have a PC to command whats going on, but what about stand-alone operation?
  • hold on their partner... I am not planning at the moment.
    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.
  • There is no polite way to say "Go back where you came from". It is just wrong in all ways one could say it.

    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
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
Sign In or Register to comment.