HyperRAM +WiFi + RTC Mate for P2D2
Peter Jakacki
Posts: 10,193
The P2D2 is designed with components on one side only but that is not strictly true, putting aside the optional flip-side microSD and LEDs etc. By designing a small thin PCB with HyperRAM and other local peripherals I can mate this onto the back of the P2D2 as an SMD component. Part of the PCB will act as an additional heatsink.
Now here are some questions I'd like to ask.
1) Is there some consensus on how best to connect the HyperRAM and clocks?
2) Although I could use an ESP8266 for WiFi, I'd like to incorporate BLE as well. Any suggestions?
3) What about a raw microUSB connector?
The P2D2 Mate will also have a DS3231 type RTC with supercap backup and maybe some LEDs etc.
There's also a P2D2 DEV motherboard that incorporates quite a number of connectors and functions for audio and LAN and VGA etc.
Now here are some questions I'd like to ask.
1) Is there some consensus on how best to connect the HyperRAM and clocks?
2) Although I could use an ESP8266 for WiFi, I'd like to incorporate BLE as well. Any suggestions?
3) What about a raw microUSB connector?
The P2D2 Mate will also have a DS3231 type RTC with supercap backup and maybe some LEDs etc.
There's also a P2D2 DEV motherboard that incorporates quite a number of connectors and functions for audio and LAN and VGA etc.
Comments
I saw press releases from SiLabs about WiFI/BLE support, not sure of their module prices.
do you mean for P2-USB use - sure, there is one on P2EV, so maybe you can use the same pins ?
Esp32?
This is so that instructions like this can be used:
setbyte OUTB, UB, #0
Typical pin setup has been as follows:
const Pin_HR_Data0 = 32
const Pin_HR_Data7 = 39
const Pin_HR_CK = 40
const Pin_HR_RWDS = 41
const Pin_HR_CSn = 42
const Pin_HR_RSTn = 43
The 8 Data lines already have series resistance selectable in the chip config register. Nothing too special but don't grossly mismatch length or have grossly different numbers of vias.
If it's a two layer board, ground traces will definitely need to run parallel to CK and RWDS. Think of these lines as a differential signal pair, and of the classic bar-bell shape of ground surrounding these two signals. If four layer, uninterrupted ground plane beneath these two signals is a necessity.
I chose to put pulldowns on CK and RWDS next to the Hyper RAM chip. Both to keep them from picking up noise when the P2 isn't driving them, and as terminator resistors. Avoid vias on the CK and RWDS signals going between the chips especially. These signals are busy.
Signal reflection is an issue, so give provisions for ~15 to 50 ohm series resistors on for example the Clock, RWDS, and Chip Select lines. Only scope testing will reveal just how bad the ringing is. Ringing on Chip Select was the most irksome for me, but I think it's because everything wakes up when CSn goes low and causes a huge power demand spike. A series resistor fixed the reflection problems.
RSTn is optional, but if you're not going to use it then it has side-effects. Upon reset the hyper ram chip goes into a known latency clock setting (6) and fixed latency (always 2x latency). It's not possible to write to the memory array without knowing the latency clock setting. So one must either just write to the config register which is a non-latency write; or, do a read config register to obtain the settings while manually clocking and watching for RWDS to transition high.
So, based on it being preferable to have “the data bus D0 – D7 aligned on an 8-bit boundary,” I believe that the pin choices for an 11-pin HyperRAM interface on port B (with the data pins at the bottom);
(A) P32-P42 (with data on P32-P39)
(B) P32-P39 + 3 more pins elsewhere
(C) P40-P50 (with data on P40-P47)
(D) P40-P47 + 3 more pins elsewhere
(E) P48-P55 + 3 more pins elsewhere
The choice of P48-P58 wouldn't seem to work well because it overlaps with either USB or I2C signaling being on P56 & P57, as well as regular boot signaling on P58.
I recall Peter mentioning his planned HyperRAM pin usage somewhere, but I searched and couldn't find the thread. But I know that it didn't start at P32 at that time because I remember guessing that it would and being wrong. Which pins would you assign to HyperRAM, Peter?
I wonder if it would be useful to come up with a recommendation for pin usage for port B that various board makers could follow that would allow for maximum compatibility without needing to change pin assignments in the drivers, not that doing so is hard. But it might avoid us coming up with lots of different (sort of conficting) hardware choices. And HyperRAM has such potential to benefit certain applications, that it might be good to make a recommendation as to whether to base it at P32 or P40 (or wherever). Just a thought.
Hmm, maybe it would be good to, for example, recommend pin usage that would allow HyperRAM and HyperFlash to coexist, preferable with separate control signals. Maybe HyperFlash could use P32-P39 + 3 pins elsewhere AND HyperRAM could use P40-P47 + 3 pins elsewhere. Maybe those 6 total control pins could go from P48-53. BTW, I'm just assuming that HyperFlash (if that's what it's called) uses 11 total pins. I don't know if that's the case, and I apologize for any disinformation. I also don't mean to suggest that all design will have HyperRAM or HyperFlash, but some many will. Or perhaps you folks would like to carve out space for quad SPI or something like that in place of HyperFlash. Now might be a good time to chime in.
And along the same lines, perhaps we could kind of “standardize” the usage of P56 & P57. In Peter's main P2D2 thread, I saw where Roger/rogloh said, “I wonder if the I2C lines now attached on P2 pins 56/57 can still be used for other purposes? On my own board I had assigned them for USB signals like the P2-ES board does, ….” Maybe it would be good if the P2-ES (and derivatives) and the P2D2 could agree on the usage, even though they are separate boards and such agreement isn't strictly necessary, as pins can be reassigned in the drivers. I mean, it might be a bit more convenient for folks. If so, then perhaps we could recommend using P56 & P57 for USB and P54 and P55 for I2C, or VICE-VERSA (not sure how set in stone the routing is for Peter's tight board, so maybe I2C on P56 & 57 could be given preference and maybe a P2-ES derivative could make a change). BTW, I'm assuming that Peter will still bring out I2C, even though he'll have an option for a RTC on his Mate board. Anyway, I'm just thinking out loud here, not that any of this is critical stuff. But if any recommendations are to be issued, now is the time...before a new P2D2 is born or any P2-ES derivatives.
So, with that said, perhaps that gives us an I/O pin map similar to the following:
P32-39: Data for HyperFlash or maybe a couple quad SPI options, etc.
P40-P47: Data for HyperRAM (or drop down to P32 if preferred)
P48-P50: Control lines for HyperRAM
P51-P53: Control lines for HyperFlash, yes, w/a gap from the data pins
P54-P55 I2C (or USB)
P56-P57 USB (or I2C)
P58-P63 Standard Boot Pins
BTW, the foregoing map attempts to keep two aligned 8-bit data buses available (they wouldn't have to be used for Hyper devices). Whatever we do, I really think it's best to stay off of port A because port B already has been “eaten” into for the bootup pins and reserving port A for the hardware “application” ensures a full 32 adjacent pins for whatever the user needs to do. Anyway, I like the idea of putting as much of the standard stuff on port B as possible, such as “dedicated” I2C lines.
Maybe someone could chime in with thoughts about where to have ROM, like for fonts. I think that Peter's P2D2 already has a provision for this (though correct me if I'm wrong, and I don't know if it's quad signaling or not).
Anyway, I'm just throwing this out there for thought. But the point is to get us thinking about some kind of “standard” or recommended usage, a hardware map of sorts, I guess. Then again, maybe it's totally not necessary/useful. So, if you think that, that's good to know, too. Cheers!
Some applications might like to have VGA video output or HDMI somewhere off port B as well I suspect. They'll need another 3/3-5 (component/VGA), or 8 pins respectively. Plus there is USB perhaps for people wanting a nice self contained interactive/dev system, that needs 2-4 pins depending on power switch control and bus overload detection monitoring, if a future USB driver intends to support that. Hopefully even with HyperRAM and/or HyperFlash fitted (same bus?) there should still be enough pins on port B to do most of this while keeping port A free for general purpose use.
My personal ideal case would be something that can operate self-contained with Wifi(via serial)/Expansion RAM/USB/VGA/Audio capabilities all on port B, with port A free for external peripheral devices. HDMI would be a bonus too. That was what I had started doing with my own board which is basically on hold right now until I get the next P2D2 to try out.
My parts order has the IS66WVH16M8BLL-100B1LI HyperRAM which I guess should be suitable.
I have come across tiny RTC 1.5x3mm chips with integrated 1ppm crystal (RV-3028) that I am looking at adding to the P2D2 and/or the Mate.
BTW, yes, I am using Port B for a lot of these expansions signals including WiFi and LAN etc and leaving Port A free.
If I remember correctly that is the 'standard' module from espressif with integrated antenna. go for the ESP32WROOM-32U if you want an external antenna (same pinout)
As far as I know, the data bus can be shared. What cannot be shared is obviously the Chip Select signal. On a hyperflash it isn't even the same pin number as a hyper RAM. Same thing with a combined chip, it has CS1# (flash) and CS2# (ram) pins. Hyperflash also adds an interrupt signal INT#
I'm not confident that Hyperflash is actually useful when we will most likely have an SD compatible card already.
Keep feature creep low, please. Assigning groups of pins for different functions/ ICs / whatever, is OK. But there are so many combinations, and so many products & experiments, that I can see on the horizon, limiting yourself to assigned groups of pins and functional ICs, is counter to what the P2 can do. Part of the design process is to use the available pins in the best possible way AND to eliminate crossover traces. You can design and lay out a PCB with direct connection to suit your needs and circuit requirements, by doing it all in software and pin assignments.
They are rather different use cases. SD is socketed, which is both a plus, and a minus.
Software layers and latency mean SD is more like a solid state drive, than local flash memory, tho someone who needs flash might choose to upgrade the SO8 flash first.
There are HyperBUS parts with both Flash and RAM die, and those could be dropped in.
I think they have a second Chip Select on the BGA ? - so it would be good to track to that, on a PCB layout ?
Doing a minor tweak at wicker's proposed pinout could enable the use of a secondary Streamer to output controlled HR_RWDS bitstreams, on par with Dn[7:0] information given by a primary Streamer.
The proposal would involve exchanging pins 40 and 41 destinations (HK_CK and HR-RWDS), enabling the use of a STREAMER's RFBYTE mode, 1-bit submodes, to control HR_RWDS at the least significant bit position of that 8-bit group.
During HR write cycles, designated to modify main data array contents, HR_RWDS = 0 meaning is DO_Write, while HR_RWDS = 1 meaning is DON'T_DO_Write.
This would enable the use of some pre-processing of data streams in order to identify and select which bytes would be enabled to modify HR contents, and which would not, approximatelly mimic'ng the behaviour of a stream of WMLONG instructions.
This way, in place of having to read the contents of, says, a scan line or even a full frame buffer from HyperRam into the Hub, superimpose some overlay or new information on it, preserving the background where the superimposed or new info has a pixel value of 00h (or any other value of choice, since its not a real WMLONG), and having to write it back from Hub to HR main data array, a single round of selective HR write cycles can do the same job.
If you intend to use low-valued series resistors at those signals, as suggested by whicker, perhaps having the option to solder them at alternative positions, or even thru the use of solder jumpers, could enable some interesting experiments to be done.
Henrique
@PropGuy2
This is a revision of the original P2D2 I did last year before the P2 chip was available and so was the first board used but I am in no hurry to push out the revision although that could be any day now. The P2D2 itself has no preassigned pin functions other than the 6 boot pins and optionally the I2C pins in that group, so P56..P63. The P2D2 Mate that surface mounts to the flip side however obviously has pins assigned to the chips, but only on port B. The P2D2 DEV obviously has too.