If you like cool interactive 3D views, go to mayhewlabs and after unzipping the attached file, drop all the contents onto where it says and click ok. Now play with the mouse (left click drag) pushing and pulling on the pcb and zooming etc.
BTW, this pcb is not the very latest but it is very close to the final.
@"Peter Jakacki"
Do you think it will be possible to have some pin pad & holes for the P2D2 EFM UB3 chip's USB D+/D- signals exposed can that pass through to a system board that carries the P2D2? I mean such that there can be some real pins added (not just soldered jumper wires) that can connect through between boards, just as all the left and right connector pins pins currently do. Standard 0.1 inch spacing would be easiest though we could resort to pogo pins perhaps if their distances are fully specified for PCB layout.
Is this going to be possible so the P2D2 is still removable/replaceable if and when required yet the USB signals can be passed through from another system board's USB connector? I could imagine this capability might also be rather helpful for your P2LAB board too.
If you look at the 3d view you will see 2 untented th pads just behind the usb connector that are there very that very purpose. I made the mistake last time of having these under the socket which sometimes are shorted against the connector due to whatever. These pads are 50mil apart but I just looked and could stretch them to 100mil which looks a long way away at this scale I will increase the pad size too.
What are you thinking you could use this for bearing in mind that the P2LAB has USB-A x2 and USB-C x2 connectors.
I will use this in my enclosure. My system board that holds the P2D2 already has the USB connector on board and a USB connector cutout ideally suited for that purpose. I won't be able to access the P2D2 USB port otherwise, as there is no room for another internal cable from the P2D2 USB connector, so I intend to route the USB D+/D- signals via these pins from my system board.
Though I may also need to strap VBUS perhaps? Or should that be added too?
Update: It may or may not be useful for your P2LAB board, though it could be to simplify cable management if you don't want to have cables coming in at different levels. Also when the WROOM32 Wifi module is fitted and it's antenna overhangs the P2D2, plugging in the P2D2's own USB cable connector will become a little harder, but thankfully still possible.
Echoing AJL's and Roy Eltham's comments: please, there are too many ways to achieve cable down/up-side positioning detection, so, please, don't let pins B6/7 unconnected.
Smart pins are so flexible, they deserve the right to reach everywhere. The same as good news, in these times of crisis!
Do you think it will be possible to have some pin pad & holes for the P2D2 EFM UB3 chip's USB D+/D- signals exposed can that pass through to a system board that carries the P2D2? I mean such that there can be some real pins added (not just soldered jumper wires) that can connect through between boards, just as all the left and right connector pins pins currently do. Standard 0.1 inch spacing would be easiest though we could resort to pogo pins perhaps if their distances are fully specified for PCB layout.
Is this going to be possible so the P2D2 is still removable/replaceable if and when required yet the USB signals can be passed through from another system board's USB connector? I could imagine this capability might also be rather helpful for your P2LAB board too.
If you wanted to remove a standard sub-board, it would be simplest to just unplug a USB connector ? - ie have a short USB cable as the link if one was required to a hosts USB.
More likely, is for the host to use the USB, and then to connect to P2 via serial, or for the host to not be USB at all, but WiFi or Ethernet ?
An alternative would be uncommitted 0.1" pins added to the 40 pins (tho that then makes them a bit 'non standard') and that would allow simple hand-wired-semi-customize to create a still plug-able board,.
Such uncommitted 0.1" pins can be generally useful for other semi-custom uses too.
If you wanted to remove a standard sub-board, it would be simplest to just unplug a USB connector ? - ie have a short USB cable as the link if one was required to a hosts USB.
More likely, is for the host to use the USB, and then to connect to P2 via serial, or for the host to not be USB at all, but WiFi or Ethernet ?
An alternative would be uncommitted 0.1" pins added to the 40 pins (tho that then makes them a bit 'non standard') and that would allow simple hand-wired-semi-customize to create a still plug-able board,.
Such uncommitted 0.1" pins can be generally useful for other semi-custom uses too.
If I could just use an internal USB cable patch connector I would, but there's no room for this in my enclosure (it's only 10cmx10cm and a couple of cm deep). Breaking out the USB programming signals to optional pads/holes is far more convenient for a clean installation and some people might prefer things this way if they intend to use the P2D2 inside their own product. The USB port on the P2D2 might not be physically accessible otherwise.
Also jmg, in my case this is not for the host on the system board to talk to the P2D2, it is only a programming port extension purely for the P2D2 (which is the main processor).
I think that diagram with B6 B7 missing was purely for HDMI pin mapping but that has nothing to do with A6/B6 & A7/B7 pairs which will always be cross connected.
@rogloh - ok, I get where you are coming from - or more correctly wanting to go to
If I could just use an internal USB cable patch connector I would, but there's no room for this in my enclosure (it's only 10cmx10cm and a couple of cm deep).
Breaking out the USB programming signals to optional pads/holes is far more convenient for a clean installation and some people might prefer things this way if they intend to use the P2D2 inside their own product. The USB port on the P2D2 might not be physically accessible otherwise.
Also jmg, in my case this is not for the host on the system board to talk to the P2D2, it is only a programming port extension purely for the P2D2 (which is the main processor).
btw - you can connect directly to P63 and P62 because not only is P63 fed by a 220R resistor from the UB3, but the UB3 also floats its tx if it is not connected to USB. But obviously if you bypassed it then you wouldn't have the features although I will be making a USB serial "component" which is basically this circuitry and since it includes I2C pins, I will also have the RTC on there. Might be useful in other projects.
Hmm, if I just strap VBUS high, does that mean that the serial output remains driven by the UB3 (and therefore preventing Wifi use) or does UB3 USB also need to be truly connected to a real PC & its USB endpoint fully attached/configured etc for the serial output to be enabled? Hoping the latter is true and it is not based on sensing 5V at VBUS.
UB3 is powered from a local 3.3V supply so doesn't need VBUS for power.Even if the serial output was driven, which it won't be, there is still a resistor there anyway.
FWIW I have used 0.05" pins and shunts. While they are not that readily available they can be had. They are really nice when you need low profile jumpers. You can even cheat and slide the spacer and after soldering, remove the spacer and cut the excess pins. I've also done this for low profile 0.1" pins and shunts.
.. or does UB3 USB also need to be truly connected to a real PC & its USB endpoint fully attached/configured etc for the serial output to be enabled? Hoping the latter is true and it is not based on sensing 5V at VBUS.
Yes, VBUS is ignored in the SiLabs firmware, and UB3.TX floats with light pullup until USB PC-Terminal-connects, then releases the CMOS drive on terminal disconnect.
.. or does UB3 USB also need to be truly connected to a real PC & its USB endpoint fully attached/configured etc for the serial output to be enabled? Hoping the latter is true and it is not based on sensing 5V at VBUS.
Yes, VBUS is ignored in the SiLabs firmware, and UB3.TX floats with light pullup until USB PC-Terminal-connects, then releases the CMOS drive on terminal disconnect.
I'm really impressed with what Peter has done. I really want one, and now I understand why they are the price they are. I would love to see Parallax manufacture these rather than the P2 Eval that is quite expensive and can be replace with a "matrix board" that peter talked about or a simple adapter plate.
And then the P2Pal is quite neat.
The way he figured out the USB2Serial bridge is quite excellent as well.
I am very sorry to have missed this presentation. Well done!
I do like your basic concept of layering the boards. I like it a lot.
Sure I was aware that I need to put the P2D2 upside down on my own board with pins on it, makes sense mounting-wise and - well - comes from down under and feels better upside down here. All of this makes sense and I actually expected it.
But to smd mount your other boards on the back of the P2D2 is absolutely smart. I love it.
I am not a big fan of the PI either, but I think the additional headers for the PI are nice and if one does not need them one can cut them off. Same for the option to do this castillation(?) thing to just solder it instead of using headers.
If I followed right you have all components on one side, but optional SD on the back for better access as the SD on top. Also a very nice decision.
Your UB3 replacement for FTDI is something Parallax should adapt for all of them Boards, even P1 ones. I still hate Parallax decision to put USB on all boards but disallow you to use them with a PropPlug or from another micro serial, or even just plug the USB into a PC or unplug it without reset.
You solved both problems nicely with powering internally (to prevent parasitic power up while sending to the USB w/o connection) AND tri-state so one can use the serial pins manually. REALLY well done
This USB thing hunts me since Parallax stopped to build the Project Boards w/o USB. After I run out of them I had to cut traces to reset and put jumpers there, tedious and error prone process.
I got a big smile on my face as you said that the P2LAB has pins for two P2D2, one for development and one for the 'target'. Yes, I really like that.
so THANK YOU for all the work you are putting in there, this is by far the best way to go and Parallax should mass produce them like they did with the flip.
And NO Chip and Ken, not a - most cheap version - what is needed is a - most useful one - so even if there is a need to reduce the BOM of P2D2 i would strongly disagree. It is good as it is. UB3, SD, Flash, RTC, maybe even Hyper Ram should be in the Standard Parallax P2 Module.
It is smaller than a Stamp and has way more punch.
I love Peter's vision of P2 as a platform for hosting a P2. The P2 is powerful enough with some external ram to do the Spin2 development in the P2 itself, and to load up another prop.
It actually seems a little disjointed to me that Chip is doing the spin2 compiler in 386 assembly rather than in P2 assembly, especially since he has dreamed about a self hosting system as well.
Just think of how much less hassle there would be if your development environment was just delivered as a microSD image like the raspberry pi has, and rely on readily available terminal software for the interface. 8Mbit is fast enough to even to load and save files, which many terminal emulators have built in already, and what isn't can be done quite easily while leaving the heavy lifting on the prop itself.
The self-hosting system would have a standard monitor and USB keyboard/mouse although I think we should be able to get Bluetooth keyboard/mouse to work with the ESP32. One of the problems with a self-hosting system is that if you are developing and testing the underlying host operating system itself, this could be a problem, although you could also have the "BIOS" give you a multi-boot selection menu.
But imagine this P2PC, a 170x120x60mm box that is your P2 computer + extra P2 target development system. connect FHD monitors especially with the HyperRAM option for 16-bit color and with dual full size SD card slots, WiFi, Bluetooth, serial, I2C, plus USB/Bluetooth keyboard/mouse, A/V, USB, USB-C (HDMI, VGA), WiFi, Bluetooth, LAN, mikroBUS, and headers for matrix or custom boards. Plug in your HDMI monitor via a compact passive USB-C to HDMI cable but don't plug in your Bluetooth keyboard/mouse! Use a USB-C charger to power it or supply external 5..24VDC power.
I just did a 1,000 piece bom only costing on the P2D2 and at that quantity the P2 is the main cost while the paneled pcb (2oz enig), chips, sockets and other parts including the dual 2A IMSMPS chip all costing less than the P2 chip itself. Adding the RTC+CAP+Clock Gen is only another $3.12. Unless there was a very good reason for it, I'd make those "extras" a standard feature.
p.s of course - the whole P2PC itself is a hardware configurable and dedicated controller, maybe with just a 7" touchscreen mounted on top.
None of the components are smaller than 0603 and are readily available. Of course there are assembly costs and testing, yields, packaging, shipping, overheads, taxes, and margins etc to be factored in but it has to be a much cheaper board to manufacture than the P2EVAL which really by its form factor was designed as a bench tool to evaluate and test the P2 chip itself rather than build into a product.
Very interesting talk Peter, thank you; the P2D2 looks attractive to both hobbyists like myself and for small to medium runs of commercial products. Sounds like you've got plenty of offers of support for manufacture when you're ready, too, which is good news.
The self-hosting system would have a standard monitor and USB keyboard/mouse although I think we should be able to get Bluetooth keyboard/mouse to work with the ESP32. One of the problems with a self-hosting system is that if you are developing and testing the underlying host operating system itself, this could be a problem, although you could also have the "BIOS" give you a multi-boot selection menu.
But imagine this P2PC, a 170x120x60mm box that is your P2 computer + extra P2 target development system. connect FHD monitors especially with the HyperRAM option for 16-bit color and with dual full size SD card slots, WiFi, Bluetooth, serial, I2C, plus USB/Bluetooth keyboard/mouse, A/V, USB, USB-C (HDMI, VGA), WiFi, Bluetooth, LAN, mikroBUS, and headers for matrix or custom boards. Plug in your HDMI monitor via a compact passive USB-C to HDMI cable but don't plug in your Bluetooth keyboard/mouse! Use a USB-C charger to power it or supply external 5..24VDC power.
I just did a 1,000 piece bom only costing on the P2D2 and at that quantity the P2 is the main cost while the paneled pcb (2oz enig), chips, sockets and other parts including the dual 2A IMSMPS chip all costing less than the P2 chip itself. Adding the RTC+CAP+Clock Gen is only another $3.12. Unless there was a very good reason for it, I'd make those "extras" a standard feature.
p.s of course - the whole P2PC itself is a hardware configurable and dedicated controller, maybe with just a 7" touchscreen mounted on top.
None of the components are smaller than 0603 and are readily available. Of course there are assembly costs and testing, yields, packaging, shipping, overheads, taxes, and margins etc to be factored in but it has to be a much cheaper board to manufacture than the P2EVAL which really by its form factor was designed as a bench tool to evaluate and test the P2 chip itself rather than build into a product.
The self hosting is a totally reasonable proposition, and for the most part it works on P1 with some extras. Let me explain.
My P1 RamBlade has a 512KB SRAM directly interfaced to the pins, and together with the 64KB EEPROM and microSD card, takes 30 pins. This leaves 2 free pins, which can be configured for either serial (or USB via an interface chip or software which Brad has mostly working) or a pair of 1-pin interfaces which I wrote to support 1-pin composite TV and 1-pin PS2 Keyboard (yes, you can use a standard PS2 keyboard in 1-pin input mode!).
On top of this configuration I run my P1 OS which boots from a FAT32 (FAT16 also works) using a bootloader programmed into the EEPROM. This OS supports either the serial or 1-pin pairs. Only a single BIOS style file changes to support either the serial or 1-pin terminals. It would be a simple matter to allow this to be changed on the fly.
This configuration can also run Catalina C giving it the full 512KB of XMM memory space.
It also runs CPM2.2 and the Z80 emulation ZiCog. You can run this from the OS, and at the end, return to the OS. The OS provides programs (OS commands) to copy files to and from the CPM disk emulation files on the SD card. So now you can copy a source file from FAT32 to CPM, run CPM, edit the file with Wordstar or Vedit, and then return to the OS and copy the edited file back to the OS. I have taken Michael Parks sphinx compiler and made it work under the OS, so now you can compile your P1 spin/pasm code to a binary on the SD card. This sphinx converted compiler hasn't been largely tested, but I have proved the basics work.
This all works on P1 now, and has done for many years. P2 has 512KB internal hub, and more pins. There is no reason this will not work. BTW I am well on the way to realising this - the P2 OS is basically running, CPM2.2 is also basically running, and of course we can boot directly to the SD (FAT32).
We just need an editor which the micropython guys seem to have, and then the P2 hosted compiler.
Hey @"Peter Jakacki"
And NO Chip and Ken, not a - most cheap version - what is needed is a - most useful one - so even if there is a need to reduce the BOM of P2D2 i would strongly disagree. It is good as it is. UB3, SD, Flash, RTC, maybe even Hyper Ram should be in the Standard Parallax P2 Module.
I somewhat agree here. When we had the P1 Demo board, we had known config for VGA, Keyboard, Mouse, and the community kind of developed a standard way to attach an SD card. Since there was this standard, we shared precompiled images that just worked on the Demo board, and that was fun to see what the propeller could do, and also to show off. This time around, there is enough power in the P2 to do a complete development system like many of used in the 1980's without fear of virus's, downloading gigabytes of development platform, multi-platform and multi-version headaches. The only thing missing is some fairly fast and big enough(whatever that means) RAM. What makes sense to me, economically is to take what peter has done already with the P2D2 and mass produce it, and provide a Demo/Host/Lab board to plug it into, and build the ecosystem around that and reward Peter handsomely for his awesome efforts.
I would love to see what Peter, Ken and Chip think about that as I don't know the economics and the viability of this.
The self-hosting system would have a standard monitor and USB keyboard/mouse although I think we should be able to get Bluetooth keyboard/mouse to work with the ESP32. One of the problems with a self-hosting system is that if you are developing and testing the underlying host operating system itself, this could be a problem, although you could also have the "BIOS" give you a multi-boot selection menu.
But imagine this P2PC, a 170x120x60mm box that is your P2 computer + extra P2 target development system. connect FHD monitors especially with the HyperRAM option for 16-bit color and with dual full size SD card slots, WiFi, Bluetooth, serial, I2C, plus USB/Bluetooth keyboard/mouse, A/V, USB, USB-C (HDMI, VGA), WiFi, Bluetooth, LAN, mikroBUS, and headers for matrix or custom boards. Plug in your HDMI monitor via a compact passive USB-C to HDMI cable but don't plug in your Bluetooth keyboard/mouse! Use a USB-C charger to power it or supply external 5..24VDC power.
I just did a 1,000 piece bom only costing on the P2D2 and at that quantity the P2 is the main cost while the paneled pcb (2oz enig), chips, sockets and other parts including the dual 2A IMSMPS chip all costing less than the P2 chip itself. Adding the RTC+CAP+Clock Gen is only another $3.12. Unless there was a very good reason for it, I'd make those "extras" a standard feature.
p.s of course - the whole P2PC itself is a hardware configurable and dedicated controller, maybe with just a 7" touchscreen mounted on top.
None of the components are smaller than 0603 and are readily available. Of course there are assembly costs and testing, yields, packaging, shipping, overheads, taxes, and margins etc to be factored in but it has to be a much cheaper board to manufacture than the P2EVAL which really by its form factor was designed as a bench tool to evaluate and test the P2 chip itself rather than build into a product.
The advantage of a self hosting system is size and cost. I was thinking of something a little bigger than the P1 demo board being just a baseboard with all of the connectors (VGA/HDMI, USB serial A/V etc) and ram and ESP32, that the P2D2 plugs into. I don't see the need for an enclosure, or the need to have a target system in the enclosure. Can't you just hang the target off of 5 wires; +5v, GND, TX, RX and RST? For the tinkerer like me, without a lot of budget, getting a self hosting system would be quite nice as long as in the end you can free up enough cogs, mem, and pins to be useful to get started in programming on the prop and be the best supported dev platform. The thing about getting all of that(basically everything from P2Lab and P2Pal) built into the baseboard that is not already on the P2D2 for a 2 board solution, rather than a 3 board solution (or 4 boards including a 2nd P2D2), is that it likely can be manufactured cheaper. Whatever gets done, I hope Parallax adopts it as their standard demoboard or somesuch and someone manufactures them in large quantities.
I'm certainly not against USB-C connections for external VGA/HDMI/Ethernet if there are full opensource drivers. Binary blobs defeat the purpose of having a fully controllable system.
Anyways, Peter, thanks for your genius. You got me dreaming of little hardware again.
At least two MikroBUS sockets are on the board and the second P2D2 could be any pcb or plug-in matrix board for prototyping. The P2PAL is not really a board in that it is an optional layer for the P2D2. Sure, the P2D2 could be made 4 layer and the exact same P2PAL could be part of it but having an optional layer than can be "glued" on has advantages.
The enclosure is entirely optional, it's just that so often pcbs are designed without any regard for mounting into an enclosure and to have connector access that is practical. Take the RPi for instance with connectors coming out all sides or the P2 EVAL. Just not practical. The fact is that you can operate the P2LAB on the bench as a bare and vulnerable pcb or build it into a mountable ots ABS enclosure and leave it running in the field. The way the pcb has been designed also makes it easy to customize the enclosure easily with hand tools if required.
USB-C is a connector standard, the HDMI signals do not require special drivers, it is just using the USB-C pins for HDMI signals which has a standard pinout and passive cables are readily available. I've used these on NUCs. Because smartpins will be driving it I can see that it could become a very general purpose connector and I will have a tiny USB-C to VGA dongle pcb as well so all I need for VGA is the USB-C cable running up to the monitor and this little passive dongle which plugs directly into the monitor. No need for bulky VGA cables and connectors. To facilitate HDMI I will produce a similar dongle as well.
I am not trying to stop anyone using source code for drivers, but neither are they being forced to if you have "ROMS" that have a standard API. Think of DLLs and library functions, you don't always have the source for those yet we use them.
I don't care much for the P2Eval. It is way too big, way to expensive, especially by the time I add the connectors I want, and way to configurable for what I want, which is a platform standard. Look at how many games that were produced for the Commodore64. They all just worked because we all had the same basic standard(mostly). I had a C=128, so i could just GO64 and I was in C=64 mode. I really like that idea, especially for teaching hardware, software, etc, without all of the complicated baggage that the RasPi carries an with the ability to efficiently wiggle those smartpins. The 8-bit guy has some similar deams, but I don't understand the desire for the limitation of 16 bits or external chips for video, and over complicated limitations. All of that can be done in the P2 and then some, or even just a pair of P1's or a P1 and a 6516. The advantage of the Commander16's design is that has 6502 or 65816 assembly language that is really easy to understand, but that is what BASIC is for, IMHO.
The advantage of the Commander16's design is that has 6502 or 65816 assembly language that is really easy to understand, but that is what BASIC is for, IMHO.
Since when does 65816 ASM qualify as easy-to-understand? Even 6502 isn't as nice as PASM, IMO.
@Wuerfel_21 You have a point. It's the 6502 that is really simple, so there aren't that many instructions to remember, and some of us grew up with it. I don't know if the 65816 is as close to as simple as the 6502.
However, because it was so simple, doing anything in 6502 took many instructions, that on the P2 would only take a few with it's richer instruction set and "registers".
There also is the nostalgia factor that the 8-bit guy is hung up on also.
I just want a good dev environment NOT dependent on some other platform, like PC/Mac/Linux. Multi-language is nice, but give me TAQOZ a microSD, VGA, keyboard, mouse, audio and a boot flash, and some spare pins, and I'm good. You ad a 32MB HyperRAM module to it, and wow! We could do so much with that. It would be SOOO cool if Chip actually did all of his propeller tool on P2 assembly or spin2. Need a GUI on PC/Mac/Linux/Android/iOS? Just run a Python/Tk interpreter for the interface that is already cross platform, and drive it from commands from the P2 or visa versa. The trick is to get the heavy lifting done on the P2 itself while letting just the GUI be a cross-platform script, and the actual compiler assembler and loader (for loading another P2 or the current one) done from the TAQOZ command line.
Comments
BTW, this pcb is not the very latest but it is very close to the final.
Do you think it will be possible to have some pin pad & holes for the P2D2 EFM UB3 chip's USB D+/D- signals exposed can that pass through to a system board that carries the P2D2? I mean such that there can be some real pins added (not just soldered jumper wires) that can connect through between boards, just as all the left and right connector pins pins currently do. Standard 0.1 inch spacing would be easiest though we could resort to pogo pins perhaps if their distances are fully specified for PCB layout.
Is this going to be possible so the P2D2 is still removable/replaceable if and when required yet the USB signals can be passed through from another system board's USB connector? I could imagine this capability might also be rather helpful for your P2LAB board too.
What are you thinking you could use this for bearing in mind that the P2LAB has USB-A x2 and USB-C x2 connectors.
Though I may also need to strap VBUS perhaps? Or should that be added too?
Update: It may or may not be useful for your P2LAB board, though it could be to simplify cable management if you don't want to have cables coming in at different levels. Also when the WROOM32 Wifi module is fitted and it's antenna overhangs the P2D2, plugging in the P2D2's own USB cable connector will become a little harder, but thankfully still possible.
Echoing AJL's and Roy Eltham's comments: please, there are too many ways to achieve cable down/up-side positioning detection, so, please, don't let pins B6/7 unconnected.
Smart pins are so flexible, they deserve the right to reach everywhere. The same as good news, in these times of crisis!
Henrique
If you wanted to remove a standard sub-board, it would be simplest to just unplug a USB connector ? - ie have a short USB cable as the link if one was required to a hosts USB.
More likely, is for the host to use the USB, and then to connect to P2 via serial, or for the host to not be USB at all, but WiFi or Ethernet ?
An alternative would be uncommitted 0.1" pins added to the 40 pins (tho that then makes them a bit 'non standard') and that would allow simple hand-wired-semi-customize to create a still plug-able board,.
Such uncommitted 0.1" pins can be generally useful for other semi-custom uses too.
If I could just use an internal USB cable patch connector I would, but there's no room for this in my enclosure (it's only 10cmx10cm and a couple of cm deep). Breaking out the USB programming signals to optional pads/holes is far more convenient for a clean installation and some people might prefer things this way if they intend to use the P2D2 inside their own product. The USB port on the P2D2 might not be physically accessible otherwise.
Also jmg, in my case this is not for the host on the system board to talk to the P2D2, it is only a programming port extension purely for the P2D2 (which is the main processor).
@rogloh - ok, I get where you are coming from - or more correctly wanting to go to
Yes, that's what my second suggestion does.
@jmg, no room for 90 degree cable, P2D2 USB socket will basically be occluded
Yes, VBUS is ignored in the SiLabs firmware, and UB3.TX floats with light pullup until USB PC-Terminal-connects, then releases the CMOS drive on terminal disconnect.
I'm really impressed with what Peter has done. I really want one, and now I understand why they are the price they are. I would love to see Parallax manufacture these rather than the P2 Eval that is quite expensive and can be replace with a "matrix board" that peter talked about or a simple adapter plate.
And then the P2Pal is quite neat.
The way he figured out the USB2Serial bridge is quite excellent as well.
Great job Peter!
I am very sorry to have missed this presentation. Well done!
I do like your basic concept of layering the boards. I like it a lot.
Sure I was aware that I need to put the P2D2 upside down on my own board with pins on it, makes sense mounting-wise and - well - comes from down under and feels better upside down here. All of this makes sense and I actually expected it.
But to smd mount your other boards on the back of the P2D2 is absolutely smart. I love it.
I am not a big fan of the PI either, but I think the additional headers for the PI are nice and if one does not need them one can cut them off. Same for the option to do this castillation(?) thing to just solder it instead of using headers.
If I followed right you have all components on one side, but optional SD on the back for better access as the SD on top. Also a very nice decision.
Your UB3 replacement for FTDI is something Parallax should adapt for all of them Boards, even P1 ones. I still hate Parallax decision to put USB on all boards but disallow you to use them with a PropPlug or from another micro serial, or even just plug the USB into a PC or unplug it without reset.
You solved both problems nicely with powering internally (to prevent parasitic power up while sending to the USB w/o connection) AND tri-state so one can use the serial pins manually. REALLY well done
This USB thing hunts me since Parallax stopped to build the Project Boards w/o USB. After I run out of them I had to cut traces to reset and put jumpers there, tedious and error prone process.
I got a big smile on my face as you said that the P2LAB has pins for two P2D2, one for development and one for the 'target'. Yes, I really like that.
so THANK YOU for all the work you are putting in there, this is by far the best way to go and Parallax should mass produce them like they did with the flip.
And NO Chip and Ken, not a - most cheap version - what is needed is a - most useful one - so even if there is a need to reduce the BOM of P2D2 i would strongly disagree. It is good as it is. UB3, SD, Flash, RTC, maybe even Hyper Ram should be in the Standard Parallax P2 Module.
It is smaller than a Stamp and has way more punch.
Mike
It actually seems a little disjointed to me that Chip is doing the spin2 compiler in 386 assembly rather than in P2 assembly, especially since he has dreamed about a self hosting system as well.
Just think of how much less hassle there would be if your development environment was just delivered as a microSD image like the raspberry pi has, and rely on readily available terminal software for the interface. 8Mbit is fast enough to even to load and save files, which many terminal emulators have built in already, and what isn't can be done quite easily while leaving the heavy lifting on the prop itself.
Just my 2 gwei worth.
But imagine this P2PC, a 170x120x60mm box that is your P2 computer + extra P2 target development system. connect FHD monitors especially with the HyperRAM option for 16-bit color and with dual full size SD card slots, WiFi, Bluetooth, serial, I2C, plus USB/Bluetooth keyboard/mouse, A/V, USB, USB-C (HDMI, VGA), WiFi, Bluetooth, LAN, mikroBUS, and headers for matrix or custom boards. Plug in your HDMI monitor via a compact passive USB-C to HDMI cable but don't plug in your Bluetooth keyboard/mouse! Use a USB-C charger to power it or supply external 5..24VDC power.
I just did a 1,000 piece bom only costing on the P2D2 and at that quantity the P2 is the main cost while the paneled pcb (2oz enig), chips, sockets and other parts including the dual 2A IMSMPS chip all costing less than the P2 chip itself. Adding the RTC+CAP+Clock Gen is only another $3.12. Unless there was a very good reason for it, I'd make those "extras" a standard feature.
p.s of course - the whole P2PC itself is a hardware configurable and dedicated controller, maybe with just a 7" touchscreen mounted on top.
None of the components are smaller than 0603 and are readily available. Of course there are assembly costs and testing, yields, packaging, shipping, overheads, taxes, and margins etc to be factored in but it has to be a much cheaper board to manufacture than the P2EVAL which really by its form factor was designed as a bench tool to evaluate and test the P2 chip itself rather than build into a product.
The self hosting is a totally reasonable proposition, and for the most part it works on P1 with some extras. Let me explain.
My P1 RamBlade has a 512KB SRAM directly interfaced to the pins, and together with the 64KB EEPROM and microSD card, takes 30 pins. This leaves 2 free pins, which can be configured for either serial (or USB via an interface chip or software which Brad has mostly working) or a pair of 1-pin interfaces which I wrote to support 1-pin composite TV and 1-pin PS2 Keyboard (yes, you can use a standard PS2 keyboard in 1-pin input mode!).
On top of this configuration I run my P1 OS which boots from a FAT32 (FAT16 also works) using a bootloader programmed into the EEPROM. This OS supports either the serial or 1-pin pairs. Only a single BIOS style file changes to support either the serial or 1-pin terminals. It would be a simple matter to allow this to be changed on the fly.
This configuration can also run Catalina C giving it the full 512KB of XMM memory space.
It also runs CPM2.2 and the Z80 emulation ZiCog. You can run this from the OS, and at the end, return to the OS. The OS provides programs (OS commands) to copy files to and from the CPM disk emulation files on the SD card. So now you can copy a source file from FAT32 to CPM, run CPM, edit the file with Wordstar or Vedit, and then return to the OS and copy the edited file back to the OS. I have taken Michael Parks sphinx compiler and made it work under the OS, so now you can compile your P1 spin/pasm code to a binary on the SD card. This sphinx converted compiler hasn't been largely tested, but I have proved the basics work.
This all works on P1 now, and has done for many years. P2 has 512KB internal hub, and more pins. There is no reason this will not work. BTW I am well on the way to realising this - the P2 OS is basically running, CPM2.2 is also basically running, and of course we can boot directly to the SD (FAT32).
We just need an editor which the micropython guys seem to have, and then the P2 hosted compiler.
I would love to see what Peter, Ken and Chip think about that as I don't know the economics and the viability of this.
The advantage of a self hosting system is size and cost. I was thinking of something a little bigger than the P1 demo board being just a baseboard with all of the connectors (VGA/HDMI, USB serial A/V etc) and ram and ESP32, that the P2D2 plugs into. I don't see the need for an enclosure, or the need to have a target system in the enclosure. Can't you just hang the target off of 5 wires; +5v, GND, TX, RX and RST? For the tinkerer like me, without a lot of budget, getting a self hosting system would be quite nice as long as in the end you can free up enough cogs, mem, and pins to be useful to get started in programming on the prop and be the best supported dev platform. The thing about getting all of that(basically everything from P2Lab and P2Pal) built into the baseboard that is not already on the P2D2 for a 2 board solution, rather than a 3 board solution (or 4 boards including a 2nd P2D2), is that it likely can be manufactured cheaper. Whatever gets done, I hope Parallax adopts it as their standard demoboard or somesuch and someone manufactures them in large quantities.
I'm certainly not against USB-C connections for external VGA/HDMI/Ethernet if there are full opensource drivers. Binary blobs defeat the purpose of having a fully controllable system.
Anyways, Peter, thanks for your genius. You got me dreaming of little hardware again.
The enclosure is entirely optional, it's just that so often pcbs are designed without any regard for mounting into an enclosure and to have connector access that is practical. Take the RPi for instance with connectors coming out all sides or the P2 EVAL. Just not practical. The fact is that you can operate the P2LAB on the bench as a bare and vulnerable pcb or build it into a mountable ots ABS enclosure and leave it running in the field. The way the pcb has been designed also makes it easy to customize the enclosure easily with hand tools if required.
USB-C is a connector standard, the HDMI signals do not require special drivers, it is just using the USB-C pins for HDMI signals which has a standard pinout and passive cables are readily available. I've used these on NUCs. Because smartpins will be driving it I can see that it could become a very general purpose connector and I will have a tiny USB-C to VGA dongle pcb as well so all I need for VGA is the USB-C cable running up to the monitor and this little passive dongle which plugs directly into the monitor. No need for bulky VGA cables and connectors. To facilitate HDMI I will produce a similar dongle as well.
I am not trying to stop anyone using source code for drivers, but neither are they being forced to if you have "ROMS" that have a standard API. Think of DLLs and library functions, you don't always have the source for those yet we use them.
However, because it was so simple, doing anything in 6502 took many instructions, that on the P2 would only take a few with it's richer instruction set and "registers".
There also is the nostalgia factor that the 8-bit guy is hung up on also.
I just want a good dev environment NOT dependent on some other platform, like PC/Mac/Linux. Multi-language is nice, but give me TAQOZ a microSD, VGA, keyboard, mouse, audio and a boot flash, and some spare pins, and I'm good. You ad a 32MB HyperRAM module to it, and wow! We could do so much with that. It would be SOOO cool if Chip actually did all of his propeller tool on P2 assembly or spin2. Need a GUI on PC/Mac/Linux/Android/iOS? Just run a Python/Tk interpreter for the interface that is already cross platform, and drive it from commands from the P2 or visa versa. The trick is to get the heavy lifting done on the P2 itself while letting just the GUI be a cross-platform script, and the actual compiler assembler and loader (for loading another P2 or the current one) done from the TAQOZ command line.