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.
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)
...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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 ?
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
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 ?
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.
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.
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
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.
Comments
As Ariba pointed out, an NCO (16-bit) would be quite sufficient to get us the timing we'd need.
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.
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)
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.
http://www.slideshare.net/franciscokelvin/usb-24403356
At the end of the page there is also a link to "USB in a nutshell" which describes the packet layer quite understandable.
Andy
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.
There will likely be some cross-handshakes between Cells, so odd/even pairs helps with that and keeps logic smaller still.
I've found this reasonable
http://www.usbmadesimple.co.uk/ums_3.htm
but not quite wire-level up you are after.
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.
That has some good info. Thanks.
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.
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.
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
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
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.
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.
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 ?
This'd also be useful for a general logic analyzer
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 ?
It goes down to 8 bits, but I've been meaning to expand it to 4, 2, and 1.
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_TRANSFERThe 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?
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 bytesNothing 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: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
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.
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
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.