USB Testing

18910111214»

Comments

  • I'll do another all-FPGA compile soon. Right now, I'm looking into tightening up hub timing (CORDIC, COGINIT, etc.) for smaller-than-16-cog configurations.
  • garryj wrote: »
    ... the next demo drop can identify all of the USB-IF registered device/interface base class types, from the class/subclass/protocol "triad" that's in the device and interface descriptors. Subclass and protocol identification can get pretty gnarly, so getting detailed info for these is optional, but it's pretty easy to add, if desired. The demo does the full triad for HID, Mass Storage and the Bluetooth subset of the "Wireless Controller" base class.

    From discussion in another thread about boot choices....

    Q: What is the current code size for what you have working as HID host LS/FS now ?

    Q: Any educated guesses on what code size would be needed to appear as any of HID or CDC or MSD device to a PC host ?



  • jmg wrote: »
    Q: What is the current code size for what you have working as HID host LS/FS now ?
    Currently the "minimal" boot protocol mouse/keyboard footprint is 2 cogs and ~11KB total code/data.
    Q: Any educated guesses on what code size would be needed to appear as any of HID or CDC or MSD device to a PC host ?
    Nope. But I do know that a proper HID implementation would be a very significant undertaking because you need to parse the report descriptors to determine device capabilities, and that's a very large can of worms.

    I have yet to even scratch the surface as to what's required for mass storage and other device types outside of reading the configuration description chain.
    garryj
  • Hi garryj

    Is there much extra work for supporting USB hubs do you know? Given the per USB port COG footprint you mentioned above, it likely makes sense if you wanted say both a keyboard and a mouse device hanging off a P2 to use a USB hub to a single port, rather than burn 4 COGs to support two physical USB ports particularly now given the P2 will have 8 COGs not 16.

    From what you have done and learned so far with USB you have any idea if there will be any issues with eventually going via a hub and then supporting multiple devices on the bus? Does it then become purely a device tree management issue with additional configuration software and device state overhead etc or something more significant that needs to be considered that may add a lot of overhead somewhere?

    This hub thing also applies to the P1's USB host implementation too which is probably more of what I'm interested in at the moment (well P1V actually). There is a single physical USB port limit there right now apparently, though it appears to be software not hardware related.
  • Very good point. For practical use, a physical USB hub is going to be integral feature of any equipment using USB.
  • I think that is a very good mindset for another reason too. The hub IC takes on the job of hardened interface chip. It takes the wallops from static discharges.
  • Mouse and keyboard at the same time is supported in my "USBdemo" code, as long as both devices support the boot protocol. I have several 2.4GHz wireless (not BlueTooth) keyboard/mouse combos that I test with.

    I haven't done anything with hubs other than do some cursory spec reading. Chapter 11 in the USB 1.1 and 2.0 docs describes the hub specification. From what I've read so far, the gain of the additional physical ports provided by the hub essentially become the mouth of a funnel, and the question then becomes how big can that mouth get before the P2 and two cogs get overwhelmed? A hub handles switching and repeating, but it doesn't do anything to lighten the device count load -- the host must still manage that.
    garryj
  • garryj wrote: »
    A hub handles switching and repeating, but it doesn't do anything to lighten the device count load -- the host must still manage that.
    It must also buffer and adjust packet delivery timing (like a network switch) to make everything handled by the single 11 Mb/s port. This must be helpful for keeping processing speed manageable.
  • I suppose it could be more like a multi-drop bus (RS485). But either way the limit for the host is still the single 11 Mb/s port. That inherently keeps the load limited.
  • roglohrogloh Posts: 557
    edited October 14 Vote Up0Vote Down
    Good thing is that the bandwidth required on the bus and transfer sizes are effectively sent by the device's various descriptors and controlled by the host polling rate so in theory you could tell in advance if you are going to hit the P2 limit and can prevent enabling too many devices downstream from the hub and instead just report a problem to the user when further devices are attached. That probably violates some USB spec somewhere and you're probably meant to support the worst case bus conditions and device limits etc but at least it could keep existing devices operating if some processing limit of P2 COG implementation would be exceeded by activating too many additional devices.
  • All devices are limited by whatever a single 11 Mb/s host port can do. Same for any USB system using a hub for expansion, even for hubs inside a PC.
  • Yeah there's the USB wire transfer limit but there's also a potential limit for actually scheduling all the polling requests needed when there are multiple devices on the bus. I was wondering if that limit might be reached first, even if the P2 USB low level portions can sustain wire speed on the USB bus. Eg. Consider 127 devices on a bus all needing to be polled at various times etc. Will a controlling COG be able to keep up I wonder??
  • evanhevanh Posts: 4,180
    edited October 14 Vote Up0Vote Down
    What that means is that there must be built in allowance for sharing delays. Which in turn means it goes however fast it can. One moment it might be pulling the full rate to a single device, a file transfer, the next moment it might be checking out ten low speed devices at a rather pathetic average.
  • garryj wrote: »
    jmg wrote: »
    Q: Any educated guesses on what code size would be needed to appear as any of HID or CDC or MSD device to a PC host ?
    Nope. But I do know that a proper HID implementation would be a very significant undertaking because you need to parse the report descriptors to determine device capabilities, and that's a very large can of worms.

    I have yet to even scratch the surface as to what's required for mass storage and other device types outside of reading the configuration description chain.

    I was meaning flip from your current host, to a slave design, I think you answered for a HID host ?
    HID device only needs to supply the report descriptors, not parse them ?

    (in another thread, questions are asked about USB booting, and that needs to avoid custom drivers, so some generic USB path is needed)

    Given the code size & '2 COGs' indicated, and the fact you need to configure to some Clock source (cannot use RCFAST), I think ROM support for USB boot is not practical.
    Best to support that in Flash, I think. Flash parts are very cheap, and the user properly knows the Xtal/Osc used.



  • garryjgarryj Posts: 140
    edited October 14 Vote Up0Vote Down
    jmg wrote: »
    I was meaning flip from your current host, to a slave design, I think you answered for a HID host ?
    HID device only needs to supply the report descriptors, not parse them ?
    Oops :blush: Yes, my perspective was from host. The HID client just supplies reports when asked.
    (in another thread, questions are asked about USB booting, and that needs to avoid custom drivers, so some generic USB path is needed)

    Given the code size & '2 COGs' indicated, and the fact you need to configure to some Clock source (cannot use RCFAST), I think ROM support for USB boot is not practical.
    Best to support that in Flash, I think. Flash parts are very cheap, and the user properly knows the Xtal/Osc used.
    This is my thinking, too. The two cog approach I've used separates the host USB transaction management from the "device driver". In its current form, the host's bus management, transaction scheduling and host<->driver interface is very crude. What @evanh and @rogloh have discussed is very much on point, and a robust implementation is a significant undertaking, as is defining a practical host/driver interface compatible with PASM, Spin, C/C++, Forth, etc. So far, my USB "demo" is just that -- an attempt to demonstrate that the P2 can self-host FS/LS USB. The heavy lift to make it truly functional on the P2 has yet to come...
    garryj
  • garryj wrote: »
    .... So far, my USB "demo" is just that -- an attempt to demonstrate that the P2 can self-host FS/LS USB. The heavy lift to make it truly functional on the P2 has yet to come...

    That 'proof of hardware' step is a very significant one, do not underestimate your work... :).

    It would be nice to have 'whatever is simplest device' (ie USB slave) also confirmed working, just in case some timing wrinkle is uncovered in Device cases.

    Since you have already coded to Host a Boot Protocol device, would the 'simplest device test' be to flip that, to have P2 the emulate the mouse/keyboard ?
Sign In or Register to comment.