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
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.
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.
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.
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 ?
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.
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
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 ?
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.
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.
...
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.
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
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?
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.
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?
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
... 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.
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.
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.
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?
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.
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)
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.
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.
Comments
- yes, see below, I found it
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
Maybe that will help ? You may have hit another case where this was causing issues.
Do you have a V13 version already?
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.
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.
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.
A major change from V12 is now in V13 all the smart pin instructions are auto-ack now except the new RQPIN instruction.
You have to do ACK to reset INA.
No way around that.
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 ?
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.
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
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
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.
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?
Then, you can find what time they really do need.
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.
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.
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!
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?
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?
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.
And was I correct in my assumption that the SOP flag is cleared at the SE0->J transition of the EOP strobe?
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)
A little web searching got me here:
Bluetooth Human Interface Device Service, which looks pretty gnarley :crazy:
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):
PS: Just tried wired keyboard and mouse that came with HP computer and they both work.