@Wuerfel_21 said:
I think @pik33 had a Pi keyboard like that working. Anyways, you got the driver working with other devices?
Yes, If I connect a Logitec Keyboard to one of the Hub Ports of the PI Keyboard, this gets recognized, but the PI keyboard which I think is internally connected to the same Hub shows no reaction.
Also all the Mouses I have here are not recognized by USBnew.
I have no game controllers to try.
@Wuerfel_21 said:
I think @pik33 had a Pi keyboard like that working. Anyways, you got the driver working with other devices?
Yes, If I connect a Logitec Keyboard to one of the Hub Ports of the PI Keyboard, this gets recognized, but the PI keyboard which I think is internally connected to the same Hub shows no reaction.
Also all the Mouses I have here are not recognized by USBnew.
I have no game controllers to try.
Post output when running one of the demos in gbrk DEBUG mode (ideally with nothing else connected).
Other thing: Is the Pi keyboard actually working? (plug into your PC or whatever)
That sort of practise has probably gone out of favour because it's getting hard to tell when people are just terrible at spelling now that the Internet is used by the masses.
That sort of practise has probably gone out of favour because it's getting hard to tell when people are just terrible at spelling now that the Internet is used by the masses.
That, and the fact that the device is named for the animal, with no real benefit to using a different plural form when context is sufficient to distinguish between flesh and electronic versions.
@cgracey said:
Anyway, if we want to use a modern keyboard or mouse now, we must understand the USB protocol. We've got the basic USB serializer/deserializer in each smart pin pair, but what goes on top of that is a whole other world that I need to learn about.
Hi Chip. Yes there are a few main layers you need to know to figure out USB.
Firstly the low level electrical and signal stuff which you've worked out for the smartpin capabilities. All of that is from the primary USB 1.1 or 2.0 standard documents.
Then there is the configuration and device detection transactions that take place to identify new devices plugged into the bus and enumerate them etc.
But then there is the device operational stuff which is defined in the USB class documentation.
There's also a HUB class which affects a couple of things but is sort of separate again.
We have different USB classes defined for things like HID (kbd/mouse/game controllers etc), Comms (CDC) devices, Printer Devices, Mass storage devices, audio devices etc. Each of these behave quite differently and there is separate class documentation for each type. For example, you will find that the HID class documentation defines the report descriptor formats used by HID devices and identifies how keys, buttons, scroll wheels, analog range of controllers are reported amongst other stuff. A lot of the goodness you actually seek now relating to USB is probably defined in these documents. I found that this stuff is available to find online if you hunt around, it doesn't seem as closed off/paywalled as you expect. Certainly other standards are, but USB isn't too bad in that way these days. You will see that each class is handled very differently. They just share the low level features of USB for their various transfers and enumeration/config. But the actual data report formats and transactions are obviously different for each class type and that's what you will see when you peruse the class documentation.
I think USB HID and mass storage and comms would be the most useful for the P2 initially, along with USB hub support. We already have a lot of great work done for HIDs and HUBs on the P2 thanks to the wonderful efforts of garryj, macca and Wuerfel_21. Some other good work was done for USB serial transfers too by SaucySolition, but I think that was for a device not a host. The Mass Storage stuff would allow the P2 to read/write files off USB sticks, and would certainly be a particularly handy capability to add to the P2. Audio USB stuff could also be useful down the line, maybe MIDI too one day. For all this to happen the USB driver support needs to be expanded (ideally conditionally) to bring in custom hub exec code and APIs for handling other other USB classes supported and demux/decode configuration operations depending on the class identified in the various descriptors so that data is handled appropriately for the device and it can coexist with devices of other classes on the same bus. Also some major changes to the report polling loop would need to take place to ensure devices are serviced according to their polling requirements.
@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.
@cgracey said:
Does anyone know if there are known ways to spoof the USB-to-serial protocol?
I think Wireshark can capture the raw USB packets on both Linux and Windows. I don't know much details about that.
I don't know if this is something that has become generic on the PC side, at this point, but FTDI made drivers for Windows, at least, to work with their own chips. Do other USB-to-serial converters have unique drivers, or is there a generic USB device class that Windows and other OS's can leverage these days for generic USB-to-serial operation?
There is the Comunication Device Class (CDC) for USB-Serial adapters, all OSes support that out of the box without the need for proprietary drivers, it is used by all non-FTDI serial adapters, as far as I know.
Microchip has an example implementation in its library for USB PICs, SaucySoliton here is working on a P2 CDC device implementation.
@macca said:
There is the Comunication Device Class (CDC) for USB-Serial adapters, all OSes support that out of the box without the need for proprietary drivers, it is used by all non-FTDI serial adapters, as far as I know.
...
No, for Silicon Labs CP210x for example you need also their driver.
To be honest, I never saw any SerialToUsb-cable whithout needing a special driver.
I'm guessing that if you've already got a Windoze driver installed for another USB<>comport device then it'll happily pick up any new devices that perform the same function. ie: It services all Communication Device Class devices.
My experience is Windozes still doesn't have one inbuilt from a clean install.
From this site:
"Limitations and Issues
The biggest limitation of this implementation is the data transfer speed — it’s much slower compared to a standard USB-serial converter. "
Unrelated to current discussion, I've had it happen two(?) times now that usbnew locks up after a long time of running. I think both of those were on @Rayman 's skrunkly boards, so idk if it's isolated to that, but now I can't sleep at night. Will have to run some more tests again.
@Rayman said:
Was that running an emulator at >300 MHz?
Possibly Though weird in that just the USB goes bad and nothing else. I think I may have just the audio go bad once, too? That actually also happened when I heated up the EDGE, so maybe that just happens. Still, gonna let the EVAL run for a few days to see if the USB still works.
Wrapping it up or heating it would be a fast way to test it. I've soldered a thermocouple to one of my Eval boards so I can get an idea of temperatures for such cases.
I realized in the USB smart pin doc, I didn't mention that you need to do an 'AKPIN upperpin' to clear IN on the upper pin, so that it can rise on the next transmit-buffer-empty. I updated the doc to reflect this. I suppose anyone who's been using the USB smart pin had figured this out.
@cgracey said:
... I suppose anyone who's been using the USB smart pin had figured this out.
I suspect GarryJ was the only one that went that deep.
If you want to know when it's okay to put another byte into the output queue, you must do an AKPIN on the upper pin to clear its IN. I think people must have reasoned this out, otherwise they would have been really stuck and maybe not able to make a driver.
Relateldy, I'd really think it'd be neat if the preamble could be generated using the smartpin. Currently we do it in software. I think the smartpins have more precise control over the baud rate. Looking at it, I'm not sure why it's like this to begin with. I think @macca wrote this part originally?
Relateldy, I'd really think it'd be neat if the preamble could be generated using the smartpin. Currently we do it in software. I think the smartpins have more precise control over the baud rate. Looking at it, I'm not sure why it's like this to begin with. I think @macca wrote this part originally?
@cgracey said:
What is the preamble? Is it the two-period SE0 that preceeds each queery?
The preamble is needed when talking to a low-speed device through a hub. The hub needs this to enable ports with low-speed devices (they're usually disabled so they don't get confused by full-speed signalling all the time)
@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...
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.
Then Arduino came out with one or two boards that used HID, so this should have made the product more sure proof (no driver necessary), but there were problems with HID as well, and I think Arduino shyed away from it.
So now in comparison to HID, having to install an FTDI driver doesn't seem so bad.
My question here is, how widespread are these FTDI ser-to-USB chips in products? Aside from Arduino/Parallax stuff, I have never seen anywhere else. Maybe they're all over the place and I don't know it. What are some other products that use them?
As I know the driver for the FTDI is already delivered with the operating system (Windows, Linux). The FTDI is really widely used.
The second choice which is also often used is Silicon Labs CP2102.
@dnalor said:
As I know the driver for the FTDI is already delivered with the operating system (Windows, Linux). The FTDI is really widely used.
The second choice which is also often used is Silicon Labs CP2102.
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.
Comments
Yes, If I connect a Logitec Keyboard to one of the Hub Ports of the PI Keyboard, this gets recognized, but the PI keyboard which I think is internally connected to the same Hub shows no reaction.
Also all the Mouses I have here are not recognized by USBnew.
I have no game controllers to try.
Post output when running one of the demos in gbrk DEBUG mode (ideally with nothing else connected).
Other thing: Is the Pi keyboard actually working? (plug into your PC or whatever)
Other other thing: the plural of mouse is mice.
There was a time when it was common to use "mouses" to refer to computer mice.
Didn't know this time is over now.
And yes, the PI Keyboard works with a PI and with a PC.
Im not at home, so I can't try the DEBUG mode now.
That sort of practise has probably gone out of favour because it's getting hard to tell when people are just terrible at spelling now that the Internet is used by the masses.
That, and the fact that the device is named for the animal, with no real benefit to using a different plural form when context is sufficient to distinguish between flesh and electronic versions.
I think it was more just a style of the times.
https://www.urbandictionary.com/define.php?term=Kliban Cat
Hi Chip. Yes there are a few main layers you need to know to figure out USB.
We have different USB classes defined for things like HID (kbd/mouse/game controllers etc), Comms (CDC) devices, Printer Devices, Mass storage devices, audio devices etc. Each of these behave quite differently and there is separate class documentation for each type. For example, you will find that the HID class documentation defines the report descriptor formats used by HID devices and identifies how keys, buttons, scroll wheels, analog range of controllers are reported amongst other stuff. A lot of the goodness you actually seek now relating to USB is probably defined in these documents. I found that this stuff is available to find online if you hunt around, it doesn't seem as closed off/paywalled as you expect. Certainly other standards are, but USB isn't too bad in that way these days. You will see that each class is handled very differently. They just share the low level features of USB for their various transfers and enumeration/config. But the actual data report formats and transactions are obviously different for each class type and that's what you will see when you peruse the class documentation.
Some of this stuff can be found here...
https://www.usb.org/documents?search=&type[0]=55&items_per_page=50
I think USB HID and mass storage and comms would be the most useful for the P2 initially, along with USB hub support. We already have a lot of great work done for HIDs and HUBs on the P2 thanks to the wonderful efforts of garryj, macca and Wuerfel_21. Some other good work was done for USB serial transfers too by SaucySolition, but I think that was for a device not a host. The Mass Storage stuff would allow the P2 to read/write files off USB sticks, and would certainly be a particularly handy capability to add to the P2. Audio USB stuff could also be useful down the line, maybe MIDI too one day. For all this to happen the USB driver support needs to be expanded (ideally conditionally) to bring in custom hub exec code and APIs for handling other other USB classes supported and demux/decode configuration operations depending on the class identified in the various descriptors so that data is handled appropriately for the device and it can coexist with devices of other classes on the same bus. Also some major changes to the report polling loop would need to take place to ensure devices are serviced according to their polling requirements.
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.
I think Wireshark can capture the raw USB packets on both Linux and Windows. I don't know much details about that.
There is the Comunication Device Class (CDC) for USB-Serial adapters, all OSes support that out of the box without the need for proprietary drivers, it is used by all non-FTDI serial adapters, as far as I know.
Microchip has an example implementation in its library for USB PICs, SaucySoliton here is working on a P2 CDC device implementation.
No, for Silicon Labs CP210x for example you need also their driver.
To be honest, I never saw any SerialToUsb-cable whithout needing a special driver.
Think I've seen people using HID protocol to send data to PC without a special driver.
This looks like an example:
https://rayshobby.net/wordpress/hid-class-usb-serial-communication-for-avrs-using-v-usb/
I'm guessing that if you've already got a Windoze driver installed for another USB<>comport device then it'll happily pick up any new devices that perform the same function. ie: It services all Communication Device Class devices.
My experience is Windozes still doesn't have one inbuilt from a clean install.
From this site:
"Limitations and Issues
The biggest limitation of this implementation is the data transfer speed — it’s much slower compared to a standard USB-serial converter. "
Unrelated to current discussion, I've had it happen two(?) times now that usbnew locks up after a long time of running. I think both of those were on @Rayman 's skrunkly boards, so idk if it's isolated to that, but now I can't sleep at night. Will have to run some more tests again.
Was that running an emulator at >300 MHz?
If so, I'm glad to have boards that can run them at all!
Possibly
Though weird in that just the USB goes bad and nothing else. I think I may have just the audio go bad once, too? That actually also happened when I heated up the EDGE, so maybe that just happens. Still, gonna let the EVAL run for a few days to see if the USB still works.
Wrapping it up or heating it would be a fast way to test it. I've soldered a thermocouple to one of my Eval boards so I can get an idea of temperatures for such cases.
I realized in the USB smart pin doc, I didn't mention that you need to do an 'AKPIN upperpin' to clear IN on the upper pin, so that it can rise on the next transmit-buffer-empty. I updated the doc to reflect this. I suppose anyone who's been using the USB smart pin had figured this out.
I suspect GarryJ was the only one that went that deep.
Have a look at the ,,Simple USB Logger" - phantastic piece of software!
https://www.incentivespro.com/downloads.html#usb-logger
If you want to know when it's okay to put another byte into the output queue, you must do an AKPIN on the upper pin to clear its IN. I think people must have reasoned this out, otherwise they would have been really stuck and maybe not able to make a driver.
Well, we are all just hacking on what Garry initially came up with. And that has
utx_byte testp dp wc if_nc jmp #utx_byte akpin dp waitx utx_tweak ' Wait #0 '#3 if < 180MHz, wait #3 '#20 if 180MHz+ _ret_ wypin utx, dmnot sure what's going on with utx_tweak there.
Relateldy, I'd really think it'd be neat if the preamble could be generated using the smartpin. Currently we do it in software. I think the smartpins have more precise control over the baud rate. Looking at it, I'm not sure why it's like this to begin with. I think @macca wrote this part originally?
utx_pre dirl dm ' Put smart pins into reset dirl dp setq #1 wrpin #0, dm ' Disable smartpin mode drvl dm drvh dp mov htmp, ##OUT_SOP | (PID_PRE << 8) rep @.l1, #16 + 1 shr htmp, #1 wc if_nc setq #1 if_nc outnot dm ' Bit-bang sync+preamble+idle waitx _preamble_wait_ .l1What is the preamble? Is it the two-period SE0 that preceeds each queery?
Looks like Garry had it figured out, anyway. No sure why the ux_tweak, either.
The preamble is needed when talking to a low-speed device through a hub. The hub needs this to enable ports with low-speed devices (they're usually disabled so they don't get confused by full-speed signalling all the time)
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...
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.
Then Arduino came out with one or two boards that used HID, so this should have made the product more sure proof (no driver necessary), but there were problems with HID as well, and I think Arduino shyed away from it.
So now in comparison to HID, having to install an FTDI driver doesn't seem so bad.
My question here is, how widespread are these FTDI ser-to-USB chips in products? Aside from Arduino/Parallax stuff, I have never seen anywhere else. Maybe they're all over the place and I don't know it. What are some other products that use them?
As I know the driver for the FTDI is already delivered with the operating system (Windows, Linux). The FTDI is really widely used.
The second choice which is also often used is Silicon Labs CP2102.
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.