I would add a USB-B (mini) header with all pins connectet 1:1 to one of the USB A.
This allows to test USB device software, and also makes sniffing unknown protocols very easy. You just connect a PC on the USB B side and the device to sniff on the USB A side and start the passive sniffer software on the P2.
Andy
Edit: The USB-B header can also provide the 5V supply
Ray were you going to have some switches also on the resistors for modifying the startup sensing?
Good idea, because this should be able to test all 4 possible USB modes - Host/Device and LS/FS.
USB-FS Device will be a good boot candidate, for example.
Yes Eagle. It has a differential routing option that is pretty interesting. I did these manually though. I'm sure trace length doesn't mater for low speed USB.
If you care about trace lengths matching, you could get the length( info ) of each element of the trace and total it to see how each trace compares. You could do some radius turns and lines to extend a trace that is shorter, get the lengths closely matched to help ensure a good match. Another benefit of doing non- straight lines is to reduce cap coupling of lines that are running side by side and close together. I saw a board doing this technique recently.
Here are the files: If you can squeeze that chip in there, that'd be great.
Or, we can just leave it as is.
I think there's not much point right now as there's no stock for the 3 V part...
But, maybe it comes soon.
Here are the files: If you can squeeze that chip in there, that'd be great.
Or, we can just leave it as is.
I think there's not much point right now as there's no stock for the 3 V part...
But, maybe it comes soon.
3v Stock show as arriving on 25th May and you can place orders now
Could be worth ordering 10 or maybe even 25 ?
It looks like the HyperRAM can work with P1, as there is no tight clock specs, and you can pause the clock.
The only timing limit is the CS max low time, which is a strangely short 4us.
P1 can meet that, but it makes simple direct video streaming trickier ??
With a 20MHz BUS speed, std speed P1 has 80 slots in that 4us, so can Addr & read up to ideally ~ 60 bytes in 4 us, (unrolled time budget alone, appx 80 bytes at 96 MHz ) - sounds like a great candidate for reading Byte Codes.
Image size is no problem
Length is more of an issue, & this may need two streamers on P2.
One to read from HyperRAM, in bursts of up to the 4us.
(not quite enough for one video line, so need a few of these per scan line)
and a slightly slower write via CLUT streamer than can use a 8:16 or 8:24 table for Video (DAC or Digital)
An alternative would be no CLUT, and a just over 2:1 ratio, so the HR stores 16b pixels
This is looking like a very good test for P2 Streamers.
Very interesting speed. Normally the higher the voltage the higher the speed.
Until you hit signaling, and there, HS USB uses lower-swing than FS USB, and HDMI uses LVDS type drivers.
Same effect applies here, 1,8V part uses Differential Clock signal drive.
HyperRAM is DDR, so at 160MHz we could do 160MB/second.
Looking at the control of HyperRAM, there could be time benefits in live Clock-Speed changes.
In P1 there is short latency between a timer-change, and the pin response, and the frequency limit on P1 I think is 40MHz.
eg P1 could naturally change between 10MHz (==WrPin+Rotate Speed ) and 40MHz.
In P2 there seem to be two issues :
Q: Can P2 generate frequencies above SysCLK/2 ?
The normal NCO design tops out at SysCLK/2 and there were requests to allow Clock gating at the pin, to give SysCLK upper limit ?
Q: How quickly can P2 change a generated clock, and is that latency always jitter-free ?
For DDR, we just need SysCLK/2 at 80 MHz to read in at 160 MHz, right?
BTW: I'm glad I just ordered 2 boards. The fab shop found some crossed traces and let me fix them. I didn't check the design rule error list close enough... It was just the camera interface though, not something I'll probably check right away...
Actually, I guess we should figure out if it's easier to interface with USB camera or raw camera module...
Looks like most cameras are USB 2.0. But, I see HUE HD appears to support USB 1.1...
Comments
This allows to test USB device software, and also makes sniffing unknown protocols very easy. You just connect a PC on the USB B side and the device to sniff on the USB A side and start the passive sniffer software on the P2.
Andy
Edit: The USB-B header can also provide the 5V supply
Maybe mini-A since that's a footprint I already have for FTDI USB..
Ray were you going to have some switches also on the resistors for modifying the startup sensing?
Actually, I guess it's just device mode where you need a pull up....
Good idea, because this should be able to test all 4 possible USB modes - Host/Device and LS/FS.
USB-FS Device will be a good boot candidate, for example.
Got it all routed:
Looks good Ray. Looks like you switched from ExpressPCB to Eagle?
Maybe they could help check for errors...
Cheapest SPI Flash I can find is FT25H16T-RB TSSOP8. $0.13860/1k
I think Digikey do have the SO8 equivalent, but they mangled the descriptions on FT25H16S-RT part code.
I cleaned up the design a bit, here's the result.
Happy to check over your board if you like. I'd definitely like a couple.
Or, we can just leave it as is.
I think there's not much point right now as there's no stock for the 3 V part...
But, maybe it comes soon.
--> Need to ask for and process HID Report Descriptor
Unfortunately, it's a little complex for general purpose.
Have to think about how to handle that.
It's a bit much for assembly...
There's a page here with a primer:
http://eleccelerator.com/tutorial-about-usb-hid-report-descriptors/
But what you really need is this document:
http://www.usb.org/developers/hidpage/HID1_11.pdf
There's a "HID Descriptor Tool" App that helps too.
I learned enough to process the report from my Amazon Mouse:
3v Stock show as arriving on 25th May and you can place orders now
Could be worth ordering 10 or maybe even 25 ?
It looks like the HyperRAM can work with P1, as there is no tight clock specs, and you can pause the clock.
The only timing limit is the CS max low time, which is a strangely short 4us.
P1 can meet that, but it makes simple direct video streaming trickier ??
With a 20MHz BUS speed, std speed P1 has 80 slots in that 4us, so can Addr & read up to ideally ~ 60 bytes in 4 us, (unrolled time budget alone, appx 80 bytes at 96 MHz ) - sounds like a great candidate for reading Byte Codes.
Almost want a P2 package with HyperRAM mounted on top...
I guess a 160 MHz P2 could pump bytes in or out at 80 MHz.
Seems like could buffer XGA image on one...
HyperRAM is DDR, so at 160MHz we could do 160MB/second.
And the 3V part is rated for up to 3.6V, so 3.3V is fine.
Yes, device limits are
166-MHz clock rate (333 MB/s) at 1.8V V CC
100-MHz clock rate (200 MB/s) at 3.0V V CC
At those limits, using the return clock probably becomes important, but a 160 MB/s link to a large 64 MBit of RAM would get a lot of attention
Length is more of an issue, & this may need two streamers on P2.
One to read from HyperRAM, in bursts of up to the 4us.
(not quite enough for one video line, so need a few of these per scan line)
and a slightly slower write via CLUT streamer than can use a 8:16 or 8:24 table for Video (DAC or Digital)
An alternative would be no CLUT, and a just over 2:1 ratio, so the HR stores 16b pixels
This is looking like a very good test for P2 Streamers.
Can a P2 at 160 MHz really read in/write out bytes at 160 MB/s?
That would be pretty incredible...
Opens up 1080p buffer
Same effect applies here, 1,8V part uses Differential Clock signal drive.
That should be plenty.
Can think about adding memory later...
Actually, I'm just going to get 2 done real fast to make sure they work first. Don't want to wind up with a bunch of bad boards...
Looking at the control of HyperRAM, there could be time benefits in live Clock-Speed changes.
In P1 there is short latency between a timer-change, and the pin response, and the frequency limit on P1 I think is 40MHz.
eg P1 could naturally change between 10MHz (==WrPin+Rotate Speed ) and 40MHz.
In P2 there seem to be two issues :
Q: Can P2 generate frequencies above SysCLK/2 ?
The normal NCO design tops out at SysCLK/2 and there were requests to allow Clock gating at the pin, to give SysCLK upper limit ?
Q: How quickly can P2 change a generated clock, and is that latency always jitter-free ?
BTW: I'm glad I just ordered 2 boards. The fab shop found some crossed traces and let me fix them. I didn't check the design rule error list close enough... It was just the camera interface though, not something I'll probably check right away...
Actually, I guess we should figure out if it's easier to interface with USB camera or raw camera module...
Looks like most cameras are USB 2.0. But, I see HUE HD appears to support USB 1.1...