My first P2 PCB (it's finally done!)
Rayman
Posts: 14,646
I'm working to get this done before chips arrive...
There's a lot of stuff here that's new to me, so this board is somewhat experimental...
Here's some stuff it's got:
HDMI
uSD
HyperRAM
Raspberry Pi Zero interface with EEPROM
RTC
2x Nunchuk
USB
2x Eval Board compatible headers
9-axis accelerometer
Update: The attached Eagle files have fixed the issues so far with this board, TEST now tied to GND, Pullup on RESn, Pullup on CSn of flash chip and replaced micro-USB connector (also grounded i2c address pins on LSM9DS1). Warning: Not a proven design.
Update2: Seems the new micro-usb footprint has an overlap error... Would have to cut away some copper if used this design or 5V would be shorted to ground. Working on fix...
Update3: Removed Eagle files because of a major issue... The new FT USB chip (FT231X) cannot have I/O powered by 5V, like FT232RL could. That was a major mistake and might explain why I had some strange issues...
Update4: Finally have a version that works the right way! Eagle source and Gerbers posted here.
Update5: Uploaded Eagle source and Gerbers for a second version with HDMI and different regulator options.
There's a lot of stuff here that's new to me, so this board is somewhat experimental...
Here's some stuff it's got:
HDMI
uSD
HyperRAM
Raspberry Pi Zero interface with EEPROM
RTC
2x Nunchuk
USB
2x Eval Board compatible headers
9-axis accelerometer
Update: The attached Eagle files have fixed the issues so far with this board, TEST now tied to GND, Pullup on RESn, Pullup on CSn of flash chip and replaced micro-USB connector (also grounded i2c address pins on LSM9DS1). Warning: Not a proven design.
Update2: Seems the new micro-usb footprint has an overlap error... Would have to cut away some copper if used this design or 5V would be shorted to ground. Working on fix...
Update3: Removed Eagle files because of a major issue... The new FT USB chip (FT231X) cannot have I/O powered by 5V, like FT232RL could. That was a major mistake and might explain why I had some strange issues...
Update4: Finally have a version that works the right way! Eagle source and Gerbers posted here.
Update5: Uploaded Eagle source and Gerbers for a second version with HDMI and different regulator options.
Comments
Kind regards, Samuel Lourenço
Kind regards, Samuel Lourenço
I'm mostly hoping that the SMT parts work, so that I can reuse the stencil for future boards...
This gives me a GPU with 2D and 3D graphics and 1080p output.
Also provides Bluetooth and WiFi.
I'm hoping I can turn it into a slave device (even though it wants to be master...).
Yes, a nice combination.
I've seen LCDs for Pi's that talk 125MHz SPI, wonder if a P2 can slave at that speed ? (or how easy that driver is to scale?)
Experience suggests the prop2's sysclock will need the be at least 3x the SPI clock to be reliable. 3x 125 = 375 MHz.
EDIT: That may actually be too optimistic. That's based on the performance of the asynchronous serial smartpin behaviour, which has no separate clock and data. The existence of SPI clock may increase the oversampling needs to 6x the SPI clock.
For higher throughput it could be interesting to try to target using the SMI (secondary memory interface) mode of the RasPi pins. There's not a lot of documentation out there for it but there is a working driver available online. From memory it is a 16/18 bit parallel interface mode that looks a bit like a small register file/32 entry SRAM. ie. CS/RD/WR Address and Data etc. Could potentially give faster transfer speeds of bulk video data etc though SPI is more universal. I think this person already managed 44MB/s over it and more might be possible:
https://github.com/fenlogic/IDE_trial
I've always wanted to attempt a project to hook up the P1/P2 to a Pi this way, but haven't got around to try it.
The Pi I2S interface supports slave clocks. I haven't tested that. In master mode it can run at 250mbps. Although at those speeds it can be challenging to keep the fifos full, even though they are larger than the SPI controller. The pins probably can't handle that data rate anyway. Although, it should be able to do about 100mbps in each direction full duplex.
Rayman, check the trace widths for Vdd. I'm not sure if they will handle the current needed.
Now have Samba going and it now looks like a shared drive on my Windows box.
I think I should have connected the rpi UART to P62, P63 and used a GPIO to connect to reset.
I'm thinking that would have let me program the P2 over wifi using SSH terminal...
That would be fun, but not one of my goals at the present...
I have not played with surface mount in a toaster oven. Any leads
I’ve used screaming circuits before.
They are fast...
Just realized I didn't add any pull ups or pull downs on the boot Flash/uSD pins...
What happens in this case?
Just looked up the table... Looks like always goes to serial...
[By the way, I'm assuming that pin 1 of the flash chip is at the top-left in your design image and that the actual/physical pin-out arrangement differs from the "layout" for your schematic symbol of the flash chip. I've never used such an SPI flash chip, but I checked a few pin-outs from different manufactures just now and I think that makes sense for your image and schematic.]
I noticed the symbol has pins in wrong places too. But, it's actually connected the right way.
That's OK.
But, I do have a major problem somewhere on the board...
It won't identify and found that RESn is being pulled down by the P2 chip instead of pulled up...
Anyway, was just searching the forum now for related info, and about three years ago, I believe folks were saying then that the reset line was only an input and that the P2 couldn't drive it. But then that may have changed to accommodate resetting flash chips that are available from certain vendors. Not sure about that, but I see that you were a big part of that discussion, so you undoubtedly know. And you're saying that the P2 is holding the line low (as opposed to something else), so I guess a change was made.
By the way, in "researching" that, I was confused as to whether the RESn pin was actually pulled up by the P2 or not because some posts said (or seemed to me to say) that an external pull-up was necessary. And if that's true and one designed with the opposite assumption, then that'd likely be a problem. So what's the word now that we have actual P2 silicon? Is RESn pulled up by the P2 itself (possibly lightly)? But I think that I read that the P2D2 pulls it up (externally), even if it may not be strictly necessary. Sorry, I didn't carefully and exhaustively read all the related posts. Anyway, good luck figuring your board out.
I also noticed that I didn't tie TEST to GND, like they did on Eval Board. But, connecting to ground didn't fix RESn problem...
Actually, it seems there is an external pull-up on RESn on Eval. Board.
The Eval SCH shows a 10k pullup, but it's not clear if there is an internal pullup. It's common to have pullups on RESn and
I copied my FTDI reset circuit from a P1 design, but I see that Eval board does it differently. That might be a problem as well...
But, maybe I didn't try that and grounding TEST at the same time...
I was just thinking the same. If we could ask @cgracey to confirm what the TEST pin is for, and how it should be connected on user boards, then I'll get that detail added to the Eval docs pinout table. With Eval we have it hooked to Ground, but I can't recall if that could be to either rail (or allowed to float), and if it might have any possible user purpose.
As for RESn, that would be good to ask Chip's confirmation too, if there's any internal pull resistance and/or capacitance.
On the Eval, we had RESn pulled up anyway, because the DTR reset circuit requires a pull-up on the P2 side of the series capacitor. I could create a little app-note about the P2 reset and data interface that we used on the Eval board, and get that shared out as a reference. The common P1 reset circuit would also work; the main reason for the new version is that it's simpler.
UB3 P2 reset is even simpler
A simple 'minimum connection' app note is a good idea.
That could also include a suggested Xtal CAP value & Osc sources.
Did Parallax collect Osc MHz values for the first batch of boards ?
My tests of EvalA, hint that the present chosen Xtal has too low a CL, but that's a sample size of 1.
The other think I'm possibly doing wrong is using the FTDI with 5V I/O and 10k series resistors between it's RX/TX and the Prop's.
This was a trick to prevent the Prop1 from powering up the FTDI chip and generating a reset pulse.
But, maybe the FT231X doesn't need that...
If you intend to power USB separate from P2, then I think that's still needed.
IIRC the Eval B adds speed-up parallel caps to those 10k's
RESn has no internal pull-up, so you'll need to add one.
That might explain it
Kind regards, Samuel Lourenço