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.
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.
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.
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.
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.
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).
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?
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 ?
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
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.
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.
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.
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?
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.
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?
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'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?
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.
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.
Comments
Any decision on actual price yet?
Will any of the adapter boards be ready soon?
Your volunteer crew is at the ready!
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.
But a version that just runs in a single-core at least from a high-level doesn't look that evil (at first glance).
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
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
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.
interesting. Any code size indications ? Maybe this Python talk needs forking to a separate thread, by a moderator ?
I'm on the second list, so I'll wait it out to make sure that the (IMO) more important people get their first.
I'm on board! Lets do this!
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.
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:
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.
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?
Yeah Roy, it could be.
That's the question !, pretty please ?
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?
Ken Gracey
I saw a license plate this morning, "P II", I took that as a very good sign.
Chris W.