Boards:
P2D2 - Complete P2 system inc RTC and precision clock gen and USB serial supervisor with watchdog and smart reset etc.
P2PAL - ESP32, 16MB HyperRAM, 8MB PSRAM, 6 LEDs+RGB, microSD, USB-C for alt mode HDMI (or VGA).
P2PINS - 100mil headers inc 40-pin RPi "layer"
P2HAT - An RPi HAT with prototyping pads + connection for a P2D2 (smd or 50mil pins)
P2LAB - The P2D2 Motherlode board (mikroBUS, Ethernet, HDMI, VGA, A/V, USB, dual SD, DC, etc)
P2MAT - A general-purpose 3.75" x 2.75" 50mil matrix prototype board
P2USB - a tiny 8-pin vertical SIP USB serial module with the EFM8UB3 (watchdog, smart reset etc)
QUESTION: How many would want a P2D2+ preassembled?
What a nice shopping list ....
for me please ...
1 P2D2+PAL assembled
1 P2LAB
1 Pins
1 mat
1 USB
1 USB-C HDMI/VGA dongle ... or are those on ebay/Aliexpress?
This would make a great bundle ...
@ErNa
Maybe it is a good idea to collect the preorders at the continental distributors?
To relief Peter from handling. And just send him the summary order?
Boards:
P2D2 - Complete P2 system inc RTC and precision clock gen and USB serial supervisor with watchdog and smart reset etc.
P2PAL - ESP32, 16MB HyperRAM, 8MB PSRAM, 6 LEDs+RGB, microSD, USB-C for alt mode HDMI (or VGA).
Standalone P2D2+ for development
QUESTION: How many would want a P2D2+ preassembled?
Yeah, that's pretty much what I want. I already chipped in early. I'll chip in more, too.
What's the plan for USB-C CC signalling to negotiate altmodes? That got my ears perked, as a passive altmode hdmi / type-c dongle is pretty cheap.
I've seen some of the STM32G0 series that are suitable for CC signalling, in as small as 8SOIC. But given all the EFM8UB3 work, it's probably not something you'd want to jump on this late in the game.
I'm not interested much in the big lab board, myself.
I am a fan of the castellated/dip-alike through-hole header designs. Got a good set of STM32F411 boards from WeACT (Chinese, but they're on github) for running micropython on, I also intend to run micropython + hdmi + esp32 wifi on my P2D2+.
The P2PAL has enough on it to work out as a nice singleboard computer, now that the ESP32 ESP-IDF v4.2 has some examples for BTLE HID client and server, which takes care of figuring out cabled input devices.
I wouldn't need a type-A port for a logitech unifying dongle, or PS/2 for a wired keyboard/mouse, and I've got a couple bluetooth keyboards around already that would fit the bill.
The type-C port handling power and video will suit me very well. If I want to mess with physical devices, I'll solder on short sets of header to the pins I want (I2S for audio, or I2C or SPI for the little OLED displays I have on hand already) and ignore all the other pins.
I don't really intend on connecting any GPIO buttons or rotary encoders, and I hope all of the LEDs will be PWM dimmable; or if there's a power-good led, that it's resistor is selected well to keep it from being too blinding.
I originally was interested in the pairing with a pi-compatible SBC, but I've lost interest in that with the inclusion of the ESP32.
Please make sure you use the ESP32 module with the largest flash -- there's options for 4MiB, 8MiB, and 16MiB, and I'd prefer to flash the ESP32 with micropython as a FreeRTOS task coexisting with the wifi and bluetooth, as well as run micropython on the P2 simultaneously. Heck, if it had an STM32 for USB, I'd probably try to run micropython on it too... *laughs*
I'd honestly prefer if the P2PAL used the ESP32 WROVER module with it's own PSRAM, as that opens the ESP32 up to bridging serial to complex cryptography protocols like SSH easily (since libssh2 is such a memory hog) but I can see the PCB space is limited; and the WROVER module's footprint is simply too large for the P2PAL... Honestly I was hoping for some way to be able to share the PSRAM's SPI bus between both masters, but that's not really a good idea, since the ESP32's NOR flash shares the bus, and it's easy to lock the ESP32 up if it's cache controller can't get to the flash chip for some XIP code segment.
I'll just reduce the libssh2 buffer sizes to avoid PSRAM allocations.
These are simply my opinions and preferences.
The short answer to the QUESTION: is, Yes, I want a P2D2+ preassembled.
Once publison's got some stock on hand, maybe I'll take another P2D2 without the pal if I get into playing with smartpins heavily, but I've got a rev b 64000-ES if I wanna do that, so I'll be solid with a P2D2+ that lets no blue smoke out.
Two major things I want to do with it: ~84Mhz HDMI Oscilloscope for watching STM32 pins, and playing with a bearlibterminal-like sprite-based cell renderer along with audio, SIDCOG perhaps, with ESP32 doing SSH networking. http://foo.wyrd.name/en:bearlibterminal:design
Wouldn't mind a little P2USB-like stub board to take a few JFET level-converted castellated pins out to 0.100" header for use with the 'scope, if that was ever something you wanted to have as a design-feature.
I have only one question, can I get the P2D2 with an P2 Rev C
While I have a stack of Rev B chips I guess the production stock will use whatever Parallax supplies. The only difference between these is the trace that is cut between adjacent pins for A/D. From what Chip said today though that we really need a good 16-bit audio A/D to improve the audio functions, then it probably doesn't make any real difference depending upon what you are trying to do. I'm doing some audio work with microphone elements so I guess I will forget about the analog type and just go for MEMS with PDM output.
@kamilion - I'm only using a USB-C connector but I am not supporting USB-C protocols including alt mode although there is no need to since it is totally under the P2's control as to what all 10 smartpins do. I am planning to plug the USB-C cable into a passive adapter for HDMI and another for VGA, so that has nothing to do with alt mode. As for power, then ditto all that as I simply have VIN connected to USB-C so that USB power on the serial port can supply power, or power can be supplied via the USB-C. Think of this connector as a convenient connector for these modes as well as slow USB of course. I was toying with the idea of adding a HDMI, but that's too big, and a micro HDMI needs an adapter anyway etc.
What's the plan for USB-C CC signalling to negotiate altmodes? That got my ears perked, as a passive altmode hdmi / type-c dongle is pretty cheap.
I've seen some of the STM32G0 series that are suitable for CC signalling, in as small as 8SOIC. But given all the EFM8UB3 work, it's probably not something you'd want to jump on this late in the game.
If you have a look at the EFM8UB3 datasheet you will find that one of the applications is CC signaling. But CC signaling on the P2D2 will eventualli be useful only in connection with a host (PC) device to eventually request more power from the USB socket.
If you use a passive USB-C to HDMI cable IMHO the CC link is not required given on the other side sits a monitor which do not support CC protocol on the HDMI connector. I think for HDMI you need to negotiate the alternative mode onli if you have active cables with some sort of repeter/signal regeneration function in it. I am assuming the passive cable have only wires in it.
I'd honestly prefer if the P2PAL used the ESP32 WROVER module with it's own PSRAM, as that opens the ESP32 up to bridging serial to complex cryptography protocols like SSH easily (since libssh2 is such a memory hog) but I can see the PCB space is limited; and the WROVER module's footprint is simply too large for the P2PAL... Honestly I was hoping for some way to be able to share the PSRAM's SPI bus between both masters, but that's not really a good idea, since the ESP32's NOR flash shares the bus, and it's easy to lock the ESP32 up if it's cache controller can't get to the flash chip for some XIP code segment.
This (WROVER) is a good suggestion I am also looking over (since a month now). @"Peter Jakacki" have a look if you can design the P2PAL with double overlapped socket for the ESP32. If you look carefully you will see that WROOM and WROVER have the same pinout with the difference that what the WROOM has on the bottom side the WROVER have on the sides, half on each side. This is strait forward also in regards to PCB routing. You can leave to the end user the duty to solder the ESP32 module so each one can choose the one he prefers.
Infact the difference between the WROOM and WROVER is the builtin PSRAM. Now on the WROVER the flash and psram shares the same SPI bus which pins are not brought out on the WROOM module. It is true that you can wire an esternal PSRAM on another SPI bus but as far as I have read and experimented till now (on the Olimex ESP32-PoE) the external psram can be used in whatever way by the user code but it can't be allocated as system memory and thus used transparently (eg for communication buffers). Perhaps you need to modify the system libraries to change the communication channel to the external psram but many of the ESP-IDF libraries are closed source and I have not investigated to this point.
If you have a look at the EFM8UB3 datasheet you will find that one of the applications is CC signaling. But CC signaling on the P2D2 will eventualli be useful only in connection with a host (PC) device to eventually request more power from the USB socket.
If you use a passive USB-C to HDMI cable IMHO the CC link is not required given on the other side sits a monitor which do not support CC protocol on the HDMI connector. I think for HDMI you need to negotiate the alternative mode onli if you have active cables with some sort of repeter/signal regeneration function in it. I am assuming the passive cable have only wires in it.
Ah, I see. CC signalling has some very quirky voltage requirements. Also, I've noticed even "passive" cables have some kind of negotiation capability now, I have a type C to 3.5mm audio dongle that somehow refuses power when plugged into the inline voltage monitor. Haven't looked into it deeply.
This (WROVER) is a good suggestion I am also looking over (since a month now). @"Peter Jakacki" have a look if you can design the P2PAL with double overlapped socket for the ESP32. If you look carefully you will see that WROOM and WROVER have the same pinout with the difference that what the WROOM has on the bottom side the WROVER have on the sides, half on each side. This is strait forward also in regards to PCB routing. You can leave to the end user the duty to solder the ESP32 module so each one can choose the one he prefers.
So, the central six pins on the bottom the WROOM are "mostly useless" as they go to the flash/PSRAM bus on the ESP32, they can safely be NC/ignored in layout. You only need the two at either edge for the WROOM (GND/GPIO13 and GPIO15/GPIO2), and the bottom three on each side of the WROVER can also be NC pads.
The DevkitC V4 PCB layout shows this fairly clearly.
On the module, they're labeled SD0, SD1, SD2, SD3, CMD, and CLK. (GPIO6 to GPIO11) The ESP32's internal cache controller REALLY does not like these traces being extended beyond the headers they're routed to on the DevkitC; and they've been a trap for a lot of newbies picking 'conveniently labeled pins' and mistaking them for usable GPIOs, and causing the module to fail to boot.
The only time they should be used is when the NOR flash is entirely absent from the ESP32 pcb design and the design is spec'd for SDIO with eFUSEs pre-blown.
This will not work with any existing modules unless you peel the RF can off a module and remove the NOR flash, or buy the bare ESP32-D0WD chip.
As far as I know, espressif hasn't released any publicly available documentation on how to do this; but with the IDF 4.2 (unreleased as yet), they've started some new SDIO examples which will later bear fruit in the form of actual official documentation on their readthedocs site.
As for using the device under linux, apparently recent versions of the ESP8266 "eagle" firmware will boot on the ESP32. It's pushed over SDIO by the linux kernel driver as part of device initialization. We don't have much in the way of documentation other than the kernel driver source code. I've seen this used in a few of the newer gameboy clone designs like Hardkernel's ODROID-Advance BE and some other Rockchip based handhelds for use with emulation-station and retroarch and the like.
It is worth noting, on the WROVER module, the PSRAM shares the data bus, but has a separate clock pin and enable pin (GPIO 16/17) that should not be reused elsewhere. (Description of issue by Sprite_TM in 2017)
Infact the difference between the WROOM and WROVER is the builtin PSRAM. Now on the WROVER the flash and psram shares the same SPI bus which pins are not brought out on the WROOM module. It is true that you can wire an esternal PSRAM on another SPI bus but as far as I have read and experimented till now (on the Olimex ESP32-PoE) the external psram can be used in whatever way by the user code but it can't be allocated as system memory and thus used transparently (eg for communication buffers). Perhaps you need to modify the system libraries to change the communication channel to the external psram but many of the ESP-IDF libraries are closed source and I have not investigated to this point.
You're mistaken that it can't be allocated as 'system' memory. It can absolutely be added to the system memory map, it can absolutely be used for communication buffers (and even as a framebuffer for SPI displays), but what it CANNOT do is operate as execute-in-place memory. It can't be used in place of IRAM (Instruction-RAM). But for everything else (DRAM/Data-RAM, and some low-speed-peripheral DMA); it can be added to the system allocator or further abused through their himem system to do bank switching for accessing capacities over 4MiB. There were some design limits in ESP31, only 4MiB of PSRAM in the address map and XIP is limited to mapping 12.5MB of NOR flash -- some of which have been fixed with the ESP32-S2 and ESP32-S3 chips coming soon, both of which can XIP in NOR, NAND and PSRAM address space, up to 128MiB. (woohoo!)
But don't hold your breath waiting for -S2 or -S3.
Also, you can't add PSRAM to V_SPI or H_SPI, they don't route through the MMU/Cache Controller like the NOR flash bus, and you'd have to command them manually with SPI commands instead of relying on the MMU's JEDEC command controller doing the work in the background for you. This IS documented and commonly done on AVRs and STMs. It's sort of unfortunate that SPI JEDEC commands are different between NOR flash, NAND flash, and PSRAM. And the ESP31/32 design can't even handle the NAND flash commands to get to parts like the latest 8Gbit/1GiB Kioxia/Microns or the 2Gbit/256MiB Winbonds at all.
However, when you're using a VM on the device like Micropython, whitecat / Lua, or duktape / JS, the bytecode that the VM runs is normal DataRAM; it does NOT need to be considered executable in the memory map. Only the VM's bytecode interpreter needs to be resident in IRAM. So abusing a bytecode VM is a really neat way to get pretty close to full access to the device's capabilities. Arduino-ESP32 and it's sketch code must be resident in IRAM though, so it's "almost impossible" to get arduino sketches to really make the chip roar.
That olimex ethernet board is also a bit of a special case; the ethernet MAC needs a high speed clock source, and the ESP32's pinmux system can't redirect high speed peripherals to other pads. So the GPIOs remaining to you are rather limited on that olimex. I think you get one of the three SPI busses (ethernet MAC's gobbling the other, which also blocks JTAG from being used as those pins are also shared) and the I2C bus, but I could be mistaken -- and I2C's a low speed peripheral so pinmux can assign it to any of roughly half of the pads.
Also, almost all of the code in ESP-IDF is open-source; I can only think of libwifi.a and hci.a (for bluetooth) as closed modules. Even the newlib source is available (check the components dir in github, you'll see references to many other repos) but rather difficult to link, since the ESP32 has a comparatively VERY large internal MaskROM (448KiB?) containing an older version of newlib, ESP-IDF will instead use delta-patching against it to minimize the flash image. So it's really ugly and looks more closed than it really is, but it's more of a quirky build process. Also can't say I'm too happy with the cmake migrations.
ESP32
P2PAL uses the HSPI on the WROOM as a possible high speed path between the P2 and the ESP32. But it's a bit late to make any changes to P2PAL at this stage, but alternatives can certainly be considered for next time.
AUDIO
P2LAB allows for 2 mikroBUS modules so after hearing Chip mention that the P2 really needs good quality audio A/D I decided to put two 24-bit stereo A/Ds on a mikoBUS module along with a headphone amp. The stereo A/D inputs each connect to a 3.5mm TRS jack while the headphone amp uses a TRRS which connects any headset microphone to one of the A/D channels. I'm putting all this together at the moment but always with any 24-bit analog it requires careful layout and component choices.
I cascaded the two chips so that they only need the one SPI bus repurposed to I2S/TDM.
The fact that they are on mikroBUS modules is a plus because the design can be tight and separate from the main circuitry. The other plus is that these mikroBUS modules can be used with any MCU.
I think the connector arrangement should be suitable for most work and flexible enough but if you have any thoughts on that, please let me know, it's easy enough to change that part.
BTW, P2LAB still allows for direct P2 analog on the front-panel audio jacks.
P2LAB allows for 2 mikroBUS modules so after hearing Chip mention that the P2 really needs good quality audio A/D I decided to put two 24-bit stereo A/Ds on a mikoBUS module along with a headphone amp. The stereo A/D inputs each connect to a 3.5mm TRS jack while the headphone amp uses a TRRS which connects any headset microphone to one of the A/D channels. I'm putting all this together at the moment but always with any 24-bit analog it requires careful layout and component choices.
I cascaded the two chips so that they only need the one SPI bus repurposed to I2S/TDM.
This sounds good. I2S is going to be nice for audio I/O with a good Codec. Headphone amp is a good idea too, it's a pain to be limited to need external amps otherwise. Is there a D/A on the board too or just A/D?
There are some head-phone amps that are basically an audio dac with an amp, so I may end up using those, as long as I can still feed it with a P2 dac for comparison and enhancement. It's easy enough to do another module later on and the main thing at the moment is to make sure we can handing audio in.
@"Peter Jakacki" when do you schedule the shipping of the P2D2? We can not wait until all the possible additions are ready, that will result in delay not acceptable. Any date after some more weeks?
We are all waiting patiently and not rushing Peter, no ? On the other hand having an even rough estimate wouldn't hurt either, would it ?
Until I learn the answer to my question about 1 2 3 simple (but complete) steps to become a happy owner of the P2D2 and some other goodies too, I say nothing more. I'll just wait .
But @ErNa, please put me on your waiting list too. I'm in Europe.
I'm waiting in the queue too! At present I am wrestling with Protel99SE to give me my P2PAL pcb back. if I can't get it I will have to update a pcb backup from a week ago!@#$#! As soon as I can I will migrate to Kicad.
The 4 pcbs that I expect to have back next week are:
P2D2
P2PAL
P2PINS
P2MAT
While I am waiting for that I am filling in all the details for the bill of materials for the P2D2 and P2PAL so that I can get quotes back on a small and larger run. Then I intend to finish up P2LAB and some other minor pcbs including the P2HAT and send those off. By that time I will have my P2D2 batch back so I will make up one initially and test it thoroughly along with a P2PAL. If there are no changes needed then I can proceed with getting these boards assembled.
Thanks, ErNa.
It had never occurred to me that you meant SIPO (like FIFO, FILO, LIFO, LILO). That was just too obvious. My mind works as it pleases these days. I think it's seriously twisted. I should start worrying perhaps.
And thanks, Peter for the update. I don't envy you.
Funny, I didn't experience these symptoms before entering the Propeller camp. Should the two be correlated ?
QUESTION: How many would want a P2D2+ preassembled?
Me, please!
I can't remember how much I paid for the original base P2D2, but if you let me know the additional cost for the assembled P2D2+, I will happily send you another payment.
Such a big chock into my own mind, by the 70', when I was first introduced to it.
Yanomani, you are not mistaken. I am . I remember that crude, big, plastic calculator with a small red display (can't recall the name of it) where you entered the values first and then the action on these values and I had trouble with that at the time (late 70'/early 80') Not so since then.
QUESTION: How many would want a P2D2+ preassembled?
Me, please!
I can't remember how much I paid for the original base P2D2, but if you let me know the additional cost for the assembled P2D2+, I will happily send you another payment.
Ross.
Me too. Ready to raid the piggy bank to get a P2D2+ that is ready to run on arrival.
BTW I was the (naughty) soul who asked for the 0.050” headers to be on 1.000” centres. They were slightly wider than this at IIRC 1.045”.
Now this actually makes the P2D2 pcb about 1.1” wide depending on the distance beyond the holes to the second set of castellated holes (if they are still on the pcb)??? And about 2.2” long?
Getting small runs of blank pcbs are cheap these days so I can afford to have various adapters etc. However assembling a quantity of the P2D2 itself requires that I keep that part of it as standard as possible. If I ask for quotes on a fully loaded build and the price looks right then I will go ahead and get them made up and ship extra stock to Publison so that anyone in the US/Canada who wants one or ten can get them in a matter of days. Same too with Europe.
The same is true of the P2PAL option and this can be stocked separately since it is a relatively easy matter to sandwich them together and solder up the edge pads with an iron or solder them together when you add the pin socket . But it may turn out that many may want the P2D2+ preassembled so this complicates the stock situation.
Boards:
P2D2 - Complete P2 system inc RTC and precision clock gen and USB serial supervisor with watchdog and smart reset etc.
P2PAL - ESP32, 16MB HyperRAM, 8MB PSRAM, 6 LEDs+RGB, microSD, USB-C for alt mode HDMI (or VGA).
P2PINS - 100mil headers inc 40-pin RPi "layer"
P2HAT - An RPi HAT with prototyping pads + connection for a P2D2 (smd or 50mil pins)
P2LAB - The P2D2 Motherlode board (mikroBUS, Ethernet, HDMI, VGA, A/V, USB, dual SD, DC, etc)
P2MAT - A general-purpose 3.75" x 2.75" 50mil matrix prototype board
P2USB - a tiny 8-pin vertical SIP USB serial module with the EFM8UB3 (watchdog, smart reset etc)
Some use cases:
Embedded P2D2 surface mounted to production PCB.
Embedded P2D2 (optional P2PAL) sandwiched to a 100mil header breakout layer (P2PINS)
Embedded P2D2 (optional P2PAL) mounted via pin headers to custom PCB or P2LAB or P2HAT
Standalone P2D2 for development
Standalone P2D2+ for development
The original P2D2 had to be chopped down if you didn't want 100mil pin headers and those pin headers make the board 70% wider. But it turns out you can't really just chop the board down if you want to smd it, they have to be milled for castellations. This is the main reason for the slim P2D2 module.
QUESTION: How many would want a P2D2+ preassembled?
You define P2D2(which is now r4), P2PAL, P2PINS, P2HAT, P2LAB, P2MAT, and P2USB, but then go on to ask how many would like a P2D2+ without defining it. Many have guessed, but you never explicitly confirmed their guesses.
I, for one, would just like a P2D2 actually in my hand, connected to my computer and working so I can start playing with the P2. For all of these other things to be developed without actually delivering on the P2D2 doesn't seem like the right path...but wait there's more...
What that entails is:-
P2 + clockgen + 16MB Flash + USB serial monitor + watchdog + microSD + RTC + ESP32 + 16MB HyperRAM + 8MB PSRAM + WS2812 + 6 LEDS + USB-C(HDMI/VGA)
That's a lot of pluses, so maybe it should be a P2D2+++++++++
What that entails is:-
P2 + clockgen + 16MB Flash + USB serial monitor + watchdog + microSD + RTC + ESP32 + 16MB HyperRAM + 8MB PSRAM + WS2812 + 6 LEDS + USB-C(HDMI/VGA)
That's a lot of pluses, so maybe it should be a P2D2+++++++++
ETA keeps getting moved I'm trying to nail that one down
What is definite is that I am testing all this stuff this month and at the same time I'm lining up quotes for rapid A&T of these modules so that I will have plenty of stock, not just here, but also in the US and Europe. It looks like I can expect turn-around within 2 weeks from confirmation of the design to getting boards back, so October.
It's not a matter of if, but when. When the sourcing and delivery of A&T-ed boards is locked in, I will be placing more orders. It's not a matter of which one, but also how many?
I'm excited to start playing with the P2D2 as a platform module. I'd rather be designing stackables to accessorize with it than re-inventing the wheel. Or, as an intermediary step, building on the P2D2 schematic [and board] for designs as a way to maintain modularity [of the signaling and IO setup, grouping, etc] with a different style of connectors [for different types of applications]
In any case, it's really nice to see the progress. Knowing that I can build on top of the P2D2 board has changed my approach to building modules based on the P2, but therein lies the rub. I can focus on building accessory boards in the meantime.
Keep going, and take more of my money when you can!
Comments
for me please ...
1 P2D2+PAL assembled
1 P2LAB
1 Pins
1 mat
1 USB
1 USB-C HDMI/VGA dongle ... or are those on ebay/Aliexpress?
This would make a great bundle ...
@ErNa
Maybe it is a good idea to collect the preorders at the continental distributors?
To relief Peter from handling. And just send him the summary order?
Yeah, that's pretty much what I want. I already chipped in early. I'll chip in more, too.
What's the plan for USB-C CC signalling to negotiate altmodes? That got my ears perked, as a passive altmode hdmi / type-c dongle is pretty cheap.
I've seen some of the STM32G0 series that are suitable for CC signalling, in as small as 8SOIC. But given all the EFM8UB3 work, it's probably not something you'd want to jump on this late in the game.
I'm not interested much in the big lab board, myself.
I am a fan of the castellated/dip-alike through-hole header designs. Got a good set of STM32F411 boards from WeACT (Chinese, but they're on github) for running micropython on, I also intend to run micropython + hdmi + esp32 wifi on my P2D2+.
The P2PAL has enough on it to work out as a nice singleboard computer, now that the ESP32 ESP-IDF v4.2 has some examples for BTLE HID client and server, which takes care of figuring out cabled input devices.
I wouldn't need a type-A port for a logitech unifying dongle, or PS/2 for a wired keyboard/mouse, and I've got a couple bluetooth keyboards around already that would fit the bill.
The type-C port handling power and video will suit me very well. If I want to mess with physical devices, I'll solder on short sets of header to the pins I want (I2S for audio, or I2C or SPI for the little OLED displays I have on hand already) and ignore all the other pins.
I don't really intend on connecting any GPIO buttons or rotary encoders, and I hope all of the LEDs will be PWM dimmable; or if there's a power-good led, that it's resistor is selected well to keep it from being too blinding.
I originally was interested in the pairing with a pi-compatible SBC, but I've lost interest in that with the inclusion of the ESP32.
Please make sure you use the ESP32 module with the largest flash -- there's options for 4MiB, 8MiB, and 16MiB, and I'd prefer to flash the ESP32 with micropython as a FreeRTOS task coexisting with the wifi and bluetooth, as well as run micropython on the P2 simultaneously. Heck, if it had an STM32 for USB, I'd probably try to run micropython on it too... *laughs*
I'd honestly prefer if the P2PAL used the ESP32 WROVER module with it's own PSRAM, as that opens the ESP32 up to bridging serial to complex cryptography protocols like SSH easily (since libssh2 is such a memory hog) but I can see the PCB space is limited; and the WROVER module's footprint is simply too large for the P2PAL... Honestly I was hoping for some way to be able to share the PSRAM's SPI bus between both masters, but that's not really a good idea, since the ESP32's NOR flash shares the bus, and it's easy to lock the ESP32 up if it's cache controller can't get to the flash chip for some XIP code segment.
I'll just reduce the libssh2 buffer sizes to avoid PSRAM allocations.
These are simply my opinions and preferences.
The short answer to the QUESTION: is, Yes, I want a P2D2+ preassembled.
Once publison's got some stock on hand, maybe I'll take another P2D2 without the pal if I get into playing with smartpins heavily, but I've got a rev b 64000-ES if I wanna do that, so I'll be solid with a P2D2+ that lets no blue smoke out.
Two major things I want to do with it: ~84Mhz HDMI Oscilloscope for watching STM32 pins, and playing with a bearlibterminal-like sprite-based cell renderer along with audio, SIDCOG perhaps, with ESP32 doing SSH networking.
http://foo.wyrd.name/en:bearlibterminal:design
Wouldn't mind a little P2USB-like stub board to take a few JFET level-converted castellated pins out to 0.100" header for use with the 'scope, if that was ever something you wanted to have as a design-feature.
@kamilion - I'm only using a USB-C connector but I am not supporting USB-C protocols including alt mode although there is no need to since it is totally under the P2's control as to what all 10 smartpins do. I am planning to plug the USB-C cable into a passive adapter for HDMI and another for VGA, so that has nothing to do with alt mode. As for power, then ditto all that as I simply have VIN connected to USB-C so that USB power on the serial port can supply power, or power can be supplied via the USB-C. Think of this connector as a convenient connector for these modes as well as slow USB of course. I was toying with the idea of adding a HDMI, but that's too big, and a micro HDMI needs an adapter anyway etc.
If you use a passive USB-C to HDMI cable IMHO the CC link is not required given on the other side sits a monitor which do not support CC protocol on the HDMI connector. I think for HDMI you need to negotiate the alternative mode onli if you have active cables with some sort of repeter/signal regeneration function in it. I am assuming the passive cable have only wires in it.
This (WROVER) is a good suggestion I am also looking over (since a month now). @"Peter Jakacki" have a look if you can design the P2PAL with double overlapped socket for the ESP32. If you look carefully you will see that WROOM and WROVER have the same pinout with the difference that what the WROOM has on the bottom side the WROVER have on the sides, half on each side. This is strait forward also in regards to PCB routing. You can leave to the end user the duty to solder the ESP32 module so each one can choose the one he prefers.
Infact the difference between the WROOM and WROVER is the builtin PSRAM. Now on the WROVER the flash and psram shares the same SPI bus which pins are not brought out on the WROOM module. It is true that you can wire an esternal PSRAM on another SPI bus but as far as I have read and experimented till now (on the Olimex ESP32-PoE) the external psram can be used in whatever way by the user code but it can't be allocated as system memory and thus used transparently (eg for communication buffers). Perhaps you need to modify the system libraries to change the communication channel to the external psram but many of the ESP-IDF libraries are closed source and I have not investigated to this point.
Ah, I see. CC signalling has some very quirky voltage requirements. Also, I've noticed even "passive" cables have some kind of negotiation capability now, I have a type C to 3.5mm audio dongle that somehow refuses power when plugged into the inline voltage monitor. Haven't looked into it deeply.
So, the central six pins on the bottom the WROOM are "mostly useless" as they go to the flash/PSRAM bus on the ESP32, they can safely be NC/ignored in layout. You only need the two at either edge for the WROOM (GND/GPIO13 and GPIO15/GPIO2), and the bottom three on each side of the WROVER can also be NC pads.
The DevkitC V4 PCB layout shows this fairly clearly.
On the module, they're labeled SD0, SD1, SD2, SD3, CMD, and CLK. (GPIO6 to GPIO11) The ESP32's internal cache controller REALLY does not like these traces being extended beyond the headers they're routed to on the DevkitC; and they've been a trap for a lot of newbies picking 'conveniently labeled pins' and mistaking them for usable GPIOs, and causing the module to fail to boot.
The only time they should be used is when the NOR flash is entirely absent from the ESP32 pcb design and the design is spec'd for SDIO with eFUSEs pre-blown.
This will not work with any existing modules unless you peel the RF can off a module and remove the NOR flash, or buy the bare ESP32-D0WD chip.
As far as I know, espressif hasn't released any publicly available documentation on how to do this; but with the IDF 4.2 (unreleased as yet), they've started some new SDIO examples which will later bear fruit in the form of actual official documentation on their readthedocs site.
As for using the device under linux, apparently recent versions of the ESP8266 "eagle" firmware will boot on the ESP32. It's pushed over SDIO by the linux kernel driver as part of device initialization. We don't have much in the way of documentation other than the kernel driver source code. I've seen this used in a few of the newer gameboy clone designs like Hardkernel's ODROID-Advance BE and some other Rockchip based handhelds for use with emulation-station and retroarch and the like.
It is worth noting, on the WROVER module, the PSRAM shares the data bus, but has a separate clock pin and enable pin (GPIO 16/17) that should not be reused elsewhere.
(Description of issue by Sprite_TM in 2017)
You're mistaken that it can't be allocated as 'system' memory. It can absolutely be added to the system memory map, it can absolutely be used for communication buffers (and even as a framebuffer for SPI displays), but what it CANNOT do is operate as execute-in-place memory. It can't be used in place of IRAM (Instruction-RAM). But for everything else (DRAM/Data-RAM, and some low-speed-peripheral DMA); it can be added to the system allocator or further abused through their himem system to do bank switching for accessing capacities over 4MiB. There were some design limits in ESP31, only 4MiB of PSRAM in the address map and XIP is limited to mapping 12.5MB of NOR flash -- some of which have been fixed with the ESP32-S2 and ESP32-S3 chips coming soon, both of which can XIP in NOR, NAND and PSRAM address space, up to 128MiB. (woohoo!)
But don't hold your breath waiting for -S2 or -S3.
Also, you can't add PSRAM to V_SPI or H_SPI, they don't route through the MMU/Cache Controller like the NOR flash bus, and you'd have to command them manually with SPI commands instead of relying on the MMU's JEDEC command controller doing the work in the background for you. This IS documented and commonly done on AVRs and STMs. It's sort of unfortunate that SPI JEDEC commands are different between NOR flash, NAND flash, and PSRAM. And the ESP31/32 design can't even handle the NAND flash commands to get to parts like the latest 8Gbit/1GiB Kioxia/Microns or the 2Gbit/256MiB Winbonds at all.
However, when you're using a VM on the device like Micropython, whitecat / Lua, or duktape / JS, the bytecode that the VM runs is normal DataRAM; it does NOT need to be considered executable in the memory map. Only the VM's bytecode interpreter needs to be resident in IRAM. So abusing a bytecode VM is a really neat way to get pretty close to full access to the device's capabilities. Arduino-ESP32 and it's sketch code must be resident in IRAM though, so it's "almost impossible" to get arduino sketches to really make the chip roar.
That olimex ethernet board is also a bit of a special case; the ethernet MAC needs a high speed clock source, and the ESP32's pinmux system can't redirect high speed peripherals to other pads. So the GPIOs remaining to you are rather limited on that olimex. I think you get one of the three SPI busses (ethernet MAC's gobbling the other, which also blocks JTAG from being used as those pins are also shared) and the I2C bus, but I could be mistaken -- and I2C's a low speed peripheral so pinmux can assign it to any of roughly half of the pads.
Also, almost all of the code in ESP-IDF is open-source; I can only think of libwifi.a and hci.a (for bluetooth) as closed modules. Even the newlib source is available (check the components dir in github, you'll see references to many other repos) but rather difficult to link, since the ESP32 has a comparatively VERY large internal MaskROM (448KiB?) containing an older version of newlib, ESP-IDF will instead use delta-patching against it to minimize the flash image. So it's really ugly and looks more closed than it really is, but it's more of a quirky build process. Also can't say I'm too happy with the cmake migrations.
P2PAL uses the HSPI on the WROOM as a possible high speed path between the P2 and the ESP32. But it's a bit late to make any changes to P2PAL at this stage, but alternatives can certainly be considered for next time.
AUDIO
P2LAB allows for 2 mikroBUS modules so after hearing Chip mention that the P2 really needs good quality audio A/D I decided to put two 24-bit stereo A/Ds on a mikoBUS module along with a headphone amp. The stereo A/D inputs each connect to a 3.5mm TRS jack while the headphone amp uses a TRRS which connects any headset microphone to one of the A/D channels. I'm putting all this together at the moment but always with any 24-bit analog it requires careful layout and component choices.
I cascaded the two chips so that they only need the one SPI bus repurposed to I2S/TDM.
The fact that they are on mikroBUS modules is a plus because the design can be tight and separate from the main circuitry. The other plus is that these mikroBUS modules can be used with any MCU.
I think the connector arrangement should be suitable for most work and flexible enough but if you have any thoughts on that, please let me know, it's easy enough to change that part.
BTW, P2LAB still allows for direct P2 analog on the front-panel audio jacks.
Until I learn the answer to my question about 1 2 3 simple (but complete) steps to become a happy owner of the P2D2 and some other goodies too, I say nothing more. I'll just wait
But @ErNa, please put me on your waiting list too. I'm in Europe.
The 4 pcbs that I expect to have back next week are:
P2D2
P2PAL
P2PINS
P2MAT
While I am waiting for that I am filling in all the details for the bill of materials for the P2D2 and P2PAL so that I can get quotes back on a small and larger run. Then I intend to finish up P2LAB and some other minor pcbs including the P2HAT and send those off. By that time I will have my P2D2 batch back so I will make up one initially and test it thoroughly along with a P2PAL. If there are no changes needed then I can proceed with getting these boards assembled.
It had never occurred to me that you meant SIPO (like FIFO, FILO, LIFO, LILO). That was just too obvious. My mind works as it pleases these days. I think it's seriously twisted. I should start worrying perhaps.
And thanks, Peter for the update. I don't envy you.
Funny, I didn't experience these symptoms before entering the Propeller camp. Should the two be correlated ?
I was mostly sure you're used to RPN...
Such a big chock into my own mind, by the 70', when I was first introduced to it.
Propellers can leave your head spinning. Tachyon does it the other way
Me, please!
I can't remember how much I paid for the original base P2D2, but if you let me know the additional cost for the assembled P2D2+, I will happily send you another payment.
Ross.
Yanomani, you are not mistaken. I am
http://www.vintagecalculators.com/html/novus_650_-mathbox-.html
My first RPN was using a HP calculator.
Me too. Ready to raid the piggy bank to get a P2D2+ that is ready to run on arrival.
Gee, thanks.
You define P2D2(which is now r4), P2PAL, P2PINS, P2HAT, P2LAB, P2MAT, and P2USB, but then go on to ask how many would like a P2D2+ without defining it. Many have guessed, but you never explicitly confirmed their guesses.
I, for one, would just like a P2D2 actually in my hand, connected to my computer and working so I can start playing with the P2. For all of these other things to be developed without actually delivering on the P2D2 doesn't seem like the right path...but wait there's more...
What that entails is:-
P2 + clockgen + 16MB Flash + USB serial monitor + watchdog + microSD + RTC + ESP32 + 16MB HyperRAM + 8MB PSRAM + WS2812 + 6 LEDS + USB-C(HDMI/VGA)
That's a lot of pluses, so maybe it should be a P2D2+++++++++
Here is some info on P2D2 modules.
jim
That sound's great. What is the price? What is a reasonably firm ETA?
What is definite is that I am testing all this stuff this month and at the same time I'm lining up quotes for rapid A&T of these modules so that I will have plenty of stock, not just here, but also in the US and Europe. It looks like I can expect turn-around within 2 weeks from confirmation of the design to getting boards back, so October.
I'm excited to start playing with the P2D2 as a platform module. I'd rather be designing stackables to accessorize with it than re-inventing the wheel. Or, as an intermediary step, building on the P2D2 schematic [and board] for designs as a way to maintain modularity [of the signaling and IO setup, grouping, etc] with a different style of connectors [for different types of applications]
In any case, it's really nice to see the progress. Knowing that I can build on top of the P2D2 board has changed my approach to building modules based on the P2, but therein lies the rub. I can focus on building accessory boards in the meantime.
Keep going, and take more of my money when you can!