What probably happens now is Windoze will automatically find and download such a driver. Just this year I had to install the FTDI driver to a laptop that wasn't on the Internet.
I only know, that ftdi driver once came with windows update.
I don't think that windows finds and download drivers from foreign pages. The silicon labs driver you have to install your self for sure.
@The_Master said:
It used to bother me that, if I wanted to offer a product with physical connectivity to a PC, it would have to go through the USB port, and that the user would have to install a driver for it. (which can always get messy) This pertains to Arduino and Parallax stuff.
I'm fairly sure that Windows includes a standard CDC driver, I have built a couple of boards using a standard CDC device with a PIC and never had to install a driver. Also built a dual serial board and worked well.
Linux certainly have CDC support included (as well as others, no need to install the proprietary FTDI driver on Linux). Not sure about MacOS.
One thing that makes me mad about FTDI is that for some time it bricked whatever devices attempts to impersonate an FTDI device (all those fake chinese adapters for examples), now I think it just corrupts the data transfered without bricking the device (to prevent being sued). Anyway, I am always afraid that a "glitch" of some kind could brick a legitimate device, not to mention that you can't know what the device actually is until you plug to a PC (buy a cable, plug to Windows, and pooff, bricked). I really don't understand why companies still uses these things when there are lower cost alternatives that don't require drivers or make weird things to other devices.
@Rayman The SparkFun Serial Basic Breakout is an easy-to-use USB-to-Serial adapter based on the CH340G IC from WCH. It works with 5V and 3.3V systems and should auto install on most operating systems without the need for additional drivers.
The Windows built-in generic USB class drivers are sometimes of questionable quality, so often you still get a vendor driver download even if the device works to some extent with the generic driver. For example, the generic HID driver has no support for force feedback, you always need a special driver for that even if all the inputs work with the generic driver. (speaking of, force feedback support in usbnew, anyone?)
@cgracey said:
What is the preamble? Is it the two-period SE0 that preceeds each queery?
The preamble packet is sent to a full-speed HUB (and only to HUBs) to signal that the comunication is directed to a low-speed device attached to it, it is SOP ($80) + PRE (%0011_1100) + 1 bit delay, then the comunication is switched to low speed and can continue normally until the end of the transaction, after which the hub automatically switch back to full-speed. See chapter 8.6.5 in usb20.pdf.
It is bitbanged for two main reasons: 1. the USB smartpin mode always sends an EOP when there is no more data (must not send an EOP after the preamble), 2. I understand very little about the smartpin modes and don't know if there is a way to configure them properly for this...
I think the USB smart pin mode can output K, J, and IDLE, each for one bit period at a time, right? Is this what you meant by having to bit-bang the preamble?
@cgracey said:
I think the USB smart pin mode can output K, J, and IDLE, each for one bit period at a time, right? Is this what you meant by having to bit-bang the preamble?
The code completely disable the smartpin mode, the bit-bang toggles the D+ and D- pins with outnot in a loop (the code was posted few messages above by Ada).
As I said, I don't know if there is a better way to do that.
Hmm, it should be possible to manually drive the states through the smartpins while maintaining the more precise baud rate and possibly reducing related code size. I think I can try that after I verify that aforementioned crash/hang issue doesn't occur on the EVAL board (still going).
Yes, we have commands for generating output states for complete bit periods.
From the silicon doc:
To affect the line states or send a packet, use WYPIN on the lower pin. Here are its D values:
0 = output IDLE - default state, float pins, except possible resistor(s) to 3.3V or GND
1 = output SE0 - drive both DP and DM low
2 = output K - drive K state onto DP and DM (opposite)
3 = output J - drive J state onto DP and DM (opposite), like IDLE, but driven
4 = output EOP - output end-of-packet: SE0, SE0, J, then IDLE
$80 = SOP - output start-of-packet: KJKJKJKK, then bytes, automatic EOP when buffer runs out
@The_Master said:
It used to bother me that, if I wanted to offer a product with physical connectivity to a PC, it would have to go through the USB port, and that the user would have to install a driver for it. (which can always get messy) This pertains to Arduino and Parallax stuff.
As well as HID, there is a growing pool of CDC USB-UART bridges, that should work with no added drivers (just use Windows in built)
IIRC the early versions of Microsoft's CDC were at the 'rubbish' end of the scale, so that pushed the VCP driver development.
I'm not sure when Microsoft CDC became usable, but the expansion of available ICs suggests it is now OK ?
@Wuerfel_21 said:
Other potential option is to go SOP, PID_PRE, $00 and then reset the smart pin at the right time before the state machine starts doing the EOP.
I wish I had not made the EOP automatic after a packet. I think I might have made it harder to know when the packet is actually done. If I recall, you can sense the EOP on the receiver side.
It turns out that you can wait for D.[2] high from 'RDPIN D, lowerpin' to determine when the automatic EOP is underway after a packet of bytes has been sent. Once D.[2] is high, you can issue another USB command.
I realize now that the reason I made the EOP automatic on buffer-empty was because I only had an 8-bit command path and all 8-bit values are valid within packets. So, there was no data value possible to signify EOP while in packet mode.
@Ariba said:
I recently bought a Raspberry Pi keyboard for my P2 work. I thought it was the ideal keyboard: small, cheap, and with built-in hub.
But it doesn't work with the USBnew driver. Maybe it doesn't support this boot protocol.
Does anyone of the USB connoisseurs know how to make it work?
Andy
My Raspberry Pi keyboard works 100% with the usbnew including a hub. Either they changed something inside (a new Logitech joystick needed updating the driver) or something else is wrong.
Thank's PIK33.
With this information, I tried a bit harder and got it to work.
First problem was that the P2 resets if you plug the RasPi Keyboard in, so my tests with plug in / plug out and watch the debug output could not work.
Second problem: With the hub it's very picky about the right frequency. When I use my Edge module with the 19.2 MHz oscillator, I had to change _XTLFREQ 19_200_000 to _XINFREQ 19_200_000 to make it work. The other keyboard is a lowspeed device and works even with the default 20 MHz XTAL setting.
@Ariba said:
First problem was that the P2 resets if you plug the RasPi Keyboard in, so my tests with plug in / plug out and watch the debug output could not work.
It really shouldn't do that. Insufficient power supply? Anyways, the DEBUG messages I'd have cared about come out regardless of if you hotplug or if the devices are already plugged in on startup.
Second problem: With the hub it's very picky about the right frequency. When I use my Edge module with the 19.2 MHz oscillator, I had to change _XTLFREQ 19_200_000 to _XINFREQ 19_200_000 to make it work. The other keyboard is a lowspeed device and works even with the default 20 MHz XTAL setting.
Yeah, running at really wrong baudrate is one way to break USB. Lowspeed has looser tolerance to baud mismatch.
@Ariba said:
I recently bought a Raspberry Pi keyboard for my P2 work. I thought it was the ideal keyboard: small, cheap, and with built-in hub.
But it doesn't work with the USBnew driver. Maybe it doesn't support this boot protocol.
Does anyone of the USB connoisseurs know how to make it work?
Andy
My Raspberry Pi keyboard works 100% with the usbnew including a hub. Either they changed something inside (a new Logitech joystick needed updating the driver) or something else is wrong.
Thank's PIK33.
With this information, I tried a bit harder and got it to work.
First problem was that the P2 resets if you plug the RasPi Keyboard in, so my tests with plug in / plug out and watch the debug output could not work.
Second problem: With the hub it's very picky about the right frequency. When I use my Edge module with the 19.2 MHz oscillator, I had to change _XTLFREQ 19_200_000 to _XINFREQ 19_200_000 to make it work. The other keyboard is a lowspeed device and works even with the default 20 MHz XTAL setting.
Andy
Changing from _XTLFREQ to _XINFREQ just kills the crystal feedback on XO. I wonder why that would make a difference.
If I change the target clock frequency from 250 MHz to 252 MHz it works more reliable, also with _XTLFREQ. 19.2 to 250 MHz seems not a good ratio for the PLL.
I power the Edge board from the PC USB port that I use for programming. For most applications this is no problem if you don't go to very high clock frequencies. The Raspberry PI keyboard draws a lot of current for a short time if you plug it in, maybe there's a big capacitor inside that needs to charge up.
If I plug the keyboard in before I power up the whole board, I have no power problems.
It's a custom board with an USB-C connector, so I can later switch to a better power supply, but at the moment I need the PC for programming and debugging, and adding another power supply complicates things.
Here is a stripped down version of USBNEW that works also in PropTool / PNUT.
It only supports keyboard and mouse. I have changed the interface a bit. You can now pass the pin numbers in the start methode.
The ZIP contains also a test program that translates the keyboard scancodes to ASCII characters and control codes. The codes are compatible with the old PS/2 keyboard driver from Prop1.
@Ariba said:
Here is a stripped down version of USBNEW that works also in PropTool / PNUT.
It only supports keyboard and mouse. I have changed the interface a bit. You can now pass the pin numbers in the start methode.
The ZIP contains also a test program that translates the keyboard scancodes to ASCII characters and control codes. The codes are compatible with the old PS/2 keyboard driver from Prop1.
Andy
Thanks, Andy. Man, this USB stuff is complicated.
I've been going over the USB spec v1.1 that I found here:
I'm writing code to signal all the packet types and handle all the transaction types. It's Spin2 code with ORG/END PASM blocks to set up the routines in cog RAM and then call them as needed. It's very small, so far, but the complexity will come in the software layers.
@cgracey said:
Thanks, Andy. Man, this USB stuff is complicated.
It is, but when you think about everything it can do with two wires, it's pretty impressive really for its time. I know things were easier to program in the old days with parallel and serial interfaces but at least we now have the ability on the P2 to do what we need for connection to USB1.1 full/low speed devices and this ultimately opens up a huge range of low cost consumer grade peripherals we can use. Software size has had to multiply significantly though to realize these benefits.
I find specifications like this are pretty dry and need to be studied when the brain is receptive to these things. Once you are in the right state of mind I find you can digest it and figure out most of what it does. The worst thing is probably if you are under pressure to deliver something quickly and have to rush it without fully understanding the entire scope of these things. That can be a real stress and could either lead to failure or a major series of bugs. Hence the fear of these standards sometimes. You need to understand it first and fit it into your mind but that takes time and you are not always ready for it.
It is overengineered. But here it is, as it is. As we have a driver, maybe it may be easier to get a documend and a driver code to understand it easier. Yes, it needs a fresh head.
@cgracey said:
I'm writing code to signal all the packet types and handle all the transaction types. It's Spin2 code with ORG/END PASM blocks to set up the routines in cog RAM and then call them as needed. It's very small, so far, but the complexity will come in the software layers.
If you're trying to write new USB code from scratch, prepare for buying loads of devices to test with. There's what the spec says, what the spec doesn't say and what actually exists in the wild.
Also, if you wanna do it really properly (i.e. unlike usbnew), there's the added complexity of having to handle multiple root ports, multiple nested hubs, multiple interfaces on one device and, for HID, multi-devices that use Report ID. (see below)
@rogloh said:
It is, but when you think about everything it can do with two wires, it's pretty impressive really for its time. I know things were easier to program in the old days with parallel and serial interfaces but at least we now have the ability on the P2 to do what we need for connection to USB1.1 full/low speed devices and this ultimately opens up a huge range of low cost consumer grade peripherals we can use. Software size has had to multiply significantly though to realize these benefits.
as mentioned, usbnew is actually rather small. The blob version used in NeoYume (only has EmuPad enabled, so no key queue or mouse code, but those are pretty small components) is 9720 bytes including flexspin startup nonsense. Certainly not as light as PS/2 drivers, but oh well. I guess the total RAM usage in proportion stays similar to what PS/2 needs on P1.
Though as said, doing things properly takes more memory. usbnew has no proper handling of multiple keyboards or mice. This becomes an issue when you have something that reports a combined kb/mouse device but is actually just a mouse or just a keyboard. When you want to use such a device together with a regular keyboard or mouse, you have to plug them in a particular order so that the other device is picked up before the fake combo device can claim the one kb/mouse registration. Using two of these devices (one as keyboard one as mouse) is impossible.
Thinking about it, multi-keyboard seems like it should be possible to make work. With the key queue, anyways. keystate is a bit prickly in that regard. Would need to communicate current device types. Which I guess is a good idea either way, but hmm.
Yeah usbnew is not that huge. I was mainly talking generally for USB vs interfacing via the legacy interfaces.
You kind of said it yourself below too...USB's increased complexity does increase code requirements, but gains functionality/convenience. Normally a lot of this is handled by the OS and you don't have to deal with all of it yourself but in our case we don't have the luxury of an OS, for better or worse.
@Wuerfel_21 said:
Also, if you wanna do it really properly (i.e. unlike usbnew), there's the added complexity of having to handle multiple root ports, multiple nested hubs, multiple interfaces on one device and, for HID, multi-devices that use Report ID. (see below)
@Wuerfel_21 said:
No, but you do need to switch to the speed the attached device runs at. Also, not uncommon to have keyboards with built-in hubs.
Yes, the keyboard with hub is kind of convenient for the mouse attachment.
What about the tiny USB RF dongles that talk to a keyboard and mouse? Do those present as a single HID, with both a keyboard and mouse, or does it look like a hub with a keyboard and mouse connected to it?
Those usually are a single device with two HID interfaces. You can also get those PS/2 to USB adapters, they also work like that. Also, as mentioned, you might get a combined receiver with just a mouse paired to it. This always reports a phantom keyboard with no keys pressed.
Speaking of, be careful as to how you parse the report from a keyboard. Most will report the pressed keys in the first bytes and then leave the rest as zeroes. GarryJ's original driver stopped after a zero byte. This is incorrect and will break with those PS/2 adapters. Always look at all six bytes.
@Wuerfel_21 said:
Those usually are a single device with two HID interfaces. You can also get those PS/2 to USB adapters, they also work like that. Also, as mentioned, you might get a combined receiver with just a mouse paired to it. This always reports a phantom keyboard with no keys pressed.
Speaking of, be careful as to how you parse the report from a keyboard. Most will report the pressed keys in the first bytes and then leave the rest as zeroes. GarryJ's original driver stopped after a zero byte. This is incorrect and will break with those PS/2 adapters. Always look at all six bytes.
Thanks, Ada. I need to learn what a hub adds into the picture.
Comments
I only know, that ftdi driver once came with windows update.
I don't think that windows finds and download drivers from foreign pages. The silicon labs driver you have to install your self for sure.
I'm fairly sure that Windows includes a standard CDC driver, I have built a couple of boards using a standard CDC device with a PIC and never had to install a driver. Also built a dual serial board and worked well.
Linux certainly have CDC support included (as well as others, no need to install the proprietary FTDI driver on Linux). Not sure about MacOS.
SparkFun has this little board that works without proprietary drivers https://www.sparkfun.com/products/14050
One thing that makes me mad about FTDI is that for some time it bricked whatever devices attempts to impersonate an FTDI device (all those fake chinese adapters for examples), now I think it just corrupts the data transfered without bricking the device (to prevent being sued). Anyway, I am always afraid that a "glitch" of some kind could brick a legitimate device, not to mention that you can't know what the device actually is until you plug to a PC (buy a cable, plug to Windows, and pooff, bricked). I really don't understand why companies still uses these things when there are lower cost alternatives that don't require drivers or make weird things to other devices.
@macca Sure that doesn't need a driver? There's a Windows driver download on the Sparkfun documents page...
@Rayman The SparkFun Serial Basic Breakout is an easy-to-use USB-to-Serial adapter based on the CH340G IC from WCH. It works with 5V and 3.3V systems and should auto install on most operating systems without the need for additional drivers.
The Windows built-in generic USB class drivers are sometimes of questionable quality, so often you still get a vendor driver download even if the device works to some extent with the generic driver. For example, the generic HID driver has no support for force feedback, you always need a special driver for that even if all the inputs work with the generic driver. (speaking of, force feedback support in usbnew, anyone?)
I think the USB smart pin mode can output K, J, and IDLE, each for one bit period at a time, right? Is this what you meant by having to bit-bang the preamble?
The code completely disable the smartpin mode, the bit-bang toggles the D+ and D- pins with outnot in a loop (the code was posted few messages above by Ada).
As I said, I don't know if there is a better way to do that.
Hmm, it should be possible to manually drive the states through the smartpins while maintaining the more precise baud rate and possibly reducing related code size. I think I can try that after I verify that aforementioned crash/hang issue doesn't occur on the EVAL board (still going).
Yes, we have commands for generating output states for complete bit periods.
From the silicon doc:
To affect the line states or send a packet, use WYPIN on the lower pin. Here are its D values:
0 = output IDLE - default state, float pins, except possible resistor(s) to 3.3V or GND
1 = output SE0 - drive both DP and DM low
2 = output K - drive K state onto DP and DM (opposite)
3 = output J - drive J state onto DP and DM (opposite), like IDLE, but driven
4 = output EOP - output end-of-packet: SE0, SE0, J, then IDLE
$80 = SOP - output start-of-packet: KJKJKJKK, then bytes, automatic EOP when buffer runs out
Other potential option is to go SOP, PID_PRE, $00 and then reset the smart pin at the right time before the state machine starts doing the EOP.
As well as HID, there is a growing pool of CDC USB-UART bridges, that should work with no added drivers (just use Windows in built)
IIRC the early versions of Microsoft's CDC were at the 'rubbish' end of the scale, so that pushed the VCP driver development.
I'm not sure when Microsoft CDC became usable, but the expansion of available ICs suggests it is now OK ?
examples: see PL2303GD USB CDC to Serial Bridge Controller here
https://prolificusa.com/product-category/chips/i-o-products/usb-to-uart-g-series/
and many here
https://www.wch-ic.com/products/categories/46.html?pid=1
I wish I had not made the EOP automatic after a packet. I think I might have made it harder to know when the packet is actually done. If I recall, you can sense the EOP on the receiver side.
It turns out that you can wait for D.[2] high from 'RDPIN D, lowerpin' to determine when the automatic EOP is underway after a packet of bytes has been sent. Once D.[2] is high, you can issue another USB command.
I realize now that the reason I made the EOP automatic on buffer-empty was because I only had an 8-bit command path and all 8-bit values are valid within packets. So, there was no data value possible to signify EOP while in packet mode.
Thank's PIK33.
With this information, I tried a bit harder and got it to work.
First problem was that the P2 resets if you plug the RasPi Keyboard in, so my tests with plug in / plug out and watch the debug output could not work.
Second problem: With the hub it's very picky about the right frequency. When I use my Edge module with the 19.2 MHz oscillator, I had to change
_XTLFREQ 19_200_000to_XINFREQ 19_200_000to make it work. The other keyboard is a lowspeed device and works even with the default 20 MHz XTAL setting.Andy
It really shouldn't do that. Insufficient power supply? Anyways, the DEBUG messages I'd have cared about come out regardless of if you hotplug or if the devices are already plugged in on startup.
Yeah, running at really wrong baudrate is one way to break USB. Lowspeed has looser tolerance to baud mismatch.
It doesn't in my setup, but I power the P2 system with a Raspberry 5.1V/3A power supply with the barrel plug attached instead of microUSB
Changing from _XTLFREQ to _XINFREQ just kills the crystal feedback on XO. I wonder why that would make a difference.
If I change the target clock frequency from 250 MHz to 252 MHz it works more reliable, also with _XTLFREQ. 19.2 to 250 MHz seems not a good ratio for the PLL.
I power the Edge board from the PC USB port that I use for programming. For most applications this is no problem if you don't go to very high clock frequencies. The Raspberry PI keyboard draws a lot of current for a short time if you plug it in, maybe there's a big capacitor inside that needs to charge up.
If I plug the keyboard in before I power up the whole board, I have no power problems.
It's a custom board with an USB-C connector, so I can later switch to a better power supply, but at the moment I need the PC for programming and debugging, and adding another power supply complicates things.
Here is a stripped down version of USBNEW that works also in PropTool / PNUT.
It only supports keyboard and mouse. I have changed the interface a bit. You can now pass the pin numbers in the start methode.
The ZIP contains also a test program that translates the keyboard scancodes to ASCII characters and control codes. The codes are compatible with the old PS/2 keyboard driver from Prop1.
Andy
Thanks, Andy. Man, this USB stuff is complicated.
I've been going over the USB spec v1.1 that I found here:
https://fabiensanglard.net/usbcheat/usb1.1.pdf
I'm writing code to signal all the packet types and handle all the transaction types. It's Spin2 code with ORG/END PASM blocks to set up the routines in cog RAM and then call them as needed. It's very small, so far, but the complexity will come in the software layers.
It is, but when you think about everything it can do with two wires, it's pretty impressive really for its time. I know things were easier to program in the old days with parallel and serial interfaces but at least we now have the ability on the P2 to do what we need for connection to USB1.1 full/low speed devices and this ultimately opens up a huge range of low cost consumer grade peripherals we can use. Software size has had to multiply significantly though to realize these benefits.
I find specifications like this are pretty dry and need to be studied when the brain is receptive to these things. Once you are in the right state of mind I find you can digest it and figure out most of what it does. The worst thing is probably if you are under pressure to deliver something quickly and have to rush it without fully understanding the entire scope of these things. That can be a real stress and could either lead to failure or a major series of bugs. Hence the fear of these standards sometimes. You need to understand it first and fit it into your mind but that takes time and you are not always ready for it.
It is overengineered. But here it is, as it is. As we have a driver, maybe it may be easier to get a documend and a driver code to understand it easier. Yes, it needs a fresh head.
If you're trying to write new USB code from scratch, prepare for buying loads of devices to test with. There's what the spec says, what the spec doesn't say and what actually exists in the wild.
Also, if you wanna do it really properly (i.e. unlike usbnew), there's the added complexity of having to handle multiple root ports, multiple nested hubs, multiple interfaces on one device and, for HID, multi-devices that use Report ID. (see below)
as mentioned, usbnew is actually rather small. The blob version used in NeoYume (only has EmuPad enabled, so no key queue or mouse code, but those are pretty small components) is 9720 bytes including flexspin startup nonsense. Certainly not as light as PS/2 drivers, but oh well. I guess the total RAM usage in proportion stays similar to what PS/2 needs on P1.
Though as said, doing things properly takes more memory. usbnew has no proper handling of multiple keyboards or mice. This becomes an issue when you have something that reports a combined kb/mouse device but is actually just a mouse or just a keyboard. When you want to use such a device together with a regular keyboard or mouse, you have to plug them in a particular order so that the other device is picked up before the fake combo device can claim the one kb/mouse registration. Using two of these devices (one as keyboard one as mouse) is impossible.
Thinking about it, multi-keyboard seems like it should be possible to make work. With the key queue, anyways.
keystateis a bit prickly in that regard. Would need to communicate current device types. Which I guess is a good idea either way, but hmm.Yeah usbnew is not that huge. I was mainly talking generally for USB vs interfacing via the legacy interfaces.
You kind of said it yourself below too...USB's increased complexity does increase code requirements, but gains functionality/convenience. Normally a lot of this is handled by the OS and you don't have to deal with all of it yourself but in our case we don't have the luxury of an OS, for better or worse.
If the goal is to talk to devices directly, and not support hubs, is it still necessary to support speed switching needed for the PRE (preamble)?
No, but you do need to switch to the speed the attached device runs at. Also, not uncommon to have keyboards with built-in hubs.
Yes, the keyboard with hub is kind of convenient for the mouse attachment.
What about the tiny USB RF dongles that talk to a keyboard and mouse? Do those present as a single HID, with both a keyboard and mouse, or does it look like a hub with a keyboard and mouse connected to it?
Those usually are a single device with two HID interfaces. You can also get those PS/2 to USB adapters, they also work like that. Also, as mentioned, you might get a combined receiver with just a mouse paired to it. This always reports a phantom keyboard with no keys pressed.
Speaking of, be careful as to how you parse the report from a keyboard. Most will report the pressed keys in the first bytes and then leave the rest as zeroes. GarryJ's original driver stopped after a zero byte. This is incorrect and will break with those PS/2 adapters. Always look at all six bytes.
Thanks, Ada. I need to learn what a hub adds into the picture.