Shop OBEX P1 Docs P2 Docs Learn Events
USB Testing - Page 5 — Parallax Forums

USB Testing

1235720

Comments

  • RaymanRayman Posts: 13,767
    I think the two servo headers could double as external 5V headers...
  • AribaAriba Posts: 2,682
    edited 2016-05-21 01:00
    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
  • RaymanRayman Posts: 13,767
    edited 2016-05-21 01:48
    That's a great idea.

    Maybe mini-A since that's a footprint I already have for FTDI USB..
  • brilliant idea, Andy

    Ray were you going to have some switches also on the resistors for modifying the startup sensing?


  • RaymanRayman Posts: 13,767
    I'm mostly thinking about low-speed USB host mode where all you need is the pull-downs.

    Actually, I guess it's just device mode where you need a pull up....
  • jmgjmg Posts: 15,140
    Tubular wrote: »
    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.

  • RaymanRayman Posts: 13,767
    Put in a header for Tubular's board.
    Got it all routed:
    689 x 845 - 93K
  • Rayman wrote: »
    Put in a header for Tubular's board.
    Got it all routed:

    Looks good Ray. Looks like you switched from ExpressPCB to Eagle?


  • RaymanRayman Posts: 13,767
    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.
  • RaymanRayman Posts: 13,767
    If anybody has Eagle and wants to see the files, let me know and I'll post them.
    Maybe they could help check for errors...
  • RaymanRayman Posts: 13,767
    I wonder how many people would want one of these... 20 maybe?
  • 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.
  • jmgjmg Posts: 15,140
    Rayman wrote: »
    Put in a header for Tubular's board.
    Got it all routed:
    Cool. Would it make sense to include Tubular's board along side this ?

    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.

  • Hey Ray i have no problem at all if you want to put a hyperram pattern down on your board. Or put the header if you're worried about the bga soldering

    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.

    378 x 453 - 17K
  • RaymanRayman Posts: 13,767
    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.

  • RaymanRayman Posts: 13,767
    edited 2016-05-22 21:13
    I see now that there is one more thing we need to do to make a generic HID driver.
    --> 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:

  • jmgjmg Posts: 15,140
    Rayman wrote: »
    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.
  • RaymanRayman Posts: 13,767
    HyperRAM is perfect for microcontrollers (with limited I/O pins).

    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...
  • cgraceycgracey Posts: 14,131
    Rayman wrote: »
    HyperRAM is perfect for microcontrollers (with limited I/O pins).

    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.
  • RaymanRayman Posts: 13,767
    Looks like the 3V part only goes to 100 MHz. 1.8V does do 166 MHz though.
  • cgraceycgracey Posts: 14,131
    Rayman wrote: »
    Looks like the 3V part only goes to 100 MHz. 1.8V does do 166 MHz though.

    And the 3V part is rated for up to 3.6V, so 3.3V is fine.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    HyperRAM is DDR, so at 160MHz we could do 160MB/second.

    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 :)
  • jmgjmg Posts: 15,140
    edited 2016-05-22 22:29
    Rayman wrote: »
    Seems like could buffer XGA image on one...
    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.
  • RaymanRayman Posts: 13,767
    edited 2016-05-22 22:34
    I didn't realize 100 MHz meant 200 MB/s

    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
  • Cluso99Cluso99 Posts: 18,066
    Very interesting speed. Normally the higher the voltage the higher the speed.
  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    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.


  • RaymanRayman Posts: 13,767
    edited 2016-05-23 15:45
    I'm going to order 40 of these USB boards now (hopefully getting them by the weekend).
    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...
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    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 ?

  • evanhevanh Posts: 15,091
    Bootable HyperMRAM! :D
  • RaymanRayman Posts: 13,767
    edited 2016-05-23 22:13
    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...
Sign In or Register to comment.