Ok, I check and looks like sequential packets are locked to the same clock, no matter what delay you put between them.
So, I guess it's just the delay between sequential packets of the same transaction that is important.
Nice to know.
Can you easily check where the delay threshold is ? (4,5,6,7us?)
Does the mouse simple fail to reply if that is too delayed ?
If you nudge the 1.5MHz away from ideal, does that improve/worsen that threshold ?
eg imagine the mouse has a RC osc that is not resyncing on every edge, that limits the time window it can decode, and it may be just enough to skew.
In that case, matching the Mouse Osc would allow longer delays.
ISTR some SW-USB designs that captured bits, then decoded later, and those could simply run out of capture room, with delays above PC-test-values ?
Any sign of a crystal in the mouse ?
So, looking closer at that now, it appears that max delay is ~11 us. Don't know why I saw it at 7 us earlier...
So appx 16 bit times fails, and 6 bit times is proven ok ?
What can the P2 get that delay down to ? Is the min possible delay, ok with the mouse or is something needed there ?
Looking on the web for "maximum inter-packet USB delay" I'm seeing 7.5 bit times for some cases (for host to respond) and 6.5 bit times for others (for device to respond to host).
I've been following the development of the P2 for quite a while, and have used the P1 in the past (mostly spin , some pasm), but the discussions during P2 development have mostly been over my head, hence the continued lurking.
But when smart pins became a reality and the P123-A9 board was available, I decided it was time to get my feet wet, as it were, with a goal of getting a USB low-speed keyboard interface working. It's just been in the last few days that I've gotten to the point where I understand the USB protocol enough to do some physical experimentation.
Jmg's milestone is quite exciting -- I'm just at the stage where I can detect device connect/disconnect . I hope that in the future I can make a contribution to add to the great work y'all have done to make the P2 a reality!
Looking on the web for "maximum inter-packet USB delay" I'm seeing 7.5 bit times for some cases (for host to respond) and 6.5 bit times for others (for device to respond to host).
Is the case you have hit here, a change in bus direction, or just two adjacent (from P2-Host) packets ?
7.1.18.1 Low-/Full-Speed Bus Turn-around Time and Inter-packet Delay
Inter-packet delays are measured from the SE0-to-J transition at the end of the EOP to the J-to-K transition that
starts the next packet.
A device must provide at least two bit times of inter-packet delay. The delay is measured at the responding
device with a bit time defined in terms of the response. This provides adequate time for the device sending the
EOP to drive J for one bit time and then turn off its output buffers.
The host must provide at least two bit times of J after the SE0 of an EOP and the start of a new packet (TIPD). If
a function is expected to provide a response to a host transmission, the maximum inter-packet delay for a
function or hub with a detachable (TRSPIPD1) cable is 6.5 bit times measured at the Series B receptacle. If the
device has a captive cable, the inter-packet delay (TRSPIPD2) must be less than 7.5 bit times as measured at the
Series A plug. These timings apply to both full-speed and low-speed devices and the bit times are referenced to
the data rate of the packet.
The maximum inter-packet delay for a host response is 7.5 bit times measured at the host’s port pins. There is
no maximum inter-packet delay between packets in unrelated transactions.
If you nudge the 1.5MHz away from ideal, does that improve/worsen that threshold ?
Thinking some more about freq, the spec for LS is ±1.5%, so with a working setup, it could be useful to sweep across and outside that, and see where the Mouse falls over ?
That should confirm margins, and also the Baud control...
So we must respond within 7.5 clocks. For FS, this is 12MHz or 83ns x 7.5 = 625ns.
For P2, presume 160MHz, 2 clocks per instruction = 12.5ns.
Therefore we have 500 50 instructions / time to calculate and verify CRC, formulate the response, and turn around pins and begin sending the packet.
IIRC CRC takes, including the data shift/rotate, at least 5 instructions per bit. So a byte takes 8 x 5 = 40 instructions. so you would be likely that be ok for the first 10x instructions. But for larger packets, it is a more serious situation.
But when smart pins became a reality and the P123-A9 board was available, I decided it was time to get my feet wet, as it were, with a goal of getting a USB low-speed keyboard interface working.
Don't be embarrassed about staying in the shadows for so long. It's understandable that some won't want to publically declare their interest before actual silicon. But now that you've declared, you're free!
Seriously though, it's great to read that you and Rayman are working on HID protocols. It sounds hard, like you're partly working blind, which happens for early adopters. But I admire your persistence.
Although I'm biased because I have interest in keyboards, I don't think we can have much confidence in the USB capabilities until someone gets a low-speed HID device working.
Actually (as has been suggested elsewhere by another), it might be a good start if someone were able to communicate with a USB keyboard in the so-called "boot mode," even though that wouldn't test all of the USB stuff. Being able to connect a (USB or non-PS/2) keyboard to the P2 is an important milestone.
My apologies for posting when I haven't rolled up my sleeves to try to help. But maybe it helps a bit to know that there are folks out here who are watching with keen interest. Good luck and thanks for sharing your progress and for collaborating.
So we must respond within 7.5 clocks. For FS, this is 12MHz or 83ns x 7.5 = 625ns.
For P2, presume 160MHz, 2 clocks per instruction = 12.5ns.
Therefore we have 500 instructions / time to calculate and verify CRC, formulate the response, and turn around pins and begin sending the packet.
So we must respond within 7.5 clocks. For FS, this is 12MHz or 83ns x 7.5 = 625ns.
For P2, presume 160MHz, 2 clocks per instruction = 12.5ns.
Therefore we have 500 instructions / time to calculate and verify CRC, formulate the response, and turn around pins and begin sending the packet.
IIRC CRC takes, including the data shift/rotate, at least 5 instructions per bit. So a byte takes 8 x 5 = 40 instructions. so you would be likely that be ok for the first 10x instructions. But for larger packets, it is a more serious situation.
50 instructions = 7.5bits at 12Mbps full speed USB and P2 @ 160Mhz.
Best choose to do CRC byte by byte (not bitwise) as the data arrives so the computation is already mostly complete by the arrival of the last byte. With this approach there should then just need to be a "handful" (yet to be determined) of instructions to do the final CRC comparison check at the end and preparing the pin outputs etc before knowing whether to respond with the start of the sync. If 50 instructions is not sufficient for doing all that I'd be very surprised however I do recall Chip had some internal overhead cycles to control Smartpins but hopefully all together it should all still be quite a bit less than 100 clocks so that the P2 would not have to be run at its full speed just to support 12Mbps USB.
I've got the workings for a USB mouse driver working
Just ignoring CRC and sending commands sniffed when mouse was connected to PC.
I guess I don't know yet if it will work with any other mouse.
But, this is the "amazon basics" mouse, low cost mouse so not too bad anyway.
Anyway, I'm 100% sure now that P2 USB hardware will work for HID mouse.
Good start! Do you also stream the incoming data to hub as it arrives or just keep it in COG RAM? Will be really cool to get some full speed device working sometime soon too that exercises the entire path.
One thing I wish was easier is setting the inter-packet delay for when I need to send two packets in a row with a fixed, 6-7 USB clock spacing.
Maybe it could be rigged so that after P2 sends one packet, it will automatically wait 6 USB clocks before starting to send the next packet?
Something fixed could be dangerous ?
I thought the P2 made simple delays easy ? - tho they do need to be SysCLK adjusted, but so does the USB CLK divider ?
The A9 compiled okay with everything but 8 smart pins (P48..P55). It used 96% of the available logic. Fmax came in at only 68MHz, though, so I'm running it again with a different fitter seed to try to get it back up to ~74MHz. It's most likely that the 68MHz compilation would run fine at 80MHz, but I want to close the gap a bit.
Is anyone interested in a BeMicro CV-A9 compile? I just need to be pointed to that .qsf file containing pin assignments that some of you made.
How about the BeMicro CV-A2? I've done that one before for P2-Hot, so it can easily be done again.
Otherwise, aside from the Prop123-A9 board, I'll compile for the DE2-115 and the DE0-Nano.
Definitely the CV-A9 although I haven't gotten around to a pin assignment but I am planning on using the 80-pin edge connector so I can embed the module easily for early application specific boards rather than a "development" system.
I'm still working on the documentation for the next release.
I've covered LUT write sharing and LUT events, COGINIT with the dual-cog launching, the CORDIC missed-results event, and the COGATN attention mechanism. The events have been reorganized somewhat.
Still left is the streamer with its new modes and the smart pins and their slightly new modes.
Here is my working copy, in case anyone wants to read what's been done, so far:
Comments
So, I guess it's just the delay between sequential packets of the same transaction that is important.
Can you easily check where the delay threshold is ? (4,5,6,7us?)
Does the mouse simple fail to reply if that is too delayed ?
If you nudge the 1.5MHz away from ideal, does that improve/worsen that threshold ?
eg imagine the mouse has a RC osc that is not resyncing on every edge, that limits the time window it can decode, and it may be just enough to skew.
In that case, matching the Mouse Osc would allow longer delays.
ISTR some SW-USB designs that captured bits, then decoded later, and those could simply run out of capture room, with delays above PC-test-values ?
Any sign of a crystal in the mouse ?
What can the P2 get that delay down to ? Is the min possible delay, ok with the mouse or is something needed there ?
I've been following the development of the P2 for quite a while, and have used the P1 in the past (mostly spin , some pasm), but the discussions during P2 development have mostly been over my head, hence the continued lurking.
But when smart pins became a reality and the P123-A9 board was available, I decided it was time to get my feet wet, as it were, with a goal of getting a USB low-speed keyboard interface working. It's just been in the last few days that I've gotten to the point where I understand the USB protocol enough to do some physical experimentation.
Jmg's milestone is quite exciting -- I'm just at the stage where I can detect device connect/disconnect
Edit: oops, that's rayman's milestone...
7.1.18.1 Low-/Full-Speed Bus Turn-around Time and Inter-packet Delay
Inter-packet delays are measured from the SE0-to-J transition at the end of the EOP to the J-to-K transition that
starts the next packet.
A device must provide at least two bit times of inter-packet delay. The delay is measured at the responding
device with a bit time defined in terms of the response. This provides adequate time for the device sending the
EOP to drive J for one bit time and then turn off its output buffers.
The host must provide at least two bit times of J after the SE0 of an EOP and the start of a new packet (TIPD). If
a function is expected to provide a response to a host transmission, the maximum inter-packet delay for a
function or hub with a detachable (TRSPIPD1) cable is 6.5 bit times measured at the Series B receptacle. If the
device has a captive cable, the inter-packet delay (TRSPIPD2) must be less than 7.5 bit times as measured at the
Series A plug. These timings apply to both full-speed and low-speed devices and the bit times are referenced to
the data rate of the packet.
The maximum inter-packet delay for a host response is 7.5 bit times measured at the host’s port pins. There is
no maximum inter-packet delay between packets in unrelated transactions.
That seems the key info, so this should be within spec and hopefully still work down to 1.33us, and may work even lower ?
Addit:
Thinking some more about freq, the spec for LS is ±1.5%, so with a working setup, it could be useful to sweep across and outside that, and see where the Mouse falls over ?
That should confirm margins, and also the Baud control...
For P2, presume 160MHz, 2 clocks per instruction = 12.5ns.
Therefore we have 500 50 instructions / time to calculate and verify CRC, formulate the response, and turn around pins and begin sending the packet.
IIRC CRC takes, including the data shift/rotate, at least 5 instructions per bit. So a byte takes 8 x 5 = 40 instructions. so you would be likely that be ok for the first 10x instructions. But for larger packets, it is a more serious situation.
What we need to send is already known. And, the chances of an incoming error are very remote.
But, we have ages to check CRC if we want at low speed.
At high speed, I think CRC is more important and maybe more of a challenge.
>Actually, I should say "Full Speed" above as "high speed" is USB 2.0 I think
Don't be embarrassed about staying in the shadows for so long. It's understandable that some won't want to publically declare their interest before actual silicon. But now that you've declared, you're free!
Seriously though, it's great to read that you and Rayman are working on HID protocols. It sounds hard, like you're partly working blind, which happens for early adopters. But I admire your persistence.
Although I'm biased because I have interest in keyboards, I don't think we can have much confidence in the USB capabilities until someone gets a low-speed HID device working.
Actually (as has been suggested elsewhere by another), it might be a good start if someone were able to communicate with a USB keyboard in the so-called "boot mode," even though that wouldn't test all of the USB stuff. Being able to connect a (USB or non-PS/2) keyboard to the P2 is an important milestone.
My apologies for posting when I haven't rolled up my sleeves to try to help. But maybe it helps a bit to know that there are folks out here who are watching with keen interest. Good luck and thanks for sharing your progress and for collaborating.
50 instructions = 7.5bits at 12Mbps full speed USB and P2 @ 160Mhz.
Best choose to do CRC byte by byte (not bitwise) as the data arrives so the computation is already mostly complete by the arrival of the last byte. With this approach there should then just need to be a "handful" (yet to be determined) of instructions to do the final CRC comparison check at the end and preparing the pin outputs etc before knowing whether to respond with the start of the sync. If 50 instructions is not sufficient for doing all that I'd be very surprised however I do recall Chip had some internal overhead cycles to control Smartpins but hopefully all together it should all still be quite a bit less than 100 clocks so that the P2 would not have to be run at its full speed just to support 12Mbps USB.
Just ignoring CRC and sending commands sniffed when mouse was connected to PC.
I guess I don't know yet if it will work with any other mouse.
But, this is the "amazon basics" mouse, low cost mouse so not too bad anyway.
Anyway, I'm 100% sure now that P2 USB hardware will work for HID mouse.
That's great! I'm really glad you tried all that out. In the next release, the status reporting has become a little better.
Good start! Do you also stream the incoming data to hub as it arrives or just keep it in COG RAM? Will be really cool to get some full speed device working sometime soon too that exercises the entire path.
I'm about to try Boot mode.
Unfortunately, that means figuring out USB's CRC16.
But, I have it now.
Can use this web tool with hex data and look at the Modbus result:
http://www.lammertbies.nl/comm/info/crc-calculation.html
Then, have to invert all the bits. Then, you send LSByte first.
One thing I wish was easier is setting the inter-packet delay for when I need to send two packets in a row with a fixed, 6-7 USB clock spacing.
Maybe it could be rigged so that after P2 sends one packet, it will automatically wait 6 USB clocks before starting to send the next packet?
Something fixed could be dangerous ?
I thought the P2 made simple delays easy ? - tho they do need to be SysCLK adjusted, but so does the USB CLK divider ?
It could be a built in USB feature but embedding protocol into the hardware? Not sure if that is a good idea.
(I'm no expert and never played on on television!)
The A9 compiled okay with everything but 8 smart pins (P48..P55). It used 96% of the available logic. Fmax came in at only 68MHz, though, so I'm running it again with a different fitter seed to try to get it back up to ~74MHz. It's most likely that the 68MHz compilation would run fine at 80MHz, but I want to close the gap a bit.
Is anyone interested in a BeMicro CV-A9 compile? I just need to be pointed to that .qsf file containing pin assignments that some of you made.
How about the BeMicro CV-A2? I've done that one before for P2-Hot, so it can easily be done again.
Otherwise, aside from the Prop123-A9 board, I'll compile for the DE2-115 and the DE0-Nano.
The more testers now the better.
forums.parallax.com/discussion/164058/p2-fpga-for-de0-nano-bemicrocv-bemicrocva9#latest
I've covered LUT write sharing and LUT events, COGINIT with the dual-cog launching, the CORDIC missed-results event, and the COGATN attention mechanism. The events have been reorganized somewhat.
Still left is the streamer with its new modes and the smart pins and their slightly new modes.
Here is my working copy, in case anyone wants to read what's been done, so far:
https://docs.google.com/a/parallax.com/document/d/1WVk_NHejFVTZzYv33SL1xPU5lHQXCiVwYS7DXK3Um2Y/edit?usp=sharing