Personally I don't have plans for this clock generator, but others might and perhaps the phase adjustment of the main clock could help with tweaking sysclock/1 operation of HyperRAM.
In case you didn't see this update to my earlier post on HyperRAM Peter.
Update: phoned ozpropdev and he said the control pins are fine. It's arbitrary in his driver code. Having the clock signal immediately following the 8 bits of data may help with any byte banging using 9 bit direct writes to portB with alternating top bits for the clock. You could set CS low manually before the transfer and directly send bytes+clock using individual writes, so I think the mapping above is handy.
Here is the latest artwork pending design rule checks and tweaking. The RPi header has P0..P26,P28,P30 while only solder bridging a single ground pin for P18. All the signals are available in order on the main headers as well as the SMD headers.
Cool. Glad you were able to get most of the contiguous pin group to squeeze through Peter, this can help if people want to make 24 bit parallel RGB LCD breakouts using these pins (though that's only one use). Be nice if P27 could replace P30 but that gap in the upper byte is less of an issue than the original missing P18 was as these upper pins can always be LCD control pins and are a little more flexible, though P24 is rather useful to keep for sync/DE reasons with the DAC and you've still got that one too.
Here are the latest 3d pcb renderings that I intend to have running by the end of the month. I still have some tweaks on P2PAL, and I need to finalize the P2LAB motherboard.
BTW, I'm using the ESP32 modules that are cheaply available from Mouser etc but I've never used them before. I'm guessing that a serial WiFi connection is possible and in which case I would have TAQOZ handle either input for console connection. The P2PAL is an optional thin PCB that surface-mounts just like a component itself to the bottom of the P2D2.
How'd the trace matching go on the HyperRAM data lines?
Will the P2PAL board need to overhang the P2D2 in length if the ESP module is not fitted? It would be rather nice if the footprint remained the same. Can it be shortened? Ideally the boards would be both the same length (even if Wifi was fitted). I'm not sure it will fit my enclosure now if it does overhang like that, or maybe that is a rendering issue with the Wifi module outline...? UPDATE: Looking again at my enclosure size, I think this Wifi antenna overhang may actually just fit If it didn't there's always the shorter ESP32-WROOM-32U model I could use with the external antenna which could work for me too.
Update: Also do you have a schematic for the P2PAL to see how you'll be using your P2 pins for the Wifi module and other peripherals? Eg. will Wifi module be able to reset/download to the P2D2 remotely for example?
Update2: BTW, HyperRam label is misspelled on the board, needs two R's in the word.
Update3: Maybe you are yet to do this but how will the 0.2F supercap power on the P2PAL get down into the lower board?
Update4: Looking at the image it appears there are some pads near the P2D2 USB connector, hopefully these are some that could be wired for remotely mounting the USB connector elsewhere when the P2D2 is embedded inside another product/enclosure. Ideally they'd be aligned to the grid and with a suitable mating connector could then feed in the D+/D- signals through a system board that had the USB programming port exposed elsewhere, instead of soldering flying leads... Is this possible Peter?
I've sort of reversed engineered out the pins from what I can tell in the image (may be incorrect) and it looks rather good for the following use of peripherals, which frees up PortA completely:
PIN32-42 : HyperRAM/RTC
PIN43-47 : free (could be good for 5 pin VGA as RGBHV and/or status LEDs)
PIN48-53 : 6 pin QuadSPI FLASH/PSRAM
PIN54-55 : free (could be good for a USB keyboard/mouse, hopefully eventually USB code will become hub capable)
PIN56-57 : I2C
PIN58-61 : SD/SPI
PIN62-63 : USB/SERIAL/WIFI?
BTW, I'm using the ESP32 modules that are cheaply available from Mouser etc but I've never used them before. I'm guessing that a serial WiFi connection is possible and in which case I would have TAQOZ handle either input for console connection.
Here's the schematic for the newer version of the P2PAL and the current layout which is still being tweaked. I read what I could read about the ESP32 and the boot modes etc so I think I have enough options on there to use it well. The ESP32 can be the main coms port for the P2 so remote programming is possible because I can make the UB3 (USB serial and support micro) on the P2D2 detect the load strings and pulse reset etc. There's also another secondary serial port that is connected too.
I haven't done any track length optimization for the HyperRAM on this version because it is too awkward on a double layer pcb but I could do one on a future multilayer that also compensated for the P2D2 tracks as well. But this is where I might try to make the shift from Protel99SE to Kicad or Diptrace.
Since I was feeding VIO (3.6V) from the P2D2 switcher directly to the ESP32 which can draw 500ma or so at times, I decided to power the other chips direct from this as well. It's all within spec and quite safe for the chips and for the P2 I/O. The extra RTC caps are optional as they are also optional on the P2D2 reverse side where this layer would be meshed to the P2D2. Since it is surface-mounted, the P2PAL directly interfaces to those RTC cap pads on the P2D2 itself. All the other connections are made to the 50mil pitch SMD pads. The PCB will probably be 0.6 or 0.8mm thick since it is mating directly to the P2D2 itself.
BTW - this PCB would be castellated - so the pcb cut edge is down the center of the header holes.
Please let me know if there is something practical I could change with the HyperRAM and ESP32 to make it better.
Please ignore the XMC1100 micro - it's something that I could fit in and I'd like to experiment with it but it won't be fitted (unless you really want it).
I will post the schematic for the P2D2r5 here as well - just ignore any unconnected component and "shorts" though, I've just been making some changes.
Thanks for posting the P2PAL schematic Peter, as it helps us figure out how best to use/improve it.
Few suggestions:
Unfortunately I'm no expert on ESP32 but it would be good to not force us to have all these extra pins always connected to it, e.g. P54-P55, P4-9, unless desired or absolutely required to enable the ESP32 to function, so maybe solder jumpers that can be bridged to connect or remove the link would be handy. I do expect certain pins on the ESP32 may need to be strapped high/low for boot modes, at least that was the case on the 8266 device.
Right now I don't yet see how the ESP32 can reset the P2D2. It would be very good to have this capability for reprogramming the P2 over the air. Depending on how you wire and drive the P2 reset for pullup/pulldown, maybe a diode is required there too to prevent shorts.
LEDS: I do like your 4 LEDs for status, they are always handy. It might be useful to add a very small quad buffer chip or discrete transistors if they fit, so these P2 pins could remain functional as high impedance inputs instead of being loaded down by the LEDs at all times.
HyperRAM connections to the P2 look okay, and I think the HyperRAM should still be pretty usable without perfect trace matching, it just might not overclock quite as high. The P2-EVAL doesn't match trace lengths and the traces are probably slightly longer than your small board, yet that still manages over 300MHz on its worst group of pins.
One thing I would consider doing is try to route P43 to the unused second CS input (CS1#) in the HyperRAM footprint for those special combo devices (HyperFLASH+HyperRAM) that can use the extra chip select to access the second device. That gives the option of populating that combo device too on your board one day. I believe this extra pin would be not connected in regular HyperRAM so it won't load it unless that special part is populated, or if you are worried it might load it, maybe solder jumper enable this extra P43 connection somewhere on the P2PAL
Thanks Roger - I will add the extra pin for HyperFlash.
I was thinking that these extra ESP32 pins would be configurable so I could leave them disconnected in software but I haven't played with the IDE yet. I will see if I can add those solder pad jumpers and leave them normally open.
My thinking with the LEDs was mainly that because they are directly connected via the anode that I could use them for sensing apps too with perhaps a different color for each one. If only they made LEDs like they make all IC's, with resistors and buffers I wish. The P2LAB board is a better candidate for LED indicators though which is why I won't bother with buffered these ones although I might make it a 3k3 resistor there. I think there might be apps where we don't have LEDs connected etc but I try to overthink this too much otherwise I will never get it done.
The little EFM8UB micro onboard the P2D2 can be made to detect the auto-baud > sequence that the loader uses and reset the P2, although I still need to try this though. The P2 reset is driven directly from the UB3 and the external reset and reset button drive the UB3 so that when the P2 is reset, the external reset is also driven low by the UB3.
...
Right now I don't yet see how the ESP32 can reset the P2D2. It would be very good to have this capability for reprogramming the P2 over the air. ..
I've not tried ESP32, but maybe it could use the back channel UART commands, as they include this command (4 bytes sent )
0xF5,0xE5,0xFA,0xA5 does a SW reset on UB3 and that resets P2
That would need UB3 and ESP32 to agree on some default baud speed - maybe 115200 ? - UB3 can default to pretty much anything (24M/N)
@jmg - I'd use the '> Prop_Clk 0 0 0 0 ' type loader prompts to do this or more correctly the '> Pr' part of it should do the trick. The loader might have to retry due to the delayed reset which only needs to happen on the first prompt or on any prompt after a timeout. I will play with that later to confirm that works.
The little EFM8UB micro onboard the P2D2 can be made to detect the auto-baud > sequence that the loader uses and reset the P2, although I still need to try this though. ...
The P2 uses smart pins to extract the '> ', so it can extract timing at any baud setting. The UB3 lacks that hardware.
The UB3 would need to assume some default baud, which it could do after reset, but anytime it USB connected, the PC baud would replace that baud setting.
Yeah Peter if all these extra ESP pins are not normally connected and just float then it would be okay to leave them connected, but you'd want to check that. A solder jumper plays it safer if they can fit. It certainly looks a squeeze
The reset path gets interesting and is important. If there was a diode footprint from a nearby free ESP32 GPIO, with the cathode facing ESP32, and anode going to RST (which appears to then goes to P1.0 of the UB3, shared with SDON signal by the looks of the P2D2 schematic) then pulling this line low will allow the UB3 to be reset by the ESP32 when the pin is driven active low. Floating it or otherwise driving it high from the ESP32 will not cause any operational issues. It might give you a safer way to do a full remote reset in the future without needing to develop extra UB3 code to try to sense things on the serial pins, and we can always leave the diode out if we don't need it. Probably safe to just add the diode footprint it if fits. Maybe in the top right corner on the other side of the reset switch pad near the B label at Pin1 ? ESP32 module pin 8 might be suitable (just need to check if special at boot etc).
Another thing to think about is the re-programming of the ESP32 itself and if any lines need to be pulled hi/lo by the P2 for this. You might want to consider this way of wiring perhaps, which may keep it from requiring use of any pins on port A:
P55 for EN_RTS - but via solder jumper to your pullup resistor & EN pin of ESP32 (you already almost have this)
P54 for GPIO0 - via solder jumper, and when unconnected it will be pulled high by the ESP32 and this should boot normally but the P2 could still override it when required to re-program. At runtime, this extra GPIO pin could also then be used for signalling the P2 for wifi status, interrupt wakeup use, etc.
This way the Wifi will default to be enabled and boot up normally if the P54/P55 pins are not connected via the jumpers, but people can always have their solder jumpers configured to allow it to be re-programmed and optionally powered down/reset by the P2 if they want to use P54/P55 for that purpose.
The extra serial port pins etc on Port A are probably reasonable to wire into the P2D2 but it may make sense to float GPIO2 of ESP32 to avoid forcing the P2 to have to control it during flashing of the ESP32 if that pin is ever shared by other devices on port A. I think it's just best to not have to put any particular system constraints on use of port A. Solder jumpers can help disconnect it.
The ESP32 would have to have it's channel set to a baud rate but baud rate is irrelevant over WiFi so the ESP32 would be set the same as the UB3. However, I may do something smart with that little XMC1100 chip I'm playing with, who knows. I might have to hack an ESP32 onto my test P2D2 just so I can see what is possible.
By the way if the Wifi module is to be re-programmed by the P2 it will require the UB3 to tri-state its TX output line during this time because the 220 ohm resistor it connects to will overpower the 1k on the ESP32 and always force the line logic high when idling high.
By the way if the Wifi module is to be re-programmed by the P2 it will require the UB3 to tri-state its TX output line during this time because the 220 ohm resistor it connects to will overpower the 1k on the ESP32 and always force the line logic high when idling high.
All the little gotchas
I'm taking a careful but casual view of the P2PAL at the moment as I'm expecting to find these little gotchas here and there and then roll out an improved version for another batch.
BTW, do we still have used for a programmable clock output or two that I have available from the P2D2 Si5351?
All the little gotchas
I'm taking a careful but casual view of the P2PAL at the moment as I'm expecting to find these little gotchas here and there and then roll out an improved version for another batch.
I know. Only trying to assist getting it working successfully on hopefully the first rev so we all get it sooner. One problem is once the P2PAL board is bonded to the P2D2 it would be quite hard for us to replace if a problem/shortcoming is found later...so ordering the fixed board revision may not be ideal. Maybe a strip of 0.05 inch headers could be useful to plug into for initial debug test/development before committing to soldering it down.
All the little gotchas
I'm taking a careful but casual view of the P2PAL at the moment as I'm expecting to find these little gotchas here and there and then roll out an improved version for another batch.
I know. Only trying to assist getting it working successfully on hopefully the first rev so we all get it sooner. One problem is once the P2PAL board is bonded to the P2D2 it would be quite hard for us to replace if a problem/shortcoming is found later...so ordering the fixed board revision may not be ideal. Maybe a strip of 0.05 inch headers could be useful to plug into for initial debug test/development before committing to soldering it down.
Of course I will try to get it right the first time, at least the first time that I get it right that is
You have to think of the P2PAL as another layer or component. Just like there are 100 or so P2 Rev A eval boards out there, it is what it is. Actually, I think the P2PAL could be removed easily enough since it is fairly easy to lift when reflowing with hot air.
If it were me I would probably just try to put secondary ESP32 serial TX/RX pins to P8 and P9 (keeping full lowest 8 bits of port A free), and have all these pins via solder jumpers.
eg. something like this would be good:
P8 - RX2 via solder jumper
P9 - TX2 via solder jumper/resistor (you might have room for this near UX1)
P54 - GPIO0 - via solder jumper/resistor to P2 and external pullup to enable SPI boot by default instead of re-program.
P55 - WIFI EN - via solder jumper to P2 and external pullup to enable by default.
A nearby GPIO from ESP32 via optional diode path to RST. GPIO32 (module Pin8) might be good though it also has secondary use for 32kHz input, so it needs to be checked. Some other nearby pins suggest they are inputs only which would be no good for a reset.
Other pins of interest in the ESP32 are apparently these but they may not need to be passed to the P2.
MTDI - default pull down will set voltage to 3.3V for on module FLASH
GPIO2 - default pull down will already allow reprogramming when GPIO0 is pulled down at ESP startup
MTDO - possibly wire to a pull down to avoid ESP debug log being output on TXD0 serial lines during ESP32 boot which may mess up P2's own boot?
GPIO5 - does this need consideration for SDIO slave along with MTDO?
By the way if the Wifi module is to be re-programmed by the P2 it will require the UB3 to tri-state its TX output line during this time because the 220 ohm resistor it connects to will overpower the 1k on the ESP32 and always force the line logic high when idling high.
UB3 is coded to default to light pullup, and only goes to CMOS drive when USB connected.
When USB disconnected, it also reverts to light pullup.
One more idea I had looking at your board Peter...it might make sense to have room for a soldered ground pin loop for scoping use etc. You might have room on the bottom corner of the board for this. There are these special hook loops that make things easy to connect to, or you can simply solder your own loop of wire as shown in the red attachment to your PCB. Just need the holes drilled. Saves trying to connect onto other ground connectors when they are already in use etc. Nice to have this always available.
@rogloh - on practically every board I design I allow for a 2-pin ground header since I've found that is the easiest and cheapest "ground connector". With two pins I can clip to it very easily, and it holds. With two pins I can slip a meter probe between them and with the groove that they have in the probe tip, it holds. With pin header cables and logic analyzers I can plug them right in, and it holds. I also have a tiny bit of matrix board with pin headers and a pin header wire so I can plug it in and then connect all those bulky scope probes etc to it etc.
But the P2D2 already has so much packed into it in less than a quarter of the size of the P2 EVAL, plus it has so many pin header connections on it already!
However - if I can fit something extra in, I will. (I now have)
Very cool Peter. I had thought something might fit in that spot and this P2D2+P2PAL board combo is just getting better and better. I look forward for it to ship and then I can continue my own design using it. It's actually already about 99.5% perfect for my application with the added HyperRAM and Wifi (assuming P2 port A is not going to be required for Wifi use, and if it is that P8-P9 are used for its second channel).
One thing I forgot to mention earlier about the HyperRAM, Peter, was that @evanh previously found that adding an optional capacitor to ground from the clock line can also help with write performance at sysclk/1 rates. I'm not sure you have the room for it on your P2PAL, but if you did, a tiny SMD footprint for a small ceramic cap ~10pF or so (but left unpopulated) going from the HyperRAM clock net down to ground could be handy for that option some day, but it does look pretty packed in there right now. If it can't fit so be it.
On the P2PAL the ESP32 should be wired:
- on P56SCL and P57SDA: for I2C
- on P63 using a dedicated 220R and P62: using ESP32 to P2 comm so the ESP is in parallel with UB3 in regards to RX/TX
- on P61R, P60R, P59R, P58R: for SPI using flash pin layout/meaning
- with an additional link (CS) between ESP32 and P2: so that P2 can have 2 CS to share the SPI bus between flash and ESP32 in SPI slave mode
since P2D2 already have the SD I would use the SD on the P2PAL wired to the ESP32 4bit SD controller peripheral:
- the ESP32 can store the pages of a web-server for product configuration/setup and/or some basic web based GUI
- the ESP32 can serve contents from its SD through one of the above communication channels to the P2 (eg the ESP32 SPI slave link)
With the above communication channels the ESP32 can:
- reset the P2 and request RX/TX exclusive access through the I2C command to the UB3
- program P2 through RX/TX
- directly program the P2 flash acting as SPI master with P61R (P2 kept in reset by UB3)
- exchange data to P2 (eg ESP32's SD, Web-GUI values, ...) acting as SPI slave or SDIO slave through the additional CS I/O link between the two
- use the I2C between the P2 and UB3 to agree/setup/configure the various operating modes of the other communication channels
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.
Perhaps it will be useful to foresee an external SRAM chip for the ESP32 using the parallel QSPI interface which supports also DMA.
@dMajo - I appreciate the feedback and information there but I've got a feeling that this level of marrying up the ESP32 and the P2 is a whole other board altogether. I'm trying to use this device in the most useful way possible without losing the focus on the P2 chip itself and overly complicating the P2D2 design. I'd have to go to 4 layer board just to route these signals for starters. Besides, I'm not even sure where to start until I do start, which is one of the reasons for integrating it onto the P2PAL Perhaps this new board will be the P2ESP32
Of course I will try to get it right the first time, at least the first time that I get it right that is
You have to think of the P2PAL as another layer or component. Just like there are 100 or so P2 Rev A eval boards out there, it is what it is. Actually, I think the P2PAL could be removed easily enough since it is fairly easy to lift when reflowing with hot air.
Peter: get it first at the right time! There are many chances for changes later if there is an earlier! I will have a few days off end of July/ start of August and then I absolutely need the boards! I build on you. I had to outsource a certain task I intended to solve with the P2D2. Now there is another start window as that project failed, money and time was lost and I have to come back to the original solution. That experience would have allowed me to invest a lot into the P2D2, .... But: there is another window, please take that chance!
Comments
Update: phoned ozpropdev and he said the control pins are fine. It's arbitrary in his driver code. Having the clock signal immediately following the 8 bits of data may help with any byte banging using 9 bit direct writes to portB with alternating top bits for the clock. You could set CS low manually before the transfer and directly send bytes+clock using individual writes, so I think the mapping above is handy.
BTW, I'm using the ESP32 modules that are cheaply available from Mouser etc but I've never used them before. I'm guessing that a serial WiFi connection is possible and in which case I would have TAQOZ handle either input for console connection. The P2PAL is an optional thin PCB that surface-mounts just like a component itself to the bottom of the P2D2.
How'd the trace matching go on the HyperRAM data lines?
Will the P2PAL board need to overhang the P2D2 in length if the ESP module is not fitted? It would be rather nice if the footprint remained the same. Can it be shortened? Ideally the boards would be both the same length (even if Wifi was fitted). I'm not sure it will fit my enclosure now if it does overhang like that, or maybe that is a rendering issue with the Wifi module outline...? UPDATE: Looking again at my enclosure size, I think this Wifi antenna overhang may actually just fit
Update: Also do you have a schematic for the P2PAL to see how you'll be using your P2 pins for the Wifi module and other peripherals? Eg. will Wifi module be able to reset/download to the P2D2 remotely for example?
Update2: BTW, HyperRam label is misspelled on the board, needs two R's in the word.
Update3: Maybe you are yet to do this but how will the 0.2F supercap power on the P2PAL get down into the lower board?
Update4: Looking at the image it appears there are some pads near the P2D2 USB connector, hopefully these are some that could be wired for remotely mounting the USB connector elsewhere when the P2D2 is embedded inside another product/enclosure. Ideally they'd be aligned to the grid and with a suitable mating connector could then feed in the D+/D- signals through a system board that had the USB programming port exposed elsewhere, instead of soldering flying leads... Is this possible Peter?
PIN32-42 : HyperRAM/RTC
PIN43-47 : free (could be good for 5 pin VGA as RGBHV and/or status LEDs)
PIN48-53 : 6 pin QuadSPI FLASH/PSRAM
PIN54-55 : free (could be good for a USB keyboard/mouse, hopefully eventually USB code will become hub capable)
PIN56-57 : I2C
PIN58-61 : SD/SPI
PIN62-63 : USB/SERIAL/WIFI?
Yes, you will need to load the appropriate sw on the ESP32, like this one: https://github.com/AlphaLima/ESP32-Serial-Bridge (there is also an example in the SDK, which is a bit more spartan)
Access on the PC side is done with telnet (Unix) or putty raw mode (Windows), not sure on Mac but assume telnet is available there
I haven't done any track length optimization for the HyperRAM on this version because it is too awkward on a double layer pcb but I could do one on a future multilayer that also compensated for the P2D2 tracks as well. But this is where I might try to make the shift from Protel99SE to Kicad or Diptrace.
Since I was feeding VIO (3.6V) from the P2D2 switcher directly to the ESP32 which can draw 500ma or so at times, I decided to power the other chips direct from this as well. It's all within spec and quite safe for the chips and for the P2 I/O. The extra RTC caps are optional as they are also optional on the P2D2 reverse side where this layer would be meshed to the P2D2. Since it is surface-mounted, the P2PAL directly interfaces to those RTC cap pads on the P2D2 itself. All the other connections are made to the 50mil pitch SMD pads. The PCB will probably be 0.6 or 0.8mm thick since it is mating directly to the P2D2 itself.
BTW - this PCB would be castellated - so the pcb cut edge is down the center of the header holes.
Please let me know if there is something practical I could change with the HyperRAM and ESP32 to make it better.
Please ignore the XMC1100 micro - it's something that I could fit in and I'd like to experiment with it but it won't be fitted (unless you really want it).
I will post the schematic for the P2D2r5 here as well - just ignore any unconnected component and "shorts" though, I've just been making some changes.
Few suggestions:
Unfortunately I'm no expert on ESP32 but it would be good to not force us to have all these extra pins always connected to it, e.g. P54-P55, P4-9, unless desired or absolutely required to enable the ESP32 to function, so maybe solder jumpers that can be bridged to connect or remove the link would be handy. I do expect certain pins on the ESP32 may need to be strapped high/low for boot modes, at least that was the case on the 8266 device.
Right now I don't yet see how the ESP32 can reset the P2D2. It would be very good to have this capability for reprogramming the P2 over the air. Depending on how you wire and drive the P2 reset for pullup/pulldown, maybe a diode is required there too to prevent shorts.
LEDS: I do like your 4 LEDs for status, they are always handy. It might be useful to add a very small quad buffer chip or discrete transistors if they fit, so these P2 pins could remain functional as high impedance inputs instead of being loaded down by the LEDs at all times.
HyperRAM connections to the P2 look okay, and I think the HyperRAM should still be pretty usable without perfect trace matching, it just might not overclock quite as high. The P2-EVAL doesn't match trace lengths and the traces are probably slightly longer than your small board, yet that still manages over 300MHz on its worst group of pins.
One thing I would consider doing is try to route P43 to the unused second CS input (CS1#) in the HyperRAM footprint for those special combo devices (HyperFLASH+HyperRAM) that can use the extra chip select to access the second device. That gives the option of populating that combo device too on your board one day. I believe this extra pin would be not connected in regular HyperRAM so it won't load it unless that special part is populated, or if you are worried it might load it, maybe solder jumper enable this extra P43 connection somewhere on the P2PAL
Here's the data sheet so you can check that extra CS pin...
https://www.cypress.com/file/322936/download
I was thinking that these extra ESP32 pins would be configurable so I could leave them disconnected in software but I haven't played with the IDE yet. I will see if I can add those solder pad jumpers and leave them normally open.
My thinking with the LEDs was mainly that because they are directly connected via the anode that I could use them for sensing apps too with perhaps a different color for each one. If only they made LEDs like they make all IC's, with resistors and buffers
The little EFM8UB micro onboard the P2D2 can be made to detect the auto-baud > sequence that the loader uses and reset the P2, although I still need to try this though. The P2 reset is driven directly from the UB3 and the external reset and reset button drive the UB3 so that when the P2 is reset, the external reset is also driven low by the UB3.
0xF5,0xE5,0xFA,0xA5 does a SW reset on UB3 and that resets P2
That would need UB3 and ESP32 to agree on some default baud speed - maybe 115200 ? - UB3 can default to pretty much anything (24M/N)
The UB3 would need to assume some default baud, which it could do after reset, but anytime it USB connected, the PC baud would replace that baud setting.
The reset path gets interesting and is important. If there was a diode footprint from a nearby free ESP32 GPIO, with the cathode facing ESP32, and anode going to RST (which appears to then goes to P1.0 of the UB3, shared with SDON signal by the looks of the P2D2 schematic) then pulling this line low will allow the UB3 to be reset by the ESP32 when the pin is driven active low. Floating it or otherwise driving it high from the ESP32 will not cause any operational issues. It might give you a safer way to do a full remote reset in the future without needing to develop extra UB3 code to try to sense things on the serial pins, and we can always leave the diode out if we don't need it. Probably safe to just add the diode footprint it if fits. Maybe in the top right corner on the other side of the reset switch pad near the B label at Pin1 ? ESP32 module pin 8 might be suitable (just need to check if special at boot etc).
Another thing to think about is the re-programming of the ESP32 itself and if any lines need to be pulled hi/lo by the P2 for this. You might want to consider this way of wiring perhaps, which may keep it from requiring use of any pins on port A:
P55 for EN_RTS - but via solder jumper to your pullup resistor & EN pin of ESP32 (you already almost have this)
P54 for GPIO0 - via solder jumper, and when unconnected it will be pulled high by the ESP32 and this should boot normally but the P2 could still override it when required to re-program. At runtime, this extra GPIO pin could also then be used for signalling the P2 for wifi status, interrupt wakeup use, etc.
This way the Wifi will default to be enabled and boot up normally if the P54/P55 pins are not connected via the jumpers, but people can always have their solder jumpers configured to allow it to be re-programmed and optionally powered down/reset by the P2 if they want to use P54/P55 for that purpose.
The extra serial port pins etc on Port A are probably reasonable to wire into the P2D2 but it may make sense to float GPIO2 of ESP32 to avoid forcing the P2 to have to control it during flashing of the ESP32 if that pin is ever shared by other devices on port A. I think it's just best to not have to put any particular system constraints on use of port A. Solder jumpers can help disconnect it.
All the little gotchas
I'm taking a careful but casual view of the P2PAL at the moment as I'm expecting to find these little gotchas here and there and then roll out an improved version for another batch.
BTW, do we still have used for a programmable clock output or two that I have available from the P2D2 Si5351?
I know.
Of course I will try to get it right the first time, at least the first time that I get it right that is
You have to think of the P2PAL as another layer or component. Just like there are 100 or so P2 Rev A eval boards out there, it is what it is. Actually, I think the P2PAL could be removed easily enough since it is fairly easy to lift when reflowing with hot air.
eg. something like this would be good:
P8 - RX2 via solder jumper
P9 - TX2 via solder jumper/resistor (you might have room for this near UX1)
P54 - GPIO0 - via solder jumper/resistor to P2 and external pullup to enable SPI boot by default instead of re-program.
P55 - WIFI EN - via solder jumper to P2 and external pullup to enable by default.
A nearby GPIO from ESP32 via optional diode path to RST. GPIO32 (module Pin8) might be good though it also has secondary use for 32kHz input, so it needs to be checked. Some other nearby pins suggest they are inputs only which would be no good for a reset.
Other pins of interest in the ESP32 are apparently these but they may not need to be passed to the P2.
MTDI - default pull down will set voltage to 3.3V for on module FLASH
GPIO2 - default pull down will already allow reprogramming when GPIO0 is pulled down at ESP startup
MTDO - possibly wire to a pull down to avoid ESP debug log being output on TXD0 serial lines during ESP32 boot which may mess up P2's own boot?
GPIO5 - does this need consideration for SDIO slave along with MTDO?
UB3 is coded to default to light pullup, and only goes to CMOS drive when USB connected.
When USB disconnected, it also reverts to light pullup.
One more idea I had looking at your board Peter...it might make sense to have room for a soldered ground pin loop for scoping use etc. You might have room on the bottom corner of the board for this. There are these special hook loops that make things easy to connect to, or you can simply solder your own loop of wire as shown in the red attachment to your PCB. Just need the holes drilled. Saves trying to connect onto other ground connectors when they are already in use etc. Nice to have this always available.
But the P2D2 already has so much packed into it in less than a quarter of the size of the P2 EVAL, plus it has so many pin header connections on it already!
However - if I can fit something extra in, I will. (I now have)
On the P2PAL the ESP32 should be wired:
- on P56SCL and P57SDA: for I2C
- on P63 using a dedicated 220R and P62: using ESP32 to P2 comm so the ESP is in parallel with UB3 in regards to RX/TX
- on P61R, P60R, P59R, P58R: for SPI using flash pin layout/meaning
- with an additional link (CS) between ESP32 and P2: so that P2 can have 2 CS to share the SPI bus between flash and ESP32 in SPI slave mode
since P2D2 already have the SD I would use the SD on the P2PAL wired to the ESP32 4bit SD controller peripheral:
- the ESP32 can store the pages of a web-server for product configuration/setup and/or some basic web based GUI
- the ESP32 can serve contents from its SD through one of the above communication channels to the P2 (eg the ESP32 SPI slave link)
With the above communication channels the ESP32 can:
- reset the P2 and request RX/TX exclusive access through the I2C command to the UB3
- program P2 through RX/TX
- directly program the P2 flash acting as SPI master with P61R (P2 kept in reset by UB3)
- exchange data to P2 (eg ESP32's SD, Web-GUI values, ...) acting as SPI slave or SDIO slave through the additional CS I/O link between the two
- use the I2C between the P2 and UB3 to agree/setup/configure the various operating modes of the other communication channels
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.
Perhaps it will be useful to foresee an external SRAM chip for the ESP32 using the parallel QSPI interface which supports also DMA.
Peter: get it first at the right time! There are many chances for changes later if there is an earlier! I will have a few days off end of July/ start of August and then I absolutely need the boards! I build on you. I had to outsource a certain task I intended to solve with the P2D2. Now there is another start window as that project failed, money and time was lost and I have to come back to the original solution. That experience would have allowed me to invest a lot into the P2D2, .... But: there is another window, please take that chance!