...
And over the ESP32 SPI slave channel the ESP32 can also offer to the P2 all the other TCP/UDP protocolls using or a WiFi or wired FastEthernet links.
...
I was thinking along this lines as well.
Having worked with Tachyon and the EASYNET module (thanks @"Peter Jakacki" ) via WIZ5x00 chips I really liked having 4 or 8 sockets available
for 'simultaneous' use for Telnet, FTP, HTTP, STP, ... connected via fast SPI.
With only a serial link between ESP32 and P2 this would have to be handled in SW playing together on both sides.
And would probably be slower as well.
The interface provided by EASYNET.fth I was really easy to use and quite powerful.
@ErNa - what I have designed is as right as it can be although there will always be "needs" that we discover that require improvements in the design. But those needs aren't really known or understood until we have a working design. I would hesitate to interconnect the P2 and ESP32 to the point where I couldn't rely on either of them because of unknown interactions. But since I'm still making some changes and finalizing the P2LAB motherboard, I will certainly give myself the weekend at least to look into it further.
If anyone has a connection scheme they think will work, then I will look into it.
@MJB - The P2 can communicate serially at very high speeds with the help of the smartpins so 40Mbd is quite feasible although there would be a practical limit there somewhere especially with the ESP32 itself. The ESP32 is supposed to provide serial coms at least and with the larger memory on the 32D the P2 can load it up with common files that it can serve up I guess. Until I've had time to play with it, I can't say what changes might be needed. I have to be careful at this point though that the ESP32 doesn't interfere with the normal operation or hog the resources of the P2 that it is meant to support.
For people who want extra SPI slave buses for transfers in/out of the ESP32, the way Peter has all the solder holes on each ESP32 pin, there is an option to solder in 4 short wire links from appropriate ESP32 pins to the PSRAM device pads (if unpopulated) for example, and develop dedicated ESP32 code for that purpose. Or they can connect into the other P2 pins via the 0.05 headers perhaps. If HyperRAM is fitted then the PSRAM device probably won't have much need to be fitted.
Actually Peter, looking at your P2PAL board layout, given the proximity of the PSRAM to the four ESP32 HSPI bus pins, it may be possible to check if these PSRAM pads can be also solder jumpered though into these ESP32 holes as an option (maybe via a resnet for safety). They are right near the PSRAM so it could be doable. ESP IO14, IO12, IO13 and IO15 comprise the HSPI which I read can be operated as a slave, but should be checked. It's almost an ideal position for these signals too and you shouldn't need 4 layers. Have a look to see what you think.
I wonder if it makes sense to power the P2PAL devices via a schottky diode to drop the 3.6 VIO voltage down a little? Will the HyperRAM, flash and Wifi module all like to run at their full max of 3.6V? There's not a lot of room for supply tolerance at that level though maybe some natural IR drop will help us a bit. I notice the ESP32 WROOM is at its absolute maximum rating limit when at 3.6V. Maybe a small schottky might help to drop by 0.3-0.5V or so? Perhaps there is still too much variation with that though.
Here are the latest full schematics for the P2D2 and the P2PAL board. Unlike the "schematic" for the P2 EVAL board which is more of a multipage netlist diagram, I try to put everything together in a "schematic view" so it is easy to see the relationship and connections of all the components.
On the P2D2 there are multiple options for the same component and to simplify the schematic I used the trick of overlaying them in the same position so that you see only one component although there are multiple labels. This applies to the microSD socket and LEDs mainly. There are also optional components that could go on the reverse if needed and these have a light blue background. Components that aren't fitted have a light pink background.
@rogloh - can you let me know which actual pins I could connect up from the ESP32 to the P2? There are so many different names and functions for these pins, so I just want to be sure before trying to connect them.
@rogloh - can you let me know which actual pins I could connect up from the ESP32 to the P2? There are so many different names and functions for these pins, so I just want to be sure before trying to connect them.
Ok I'll take a look. Bear in mind I've not interfaced with ESP32 before, only the 8266. But I'll try to make a suggestion on what I'd do from what I will gather by reading more. No guarantee it will be 100% perfect if I happen to miss seeing some critical thing about specific IO pin limitations etc. It's important to keep this simple, and as you mention not burden or hog the P2 with lots of extra signals/startup requirements etc. Ideally we'd keep it to something like this set of features (decreasing order of priority):
1) ESP32 and P2 can communicate serially via P2 pins 62/63
2) ESP32 can reset the P2 for Wifi remote downloads
3) P2 can enable/disable the ESP32, or have it startup by default if this P2 control pin is to be used for other purposes
4) P2 can serially re-program the ESP32, or just have it startup normally from its own flash by default
5) provide an optional SPI interface for controlling ESP32 out of band from P2 or for multiplexing multiple sockets/channels etc
6) some type of status pin/interrupt between the P2 and ESP to trigger servicing/waking etc, (ideally shared with same P2 pin needed for doing item 4).
7) provide an optional secondary serial interface, so debug vs application output can be separated.
If we have all of 1-7 with the minimum set of P2 pins used I think this will be very good.
Ok Peter this is what I came up with for interfacing P2 and ESP32 on P2PAL (you should still double-check these pins):
P2 PIN ESP32 GPIO ESP32-WROOM32 Notes
63 (Rx in) TXD0 35
62 (Tx out) RXD0 34
..
55 EN 3 Pull high to enable by default, low to disable module, pullup resistor should be fitted.
54 GPIO0 25 Pull high by default to run, or low to reprogram module, pullup resistor should be fitted.
..
51 HSPICS0 (IO15) 23 Wired this exact way you can still share both the PSRAM and Wifi SPI in 1 or 2 bit mode,
50 HSPICLK (IO14) 13 but it would be a good idea to put a small series resistor on the HSPID and Q lines
49 HSPIQ (IO12) 14 so any accidental full QSPI(4 bit) access to the PSRAM when Wifi is fitted doesn't
48 HSPID (IO13) 16 short out with the PSRAM if the ESP32 image also happens to respond by mistake.
All these 4 HSPI connections should be via a solder jumpers to enable only if required.
..
9 U2TXD (IO17) 28 Secondary serial - via solder jumpers to allow full disconnect from port A, fit series resistor?
8 U2RXD (IO16) 27 Secondary serial - via solder jumper.
RST# IO32 8 A diode connection from the ESP32 to the reset input of the P2D2 EFM chip will allow full H/W reset
- MTDI 14 Shared with HSPIQ/IO14 pin, maybe pulldown low (though it already defaults low for 3.3V LDO)
- GPIO2 24 Float or pulldown (defaults low anyway)
- GPIO5 29 Float (defaults high anyway, I believe this is a don't care as we don't use the SDIO slave)
Wired this way you should be able to do the following:
1) provide a standard Wifi serial channel via P62/63
2) reboot the P2 by ESP output pin (the ESP32 RTC /ULP state machine processor can also then reset the P2 while sleeping, this could become handy to still control the P2D2 even from a wifi sleep mode)
3) shutdown the ESP32 to save power
4) re-progam the ESP32 from the P2 by holding GPIO0 low during ESP startup once EN goes high
5) control the ESP32 via the P2 over an optional SPI slave interface, with the ability to keep an SPI PSRAM/Flash chip on the P2PAL still operating in parallel if desired
6) interrupt the P2 from the ESP32 using GPIO0 pin after ESP startup, for status or ISR reasons, or for other flow control use etc
7) provide an optional secondary Wifi serial channel on P2 port A pins 8/9
8) wake up the ESP32 if it is sleeping by pulsing any of its RTC IO pins from the P2 which do include those fitted for HSPI or GPIO0
The good thing about this approach is that it is flexible and you can reduce it for pin constrained setups or enable more capabilities if you enable the solder jumpers.
For example, there are at least 4 different use cases possible:
(for b,c,d it would be good to have solder jumpers to enable them)
a) Use 2 Prop2 RX/TX pins only with EN/GPIO strapped for default operation, along with the optional P2D2 HW reset when the diode is fitted
b) Add 2 optional GPIO0 & EN P2 pins to re-program the ESP32 and/or reset it, instead of permanently starting it up
c) Add 4 more P2 pins for a SPI SLAVE interface, while still keeping PSRAM functional (4 pins shared with PSRAM)
d) Add 2 more P2 pins for a secondary serial interface
I only really wonder if we need to allow for a pull down resistor to be fitted to IO15 to stop any debug output on TXD0 by default during ESP32 startup as this extra serial output may not be desired on TXD0 when the P2 is also booting, however as mentioned in another post above the 220 ohm resistor from the EFM serial output may overpower the 1k resistor fitted on the ESP32 TXD0 line and help save us there even without this pulldown. The only problem I see with using a pulldown is that it sort of enables HSPICS0 by default, but maybe try to layout for a DNP pulldown resistor just in case it is warranted.
@"Peter Jakacki" I can always give you a call to discuss these suggestions, I believe Lachlan already has your number which I can get from him, or you can PM it to me if you want to discuss these ideas in person.
@"Peter Jakacki" ( @jmg )
I had a look to your P2D2 schematic.
As I understand now UB3-P1.1 is driven always high (due to 100K pull-down on RESn) to take P2 out of reset hence UB3 can't monitor the status of the reset line.
Are you perhaps using P1MAT.1 to detect en eventual low state (for external reasons) while the RESn is driven high by P1.1?
BTW: Since the UB3 have its pull-ups (of about 180K (20uA with 3.6VIO)) active during its power-up/reset the 100K pull-down will not prevent gliches because the voltage divider that forms this way (100K+180K) will give 1.17V on RESn.
I've seen also you are now using P1.0 to detect the RST button. So now by pressing the RST will power-cycle the SD that is otherwise pulled-up. I hope that during regular resets issued by UB3 the P1.0 is temporarily switched to output and driven low to power-cycle and thus reset the SD also.
BTW: Since the UB3 have its pull-ups (of about 180K (20uA with 3.6VIO)) active during its power-up/reset the 100K pull-down will not prevent gliches because the voltage divider that forms this way (100K+180K) will give 1.17V on RESn.
That's a typo I think, the pulldown is actually 10~12k. (as you say needed to get a guaranteed low on P2 RST)
@"Peter Jakacki" ( @jmg )
I've seen also you are now using P1.0 to detect the RST button. So now by pressing the RST will power-cycle the SD that is otherwise pulled-up. I hope that during regular resets issued by UB3 the P1.0 is temporarily switched to output and driven low to power-cycle and thus reset the SD also.
Yes, PushButton and any external reset is via P1.0 (20 pin), and other DTR and watchdog resets drive both SD and RESn low.
WS2812B color LED on P43 is a great idea Peter, but it may need to be first level shifted from the 3.3V IO with a FET to give closer to 3.5V minimum logic level. Hopefully even with the WS2812B you can also pass this same pin into that HyperFlash/HyperRAM combo part footprint as the additional chip select.
What dMajo has pointed out about the reset signal seems a concern. If there is only a weak pullup in UB3 of 180K and you need to resort to driving the P2 reset active high from the UB8 because of this then we can't reset via the RST# line pin from the ESP32 or other on board system devices for that matter without shorting the driver in the UB8. Maybe that was the intent but this would be a serious limitation if we can't safely pull this reset signal low ourselves. Maybe a higher resistance pulldown resistor on the P2 reset pin could help this?
That's a typo I think, the pulldown is actually 10~12k. (as you say needed to get a guaranteed low on P2 RST)
Yes, PushButton and any external reset is via P1.0 (20 pin), and other DTR and watchdog resets drive both SD and RESn low.
Seems I cross posted before reading your answer jmg, and the schematic shows that P1.0 is not passed into the P2PAL or brought out externally only RST# is available, so it sort of needs to work for any other device to fully signal the hard reset of the P2D2, including the ESP32 for that matter.
The glitch maybe solved but the shorting problem still exists if the internal P1.1 UB3 pullup level is 180k and the external P2 reset pull down resistor is 10-12k. How do we safely pull down RST# without shorting the driver? It could be better to add a small series resistor from that pin before the pull down resistor perhaps? It might be nice to be able to sense this pin going down by the UB3, in order to take action on the SDON signal but I don't see how this is possible if being actively driven unless it reports the actual pin input voltage is low while shorted low externally...
Just because it has an 8051 core doesn't mean the I/O is identical to the quasi-bidirectional I/O of the original 8051 I/O. The pullups are programmable, as are CMOS drive and even the strength too. With 100k pull-down (but maybe it is 10k, I will check), the P2 is held in reset by the "brown-out reset circuit", that is the UB3 chip. That is why it drives the P2 reset and external resets via USB or via push-button or external signal are into the UB3. But this "reset input" also goes low on any reset event so external circuits can use this signal to reset themselves and this same signal drives the supply switch to the SD so it also "resets" the SD unconditionally. In fact, this was the primary use for this I/O, to simply have a way to reset the SD but when I changed the P2 reset to a default pull-down, this became the input.
Funny thing about all the WS2812 devices that I have ever used is that I never have any trouble driving them from 3.3V signals. I guess if the 5V supply was on the high side that this might be a problem but I had networks of Prop chips each with a WS2812 as a status LED, and they always worked. However as I recheck the datasheet it species the supply volts minimum as 3.5V which makes the 3.6V supply I have an ideal candidate and brings Vih(max) down to 2.5V.
P2PAL access this external reset I/O pin so that the reset button on it does the same thing as the reset button does on a bare P2D2. There is never any contention on any of these lines. Nothing else accesses P2 RESn and neither can the P2 drive its own reset low as it does in the P1.
That's a typo I think, the pulldown is actually 10~12k. (as you say needed to get a guaranteed low on P2 RST)
Yes, PushButton and any external reset is via P1.0 (20 pin), and other DTR and watchdog resets drive both SD and RESn low.
Seems I cross posted before reading your answer jmg, and the schematic shows that P1.0 is not passed into the P2PAL or brought out externally only RST# is available,..
That may be miss-labeled. The older layout I have has PButton on the 50 mil header.
P2 main board P2 reset pin is RESn and the slave board is tagged RST, which does not seem to exist on main board.
The glitch maybe solved but the shorting problem still exists if the internal P1.1 UB3 pullup level is 180k and the external P2 reset pull down resistor is 10-12k. How do we safely pull down RST# without shorting the driver? ...
The UB3 has a light drive mode, that we measure at 12~14mA when in contention (Hi pulled low) which is below any damage levels - but I think external reset is across the button, which is light pullup.
That may be miss-labeled. The older layout I have has PButton on the 50 mil header.
P2 main board P2 reset pin is RESn and the slave board is tagged RST, which does not seem to exist on main board.
Yeah I hope just a PCB net labeling problem, it would be awful to make a bunch of P2D2 boards with the incorrect reset pin exposed on the headers. So it sounds like the net going out to the pin header is the SDON, not RSTn. That should allow us to pull it down externally and reset everything. It would then all make sense if the P2PAL reset pushbutton gets paralleled with the push button on the main P2D2, so perhaps this is just a labeling issue.
I hadn't checked the header schematic labeling and normally this would have been thrown up as an error but I did some manual net reassignments first just to get things right and now I'm making sure the schematic is correct by checking that everything matches when I update the pcb from the schematic etc. Normally this isn't a problem with a fresh design, but I was checking to see what I could do with the pcb first. The header is actually RESET as it has been labelled in the updated main schematic.
There's a lot of stuff going onto the P2LAB motherboard which is starting to look more like a PC with everything that can be connected to it. The board is designed to fit into a standard 170x120x50mm polycarb enclosure so that the "lid" becomes the base which makes it easier to cut out notches for connectors and have the box come down over the connectors, so there is no need for holes and for extra wrangling clearances since there is no wrangling involved.
Besides the many things I have outlined before I am looking at using USB-C connectors direct to the P2 I/O through resistors in place of dedicated HDMI or VGA connectors. Then I will make up some little included adapter dongles for HDMI, DisplayPort, and even VGA etc so that all you need are USB C cables to plug into the P2LAB and an adapter dongle on the other end that it plugs into to. So VGA vs HDMI is basically software configuration of the P2 smartpins. The USB C sockets are cheap and small and have 12x2 pins. While I may have VGA/HDMI connectors on the main board, I can see USB-C being quite versatile for all kinds of stuff.
I'm also allowing for a TFT touchscreen display to be plugged in directly into the pcb so that anything up to a 7" screen can be fitted onto the top (bottom flipped up). It seems sensible to include an internal speaker option too so I will add a 2-pin header to the board to allow for that.
Standard size SD card slots are on the front and besides the ESP32 that will be on the P2PAL, I will also allow for my W5500 modules for hard-wired connections plus mikroBUS modules as well.
I will check out the spec on B5 but IIRC the +5V powers the "cable electronics" so I would guess yes. Those tiny USB power switches that I use on P2D2 should work.
P2LAB is a large but simple board to layout which gives the P2D2 and P2PAL designs time to "mellow" as I find that if I hold off after I'm finished, I usually make some improvements. If I don't, then it's ready
So I look forward to being able to use my USB-C cables to connect up HDMI or VGA and these will plug in directly into the monitor via the little in-line adapter dongle. Of course the other end could be anything that takes up to 10 smartpins. I'm just wondering about sharing some of those RX/TX signals between connectors as I don't expect to run multiple monitors and some end-point might only be using serial or I2C.
I want to be totally finished this week so I can get boards back next week or asacvp.
USB-C is meant to be plugged in either way and work, if you don't have symetric pin layouts then you are going to have issues with things plugged in the wrong way and not working or worse powering/shorting the wrong thing.
USB-C is meant to be plugged in either way and work, if you don't have symetric pin layouts then you are going to have issues with things plugged in the wrong way and not working or worse powering/shorting the wrong thing.
Yes, I'm well aware of this and also one of the things I like about the connector. I use them all the time and I wouldn't be able to entertain this idea with anything but the P2 and its smartpins. I need to have some indication which way it is plugged in so software can configure the pins correctly. At present I am just doing up the footprints for these connectors and I need to read more about the other USB-C pin functions.
I will check out the spec on B5 but IIRC the +5V powers the "cable electronics" so I would guess yes. Those tiny USB power switches that I use on P2D2 should work.
P2LAB is a large but simple board to layout which gives the P2D2 and P2PAL designs time to "mellow" as I find that if I hold off after I'm finished, I usually make some improvements. If I don't, then it's ready
So I look forward to being able to use my USB-C cables to connect up HDMI or VGA and these will plug in directly into the monitor via the little in-line adapter dongle. Of course the other end could be anything that takes up to 10 smartpins. I'm just wondering about sharing some of those RX/TX signals between connectors as I don't expect to run multiple monitors and some end-point might only be using serial or I2C.
I want to be totally finished this week so I can get boards back next week or asacvp.
I recognise that you probably aren't attempting to provide a fully USB Type-C compliant port here; are the little in-line adapter dongles active or passive? If passive, is Vconn even needed? If active, are they looking for a USB host to negotiate Alternate mode with?
Per USB-C standards to support connector reversal, as the P2 is providing the Downstream Facing Port (DFP), without Power Delivery (PD) it is meant to have inline resistors between the power rail and pins A5 and B5, and monitor both pins for a pull-down from the connecting device. In a passive cable only one of these will be pulled down, allowing the signals to be mapped correctly by the host.
As it doesn't look like you are offering connector reversal functionality maybe you should include an indicator LED controlled by the state of A5 (CC1) to show that it is plugged in the right way up; No cable, or wrong way up giving no light. Otherwise the display is probably going to be very confused.
As for using some of those pins, as you are using a USB-C connector it would seem sensible to me to allow the use of A6/7 and/or B6/7 for USB connectivity.
Peter,
Ah ok, yeah being able to reconfigure the pin/smartpins to whichever way they plugged in the usb-c cable is very cool, as long as you can detect which way.
My Protel99SE doesn't seem to have a way of specifying a plated slot rather than a hole. In the past I have drawn the slot with a track on a mechanical layer and specified that has the plated through slot layer with maybe a via in the same place to make sure the netlist is intact. Does anybody know how to do it in this venerable package? No doubt the high end Altium would do it, but I'm not spending $$$$ for that although I would like to change over at some stage (sigh) to Kicad or Diptrace.
Back then it was all done with diagrams on the mechanical layers. A track of the desired length and width was used for the slot parameters and placement on one of the mechanical layers. However, not sure that it would end up with a plated slot these days with all the automation.
Unfortunately might be time to bite the bullet and use KiCad
I may have to join you there too as my legal Protel99SE isn't cutting it these days either. Shame as I have all those footprints!
My Protel99SE doesn't seem to have a way of specifying a plated slot rather than a hole. In the past I have drawn the slot with a track on a mechanical layer and specified that has the plated through slot layer with maybe a via in the same place to make sure the netlist is intact. Does anybody know how to do it in this venerable package?
You may be best to place a unique sized hole at each end, and simply massage the drill file.
@jmg - yes that is the painful manual method But I suppose I can use the 3D viewer to confirm my text file manipulation works since I have to fudge the header Protel's text file anyway for the gerber to work.
Comments
Having worked with Tachyon and the EASYNET module (thanks @"Peter Jakacki" ) via WIZ5x00 chips I really liked having 4 or 8 sockets available
for 'simultaneous' use for Telnet, FTP, HTTP, STP, ... connected via fast SPI.
With only a serial link between ESP32 and P2 this would have to be handled in SW playing together on both sides.
And would probably be slower as well.
The interface provided by EASYNET.fth I was really easy to use and quite powerful.
Do we need a WIZ5500 emulator for ESP32 ??
If anyone has a connection scheme they think will work, then I will look into it.
@MJB - The P2 can communicate serially at very high speeds with the help of the smartpins so 40Mbd is quite feasible although there would be a practical limit there somewhere especially with the ESP32 itself. The ESP32 is supposed to provide serial coms at least and with the larger memory on the 32D the P2 can load it up with common files that it can serve up I guess. Until I've had time to play with it, I can't say what changes might be needed. I have to be careful at this point though that the ESP32 doesn't interfere with the normal operation or hog the resources of the P2 that it is meant to support.
Actually Peter, looking at your P2PAL board layout, given the proximity of the PSRAM to the four ESP32 HSPI bus pins, it may be possible to check if these PSRAM pads can be also solder jumpered though into these ESP32 holes as an option (maybe via a resnet for safety). They are right near the PSRAM so it could be doable. ESP IO14, IO12, IO13 and IO15 comprise the HSPI which I read can be operated as a slave, but should be checked. It's almost an ideal position for these signals too and you shouldn't need 4 layers. Have a look to see what you think.
On the P2D2 there are multiple options for the same component and to simplify the schematic I used the trick of overlaying them in the same position so that you see only one component although there are multiple labels. This applies to the microSD socket and LEDs mainly. There are also optional components that could go on the reverse if needed and these have a light blue background. Components that aren't fitted have a light pink background.
@rogloh - can you let me know which actual pins I could connect up from the ESP32 to the P2? There are so many different names and functions for these pins, so I just want to be sure before trying to connect them.
1) ESP32 and P2 can communicate serially via P2 pins 62/63
2) ESP32 can reset the P2 for Wifi remote downloads
3) P2 can enable/disable the ESP32, or have it startup by default if this P2 control pin is to be used for other purposes
4) P2 can serially re-program the ESP32, or just have it startup normally from its own flash by default
5) provide an optional SPI interface for controlling ESP32 out of band from P2 or for multiplexing multiple sockets/channels etc
6) some type of status pin/interrupt between the P2 and ESP to trigger servicing/waking etc, (ideally shared with same P2 pin needed for doing item 4).
7) provide an optional secondary serial interface, so debug vs application output can be separated.
If we have all of 1-7 with the minimum set of P2 pins used I think this will be very good.
Roger.
P2 PIN ESP32 GPIO ESP32-WROOM32 Notes 63 (Rx in) TXD0 35 62 (Tx out) RXD0 34 .. 55 EN 3 Pull high to enable by default, low to disable module, pullup resistor should be fitted. 54 GPIO0 25 Pull high by default to run, or low to reprogram module, pullup resistor should be fitted. .. 51 HSPICS0 (IO15) 23 Wired this exact way you can still share both the PSRAM and Wifi SPI in 1 or 2 bit mode, 50 HSPICLK (IO14) 13 but it would be a good idea to put a small series resistor on the HSPID and Q lines 49 HSPIQ (IO12) 14 so any accidental full QSPI(4 bit) access to the PSRAM when Wifi is fitted doesn't 48 HSPID (IO13) 16 short out with the PSRAM if the ESP32 image also happens to respond by mistake. All these 4 HSPI connections should be via a solder jumpers to enable only if required. .. 9 U2TXD (IO17) 28 Secondary serial - via solder jumpers to allow full disconnect from port A, fit series resistor? 8 U2RXD (IO16) 27 Secondary serial - via solder jumper. RST# IO32 8 A diode connection from the ESP32 to the reset input of the P2D2 EFM chip will allow full H/W reset - MTDI 14 Shared with HSPIQ/IO14 pin, maybe pulldown low (though it already defaults low for 3.3V LDO) - GPIO2 24 Float or pulldown (defaults low anyway) - GPIO5 29 Float (defaults high anyway, I believe this is a don't care as we don't use the SDIO slave)Wired this way you should be able to do the following:1) provide a standard Wifi serial channel via P62/63
2) reboot the P2 by ESP output pin (the ESP32 RTC /ULP state machine processor can also then reset the P2 while sleeping, this could become handy to still control the P2D2 even from a wifi sleep mode)
3) shutdown the ESP32 to save power
4) re-progam the ESP32 from the P2 by holding GPIO0 low during ESP startup once EN goes high
5) control the ESP32 via the P2 over an optional SPI slave interface, with the ability to keep an SPI PSRAM/Flash chip on the P2PAL still operating in parallel if desired
6) interrupt the P2 from the ESP32 using GPIO0 pin after ESP startup, for status or ISR reasons, or for other flow control use etc
7) provide an optional secondary Wifi serial channel on P2 port A pins 8/9
8) wake up the ESP32 if it is sleeping by pulsing any of its RTC IO pins from the P2 which do include those fitted for HSPI or GPIO0
The good thing about this approach is that it is flexible and you can reduce it for pin constrained setups or enable more capabilities if you enable the solder jumpers.
For example, there are at least 4 different use cases possible:
(for b,c,d it would be good to have solder jumpers to enable them)
a) Use 2 Prop2 RX/TX pins only with EN/GPIO strapped for default operation, along with the optional P2D2 HW reset when the diode is fitted
b) Add 2 optional GPIO0 & EN P2 pins to re-program the ESP32 and/or reset it, instead of permanently starting it up
c) Add 4 more P2 pins for a SPI SLAVE interface, while still keeping PSRAM functional (4 pins shared with PSRAM)
d) Add 2 more P2 pins for a secondary serial interface
I only really wonder if we need to allow for a pull down resistor to be fitted to IO15 to stop any debug output on TXD0 by default during ESP32 startup as this extra serial output may not be desired on TXD0 when the P2 is also booting, however as mentioned in another post above the 220 ohm resistor from the EFM serial output may overpower the 1k resistor fitted on the ESP32 TXD0 line and help save us there even without this pulldown. The only problem I see with using a pulldown is that it sort of enables HSPICS0 by default, but maybe try to layout for a DNP pulldown resistor just in case it is warranted.
I had a look to your P2D2 schematic.
As I understand now UB3-P1.1 is driven always high (due to 100K pull-down on RESn) to take P2 out of reset hence UB3 can't monitor the status of the reset line.
Are you perhaps using P1MAT.1 to detect en eventual low state (for external reasons) while the RESn is driven high by P1.1?
BTW: Since the UB3 have its pull-ups (of about 180K (20uA with 3.6VIO)) active during its power-up/reset the 100K pull-down will not prevent gliches because the voltage divider that forms this way (100K+180K) will give 1.17V on RESn.
I've seen also you are now using P1.0 to detect the RST button. So now by pressing the RST will power-cycle the SD that is otherwise pulled-up. I hope that during regular resets issued by UB3 the P1.0 is temporarily switched to output and driven low to power-cycle and thus reset the SD also.
Yes, PushButton and any external reset is via P1.0 (20 pin), and other DTR and watchdog resets drive both SD and RESn low.
What dMajo has pointed out about the reset signal seems a concern. If there is only a weak pullup in UB3 of 180K and you need to resort to driving the P2 reset active high from the UB8 because of this then we can't reset via the RST# line pin from the ESP32 or other on board system devices for that matter without shorting the driver in the UB8. Maybe that was the intent but this would be a serious limitation if we can't safely pull this reset signal low ourselves. Maybe a higher resistance pulldown resistor on the P2 reset pin could help this?
Seems I cross posted before reading your answer jmg, and the schematic shows that P1.0 is not passed into the P2PAL or brought out externally only RST# is available, so it sort of needs to work for any other device to fully signal the hard reset of the P2D2, including the ESP32 for that matter.
The glitch maybe solved but the shorting problem still exists if the internal P1.1 UB3 pullup level is 180k and the external P2 reset pull down resistor is 10-12k. How do we safely pull down RST# without shorting the driver? It could be better to add a small series resistor from that pin before the pull down resistor perhaps? It might be nice to be able to sense this pin going down by the UB3, in order to take action on the SDON signal but I don't see how this is possible if being actively driven unless it reports the actual pin input voltage is low while shorted low externally...
Funny thing about all the WS2812 devices that I have ever used is that I never have any trouble driving them from 3.3V signals. I guess if the 5V supply was on the high side that this might be a problem but I had networks of Prop chips each with a WS2812 as a status LED, and they always worked. However as I recheck the datasheet it species the supply volts minimum as 3.5V which makes the 3.6V supply I have an ideal candidate and brings Vih(max) down to 2.5V.
P2PAL access this external reset I/O pin so that the reset button on it does the same thing as the reset button does on a bare P2D2. There is never any contention on any of these lines. Nothing else accesses P2 RESn and neither can the P2 drive its own reset low as it does in the P1.
Traces
1 yellow = P2 RESn
2 cyan = SCL
3 magenta = SD CLK
4 Blue = 3.6V
P2 main board P2 reset pin is RESn and the slave board is tagged RST, which does not seem to exist on main board.
The UB3 has a light drive mode, that we measure at 12~14mA when in contention (Hi pulled low) which is below any damage levels - but I think external reset is across the button, which is light pullup.
Besides the many things I have outlined before I am looking at using USB-C connectors direct to the P2 I/O through resistors in place of dedicated HDMI or VGA connectors. Then I will make up some little included adapter dongles for HDMI, DisplayPort, and even VGA etc so that all you need are USB C cables to plug into the P2LAB and an adapter dongle on the other end that it plugs into to. So VGA vs HDMI is basically software configuration of the P2 smartpins. The USB C sockets are cheap and small and have 12x2 pins. While I may have VGA/HDMI connectors on the main board, I can see USB-C being quite versatile for all kinds of stuff.
I'm also allowing for a TFT touchscreen display to be plugged in directly into the pcb so that anything up to a 7" screen can be fitted onto the top (bottom flipped up). It seems sensible to include an internal speaker option too so I will add a 2-pin header to the board to allow for that.
Standard size SD card slots are on the front and besides the ESP32 that will be on the P2PAL, I will also allow for my W5500 modules for hard-wired connections plus mikroBUS modules as well.
More details to follow.
This is the HDMI mapping for the connector.
Are you putting +5V power on B5 ???
If so, isn't VBUS meant for power, and, doesn't allow for upside down plugging?
P2LAB is a large but simple board to layout which gives the P2D2 and P2PAL designs time to "mellow" as I find that if I hold off after I'm finished, I usually make some improvements. If I don't, then it's ready
So I look forward to being able to use my USB-C cables to connect up HDMI or VGA and these will plug in directly into the monitor via the little in-line adapter dongle. Of course the other end could be anything that takes up to 10 smartpins. I'm just wondering about sharing some of those RX/TX signals between connectors as I don't expect to run multiple monitors and some end-point might only be using serial or I2C.
I want to be totally finished this week so I can get boards back next week or asacvp.
Yes, I'm well aware of this and also one of the things I like about the connector. I use them all the time and I wouldn't be able to entertain this idea with anything but the P2 and its smartpins. I need to have some indication which way it is plugged in so software can configure the pins correctly. At present I am just doing up the footprints for these connectors and I need to read more about the other USB-C pin functions.
I recognise that you probably aren't attempting to provide a fully USB Type-C compliant port here; are the little in-line adapter dongles active or passive? If passive, is Vconn even needed? If active, are they looking for a USB host to negotiate Alternate mode with?
Per USB-C standards to support connector reversal, as the P2 is providing the Downstream Facing Port (DFP), without Power Delivery (PD) it is meant to have inline resistors between the power rail and pins A5 and B5, and monitor both pins for a pull-down from the connecting device. In a passive cable only one of these will be pulled down, allowing the signals to be mapped correctly by the host.
As it doesn't look like you are offering connector reversal functionality maybe you should include an indicator LED controlled by the state of A5 (CC1) to show that it is plugged in the right way up; No cable, or wrong way up giving no light. Otherwise the display is probably going to be very confused.
As for using some of those pins, as you are using a USB-C connector it would seem sensible to me to allow the use of A6/7 and/or B6/7 for USB connectivity.
Ah ok, yeah being able to reconfigure the pin/smartpins to whichever way they plugged in the usb-c cable is very cool, as long as you can detect which way.
Unfortunately might be time to bite the bullet and use KiCad
I may have to join you there too as my legal Protel99SE isn't cutting it these days either. Shame as I have all those footprints!
Above is Kicad drill file output, last item is a 3mm slot with a 1.123mm tool width, so G85 looks like the make-slot code.