I have been tracing a MS Keyboard that is USB LS using the P1 at 96MHz.
It is in PASM and I have also been checking CRC as it receives each bit. I am passing each byte to a spin program to decode.
In order to pass on all byte codes, I pass a 9-bit code where bit[8] indicates a special event in conjunction with the byte - SYNC, SE0, SE1, and errors.
This should be somewhat similar to getting the bytes from the smart pins.
Then, have to invert all the bits. Then, you send LSByte first.
Glad to hear of the progress!
I'm still working toward getting my first ACK'd device descriptor SETUP transaction (~$15 low-speed SIIG wired keyboard), but getting closer. My mind has been a bit numbed from reading the USB spec
It wasn't talking so I used my sniffer code on it.
The comms looked nearly identical to the Amazon mouse.
Big difference is that this Logitech mouse didn't always respond with data right away.
It would send a NAK instead of data and then you have to ask again until it gets around to sending it.
Just figured out that my period between polling was too much for Logitech.
Reduced it from 400,000 clocks to 100,000 clocks and now it works.
I can see the data is different though. Amazon had 12-bit x-y data where Logitech is 8-bit.
Here's my mouse code.
I wouldn't call it a driver yet, but it does show mouse report data over serial port to PC. It would be easy now to make this a driver though.
This is rigged for USB on pins P32 and P33, but you can change that.
Output is to Parallax Serial Terminal at 3M Baud.
Code is a complete mess and comment may or may not be accurate.
But, if you hook up a mouse and push a button or move, you might see some data.
You also need to add a 15k pull down resistor on P32 and P33.
I've tried this on 3 different mice so far and they all worked.
After years of wanting to understand USB, I think I finally know the basics...
One thing I didn't expect is that the mouse has string data stored in it.
For instance, at startup, the PC asks for first the language ID and then the name of the device. My Amazon mouse replies with "USB_Optical_Mouse" in Unicode.
It wasn't talking so I used my sniffer code on it.
The comms looked nearly identical to the Amazon mouse.
..
Just figured out that my period between polling was too much for Logitech.
Reduced it from 400,000 clocks to 100,000 clocks and now it works.
I can see the data is different though. Amazon had 12-bit x-y data where Logitech is 8-bit.
Great progress!!
Any more Mice lined up for testing ?
Big difference is that this Logitech mouse didn't always respond with data right away.
It would send a NAK instead of data and then you have to ask again until it gets around to sending it.
Hehe, so the cheapo mouse is better engineered than the Name Brand
I think that NAK, as a 'gimme-more-time', is a trick also used by Software Emulation of USB - because USB will retry, they use this to buy time for things like CRC calcs.
Of course, it throws away bandwidth, and costs energy, but the average user does not notice that.
The P2 may be able to make use of this, if it is found CRC is squeezed in FS USB.
I wonder if a WiFi mouse would look the same? Does the USB WiFi dongle just look like a USB HID at the USB end?
... and does it work at 1.5MHz ?
I just had a look at Cypress "WirelessUSB™" parts, and the irony here is, there is no USB involved - they are 2.4GHz SPI links, and 'something else' is needed for the USB.
They spec 250k and 2M data rates, so the 250k would be LS USB compatible.
I find a hybrid 2-die device, CYRF89235, that has a 32KF M8C MCU and that has only FS USB mentioned.
It looks like "Generic Desktop Contols" (page ID 01) is the one that wraps keyboard, mouse, joystick and others together. So I think one could construct a single HID "driver" to handle more than a single device -- at the same time if one had a hub driver too.
Thinking about making a little circuit board with USB connectors that plugs into the A9 board.
Needs a 3.3 V to 5 V boost circuit in order to host, but I think I have chips that can do that already for LCDs.
Might see if there's room for uSD and a flash chip too...
I was thinking of a jumper from a 5v line of an A9 board VGA connector through a transistor switch circuit so the P2 could control USB bus power. A pcb that wraps it all up would be much nicer!
I can see the data is different though. Amazon had 12-bit x-y data where Logitech is 8-bit.
How does the mouse work with only 8 bits? Seems it would need to be able to hit 1920 pixels right? Unless it is doing some type of rollover to continue counting after 8 bits?
I'm wondering how easy it might be to add direct USB communications between P2 and PC...
I think I remember some new FTDI chips communicating as HID device so that no driver is needed.
Maybe we could do that too...
Of course, once you have HOST working, you have a good idea what the PC end is actually looking for,
so it should be possible to flip that, to Device Code.
What code size & memory footprint is your Mouse/Keyboard HID Host up to ?
I'm thinking if CRC gets tight in time or code area, you could use the new Any-LUT feature (read or write mode) to manage CRC whilst the main COG does message format, and Pin-Cell admin, then the CRC is ready when it needs to send it, in a LUT address.
Today I got my first successful round trip of the SETUP portion of the get_device_descriptor transaction for my LS keyboard. I'm using Ariba's pre-computed table for generating/checking CRC16.
It's been quite a bit of flailing to get here, but seeing that first "ACK" packet come in has made it all worth it!
Now that I think about it, it would be nice if there was an easier way to get the right interpacket delay. Feels a bit cludgy now. But, maybe I'm not doing it right...
Comments
It is in PASM and I have also been checking CRC as it receives each bit. I am passing each byte to a spin program to decode.
In order to pass on all byte codes, I pass a 9-bit code where bit[8] indicates a special event in conjunction with the byte - SYNC, SE0, SE1, and errors.
This should be somewhat similar to getting the bytes from the smart pins.
I'm still working toward getting my first ACK'd device descriptor SETUP transaction (~$15 low-speed SIIG wired keyboard), but getting closer. My mind has been a bit numbed from reading the USB spec
It wasn't talking so I used my sniffer code on it.
The comms looked nearly identical to the Amazon mouse.
Big difference is that this Logitech mouse didn't always respond with data right away.
It would send a NAK instead of data and then you have to ask again until it gets around to sending it.
Just figured out that my period between polling was too much for Logitech.
Reduced it from 400,000 clocks to 100,000 clocks and now it works.
I can see the data is different though. Amazon had 12-bit x-y data where Logitech is 8-bit.
I wouldn't call it a driver yet, but it does show mouse report data over serial port to PC. It would be easy now to make this a driver though.
This is rigged for USB on pins P32 and P33, but you can change that.
Output is to Parallax Serial Terminal at 3M Baud.
Code is a complete mess and comment may or may not be accurate.
But, if you hook up a mouse and push a button or move, you might see some data.
You also need to add a 15k pull down resistor on P32 and P33.
I've tried this on 3 different mice so far and they all worked.
It is also a mess, but works.
Also rigged for P32 and P33.
This spies on traffic between PC and USB device.
If you start it before you connect the USB device, you can see the initialization sequence.
If you have those 15k resistors connected, you need to remove them for this.
One thing I didn't expect is that the mouse has string data stored in it.
For instance, at startup, the PC asks for first the language ID and then the name of the device. My Amazon mouse replies with "USB_Optical_Mouse" in Unicode.
Great progress!!
Any more Mice lined up for testing ?
Hehe, so the cheapo mouse is better engineered than the Name Brand
I think that NAK, as a 'gimme-more-time', is a trick also used by Software Emulation of USB - because USB will retry, they use this to buy time for things like CRC calcs.
Of course, it throws away bandwidth, and costs energy, but the average user does not notice that.
The P2 may be able to make use of this, if it is found CRC is squeezed in FS USB.
This might be easier than I though...
It could be that the more bone-headed your code is, the more things it works with...
This could possibly work for all HID devices...
I wonder if a WiFi mouse would look the same? Does the USB WiFi dongle just look like a USB HID at the USB end?
Then if/when that works, a unified WiFi mouse/keyboard should be simple.
Great work, Rayman!!
I just had a look at Cypress "WirelessUSB™" parts, and the irony here is, there is no USB involved - they are 2.4GHz SPI links, and 'something else' is needed for the USB.
They spec 250k and 2M data rates, so the 250k would be LS USB compatible.
I find a hybrid 2-die device, CYRF89235, that has a 32KF M8C MCU and that has only FS USB mentioned.
The 100,000 is sysclks.
usb.org/developers/hidpage/Hut1_12v2.pdf
It looks like "Generic Desktop Contols" (page ID 01) is the one that wraps keyboard, mouse, joystick and others together. So I think one could construct a single HID "driver" to handle more than a single device -- at the same time if one had a hub driver too.
Needs a 3.3 V to 5 V boost circuit in order to host, but I think I have chips that can do that already for LCDs.
Might see if there's room for uSD and a flash chip too...
I think I remember some new FTDI chips communicating as HID device so that no driver is needed.
Maybe we could do that too...
I'm in for one at either your kit or completed board level!
(I'd buy a bare PCB too...I can probably find the parts someplace!)
How does the mouse work with only 8 bits? Seems it would need to be able to hit 1920 pixels right? Unless it is doing some type of rollover to continue counting after 8 bits?
Of course, once you have HOST working, you have a good idea what the PC end is actually looking for,
so it should be possible to flip that, to Device Code.
What code size & memory footprint is your Mouse/Keyboard HID Host up to ?
I'm thinking if CRC gets tight in time or code area, you could use the new Any-LUT feature (read or write mode) to manage CRC whilst the main COG does message format, and Pin-Cell admin, then the CRC is ready when it needs to send it, in a LUT address.
There are many, many clocks between HID reports if you want to check data CRC.
The initialization sequence CRCs can be known in advance. If you really wanted to check those CRCs I guess you could in between transactions.
Code fits in a cog. No idea of actual size. You could probably control many HID devices from one cog.
It'd be a big help for P1, given PS2's decline
I was thinking of generating the CRC, more than checking it.
There is also that NAK trick, to 'buy some more time'.
It looks like most wireless devices are now FS USB, so bit-bang LS Host would have limited scope.
It's been quite a bit of flailing to get here, but seeing that first "ACK" packet come in has made it all worth it!
Now that I think about it, it would be nice if there was an easier way to get the right interpacket delay. Feels a bit cludgy now. But, maybe I'm not doing it right...