Shop Learn
SmartPin USB (was: SmartPin state machine modes) - Page 4 — Parallax Forums

SmartPin USB (was: SmartPin state machine modes)

1246712

Comments

  • cgraceycgracey Posts: 13,375
    Rayman wrote: »
    I'd like to see such a thing too... I've read about USB stuff at various times, but still don't really understand it...

    I have to image USB stuff would be a lot easier just using a 6 or 12 MHz crystal though.
    Is this a problem?

    As Ariba pointed out, an NCO (16-bit) would be quite sufficient to get us the timing we'd need.
  • jmgjmg Posts: 14,595
    Ariba wrote: »
    jmg wrote: »
    ...
    I'm not sure more than 2 pins is necessary ?

    With the existing modes you can not do it with 2 smartpins.

    For sure with a dedicated USB mode it needs only 2 pins
    dedicated USB mode can mean many things,
    I'm not sure it needs a full USB macrocell, but I think it does need USB_Tx and USB_Rx control flags.
    These enable the very small support logic around USB specific bit level tasks.
    Ariba wrote: »
    A NCO should be able to generate the bitclock for USB with a little tweak. The NCO Frequency mode must get a variant that allows to reset the phase register on edges of input A or B. There are 16 bits in X left to configure such a mode.
    The nice thing is that USB will work with every crystal/sysclock frequency maybe even with the internal oscillator because the bitclock gets synchronized on every edge in the USB datastream.
    Agreed, NCO can (re)lock, if a USB_Edge sense is added to reset phase.
    A re-lock NCO is also useful for doing Fractional Baud, & Chip is already thinking about this.
    (on UART, NCO relocks on Start-bit)
    Ariba wrote: »
    ...
    If there is no dedicated USB smartmode, a second synchronized NCO with 1/6 the frequency can be used to detect a stuffbit (the green part in the diagram).
    I'm not sure a full 32b NCO mode is the best for Stuff/Destuff, plus it would need dynamic Tx or Rx reconfig.
    That's a lot of registers, and Stuff only needs to count to 6, ie 3 FF + 1 result FF & some state gates.
    I think that is small enough it can be hard wired, simply using the 2 USB Config bits to enable as Rx or Tx Stuff.


  • slides 40-46 of this provide an overview and flowchart
    http://www.slideshare.net/franciscokelvin/usb-24403356
  • AribaAriba Posts: 2,432
    I find this useful to read. It describes a lowspeed implementation but full speed is the same, only with 12MHz bitrate. Many low level details can be extracted from that description.
    At the end of the page there is also a link to "USB in a nutshell" which describes the packet layer quite understandable.

    Andy
  • cgraceycgracey Posts: 13,375
    edited 2016-02-19 01:34
    Tubular wrote: »
    slides 40-46 of this provide an overview and flowchart
    http://www.slideshare.net/franciscokelvin/usb-24403356

    Thanks! I looked through that and a few others.

    I understand the bit stuffing and NRZ, but I'm not getting the bigger picture, yet. It looks like odd numbers of bits make up various packets. It would have been a lot cleaner to standardize at 8 bits per word. I still need to understand what kinds of responses come when.

    I think I need to get a USB analyzer to see what is really going on, or needs to go on. I'm sure it isn't complex to do full-speed and low-speed USB hardware (low-level communication), but man, is this UGLY! You plug in a USB device and it wants to have a lengthy conversation about the weather and how it's feeling today, with the host needing a set of encyclopedias for reference. What a nightmare of a protocol.

    I'm going to look for some analyzer that will let me see (hopefully) what happens in USB.
  • jmgjmg Posts: 14,595
    cgracey wrote: »
    Two pins should be able to handle it, especially if odd and even pins had different USB smarts.
    That's a good idea, would reduce my 2 config flags to a single USB_Helpers one.
    There will likely be some cross-handshakes between Cells, so odd/even pairs helps with that and keeps logic smaller still.
    cgracey wrote: »
    Something I've always wanted to see, but have never found anywhere, is a diagram of USB protocol from the wire level up. If there was something definitive to look at, this could be easy.

    I've found this reasonable
    http://www.usbmadesimple.co.uk/ums_3.htm
    but not quite wire-level up you are after.
  • @cgracey

    re:I think I need to get a USB analyzer

    http://freeusbanalyzer.com/


    Free USB Analyzer is a non-intrusive software USB sniffer and protocol analyzer for Windows.

    Using this USB Analyzer you may capture and display any traffic passing over USB connections of your computer. Captured communication data raw binary format is parsed and decoded into a human-readable form, allowing you to review the exchanged data and perform effective forensic analysis of transmitted data packets.

    The key feature of this Freeware USB logic analyzer is its ability to process monitored packets in real-time even under high traffic load. Together with other powerful features of this Free USB explorer and analyser utility it makes you able to explore and trace USB requests of all modern devices and applications, which are compatible with Hi-Speed USB 2.0 480 Mbit/s and SuperSpeed USB 3.0 5 Gbit/s dataflow.
  • cgraceycgracey Posts: 13,375
    jmg wrote: »
    cgracey wrote: »
    Two pins should be able to handle it, especially if odd and even pins had different USB smarts.
    That's a good idea, would reduce my 2 config flags to a single USB_Helpers one.
    There will likely be some cross-handshakes between Cells, so odd/even pairs helps with that and keeps logic smaller still.
    cgracey wrote: »
    Something I've always wanted to see, but have never found anywhere, is a diagram of USB protocol from the wire level up. If there was something definitive to look at, this could be easy.

    I've found this reasonable
    http://www.usbmadesimple.co.uk/ums_3.htm
    but not quite wire-level up you are after.

    That has some good info. Thanks.
  • cgraceycgracey Posts: 13,375
    edited 2016-02-19 02:44
    @cgracey

    re:I think I need to get a USB analyzer

    http://freeusbanalyzer.com/


    Free USB Analyzer is a non-intrusive software USB sniffer and protocol analyzer for Windows.

    Using this USB Analyzer you may capture and display any traffic passing over USB connections of your computer. Captured communication data raw binary format is parsed and decoded into a human-readable form, allowing you to review the exchanged data and perform effective forensic analysis of transmitted data packets.

    The key feature of this Freeware USB logic analyzer is its ability to process monitored packets in real-time even under high traffic load. Together with other powerful features of this Free USB explorer and analyser utility it makes you able to explore and trace USB requests of all modern devices and applications, which are compatible with Hi-Speed USB 2.0 480 Mbit/s and SuperSpeed USB 3.0 5 Gbit/s dataflow.

    It looks like that monitors packet flow, which is too high level for what we need. I think we need something that monitors the wire-level activity, so we can see what is actually happening, signal-wise. Thanks, though. That may come in handy later.
  • jmgjmg Posts: 14,595
    http://freeusbanalyzer.com/

    Free USB Analyzer is a non-intrusive software USB sniffer and protocol analyzer for Windows.

    Sounds good.
    The P2 can also use the cross-pin feature to sniff onto the USB pins, and do a HW logic Analyzer which could correlate with that SW layer capture.
    Getting 'example traffic' over a USB-UART/FIFO for example, is there on (all?) P2 boards, and the USB Rx code can work up to phantom RX only (where it listens, toggles pins on 1ms Frame info, and stores Rx info, but does no USB replies) - that allows test of CRC and Packet-decode etc.
    Once USB Rx is aligned, USB Tx should be easier to code as the Rx Verilog is there as a reference.

  • TubularTubular Posts: 4,286
    edited 2016-02-19 02:59
    Yes actually I think the streaming feature of the P2 might be as good as anything for capturing bit level info

    I just scoped the usb data signals on a prop plug. Even when serial transmission is idle, its sending the same (heartbeat?) pulse over and over, about 1750 ns wide. Probably could do with a proper USB PHY chip, but its encouraging enough to be able to see the signals



  • AribaAriba Posts: 2,432
    cgracey wrote: »
    Tubular wrote: »
    slides 40-46 of this provide an overview and flowchart
    http://www.slideshare.net/franciscokelvin/usb-24403356

    Thanks! I looked through that and a few others.

    I understand the bit stuffing and NRZ, but I'm not getting the bigger picture, yet. It looks like odd numbers of bits make up various packets. It would have been a lot cleaner to standardize at 8 bits per word. I still need to understand what kinds of responses come when.

    I think I need to get a USB analyzer to see what is really going on, or needs to go on. I'm sure it isn't complex to do full-speed and low-speed USB hardware (low-level communication), but man, is this UGLY! You plug in a USB device and it wants to have a lengthy conversation about the weather and how it's feeling today, with the host needing a set of encyclopedias for reference. What a nightmare of a protocol.

    I'm going to look for some analyzer that will let me see (hopefully) what happens in USB.

    An USB packet is a stream of 64 bytes (in fullspeed) with a sync pattern at begin and a EOP signal at the end (2 bittimes low on both lines). There are no start and stopbits or pauses, just a continuous bitstream.
    This 11+5 bits for example in the descriptions only show what is encoded in the bits.

    It's okay if the USB receiver signals every byte on INx, and the cog does all the rest.

    Andy

  • jmgjmg Posts: 14,595
    cgracey wrote: »
    I understand the bit stuffing and NRZ, but I'm not getting the bigger picture, yet. It looks like odd numbers of bits make up various packets. It would have been a lot cleaner to standardize at 8 bits per word. I still need to understand what kinds of responses come when.

    Payloads are 8 bit bytes, but a couple of headers are <> 8b per sub entity (eg 11+5 and 7+4+5, but fortunately those do add to 16b, so a Host emulation can send packed as 2 bytes, and a receive can input 2 bytes, then split in sw)
    BitStuff further varies the actual bits used, but that is inserted/removed pretty much at the pins, so does not impact the data payloads. It will of course appear on any Logic Probe.
  • I'm still not convinced of the necessity to have USB support. Many use cases for the P2 will have no USB. Of those use cases that do have USB, I think the overwhelming majority (all?) will have exactly one bus implemented. That's two pins. Maybe two pin cells. With that in mind, it does not make sense to me to implement any more than the basic state detection, edge aligned NCOs, and NRZI output. Those are reasonably general-purpose features that can be used well beyond USB.

    But not CRC-5-USB. Not bit stuffing. Those have too little (no?) application beyond USB. Leave that to software. No need to clutter up 63 other pin cells just so you can have it available for one cell.
  • cgraceycgracey Posts: 13,375
    So, all communications ARE multiples of complete bytes, including CRC's? If so, that's good.
  • jmgjmg Posts: 14,595
    Tubular wrote: »
    Yes actually I think the streaming feature of the P2 might be as good as anything for capturing bit level info

    I just scoped the usb data signals on a prop plug. Even when serial transmission is idle, its sending the same (heartbeat?) pulse over and over, about 1750 ns wide. Probably could do with a proper USB PHY chip, but its encouraging enough to be able to see the signals
    At a Sync-clk of 40MHz, 5000 bytes can capture a full 1ms Frame with 3 1/3 samples per USB bit.
    That should be enough to decode, or 80MHz could get 10k Bytes of samples at 6 2/3 samples per bit.
    A few SW passes would remove bit stuff, and DPLL to extract actual data information.
    With low average data rates, that information could be sent to the PC over a serial link.

    Capture of USB pin pair to extract J.K.SE0 would be nice, but I think the capture modes may not be there, and the Pin-Cell bandwidth is (just) too low ?
  • TubularTubular Posts: 4,286
    edited 2016-02-19 02:58
    jmg, we can use the streamer to bring up to 32 pins at 80MHz to hub ram, continuously, then analyze from there
    This'd also be useful for a general logic analyzer
  • jmgjmg Posts: 14,595
    edited 2016-02-19 03:14
    Tubular wrote: »
    jmg, we can use the streamer to bring up to 32 pins at 80MHz to hub ram, continuously, then analyze from there
    This'd also be useful for a general logic analyzer
    I realize that, I was just looking for more compact forms.

    Can the streamer currently capture 4b or 2b wide ?

    I guess even BYTE wide is useful, as 6 pins can be usefully used as Hardware feedback from USB testing.

    I also like the idea of a time-stamp based Logic Analyzer, but I think the limiting detail on that, is COG-Pin bandwidth ?

  • cgraceycgracey Posts: 13,375
    jmg wrote: »
    Tubular wrote: »
    jmg, we can use the streamer to bring up to 32 pins at 80MHz to hub ram, continuously, then analyze from there
    This'd also be useful for a general logic analyzer
    I realize that, I was just looking for more compact forms.

    Can the streamer currently capture 4b or 2b wide ?


    It goes down to 8 bits, but I've been meaning to expand it to 4, 2, and 1.
  • Bob Lawrence (VE1RLL)Bob Lawrence (VE1RLL) Posts: 1,718
    edited 2016-02-19 03:22
    USB output from Pnut and Prop Plug while loading VGA 640 x 480 x 16bpp 5:6:5 RGB :)

    000160: Control Transfer (UP), 2016-02-18 23:29:30.6959482 +0.0003307. (1. Device: USB Serial Converter) Status: 0x00000000
    Pipe Handle: Control Pipe
    Setup Packet
     40 01 00 02 00 00 00 00                           @.......
    Recipient: Device
    Request Type: Vendor
    Direction: Host->Device
    Request: 0x1 (Unknown)
    Value: 0x200
    Index: 0x0
    Length: 0x0
    000000: Get Descriptor Request (UP), 2016-02-18 23:28:43.4778704 (1. Device: USB Serial Converter)
    Descriptor Type: Unknown
    Descriptor Index: 0x39
    Transfer Buffer Size: 0x490050 bytes
    
    
    00000001	2016-02-18 23:29:30.0707883	+46.5929166	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000002	2016-02-18 23:29:30.0709525	+0.0001642	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000003	2016-02-18 23:29:30.0709926	+0.0000401	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000004	2016-02-18 23:29:30.0711850	+0.0001924	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000005	2016-02-18 23:29:30.0712250	+0.0000400	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000006	2016-02-18 23:29:30.0714412	+0.0002162	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000007	2016-02-18 23:29:30.0714826	+0.0000414	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000008	2016-02-18 23:29:30.0717005	+0.0002179	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000009	2016-02-18 23:29:30.0717213	+0.0000208	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000010	2016-02-18 23:29:30.0719687	+0.0002474	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000011	2016-02-18 23:29:30.0720104	+0.0000417	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000012	2016-02-18 23:29:30.0722044	+0.0001940	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000013	2016-02-18 23:29:30.0722490	+0.0000446	DOWN	0x00000000	URB_FUNCTION_SYNC_RESET_PIPE_AND_CLEAR_STALL
    00000014	2016-02-18 23:29:30.0732410	+0.0009920	UP	0x00000000	URB_FUNCTION_SYNC_RESET_PIPE_AND_CLEAR_STALL
    00000015	2016-02-18 23:29:30.0732516	+0.0000106	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000016	2016-02-18 23:29:30.0734498	+0.0001982	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000018	2016-02-18 23:29:30.0793476	+0.0058730	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000019	2016-02-18 23:29:30.0793859	+0.0000383	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000020	2016-02-18 23:29:30.0795757	+0.0001898	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000022	2016-02-18 23:29:30.0796283	+0.0000261	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000023	2016-02-18 23:29:30.0799633	+0.0003350	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000024	2016-02-18 23:29:30.0800196	+0.0000563	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000025	2016-02-18 23:29:30.0802037	+0.0001841	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000026	2016-02-18 23:29:30.0802481	+0.0000444	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000027	2016-02-18 23:29:30.0804375	+0.0001894	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000028	2016-02-18 23:29:30.0804811	+0.0000436	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000029	2016-02-18 23:29:30.0807166	+0.0002355	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000030	2016-02-18 23:29:30.0807606	+0.0000440	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000031	2016-02-18 23:29:30.0809464	+0.0001858	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000032	2016-02-18 23:29:30.0811628	+0.0002164	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000033	2016-02-18 23:29:30.0813214	+0.0001586	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000034	2016-02-18 23:29:30.0813628	+0.0000414	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000035	2016-02-18 23:29:30.0816005	+0.0002377	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000036	2016-02-18 23:29:30.0816476	+0.0000471	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000037	2016-02-18 23:29:30.0819650	+0.0003174	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000038	2016-02-18 23:29:30.0819995	+0.0000345	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000039	2016-02-18 23:29:30.0822163	+0.0002168	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000040	2016-02-18 23:29:30.0822488	+0.0000325	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000041	2016-02-18 23:29:30.0824411	+0.0001923	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000042	2016-02-18 23:29:30.0824653	+0.0000242	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000043	2016-02-18 23:29:30.0825808	+0.0001155	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000044	2016-02-18 23:29:30.0826057	+0.0000249	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000045	2016-02-18 23:29:30.0829556	+0.0003499	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000046	2016-02-18 23:29:30.0829987	+0.0000431	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000047	2016-02-18 23:29:30.0832126	+0.0002139	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000048	2016-02-18 23:29:30.0953202	+0.0121076	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000050	2016-02-18 23:29:30.1033004	+0.0079361	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000051	2016-02-18 23:29:30.1034464	+0.0001460	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000052	2016-02-18 23:29:30.1111948	+0.0077484	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000054	2016-02-18 23:29:30.1271826	+0.0159444	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000056	2016-02-18 23:29:30.1431695	+0.0159468	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000058	2016-02-18 23:29:30.1590438	+0.0158644	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000060	2016-02-18 23:29:30.1750697	+0.0160027	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000062	2016-02-18 23:29:30.1910579	+0.0159521	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000064	2016-02-18 23:29:30.2070566	+0.0159699	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000066	2016-02-18 23:29:30.2127961	+0.0057123	DOWN	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000067	2016-02-18 23:29:30.2230687	+0.0102726	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000070	2016-02-18 23:29:30.2479160	+0.0195962	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000072	2016-02-18 23:29:30.2483018	+0.0003285	DOWN	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000073	2016-02-18 23:29:30.2639598	+0.0156580	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000075	2016-02-18 23:29:30.2800708	+0.0160818	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000077	2016-02-18 23:29:30.2959517	+0.0158382	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000079	2016-02-18 23:29:30.3120658	+0.0160661	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000081	2016-02-18 23:29:30.3279702	+0.0158604	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000083	2016-02-18 23:29:30.3440487	+0.0160355	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000085	2016-02-18 23:29:30.3599634	+0.0158813	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000087	2016-02-18 23:29:30.3760042	+0.0160044	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000089	2016-02-18 23:29:30.3919371	+0.0159064	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000092	2016-02-18 23:29:30.4071009	+0.0000355	DOWN	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000093	2016-02-18 23:29:30.4080650	+0.0009641	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000095	2016-02-18 23:29:30.4239263	+0.0158322	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000097	2016-02-18 23:29:30.4400754	+0.0161222	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000099	2016-02-18 23:29:30.4559488	+0.0158280	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000102	2016-02-18 23:29:30.4716876	+0.0032452	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000104	2016-02-18 23:29:30.4876639	+0.0159412	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000106	2016-02-18 23:29:30.5035547	+0.0158587	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000108	2016-02-18 23:29:30.5195538	+0.0159637	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000110	2016-02-18 23:29:30.5253883	+0.0057971	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000111	2016-02-18 23:29:30.5255694	+0.0001811	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000112	2016-02-18 23:29:30.5256104	+0.0000410	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000113	2016-02-18 23:29:30.5259406	+0.0003302	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000114	2016-02-18 23:29:30.5259803	+0.0000397	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000115	2016-02-18 23:29:30.5262101	+0.0002298	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000116	2016-02-18 23:29:30.5262481	+0.0000380	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000117	2016-02-18 23:29:30.5264408	+0.0001927	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000118	2016-02-18 23:29:30.5264779	+0.0000371	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000119	2016-02-18 23:29:30.5267179	+0.0002400	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000120	2016-02-18 23:29:30.5269847	+0.0002668	DOWN	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000121	2016-02-18 23:29:30.5355715	+0.0085868	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000124	2016-02-18 23:29:30.5470874	+0.0000364	DOWN	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000125	2016-02-18 23:29:30.5515696	+0.0044822	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000128	2016-02-18 23:29:30.5676001	+0.0000049	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000130	2016-02-18 23:29:30.5676991	+0.0000712	DOWN	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000131	2016-02-18 23:29:30.5835711	+0.0158720	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000134	2016-02-18 23:29:30.5881108	+0.0000441	DOWN	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000135	2016-02-18 23:29:30.5994398	+0.0113290	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000138	2016-02-18 23:29:30.6087423	+0.0001540	DOWN	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000139	2016-02-18 23:29:30.6155680	+0.0068257	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000142	2016-02-18 23:29:30.6289473	+0.0000292	DOWN	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000143	2016-02-18 23:29:30.6314157	+0.0024684	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000145	2016-02-18 23:29:30.6474721	+0.0160273	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000148	2016-02-18 23:29:30.6495957	+0.0001547	DOWN	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000149	2016-02-18 23:29:30.6634269	+0.0138312	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000152	2016-02-18 23:29:30.6699907	+0.0000530	DOWN	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000153	2016-02-18 23:29:30.6794365	+0.0094458	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000156	2016-02-18 23:29:30.6953291	+0.0052333	UP	0x00000000	URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
    00000157	2016-02-18 23:29:30.6953989	+0.0000698	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000158	2016-02-18 23:29:30.6955731	+0.0001742	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    00000159	2016-02-18 23:29:30.6956175	+0.0000444	DOWN	0x00000000	URB_FUNCTION_VENDOR_DEVICE
    00000160	2016-02-18 23:29:30.6959482	+0.0003307	UP	0x00000000	URB_FUNCTION_CONTROL_TRANSFER
    
  • cgraceycgracey Posts: 13,375
    Bob, I wonder if that kind of transaction record would be sufficient to reverse engineer the packet-level protocol that FTDI drivers execute.
  • re:Bob, I wonder if that kind of transaction record would be sufficient to reverse engineer the packet-level protocol that FTDI drivers execute.

    The free version has some limitations but certainly we can learn a few tricks by playing with it. The price is right :)

    IS there something specific you would like for me to try?

  • Bob Lawrence (VE1RLL)Bob Lawrence (VE1RLL) Posts: 1,718
    edited 2016-02-19 03:53
    Configuration Descriptor
    Configuration Descriptor
     Number of interfaces: 1
     Configuration value: 0x1
     Attributes: , Bus powered
     Max power: 90 mA
    
    Interface Descriptor: 0, Alternate setting: 0
     Number of endpoints: 2
     Interface class: 0xff - Vendor Specific Class
     Interface subclass: 0xff - Vendor Specific Subclass
     Interface protocol: 0xff - Vendor Specific Protocol
     Endpoint address 0x1, Input, Bulk, max packet size: 64 bytes
     Endpoint address 0x2, Output, Bulk, max packet size: 64 bytes
    

    : Control Transfer (
    000160: Control Transfer (UP), 2016-02-18 23:29:30.6959482 +0.0003307. (1. Device: USB Serial Converter) Status: 0x00000000
    Pipe Handle: Control Pipe
    Setup Packet
     40 01 00 02 00 00 00 00                           @.......
    Recipient: Device
    Request Type: Vendor
    Direction: Host->Device
    Request: 0x1 (Unknown)
    Value: 0x200
    Index: 0x0
    Length: 0x0
    000000: Get Descriptor Request (UP), 2016-02-18 23:28:43.4778704 (1. Device: USB Serial Converter)
    Descriptor Type: Unknown
    Descriptor Index: 0x39
    Transfer Buffer Size: 0x490050 bytes
    
    
    
  • cgraceycgracey Posts: 13,375
    edited 2016-02-19 03:54
    re:Bob, I wonder if that kind of transaction record would be sufficient to reverse engineer the packet-level protocol that FTDI drivers execute.

    The free version has some limitations but certainly we can learn a few tricks by playing with it. The price is right :)

    IS there something specific you would like for me to try?

    Nothing specific. We're going to need verification that the lowest-level signaling is correct. I think we'll need a hardware analyzer to see that. I found one for $400 that looks pretty decent. It shows all non-transactional signalling, which is below the radar of a software analyzer.

    Even more than I wish I knew this stuff, I wish I wanted to know about it. I hate overwrought things, so I've avoided USB all these years. Not good business thinking, I know.

    I really look forward to getting the Prop2 standing on its own, so we could decouple from the modern mess. Trouble is, you've got to be neck deep before you can climb out.
  • re:I found one for $400

    re:It shows all non-transactional signalling, which is below the radar of a software analyzer.

    Cool!

    Can you please post the link when you pick one so we can see all the features.

    re:I really look forward to getting the Prop2 standing on its own, so we could decouple from the modern mess.

    That's too bad because you already know that doing proper USB on PROP2 is impossible LOL
  • evanhevanh Posts: 10,391
    "Proper" just meaning a licensed controller of course. ;)
  • cgraceycgracey Posts: 13,375
    re:I found one for $400

    re:It shows all non-transactional signalling, which is below the radar of a software analyzer.

    Cool!

    Can you please post the link when you pick one so we can see all the features.

    re:I really look forward to getting the Prop2 standing on its own, so we could decouple from the modern mess.

    That's too bad because you already know that doing proper USB on PROP2 is impossible LOL

    Why is it impossible? If we can signal in a timely fashion, and software handles the higher level, where would the imperfection be?

    Here is what looks best, so far (see USB 12 model):

    http://www.totalphase.com/products/usbguide/?gclid=CL_Kqu_-gssCFQUIaQodk3YDfw
  • evanhevanh Posts: 10,391
    jmg wrote: »
    I also like the idea of a time-stamp based Logic Analyzer, but I think the limiting detail on that, is COG-Pin bandwidth ?

    A Prop1 Cog can already do that quite well but limited by Hub access timing. A Prop2 Cog will be able to make use of WFLONG to excellent effect.
  • Bob Lawrence (VE1RLL)Bob Lawrence (VE1RLL) Posts: 1,718
    edited 2016-02-19 04:54
    @ Chip

    re: Why is it impossible?

    Just a little humor :)

    re:USB 12 model

    Thanks!

    Here's a few Video's for anyone interested in seeing the analyzer in action.

    (Both videos refer to using a Beagle 480 analyzer - they also apply to the Beagle 12 analyzer because the Data Center software is used for both devices)

    USB Debugging using a Real-Time USB Bus Monitor




    Using the Bus Tree Feature of the Data Center Software for USB Debugging and Analysis


  • Cluso99Cluso99 Posts: 17,420
    cgracey wrote: »
    Two pins should be able to handle it, especially if odd and even pins had different USB smarts.

    Something I've always wanted to see, but have never found anywhere, is a diagram of USB protocol from the wire level up. If there was something definitive to look at, this could be easy. Diving deep into the huge USB specification to try to construct such information by making lots of inferences has put me off. If I wanted someone to know how something worked, I would explain it in very direct terms. For whatever reason, these protocol standards are never written like that.
    Chip,
    LS and FS effectively reverses the functions of the pin pairs. But I guess we could swap the pin pair using the smart pins, so its not really an issue here.

    I did a lot of work a long time ago in understanding to bottom level protocol. It is not that bad although the crc16 could do with some help. Before smart pins I had worked out how a couple of instructions would help make software life much easier. I posted the info a couple of years ago. Note I think there is an error in the way I worked the instructions out.

Sign In or Register to comment.