Shop OBEX P1 Docs P2 Docs Learn Events
I want a P2! And how are we going to get these to you? - Page 11 — Parallax Forums

I want a P2! And how are we going to get these to you?

18911131418

Comments

  • RaymanRayman Posts: 13,767
    Sounds good.

    Any decision on actual price yet?

    Will any of the adapter boards be ready soon?
  • Ken Gracey wrote: »
    Everybody on board with the vision in this regard? This is a group effort and the results we all desire are only possible with the contributions from all of you.

    Your volunteer crew is at the ready!
    David Betz wrote: »
    Ken Gracey wrote: »
    octetta wrote: »
    Lots of tool development is ahead of us. We figured it was best to get some hardware in front of people and then we'll schedule an open invitation to talk about the compilers/interpreters/tools for these programming languages. It's going to be different than P1 this time. There are few (if any) development funds, interest in new languages, and we want to leverage existing programming environments where possible. I hope to speed the discussions using video conferencing tools in addition to the forums.

    Ken: given your contacts with schools using the P1, are there any particular languages or tools being asked for that aren't on anyone's radar here?

    So excited to be part of this path.

    MicroPython. MicroPython. Did I mention MicroPython?

    Ken Gracey
    Is someone already looking into porting MicroPython?

    I'd happily volunteer for that. I'm pretty good with Python, and I think the majority of the work is at the HAL level which could (should?) be written in Python itself. The hard part - writing the Python interpreter - should "just work" once GCC is good-to-go. I tried building the "minimal" port for x86 a few minutes ago and it built without any issue in a Docker container with nothing more than gcc-multilib, g++ multilib, make, python, and python3 installed (not sure if Python 2 was required). One could probably even tweak the makefile a bit and build Micropython today for P2 thanks to spin2cpp. But once PropGCC for P2 is complete, it should be very simple to get the minimal port up and running.
  • __red____red__ Posts: 470
    edited 2018-11-24 20:20
    The micropython "devil" I suspect won't be getting it running per se, but deciding how to implement multithreading when we actually *HAVE* separate cogs to (ab)use.

    But a version that just runs in a single-core at least from a high-level doesn't look that evil (at first glance).
  • I just tried building MicroPython using PropGCC for P1 and it failed because we don't supply alloca.h. I suppose it probably isn't that hard to write it. In fact, there is an implementation in newlib but I think there are licensing issues with newlib.
  • OzProp and I could do with a high level language before too long, and so are going to talk to some people this week about Micropython, and also how well it handles high speed (2~50M) serial as this is perhaps an issue.
  • David Betz wrote: »
    I just tried building MicroPython using PropGCC for P1 and it failed because we don't supply alloca.h. I suppose it probably isn't that hard to write it. In fact, there is an implementation in newlib but I think there are licensing issues with newlib.
    Looks like this works:
    #ifndef __ALLOCA_H__
    #define __ALLOCA_H__
    
    #define alloca(size) __builtin_alloca(size)
    
    #endif
    

  • Tubular wrote: »
    OzProp and I could do with a high level language before too long, and so are going to talk to some people this week about Micropython, and also how well it handles high speed (2~50M) serial as this is perhaps an issue.

    If the primary purpose is education, are we really concerned about high speed serial? I don't think so, unless there are external devices we need to interface to in order to achieve a good support program.

    Ken Gracey
  • __red__ wrote: »
    The micropython "devil" I suspect won't be getting it running per se, but deciding how to implement multithreading when we actually *HAVE* separate cogs to (ab)use.

    But a version that just runs in a single-core at least from a high-level doesn't look that evil (at first glance).

    Well then, start thinking evil because we're going to have to support multiple processors (we use this word with the educational audience instead of cores).

    Ken Gracey
  • jmgjmg Posts: 15,140
    Ken Gracey wrote: »
    Tubular wrote: »
    OzProp and I could do with a high level language before too long, and so are going to talk to some people this week about Micropython, and also how well it handles high speed (2~50M) serial as this is perhaps an issue.

    If the primary purpose is education, are we really concerned about high speed serial? I don't think so, unless there are external devices we need to interface to in order to achieve a good support program.

    A short-term port may have caveats around speed, and peripherals, but as those are moved to more native P2 code, things will get faster (and smaller?)

    PC Python worked well on P2 loader tests up to some MHz baud rates, (there is already a P2 PC-Python loader), so the natural target would be to at least try to match that.

    Getting above 12MBd on PC-Serial, is currently something of a black-hole, but P2-P2 links can go higher.

  • I got the minimal version of MicroPython to compile using the XMMC memory model under PropGCC for P1. I wonder if that means it has a chance of working on P2 using Dave Hein's p2gcc?
  • jmgjmg Posts: 15,140
    David Betz wrote: »
    I got the minimal version of MicroPython to compile using the XMMC memory model under PropGCC for P1. I wonder if that means it has a chance of working on P2 using Dave Hein's p2gcc?

    interesting. Any code size indications ? Maybe this Python talk needs forking to a separate thread, by a moderator ?
  • jmg wrote: »
    David Betz wrote: »
    I got the minimal version of MicroPython to compile using the XMMC memory model under PropGCC for P1. I wonder if that means it has a chance of working on P2 using Dave Hein's p2gcc?

    interesting. Any code size indications ? Maybe this Python talk needs forking to a separate thread, by a moderator ?
       text	   data	    bss	    dec	    hex	filename
     162020	      0	   2696	 164716	  2836c	build/firmware.elf
    


  • David Betz wrote: »
    jmg wrote: »
    David Betz wrote: »
    I got the minimal version of MicroPython to compile using the XMMC memory model under PropGCC for P1. I wonder if that means it has a chance of working on P2 using Dave Hein's p2gcc?

    interesting. Any code size indications ? Maybe this Python talk needs forking to a separate thread, by a moderator ?
       text	   data	    bss	    dec	    hex	filename
     162020	      0	   2696	 164716	  2836c	build/firmware.elf
    

    Never mind. Even though it compiles, links, and loads into a C3, it doesn't work. Maybe there is too little hub memory for the data. Anyway, the P2 should have a better chance. I'll stop talking about Python in this thread now. Sorry for the distraction.

  • Considering that P2 is designed for good performance with C, is anyone looking into a Lua port? I've got something like four different devices using Lua as the native scripting engine at work now.
  • TorTor Posts: 2,010
    Good plan, Ken.

    I'm on the second list, so I'll wait it out to make sure that the (IMO) more important people get their first.
  • Ken Gracey wrote: »

    Everybody on board with the vision in this regard? This is a group effort and the results we all desire are only possible with the contributions from all of you.

    I'm on board! Lets do this!
  • VonSzarvasVonSzarvas Posts: 3,262
    edited 2018-11-25 19:23
    @W9GFO

    https://drive.google.com/drive/folders/1t-KQwLfhzz7xI-AghJN2dIrHyn9Px4C8

    Folder has been updated with models for the protoboard and DVO (digital-video-out) breakouts.
    These are the 2 sizes we are using. 800x1600 and 800x3200 mil.

    The mini-breadboard reference refers to the protoboard. With headers fitted at the 1900mil spacing, the Parallax mini-breadboard will fit between.

    I think jmg asked about the 2x6 headers (that connect to P2-EVAL)... The breakouts accept SMT or TH headers. The prototype boards will likely be supplied un-soldered so customers can chose the header type they want to fit. All the other breakouts will have pre-fitted SMT headers. Sure- they could be un-soldered and changed to TH by the customer if preferred.


    The rest of the 3D models (3 or 4 more board types) will probably be uploaded tonight. I think these first 2 will show what you need for the case though, as all the other breakouts fit the same dims. They are designed so you can fit up to (all) 8 breakouts around the P2-EVAL at the same time.


    Edit: Rest will follow as part of docs effort in a few days.
  • octettaoctetta Posts: 123
    edited 2018-11-25 16:59
    I've been taking a cursory look at the Python 2.7.15 documentation https://docs.python.org/2/library/dis.html#bytecodes it shows that there are 71 byte codes emitted by the Python "compiler".

    Not yet sure about the data structures needed to support this, but it appears the VM is stack based.

    Ignoring micropython and friends for a bit, I'm curious how Chip's Spin-friendly P2PASM instructions would map to a pure P2 machine code implementation.

    I've seen chatter about a P2 simulator here... given that I don't have a FPGA/P2, would that be an appropriate place to play around with these ideas?

    For quick reference, here are the byte codes:
    STOP_CODE
    NOP
    POP_TOP
    ROT_TWO
    ROT_THREE
    ROT_FOUR
    DUP_TOP
    UNARY_POSITIVE
    UNARY_NEGATIVE
    UNARY_NOT
    UNARY_CONVERT
    UNARY_INVERT
    GET_ITER
    BINARY_POWER
    BINARY_MULTIPLY
    BINARY_DIVIDE
    BINARY_FLOOR_DIVIDE
    BINARY_TRUE_DIVIDE
    BINARY_MODULO
    BINARY_ADD
    BINARY_SUBTRACT
    BINARY_SUBSCR
    BINARY_LSHIFT
    BINARY_RSHIFT
    BINARY_AND
    BINARY_XOR
    BINARY_OR
    INPLACE_POWER
    INPLACE_MULTIPLY
    INPLACE_DIVIDE
    INPLACE_FLOOR_DIVIDE
    INPLACE_TRUE_DIVIDE
    INPLACE_MODULO
    INPLACE_ADD
    INPLACE_SUBTRACT
    INPLACE_LSHIFT
    INPLACE_RSHIFT
    INPLACE_AND
    INPLACE_XOR
    INPLACE_OR
    SLICE+0
    SLICE+1
    SLICE+2
    SLICE+3
    STORE_SLICE+0
    STORE_SLICE+1
    STORE_SLICE+2
    STORE_SLICE+3
    DELETE_SLICE+0
    DELETE_SLICE+1
    DELETE_SLICE+2
    DELETE_SLICE+3
    STORE_SUBSCR
    DELETE_SUBSCR
    PRINT_EXPR
    PRINT_ITEM
    PRINT_ITEM_TO
    PRINT_NEWLINE
    PRINT_NEWLINE_TO
    BREAK_LOOP
    LOAD_LOCALS
    RETURN_VALUE
    YIELD_VALUE
    IMPORT_STAR
    EXEC_STMT
    POP_BLOCK
    END_FINALLY
    BUILD_CLASS
    WITH_CLEANUP
    STORE_MAP
    HAVE_ARGUMENT
    

    Many are simply stack, array, math, and bitwise operations. I suspect there's a ton of complexity in the looping, class, and call/exec/yield statements.
  • octetta wrote: »
    I've been taking a cursory look at the Python 2.7.15 documentation https://docs.python.org/2/library/dis.html#bytecodes it shows that there are 71 byte codes emitted by the Python "compiler".

    Not yet sure about the data structures needed to support this, but it appears the VM is stack based.

    Ignoring micropython and friends for a bit, but I'm curious how Chip's Spin-friendly P2PASM instructions would map to a pure P2 machine code implementation.

    I've seen chatter about a P2 simulator here... given that I don't have a FPGA/P2, would that be an appropriate place to play around with these ideas?
    I'm not sure MicroPython uses byte codes. I guess it might be interesting to see if we can implement the Python byte code VM using Chip's XBYTE facility but I wonder if the rest of Python will fit? Maybe we should start a new thread for Python on P2?
  • kwinnkwinn Posts: 8,697
    Ym2413a wrote: »
    Ken Gracey wrote: »

    Everybody on board with the vision in this regard? This is a group effort and the results we all desire are only possible with the contributions from all of you.

    I'm on board! Lets do this!

    On board too. Waiting to see where to send order and payment. Any chance of getting a P2 chip for my P2D2 board in addition to the eval board?
  • I need one too. Any chance of getting a P2 chip for my P2D2 board ?

    :)



  • Ok, check in set for Wed and Thursday.

    Yeah Roy, it could be.



  • AleAle Posts: 2,363
    I need one too. Any chance of getting a P2 chip for my P2D2 board ?

    :)



    That's the question !, pretty please ?
  • Maybe On will see demand... and the resource can be more than a little over 100 chips?

  • evanhevanh Posts: 15,091
    Peter got sent some spare chips for the P2D2 boards.
  • W9GFOW9GFO Posts: 4,009
    edited 2018-11-26 06:14
    VonSzarvas wrote: »
    I'm pretty sure the breakouts won't fit as-is. They use smt headers, with the P2-Eval hdr pins passing up through the bottom of the breakout PCBs.I think they'll need the perspex removed out to the edges.

    I just re-read this. Didn't realize the pins would pass up through the breakouts. Any chance of putting a small radius on those corners?



    P2-EVAL%20with%20extensions%2003.png

    Breakout%20PCB%20interference.jpg
    775 x 600 - 671K
    823 x 800 - 143K
  • Definitely looking forward to this. Don't know how much I could contribute to serious stuff. but am excited to see what I can do with one and comparing to the P1.
  • Ken GraceyKen Gracey Posts: 7,386
    edited 2018-11-26 18:19
    The PCBs arrived this morning. Not sure where to post in our mess of threads, but I'll start here since there's an enclosure being made by W9GFO. Apologies for the upside-down photos; I'm moving quickly today with a lot to do.

    Ken Gracey
    4032 x 3024 - 2M
    4032 x 3024 - 2M
  • Cool! It's getting real.
  • ctwardellctwardell Posts: 1,716
    edited 2018-11-26 18:24
    Thanks Ken, awesome to see the progress.

    I saw a license plate this morning, "P II", I took that as a very good sign.

    Chris W.
Sign In or Register to comment.