@hinv - just as soon as I get past getting all this new hardware up and running I intend to update TAQOZ with the editor and standalone functions. I think I can make the interactive assembler handle PASM only files too since the format is closely compatible and perhaps write a Spin compiler in TAQOZ
The new P2PAL board has been redone and has a USB-C connector on it in place of the XMC chip and has 10 I/O connected to it so I will also have USB-C <--> USB-C adapter dongles for HDMI or VGA etc. The idea is to plug the adapter dongle into the monitor and connect with a standard USB-C cable straight from the P2D2 itself, even without the P2LAB dev board. I think the adapter dongle could have a USB-A connector to host a keyboard but maybe the ESP32 BT can handle wireless keyboard and mouse directly.
USB-C sounds like a convenient option for users Peter instead of the unknown XMC part that was there previously. I take it that it is still optional and can just be left off it you need full use of port A? Is there an updated schematic of your latest P2PAL board connections available?
USB-C sounds like a convenient option for users Peter instead of the unknown XMC part that was there previously. I take it that it is still optional and can just be left off it you need full use of port A? Is there an updated schematic of your latest P2PAL board connections available?
The XMC was just a filler that I could use for some tests myself otherwise it would have been unused pcb space. After a big fight with Protel database I think I have managed to get my files back again and these are the latest. Perhaps you can check them to see if I have catered for the main options. I know I need to do something for HyperFlash still but I have to check what that was. Do you think that the BGA pads are big enough? They look way too small.
btw, I intend to have this fabricated in 0.8mm thickness which is half the normal pcb but the same as the ESP32 and other smd modules.
Thanks for posting the files Peter, here's some feedback from me.
Regarding the HyperFlash/HyperRAM:
I don't have knowledge about suitable BGA pad sizes, but maybe someone who does use these footprints can jump in...?
For using regular HyperFlash (either standalone or when integrated in the combo MCP package with HyperRAM) it will be required to connect a different CS pin on device pad C2. This gets tricky.
For a standalone HyperRAM device's CS signal you need to use device pad A3. Pad C2 on these parts is RFU (reserved for future use).
For a standalone HyperFlash device's CS signal you need to use device pad C2. Pad A3 on these parts is DNU (do not use).
For the special combo HyperFlash+HyperRAM package with two CS signals, you need to use both of these pads.
You currently have P2D2 P41 as the CS wired to A3 and P43 for the WS2812B. This is all good for just running with HyperRAM and your RGB LED. However if you wish to also support HyperFlash instead of HyperRAM, you could probably consider using a tiny 2 way (3 pad) solder jumper placed at the head of the arrow in the diagram I posted. Middle of the solder jumper is P41, two outer edges of the jumper go to A3 (default) and C2 pads respectively, and you'd just solder short one of these two solder positions depending on which device is fitted on the board. The RAM pin might be selected by default as it's probably more likely the one to fit/use.
To support both CS pins for the combo Hyper package you still may be able to use P43 for this purpose if you have another jumper which also goes to pad C2 as well as the WS2812B. Then you would essentially strap P41 to A3 via the two way solder jumper and pad C2 to the P43 signal net. You would have to give up independent control of the RGBLED in this case but electrically it would not be a problem to have it connected there at the same time. The CS pin wouldn't be loaded much and any added delay from loading on the CS pin not as critical as clock/data nets anyway.
You might like to wire your RESET signal to the RESET pin of the Hyper memory device if it is still routable on your PCB. It's probably not mandatory but could still help if the latency or other settings gets changed after boot and we want to easily have it go into a known working default state consistently each time from board startup / reset button press without needing to communicate with it using the existing settings to do so in case something goes awry. It's probably still possible to restore without the RESET but you never really know. A HW reset is still a useful thing.
Regarding the USB-C which is a potential handy optional addition vs XMC. If you wire with P10-P20 you don't get a full complete 8 bit pin group usable with DVI signalling. The pins you have would allow VGA, but not an HDMI/DVI group. You could still get that if you just moved the ESP32 secondary uart signals down to within first 8 bits of port A perhaps. Ideally (for my own personal application) that secondary ESP32 uart could be on P0-P1 then I still get a 18bpp LCD possible by skipping 2 LSBs of each RGB byte, but I think I can always give up the secondary uart capabilities if the pins will float, considering the ESP32 SPI interface is available.
I don't know what other pins you may need on USB-C to remain compatible with USB-C cable wiring etc, or how much actual compatibility is required if you intend these for your own breakout use. However it appears that some of these signals will short on the heat spreading exposed copper diamond pattern under the board. Also maybe the through hole connector housing pins might cause clearance problems under the board between the mating surface of the P2PAL and P2D2?
With respect to ESP32 signals. Your latest P2PAL schematic showed a slightly different older wiring from the one in the included legend at the top that I'd think I suggested last in my PM to you. I came up with that lot to try to deal with different scenarios and I've included below, with the elaboration. What you have right now is going to work fine whenever the PSRAM is not fitted, but if you choose to follow this mapping it might allow more sharing of capabilities and solve the potential problem of the ESP32 not automatically tri-stating its HMISO when it's CS is high which would clash with the PSRAM. It also frees an even and odd P2 pin for USB use if the PSRAM is not fitted but the ESP32 SPI slave is used. This in combination with the use of VGA on P43-P47 (or P44-47 for RBGS, or P43-47 for component/RGsB), would allow a SPI slave wifi enabled setup with HyperRAM, USB, VGA and RTC, all with 32 bits of port A remaining completely free. That could be a very compelling/useful setup. The status LEDs you have on P43-P47 could still remain in parallel and shouldn't really impact the pins dual use for an optional VGA there in my view.
P55 - ESP32 EN
P54 - HMISO
P53 - SRCS (free for USB other use if PSRAM is not fitted)
P52 - SRCK (free for USB or other use if PSRAM is not fitted)
P51 - SRD3 - HSS (potentially generates PWM at ESP32 boot)
P50 - SRD2 - BOOT0 (potentially generates PWM at ESP32 boot)
P49 - SRD1 - HCLK (potentially generates PWM at ESP32 boot)
P48 - SRD0 - HMOSI
To access WIFI ESP32 SPI slave in the presence of PSRAM:
Keep PSRAM SRCS high
Drive HSS, HMOSI, HCLK, and read HMISO
To access PSRAM in the presence of ESP32 that is NOT programmed to use a SPI slave interface from P2
Drive SRCS, SRCLK, SRD0-3 (with single/dual/quad SPI all possible)
To access PSRAM in the presence of ESP32 that IS programmed to use a SPI slave interface from P2
Drive SRCS, SRCLK, SRD0-1 (either dual spi or single SPI possible, but not quad SPI in this application),
Hold HSS high to prevent access within EPS32 slave software
You know Peter, another option which might be useful as an alternative to the special USB-C connector placement on the P2PAL would be to have Parallax module compatible breakout wiring on the 8 bit port P8-P15, then people with single wide breakout modules could still easily use those devices with your board. It might also let Parallax or others continue to make available modules fully compatible with your P2D2 and the P2EVAL. You could still have the USB-C stuff fitted on your main dev board. There's possibly just enough room for this 6x2 header footprint there instead of USB-C. Maybe needs to be the surface mount type of connector that people can solder on the top surface of P2PAL if needed if the through hole affects the bottom surface clearance.
A few years ago I needed a nice display for a project that was using multiple P1s but badly needed a P2. I opted to use serial Bluetooth to a cheap 7" Android tablet and I modified a serial BT terminal program so I could write to the display in color. So effectively the tablet was a hires serial display. I figure that we can do the same for the P2 rather than worrying about memory and I/O and cogs just for the display. The P2PAL has the ESP32 which I intended to use for BT keyboards but could also communicate to the tablet via serial BT (or WiFi even) to display text and graphics. I have done some Android stuff and I have a very nice but old 10" Galaxy Tab that I can use for testing the terminal app.
I'd like to make it simple to interface to from the P2 so it would interpret text as text but allow for extended characters and commands for graphics etc. There wouldn't be any need to follow some old serial terminal emulator standard, so we could make it work well for the P2. The advantage here is that for less than $100 we can have a serial BT/WiFi screen with cap touch-screen to boot and it doesn't use up any extra I/O. Seeing Chips debugger today, we can even make it handle that too. What's also important is that no special hardware is required other than serial since you can easily add serial BT to any project. In fact I have a 4x2 or 5x1 connector with power available for my serial coms on most of my boards and with that I can plug in a HC05/06 easily.
Now here's the thing, and it may indeed call for its own thread for sure but seeing we have a low overhead keyboard/mouse/display that can turn any P2 into a "PC" in terms of hid, then perhaps this is the time to consider writing all those PC tools for the P2, to actually run on a P2 itself, thereby directly contributing to the P2 software base simply by writing the tools themselves. No longer will be be hampered by PCs and the various OSes and anti-virus viruses software. We would have a cheap P2 PC, that can devote all of its resources and memory to the compiler if it needs to, but also any humble P2 board with serial BT can have a nice hires/hicolor display.
Chip could then write in P2 assembler and Spin2 rather than 86 assembler and Delphi. Then anyone can run PNut on a P2. Why bother with wasting time developing apps for an RPi, even if it is "cheap", it still needs a display and keyboard.
btw - methinks that an ESP32 could access an online obex automatically but I'm thinking of P2 hardware that can have firmware preloaded and "ROMable" would be nice. The P2D2 has the UB3 micro that can act as a ROM even if the P2 Flash and SD were blank.
Here are images of the $70 Lenovo tablet and a $30 BT keyboard. (Australian Office supply retail prices).
A few years ago I needed a nice display for a project that was using multiple P1s but badly needed a P2. I opted to use serial Bluetooth to a cheap 7" Android tablet and I modified a serial BT terminal program so I could write to the display in color. So effectively the tablet was a hires serial display. I figure that we can do the same for the P2 rather than worrying about memory and I/O and cogs just for the display. The P2PAL has the ESP32 which I intended to use for BT keyboards but could also communicate to the tablet via serial BT (or WiFi even) to display text and graphics. I have done some Android stuff and I have a very nice but old 10" Galaxy Tab that I can use for testing the terminal app.
I'd like to make it simple to interface to from the P2 so it would interpret text as text but allow for extended characters and commands for graphics etc. There wouldn't be any need to follow some old serial terminal emulator standard, so we could make it work well for the P2. The advantage here is that for less than $100 we can have a serial BT/WiFi screen with cap touch-screen to boot and it doesn't use up any extra I/O. Seeing Chips debugger today, we can even make it handle that too. What's also important is that no special hardware is required other than serial since you can easily add serial BT to any project. In fact I have a 4x2 or 5x1 connector with power available for my serial coms on most of my boards and with that I can plug in a HC05/06 easily.
Now here's the thing, and it may indeed call for its own thread for sure but seeing we have a low overhead keyboard/mouse/display that can turn any P2 into a "PC" in terms of hid, then perhaps this is the time to consider writing all those PC tools for the P2, to actually run on a P2 itself, thereby directly contributing to the P2 software base simply by writing the tools themselves. No longer will be be hampered by PCs and the various OSes and anti-virus viruses software. We would have a cheap P2 PC, that can devote all of its resources and memory to the compiler if it needs to, but also any humble P2 board with serial BT can have a nice hires/hicolor display.
Chip could then write in P2 assembler and Spin2 rather than 86 assembler and Delphi. Then anyone can run PNut on a P2. Why bother with wasting time developing apps for an RPi, even if it is "cheap", it still needs a display and keyboard.
btw - methinks that an ESP32 could access an online obex automatically but I'm thinking of P2 hardware that can have firmware preloaded and "ROMable" would be nice. The P2D2 has the UB3 micro that can act as a ROM even if the P2 Flash and SD were blank.
Here are images of the $70 Lenovo tablet and a $30 BT keyboard. (Australian Office supply retail prices).
Agreed
There are two options here that I see as much better than the PC we currently work around...
1. A separate P2 with VGA and optional keyboard, connected serially to the P2 development board
2. The P2 development board connected serially to BT/WiFi which connects wirelessly to a tablet
Much of this code could be identical and run on the P2, so spin, pasm, C , etc. The difference would be the routines to display on the tablet would probably require some coding, and this would be equivalent to the driver needed in one cog on the separate P2. And, could also be ported to the PC too. But, the big software part will only need to be written once and run on a P2.
@DigitalBob - Yes, PayPall but only when I have boards and I have confirmed the first few work.
To all - this is the latest P2PAL layer which had quite a number of changes to the I/O to accommodate ESP32 HSPI better along with termination resistors since we may push the speed right up for faster transfers. The USB-C has also been corrected to handle HDMI signals as one byte-wide port group. So from just the tiny P2D2+ module you can plug in a USB-C cable that will then connect to a HDMI or VGA monitor with a passive USB-C->HDMI/VGA dongle stub that I will also supply. The ESP32 will allow all kinds of HID connectivity too.
@DigitalBob - Yes, PayPall but only when I have boards and I have confirmed the first few work.
To all - this is the latest P2PAL layer which had quite a number of changes to the I/O to accommodate ESP32 HSPI better along with termination resistors since we may push the speed right up for faster transfers. The USB-C has also been corrected to handle HDMI signals as one byte-wide port group. So from just the tiny P2D2+ module you can plug in a USB-C cable that will then connect to a HDMI or VGA monitor with a passive USB-C->HDMI/VGA dongle stub that I will also supply. The ESP32 will allow all kinds of HID connectivity too.
Please remind me of what those of us who have already ordered the P2D2 need to do to add the P2PAL to our orders.
What I might do with all the ones who have already paid for a P2D2 is ship it with the P2PAL as a P2D2+ that will include the ESP32, the HyperRAM, the 8MB PSRAM, uSD socket, well everything! Why not. I won't charge anything extra for this but if you feel you really want to, you can "donate" something towards the P2D2 project.
Details and pricing of the P2D2, P2PAL, P2LAB and modules in the next few days!
Once I send off the boards I will order more parts and test and upgrade the current P2D2s and send them out as samples to those I have spoken to earlier in the year.
What I might do with all the ones who have already paid for a P2D2 is ship it with the P2PAL as a P2D2+ that will include the ESP32, the HyperRAM, the 8MB PSRAM, uSD socket, well everything! Why not. I won't charge anything extra for this but if you feel you really want to, you can "donate" something towards the P2D2 project.
What I might do with all the ones who have already paid for a P2D2 is ship it with the P2PAL as a P2D2+ that will include the ESP32, the HyperRAM, the 8MB PSRAM, uSD socket, well everything! Why not. I won't charge anything extra for this but if you feel you really want to, you can "donate" something towards the P2D2 project.
Details and pricing of the P2D2, P2PAL, P2LAB and modules in the next few days!
Once I send off the boards I will order more parts and test and upgrade the current P2D2s and send them out as samples to those I have spoken to earlier in the year.
Don't worry about any of that until you get your P2D2 and if you are happy with it and to donate, then send whatever you feel or can only afford to, to my PP account as a "P2D2 PROJECT" donation. But don't feel you need to either. I will put my PP link back up again when I'm ready btw.
Don't worry about any of that until you get your P2D2 and if you are happy with it and to donate, then send whatever you feel or can only afford to, to my PP account as a "P2D2 PROJECT" donation. But don't feel you need to either. I will put my PP link back up again when I'm ready btw.
The original P2D2 document has been updated with the latest P2D2 and P2PAL details. I expect these pcbs back by the end of next week. The P2LAB and accessory modules the week after.
There were a lot of incremental enhancements to the design but it was worth it.
Here's a PDF attached but check the google doc for latest info.
Looking great Peter. It's been a long wait but this design is going to be able to offer us all so much when it's finally available. Hopefully soon you'll get your boards and they'll test out fine.
Yes, I was holding off while I tested and sorted out a few other things, but in the meantime I have made some improvements as well although they may be hard to notice, they took a bit of work.
The P2LAB and other pcbs may also include a application pcb for the SMD version of the P2D2.
Years ago I put a Prop into an extended VGA headshell that plugged directly into the back of a VGA monitor and included a USB A for a keyboard. I notice that the P2D2-SMD would fit into that headshell easily and with a very low profile so I want to do the same again with VGA and perhaps if I can find a suitable pcb mount HDMI plug, I could allow for that too.
The beauty about the P2D2 is that you have so many ways of integrating it via pin headers, RPI header, SMD mount, or just plug a USB cable straight into it and use it stand-alone.
I will pick up a couple of those HDMI plugs from Jaycar since it's easy to prototype with those ones when they are presoldered to a pcb.
So I think I definitely will do a Pixie board that plugs directly into a HDMI/VGA monitor and allows for a USB keyboard/mouse to connect directly. I wonder if I can get +5V from the monitor? If so then I can have a P2PC in a headshell!
If the Pixie pcb has smd connections on the reverse as well then I can attach the P2PAL to that so that the P2D2 is surface-mounted to the top, and the P2PAL to the bottom. Although the headshell is standard height I shouldn't have any problems fitting this in since the pcbs are very low profile.
No, usually you need to supply 5V to the monitor (to power the I2C DDC device), not draw power out of it. HDMI will provide 5V (from source side only IIRC) but it's only designed to supply to something requiring only up to 50mA I think. Typically those TV HDMI dongles have USB sockets on them to power from a TV's spare USB port. I suspect over time there will be pressure for a HDMI variant to be able to power these dongles too, or maybe that's where USB-C will start to come in. Those HDMI & DisplayPort and USB guys are all trying to one-up each other.
Years ago I put a Prop into an extended VGA headshell that plugged directly into the back of a VGA monitor and included a USB A for a keyboard. I notice that the P2D2-SMD would fit into that headshell easily and with a very low profile so I want to do the same again with VGA and perhaps if I can find a suitable pcb mount HDMI plug, I could allow for that too.
I, for one, would be interested in seeing details of this headshell with Prop1 in it!
Years ago I put a Prop into an extended VGA headshell that plugged directly into the back of a VGA monitor and included a USB A for a keyboard. I notice that the P2D2-SMD would fit into that headshell easily and with a very low profile so I want to do the same again with VGA and perhaps if I can find a suitable pcb mount HDMI plug, I could allow for that too.
I, for one, would be interested in seeing details of this headshell with Prop1 in it!
Here is a photo of a blank P1 Pixie board mounted into the headshell that plugs directly into the back of the monitor. I use monitors where the connector is facing down so this allows the Pixie to be plugged into the back and then I may have a keypad/keyboard plugged into the USB-A socket and then I have a 4-core phone cable connecting all these together for power and RS485 comms (or RS-422 with 6-core).
So the photo shows the normal Pixie and I have placed a cut down P2D2 on top of that with plenty of room to spare. The new Pixie board would have smd pads for the P2D2 and allow for a VGA or HDMI plug. I would also place smd pads under the pcb so I could attach a P2PAL as an option. No pin headers or edge connectors are needed.
A version with VGA/HDMI on one end and both a USB-A (for keyboard or USB dongle), and a USB-B or C on the other end for powering it would be good.
I wonder if there is room side by side on the left of your picture for both these USB connectors? If you can fit in the P2PAL Wifi module as well with the case lid also on, that would be really useful. Maybe a cutout on the top or bottom surface for the P2Pi pinouts or a IDE/IDC cable to protrude out for expansion too. The carrier board below the P2D2 module could have it's own USB connectors (this is why it was very good of you to bring them down through the P2D2 board with those two holes near the P2D2's own connector).
50mil 1.27mm half-pitch single row header pins and socket.
I've been chasing parts not just for the P2D2+ but also connectors etc for the P2LAB dev board. I've found 1.27mm pitch single row pin headers at a very good price and so I am ordering them. The socket which would go on the P2D2 itself is only 4.3mm deep and combined with the 1.27 wafer on the pins that puts the P2D2 around 5.6mm off the board. Not only does this make it a low-profile pluggable module but it also means we can chop the 0.1" strips off the board making it just 1.11" or just 28mm wide and very low profile at 7mm overall and add another 4mm for the P2PAL (the ESP32 is already about 3.2mm + 0.8mm for the pcb).
For prototyping on matrix board the 0.1" headers are still more useful though, but if you design a pcb for the P2D2 then you also have an option of using 50mil headers for a narrower board.
Peter,
I have 0.05" 1.27mm 1x40 male and 1x50 female. The female is 5mm socket height.
Let me know if you need any. I plan on cutting them down for my P2 boards.
Comments
The new P2PAL board has been redone and has a USB-C connector on it in place of the XMC chip and has 10 I/O connected to it so I will also have USB-C <--> USB-C adapter dongles for HDMI or VGA etc. The idea is to plug the adapter dongle into the monitor and connect with a standard USB-C cable straight from the P2D2 itself, even without the P2LAB dev board. I think the adapter dongle could have a USB-A connector to host a keyboard but maybe the ESP32 BT can handle wireless keyboard and mouse directly.
The XMC was just a filler that I could use for some tests myself otherwise it would have been unused pcb space. After a big fight with Protel database I think I have managed to get my files back again and these are the latest. Perhaps you can check them to see if I have catered for the main options. I know I need to do something for HyperFlash still but I have to check what that was. Do you think that the BGA pads are big enough? They look way too small.
btw, I intend to have this fabricated in 0.8mm thickness which is half the normal pcb but the same as the ESP32 and other smd modules.
edit: added the Protel screenshot too.
Regarding the HyperFlash/HyperRAM:
I don't have knowledge about suitable BGA pad sizes, but maybe someone who does use these footprints can jump in...?
For using regular HyperFlash (either standalone or when integrated in the combo MCP package with HyperRAM) it will be required to connect a different CS pin on device pad C2. This gets tricky.
For a standalone HyperRAM device's CS signal you need to use device pad A3. Pad C2 on these parts is RFU (reserved for future use).
For a standalone HyperFlash device's CS signal you need to use device pad C2. Pad A3 on these parts is DNU (do not use).
For the special combo HyperFlash+HyperRAM package with two CS signals, you need to use both of these pads.
You currently have P2D2 P41 as the CS wired to A3 and P43 for the WS2812B. This is all good for just running with HyperRAM and your RGB LED. However if you wish to also support HyperFlash instead of HyperRAM, you could probably consider using a tiny 2 way (3 pad) solder jumper placed at the head of the arrow in the diagram I posted. Middle of the solder jumper is P41, two outer edges of the jumper go to A3 (default) and C2 pads respectively, and you'd just solder short one of these two solder positions depending on which device is fitted on the board. The RAM pin might be selected by default as it's probably more likely the one to fit/use.
To support both CS pins for the combo Hyper package you still may be able to use P43 for this purpose if you have another jumper which also goes to pad C2 as well as the WS2812B. Then you would essentially strap P41 to A3 via the two way solder jumper and pad C2 to the P43 signal net. You would have to give up independent control of the RGBLED in this case but electrically it would not be a problem to have it connected there at the same time. The CS pin wouldn't be loaded much and any added delay from loading on the CS pin not as critical as clock/data nets anyway.
You might like to wire your RESET signal to the RESET pin of the Hyper memory device if it is still routable on your PCB. It's probably not mandatory but could still help if the latency or other settings gets changed after boot and we want to easily have it go into a known working default state consistently each time from board startup / reset button press without needing to communicate with it using the existing settings to do so in case something goes awry. It's probably still possible to restore without the RESET but you never really know. A HW reset is still a useful thing.
Regarding the USB-C which is a potential handy optional addition vs XMC. If you wire with P10-P20 you don't get a full complete 8 bit pin group usable with DVI signalling. The pins you have would allow VGA, but not an HDMI/DVI group. You could still get that if you just moved the ESP32 secondary uart signals down to within first 8 bits of port A perhaps. Ideally (for my own personal application) that secondary ESP32 uart could be on P0-P1 then I still get a 18bpp LCD possible by skipping 2 LSBs of each RGB byte, but I think I can always give up the secondary uart capabilities if the pins will float, considering the ESP32 SPI interface is available.
I don't know what other pins you may need on USB-C to remain compatible with USB-C cable wiring etc, or how much actual compatibility is required if you intend these for your own breakout use. However it appears that some of these signals will short on the heat spreading exposed copper diamond pattern under the board. Also maybe the through hole connector housing pins might cause clearance problems under the board between the mating surface of the P2PAL and P2D2?
With respect to ESP32 signals. Your latest P2PAL schematic showed a slightly different older wiring from the one in the included legend at the top that I'd think I suggested last in my PM to you. I came up with that lot to try to deal with different scenarios and I've included below, with the elaboration. What you have right now is going to work fine whenever the PSRAM is not fitted, but if you choose to follow this mapping it might allow more sharing of capabilities and solve the potential problem of the ESP32 not automatically tri-stating its HMISO when it's CS is high which would clash with the PSRAM. It also frees an even and odd P2 pin for USB use if the PSRAM is not fitted but the ESP32 SPI slave is used. This in combination with the use of VGA on P43-P47 (or P44-47 for RBGS, or P43-47 for component/RGsB), would allow a SPI slave wifi enabled setup with HyperRAM, USB, VGA and RTC, all with 32 bits of port A remaining completely free. That could be a very compelling/useful setup. The status LEDs you have on P43-P47 could still remain in parallel and shouldn't really impact the pins dual use for an optional VGA there in my view.
Cheers,
Roger
I'd like to make it simple to interface to from the P2 so it would interpret text as text but allow for extended characters and commands for graphics etc. There wouldn't be any need to follow some old serial terminal emulator standard, so we could make it work well for the P2. The advantage here is that for less than $100 we can have a serial BT/WiFi screen with cap touch-screen to boot and it doesn't use up any extra I/O. Seeing Chips debugger today, we can even make it handle that too. What's also important is that no special hardware is required other than serial since you can easily add serial BT to any project. In fact I have a 4x2 or 5x1 connector with power available for my serial coms on most of my boards and with that I can plug in a HC05/06 easily.
Now here's the thing, and it may indeed call for its own thread for sure but seeing we have a low overhead keyboard/mouse/display that can turn any P2 into a "PC" in terms of hid, then perhaps this is the time to consider writing all those PC tools for the P2, to actually run on a P2 itself, thereby directly contributing to the P2 software base simply by writing the tools themselves. No longer will be be hampered by PCs and the various OSes and anti-virus viruses software. We would have a cheap P2 PC, that can devote all of its resources and memory to the compiler if it needs to, but also any humble P2 board with serial BT can have a nice hires/hicolor display.
Chip could then write in P2 assembler and Spin2 rather than 86 assembler and Delphi. Then anyone can run PNut on a P2. Why bother with wasting time developing apps for an RPi, even if it is "cheap", it still needs a display and keyboard.
btw - methinks that an ESP32 could access an online obex automatically but I'm thinking of P2 hardware that can have firmware preloaded and "ROMable" would be nice. The P2D2 has the UB3 micro that can act as a ROM even if the P2 Flash and SD were blank.
Here are images of the $70 Lenovo tablet and a $30 BT keyboard. (Australian Office supply retail prices).
There are two options here that I see as much better than the PC we currently work around...
1. A separate P2 with VGA and optional keyboard, connected serially to the P2 development board
2. The P2 development board connected serially to BT/WiFi which connects wirelessly to a tablet
Much of this code could be identical and run on the P2, so spin, pasm, C , etc. The difference would be the routines to display on the tablet would probably require some coding, and this would be equivalent to the driver needed in one cog on the separate P2. And, could also be ported to the PC too. But, the big software part will only need to be written once and run on a P2.
To all - this is the latest P2PAL layer which had quite a number of changes to the I/O to accommodate ESP32 HSPI better along with termination resistors since we may push the speed right up for faster transfers. The USB-C has also been corrected to handle HDMI signals as one byte-wide port group. So from just the tiny P2D2+ module you can plug in a USB-C cable that will then connect to a HDMI or VGA monitor with a passive USB-C->HDMI/VGA dongle stub that I will also supply. The ESP32 will allow all kinds of HID connectivity too.
Details and pricing of the P2D2, P2PAL, P2LAB and modules in the next few days!
Once I send off the boards I will order more parts and test and upgrade the current P2D2s and send them out as samples to those I have spoken to earlier in the year.
This will be great Peter. Thank you!
That’s very generous of you! How do we ‘donate’?
Don't worry about any of that until you get your P2D2 and if you are happy with it and to donate, then send whatever you feel or can only afford to, to my PP account as a "P2D2 PROJECT" donation. But don't feel you need to either. I will put my PP link back up again when I'm ready btw.
There were a lot of incremental enhancements to the design but it was worth it.
Here's a PDF attached but check the google doc for latest info.
The P2LAB and other pcbs may also include a application pcb for the SMD version of the P2D2.
Years ago I put a Prop into an extended VGA headshell that plugged directly into the back of a VGA monitor and included a USB A for a keyboard. I notice that the P2D2-SMD would fit into that headshell easily and with a very low profile so I want to do the same again with VGA and perhaps if I can find a suitable pcb mount HDMI plug, I could allow for that too.
The beauty about the P2D2 is that you have so many ways of integrating it via pin headers, RPI header, SMD mount, or just plug a USB cable straight into it and use it stand-alone.
oddly, Jaycar have these, both full size and micro, many other regular suppliers don't. Let me know if you find other suppliers
So I think I definitely will do a Pixie board that plugs directly into a HDMI/VGA monitor and allows for a USB keyboard/mouse to connect directly. I wonder if I can get +5V from the monitor? If so then I can have a P2PC in a headshell!
If the Pixie pcb has smd connections on the reverse as well then I can attach the P2PAL to that so that the P2D2 is surface-mounted to the top, and the P2PAL to the bottom. Although the headshell is standard height I shouldn't have any problems fitting this in since the pcbs are very low profile.
I, for one, would be interested in seeing details of this headshell with Prop1 in it!
Here is a photo of a blank P1 Pixie board mounted into the headshell that plugs directly into the back of the monitor. I use monitors where the connector is facing down so this allows the Pixie to be plugged into the back and then I may have a keypad/keyboard plugged into the USB-A socket and then I have a 4-core phone cable connecting all these together for power and RS485 comms (or RS-422 with 6-core).
So the photo shows the normal Pixie and I have placed a cut down P2D2 on top of that with plenty of room to spare. The new Pixie board would have smd pads for the P2D2 and allow for a VGA or HDMI plug. I would also place smd pads under the pcb so I could attach a P2PAL as an option. No pin headers or edge connectors are needed.
A version with VGA/HDMI on one end and both a USB-A (for keyboard or USB dongle), and a USB-B or C on the other end for powering it would be good.
I wonder if there is room side by side on the left of your picture for both these USB connectors? If you can fit in the P2PAL Wifi module as well with the case lid also on, that would be really useful. Maybe a cutout on the top or bottom surface for the P2Pi pinouts or a IDE/IDC cable to protrude out for expansion too. The carrier board below the P2D2 module could have it's own USB connectors (this is why it was very good of you to bring them down through the P2D2 board with those two holes near the P2D2's own connector).
I've been chasing parts not just for the P2D2+ but also connectors etc for the P2LAB dev board. I've found 1.27mm pitch single row pin headers at a very good price and so I am ordering them. The socket which would go on the P2D2 itself is only 4.3mm deep and combined with the 1.27 wafer on the pins that puts the P2D2 around 5.6mm off the board. Not only does this make it a low-profile pluggable module but it also means we can chop the 0.1" strips off the board making it just 1.11" or just 28mm wide and very low profile at 7mm overall and add another 4mm for the P2PAL (the ESP32 is already about 3.2mm + 0.8mm for the pcb).
For prototyping on matrix board the 0.1" headers are still more useful though, but if you design a pcb for the P2D2 then you also have an option of using 50mil headers for a narrower board.
I have 0.05" 1.27mm 1x40 male and 1x50 female. The female is 5mm socket height.
Let me know if you need any. I plan on cutting them down for my P2 boards.