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

USB Testing

1679111220

Comments

  • jmgjmg Posts: 15,169
    edited 2016-11-11 21:15
    Chip did mention elsewhere about Auto-Ack fish-hooks - can't recall if he finally did two versions, one that Auto-Acks and one that does not ?
    - yes, see below, I found it
    garryj wrote: »
    BTW, the rdpin/rqpin updates in v13 have had a positive impact on getting full-speed AND crc verification of received packets working!

    Hopefully, in the very near future, I'll get a demo out that supports a wireless keyboard/mouse combo, as long as they are identified as "boot protocol" devices. For other full-speed capable devices, the verbose mode will dump as much descriptor data as it can. Oh, and low-speed devices should continue to work as they did in the previous demo.
    That's certainly good news. Testing and proving FS USB pathways is an important P2 milestone.

    Auto-ack notes from
    https://forums.parallax.com/discussion/comment/1391452/#Comment_1391452

    cgracey wrote:
    I noticed a really stupefying problem with the 'smartpin_usb_turnaround.spin2' program. Since I sped up the smart pin comms, it just hasn't been working right, at all. Turns out that the implied AKPIN that now occurs when RDPIN executes was causing conflicts when one cog was doing WxPIN instructions and the other was doing a RDPIN. RDPIN is no longer passive with the automatic AKPIN. I just need to find a way to do a RDPIN without an automatic AKPIN (maybe using WZ, or something) or make AKPIN not conflict with WxPIN. This has been holding up the FPGA release.
    ..
    I solved the problem by splitting RDPIN into RDPIN (auto acknowledge) and RQPIN (read "quiet", no acknowledge). Works fine now.

    Maybe that will help ? You may have hit another case where this was causing issues.
  • RaymanRayman Posts: 14,517
    edited 2016-11-11 21:21
    It must still need akpin, right? How else would it know to lower the IN flag?

    Do you have a V13 version already?
  • jmg wrote:
    cgracey wrote:
    I noticed a really stupefying problem with the 'smartpin_usb_turnaround.spin2' program. Since I sped up the smart pin comms, it just hasn't been working right, at all. Turns out that the implied AKPIN that now occurs when RDPIN executes was causing conflicts when one cog was doing WxPIN instructions and the other was doing a RDPIN. RDPIN is no longer passive with the automatic AKPIN. I just need to find a way to do a RDPIN without an automatic AKPIN (maybe using WZ, or something) or make AKPIN not conflict with WxPIN. This has been holding up the FPGA release.
    ..
    I solved the problem by splitting RDPIN into RDPIN (auto acknowledge) and RQPIN (read "quiet", no acknowledge). Works fine now.

    Maybe that will help ? You may have hit another case where this was causing issues.

    In this situation, rdpin/rqpin aren't in play, and the host cog is the only one that touches the USB directly. In the case of async serial, the wypin auto-ack works fine, but the flag test and wypin target the same smartpin.

  • Rayman wrote: »
    It must still need akpin, right? How else would it know to lower the IN flag?

    Do you have a V13 version already?

    Yep, I'm working with v13 now. I'm only using USB and async serial smartpins, and with the latter the new wypin doesn't need akpin.
  • jmgjmg Posts: 15,169
    garryj wrote: »
    In this situation, rdpin/rqpin aren't in play, and the host cog is the only one that touches the USB directly. In the case of async serial, the wypin auto-ack works fine, but the flag test and wypin target the same smartpin.
    If I've ready your comments right, you do have a working FS USB solution - but are unsure about the details of combining akpin with wypin, which seems to differ between Async and USB usages ?
  • jmg wrote: »
    garryj wrote: »
    In this situation, rdpin/rqpin aren't in play, and the host cog is the only one that touches the USB directly. In the case of async serial, the wypin auto-ack works fine, but the flag test and wypin target the same smartpin.
    If I've ready your comments right, you do have a working FS USB solution - but are unsure about the details of combining akpin with wypin, which seems to differ between Async and USB usages ?

    Yes, I do have a working FS USB solution, but transmit uses wypin+akpin, as it did in P2v12, so it isn't a show-stopper issue. I was just seeking clarification as to whether my wypin without akpin test fail is due to some USB smartpin caveat, or whether a bug may be afoot.
  • Rayman wrote: »
    It must still need akpin, right? How else would it know to lower the IN flag?

    A major change from V12 is now in V13 all the smart pin instructions are auto-ack now except the new RQPIN instruction.
    WRPIN D/#,S/# - Set smart pin S/# mode to D/#, acknowledge pin
    WXPIN D/#,S/# - Set smart pin S/# parameter X to D/#, acknowledge pin
    WYPIN D/#,S/# - Set smart pin S/# parameter Y to D/#, acknowledge pin
    RDPIN D,S/# {WC} - Get smart pin S/# result Z into D, flag into C, acknowledge pin
    RQPIN D,S/# {WC} - Get smart pin S/# result Z into D, flag into C, no acknowledge

  • RaymanRayman Posts: 14,517
    But, the USB mode uses INA from upper pin as a flag that input buffer is not full.
    You have to do ACK to reset INA.
    No way around that.
  • jmgjmg Posts: 15,169
    garryj wrote: »
    BTW, the rdpin/rqpin updates in v13 have had a positive impact on getting full-speed AND crc verification of received packets working! Hopefully, in the very near future, I'll get a demo out that supports a wireless keyboard/mouse combo, as long as they are identified as "boot protocol" devices. ..

    What P2 SysClk MHz range does your code indicate is practical for FS USB ?
    What is the final COG/Code/Data numbers, for FS-USB "boot protocol" Host ?


  • evanhevanh Posts: 15,828
    edited 2016-11-12 01:33
    If that's a question of handling full speed USB on the 20 MHz RC oscillator (potentially down to 13 MHz is it?), you probably should be saying so, JMG.
  • jmgjmg Posts: 15,169
    evanh wrote: »
    If that's a question of handling full speed USB on the 20 MHz RC oscillator (potentially down to 13 MHz is it?), you probably should be saying so, JMG.
    No, I was not really expecting that range, given the previous slower port access was marginal at 80MHz
    FS USB needs a Trim-Osc that can adjust better than ~ +/- 0.25%, if you want to do RC osc versions, which excludes the P2 RC Osc.

    I'd expect P2 FS-USB to need a resonator/ crystal/oscillator with PLL, but it may be able to go a little slower than 80MHz ?
    eg 48? 60? 72? MHz are possible other values.

    With the P2 Test chip looking quite functional, Chip may also be able to do a build that supports P2 PLL SysCLK control around that 80MHz value.

  • AribaAriba Posts: 2,689
    edited 2016-11-12 03:31
    jmg wrote: »
    ...
    FS USB needs a Trim-Osc that can adjust better than ~ +/- 0.25%, if you want to do RC osc versions, which excludes the P2 RC Osc.

    I'd expect P2 FS-USB to need a resonator/ crystal/oscillator with PLL, but it may be able to go a little slower than 80MHz ?
    eg 48? 60? 72? MHz are possible other values.
    ...
    I think the USB Bitclock is NCO based, so no need to tune the sysclock. You can adjust the NCO frequency value instead.
    Not sure if the Cog is fast enough with the 20 MHz RCfast oscillator, maybe only for a Lowspeed slave.

    Edit: It just occured to me that sampling of a 12 MHz Signal is not possible with a 20 MHz clock also if the rate is NCO based, so Lowspeed is the only chance.

    Andy
  • garryjgarryj Posts: 337
    edited 2016-11-12 04:12
    The host's core bus I/O fits in a single cog, and currently there is ~1Kb additional of hub exec for everything else that isn't speed critical.

    The biggest time crunch is when receiving a packet. From EOP you have no more than 18 bit periods (at FS that's ~1.5us, LS ~12us) to wrap up crc calculation, verification and any other rx overhead, and start a handshake tx before the device will timeout waiting for a response. The least amount of code inside that timespan and still have it all work is as slow as you can go ;)
  • cgraceycgracey Posts: 14,134
    edited 2016-11-12 04:20
    Garryj,

    Can you think of any simple hardware assist that we can implement to make things easier? Maybe like a CRC tracker that you can reset, feed a byte to, and read the current state of? If I recall, aren't there two different CRC computations for USB?
  • jmgjmg Posts: 15,169
    cgracey wrote: »
    Garryj,

    Can you think of any simple hardware assist that we can implement to make things easier? Maybe like a CRC tracker that you can reset, feed a byte to, and read the current state of? If I recall, aren't there two different CRC computations for USB?

    Are you thinking in the Cordic-like shared manner , or local ?
    I guess a local version that needs > 8 SysClks should be simple ?

    Margin checking this is a good idea, now it looks like the FPGA can run USB, which is a significant milestone.

    That means now, 80MHz and 16 COGs could manage 15~16 USB hosts ?

    Broadening the MHz band, and even allowing more USB channels are worth checking into. Lower MHz saves power, gives more user clock choices for the rest of their system, and could even allow more than one host.COG.

    Other serial links like SPI/UART can manage closer to the 64p io limit.
  • cgracey wrote: »
    Garryj,

    Can you think of any simple hardware assist that we can implement to make things easier? Maybe like a CRC tracker that you can reset, feed a byte to, and read the current state of? If I recall, aren't there two different CRC computations for USB?

    I can't think of anything specific that would be a game-changer.

    There's CRC5 for the token packets and the FS start-of-frame packet and CRC16 for the DATAx packets. I'm using lookup tables in LUT, and the intermediate CRC16 calc is only six instructions, with one being the LUT fetch. With the help of the P2v13 updates and additional code optimization on my part, it's now no problem to keep up with the receiver at FS. As far as I'm concerned, all of the major hurdles to get FS running at 80MHz have been cleared. I've got three wireless keyboard/mouse combos, a couple of SDCard readers and a bunch of thumb drives lying around and almost all of them enumerate at FS. The ones that don't seem to be extra picky regarding inter-packet and bus turnaround timing. I'm pretty sure that software tweaks will eventually take care of this. I'll try to get the demo code posted ASAP so others can see how their devices fare.

    One hardware thing I'd like to revisit are the USB receiver status flags. After working with them for a while, SOP/EOP as they are now cover all the bases for determining inter-packet delay and initializing the bus turnaround timer. But there are times you want to see J/K ASAP, and at 7+ bits it's not at all useful, especially at FS. If possible, I'd like to give them a try at J/K flags being set at 1+ bits, as I think they were way back when the USB smartpins were first born?
  • jmg wrote: »
    That means now, 80MHz and 16 COGs could manage 15~16 USB hosts ?
    The host cog just does USB I/O stuff. An additional "driver" cog is needed so a particular device can perform its function. Right now that second cog serves as driver/client, so in practice at least one more cog will be needed for a basic system. A seven port P2 powered "hub", maybe? :-D
  • jmgjmg Posts: 15,169
    garryj wrote: »
    ... With the help of the P2v13 updates and additional code optimization on my part, it's now no problem to keep up with the receiver at FS. As far as I'm concerned, all of the major hurdles to get FS running at 80MHz have been cleared. I've got three wireless keyboard/mouse combos, a couple of SDCard readers and a bunch of thumb drives lying around and almost all of them enumerate at FS. The ones that don't seem to be extra picky regarding inter-packet and bus turnaround timing. I'm pretty sure that software tweaks will eventually take care of this. ..
    Can you maybe test that by something like skip of CRC check ? - ie kludge it a little, to shorten timing, to confirm that really is the issue on non-working items ?
    Then, you can find what time they really do need.

  • Yes, prior to P2v13 I was skipping rx crc verify and was getting 100% coverage on my small sample set, though with devices my "driver" doesn't recognize, enumeration stops after the configuration descriptor and the asked-for strings have been read.

    Post-enumeration testing has been limited to control read/write and interrupt IN transactions with full-speed packet sizes of up to 64 bytes. Bulk transfers at FS have a max packet size of 64 bytes too, so there should be no problem there. I have no idea how it will perform with isochronous transfers, which at FS, have a 1023 byte max packet size.
  • jmgjmg Posts: 15,169
    edited 2016-11-12 21:19
    garryj wrote: »
    Yes, prior to P2v13 I was skipping rx crc verify and was getting 100% coverage on my small sample set, though with devices my "driver" doesn't recognize, enumeration stops after the configuration descriptor and the asked-for strings have been read.
    Sounds good, so you could duplicate that, then add simple delays until it breaks, to find just how much time you need ?

    I think there are 2 ways to manage CRC, IIRC the cleanest/smallest ram is to sum including the CRC, but that may be slower at the final critical turnaround, than a design that does CRC until the CRC bits, then saves, and does a faster simple compare-verify.

  • USB full-speed/low-speed demo v0.6. The P2v13 FPGA image is required.

    If you have a wireless keyboard and mouse combo, and both devices support the HID "boot protocol", you should see the device output on your terminal (Parallax Serial Terminal recommended). The output screen formatting is very minimal, so if both devices are used at the same time, things get messy quickly. But hey, it's just a demo ;)

    On the Prop123-A9 board, pushbutton PB3 can be used to toggle on/off verbose output of descriptor data to the terminal. The default at startup is off, and the device must be disconnected before the option can be changed.

    Connecting a device other than a keyboard/mouse when in verbose mode *should* output the device descriptor and the configuration descriptor chain, plus string data for the product, manufacturer and device serial number, if it exists. If it's a Human Interface Device, the index zero report descriptor data will be read for up to three interfaces, if they exist.

    This version has significantly improved error recovery, but it still has a long way to go. If a packet is missed or corrupt, it will retry up to three times before giving up. If there is a DATAx toggle synchronization problem, it should re-synchronize. If a device endpoint issues a STALL handshake, however, the system will stop.

    I have about a dozen devices laying about, mostly thumb drives, and the descriptors mentioned above are read from all of them. Hopefully it will work for others, too.

    Any and all feedback is welcome. Thanks!

  • cgraceycgracey Posts: 14,134
    Great, Garryj!

    So, I should make the J, K, and SE0 sensor bits in the USB status byte turn on right away when those states occur, right? Is there any other change that is need or would be good?
  • I think the SE0 and SE1 flags are already being set on 1+ bits, and that 's fine. It's just J/K that I'd like to try at 1+ bits instead of 7+.

    And I think the SOP status flag now gets cleared at the SE0->J transition -- at least my testing indicates this? That, partnered with the "sticky" EOP, makes it real easy to catch, and confirm, that a "good" EOP has happened. Then by bringing J/K back to 1+ bits it allows you to catch the earliest possible bus idle state, when needed.

    Thanks!
  • cgraceycgracey Posts: 14,134
    edited 2016-11-15 06:38
    garryj wrote: »
    I think the SE0 and SE1 flags are already being set on 1+ bits, and that 's fine. It's just J/K that I'd like to try at 1+ bits instead of 7+.

    And I think the SOP status flag now gets cleared at the SE0->J transition -- at least my testing indicates this? That, partnered with the "sticky" EOP, makes it real easy to catch, and confirm, that a "good" EOP has happened. Then by bringing J/K back to 1+ bits it allows you to catch the earliest possible bus idle state, when needed.

    Thanks!

    So, I should just reduce J and K sensing times to one bit period? That's it?
  • JRetSapDoogJRetSapDoog Posts: 954
    edited 2016-11-15 09:40
    garryj wrote: »
    If you have a wireless keyboard and mouse combo, and both devices support the HID "boot protocol", you should see the device output on your terminal (Parallax Serial Terminal recommended).
    Congrats again, garryj. It's exciting following what you (and also Rayman) have accomplished (with a ton of hard work) at such an early stage in the life of the P2. So, in the end (when it's all said and done and silicon has arrived), how many cogs do you see this using (due to my ignorance, I wasn't quite sure how to count based on what you described)?

    Does anyone know if the boot protocol is only supported by (some) non-Bluetooth wireless keyboards? That is, is there any possibility of the boot protocol working with a Bluetooth keyboard and Bluetooth dongle? Assuming not, I wonder if it could work if some company released a specialized dongle. It would be cool if a Bluetooth stack wasn't needed (or just a minimal one (possibly running in a dongle)), and maybe if pairing wasn't needed. But I suppose that's all wishful thinking, and likely encryption is involved in whatever is sent from (and to) the keyboard. Anyway, just wondering.

    And assuming that dongles supporting the boot protocol with Bluetooth keyboards are unlikely to come into being (though nothing seems impossible with adapters innovated in China), what are the prospects for getting a Bluetooth keyboard working on the P2? I guess they are much enhanced with the HID stuff already being addressed, such as by code like garryj's. But a minimal Bluetooth stack under (?) the HID stuff would need to be written, I suppose, probably along the lines of what scanlime (if I recall her distinctive username correctly) did with three (?) cogs on the P1.





  • cgracey wrote: »
    So, I should just reduce J and K sensing times to one bit period? That's it?
    Yes, on J/K.

    And was I correct in my assumption that the SOP flag is cleared at the SE0->J transition of the EOP strobe?
  • RaymanRayman Posts: 14,517
    Thanks for posting the V13 version. Glad to hear full speed USB works!
  • garryj wrote: »
    If you have a wireless keyboard and mouse combo, and both devices support the HID "boot protocol", you should see the device output on your terminal (Parallax Serial Terminal recommended).
    Congrats again, garryj. It's exciting following what you (and also Rayman) have accomplished (with a ton of hard work) at such an early stage in the life of the P2. So, in the end (when it's all said and done and silicon has arrived), how many cogs do you see this using (due to my ignorance, I wasn't quite sure how to count based on what you described)?
    I think it will likely be a minimum of three cogs: host, device class driver and client.
    Does anyone know if the boot protocol is only supported by (some) non-Bluetooth wireless keyboards? That is, is there any possibility of the boot protocol working with a Bluetooth keyboard and Bluetooth dongle? Assuming not, I wonder if it could work if some company released a specialized dongle. It would be cool if a Bluetooth stack wasn't needed (or just a minimal one (possibly running in a dongle)), and maybe if pairing wasn't needed. But I suppose that's all wishful thinking, and likely encryption is involved in whatever is sent from (and to) the keyboard. Anyway, just wondering.
    My understanding at this time is that most Bluetooth keyboards don't directly support the HID "boot" protocol. I've got a Zoom Bluetooth dongle (not part of a keyboard/mouse package), and it doesn't advertise an HID interface class for a keyboard or mouse. Bluetooth is in the USB E0h "Wireless Controller" interface base class, subclass 01h, protocol 01h. They call it a "Bluetooth programming interface", and refer you to bluetooth.com for details. I've attached the enumeration dump for the Zoom dongle. In the interface descriptors, "Boot interface" and "Keyboard" appear, but that's a bug, as the interface base class is not HID (03h) :blush:

    A little web searching got me here:
    Bluetooth Human Interface Device Service, which looks pretty gnarley :crazy:
  • Thanks, garryj, for that response and the link. Gee...USB & Bluetooth are "fearfully and wonderfully made." Kind of makes one long for the simplicity of PS/2, but I suppose the world has moved on and I'm glad that you're keeping up with it.
  • RaymanRayman Posts: 14,517
    edited 2016-12-07 14:47
    Just tried with Logitech mk520 wireless combo mouse & keyboard

    Good news is that keyboard works. Mouse doesn't though...

    Here is the serial output in case it tells us anything (the last bit is me banging on keyboard):
    USB low-speed host & HID boot protocol keyboard/mouse driver v0.6.
    - Button PB3 toggles verbose terminal output on/off.
    - Button PB2 toggles mouse data scrolling on/off.
    The device must be disconnected before options can be changed.
    Debug & descriptor output to terminal is off.
    Mouse data scroll option is off.
    <Full-Speed device connected.>
    Woo-hoo, found a boot keyboard!
    Keyboard ready...
    Woo-hoo, found a boot mouse!
    SetIdle(): STALL
    rerrralsdjfl;aksdflk;lk
    

    PS: Just tried wired keyboard and mouse that came with HP computer and they both work.
Sign In or Register to comment.