Ada,
Get a basic 4-port only. 4-port USB2.0 are still common as new.
Just have to make sure the upstream power supply and cabling is up to the job. These hubs never have their own power pack. Review pages are full of people complaining about devices cutting out during use.
Not that having a power pack is any sure thing either. I doubt there's any hubs that can truly supply full power to all ports at once.
@Rayman said:
Somebody once said here somewhere that all usb hub chips are four port.
Microchip were demoing a 7 port usb 3 hub chip at the local trade show last week. one of the ports was upward facing so I guess they were 6 port. I suspect these higher end chips are too expensive to use in your average retail hub though
@Wuerfel_21 said:
Just the P2. I suspect that cheap USB 3.0 hub chips weren't tested properly with fullspeed hosts because they're exceedingly rare. If a hub is in highspeed mode, it only talks to the host in highspeed and every FS/LS device message is translated by the hub. But I didn't really look into it much further. The hub also came with the world's sketchiest wall adapter... Also didn't bother with cheapo 2.0 Hubs, went to ebay and ordered a used one that I am reasonably sure is a true 7-port.
The HUB is recognized by the P2 ? Because, if it is recognized then it is capable of talking upstream with full-speed hosts and it should adapt itself to that. The HUB chapter of the USB specs. talks about transactions used by USB 3.0 HUBs to comunicate with low/high speed devices, maybe it supports only that, which I believe is unusual.
FWIW, I have a 7-port USB 3.0 HUB that is a linked 2 4-ports (like yours), works well so far with the P2 and low speed devices, and an old 7-port 2.0 HUB that is really a 7-port HUB.
@macca or @Wuerfel_21 do you know why the USB driver (regularly?) fails to fully startup when debug is enabled (the code is built with -gbrk in flexspin)? I get the following debug output then nothing else when I plug in devices (either directly or via the USB hub) and the test application fails to respond to plugged in devices as well on screen. I've seen it startup and print some device information etc before but it seems sporadic and I'm unsure exactly why it fails.
@macca said:
The HUB is recognized by the P2 ? Because, if it is recognized then it is capable of talking upstream with full-speed hosts and it should adapt itself to that. The HUB chapter of the USB specs. talks about transactions used by USB 3.0 HUBs to comunicate with low/high speed devices, maybe it supports only that, which I believe is unusual.
Yes, it is detected, but only full-speed devices work. I haven't really debugged this at all, but my money is that the cheapo chips they're probably using don't properly handle the low-speed preamble from a full-speed host (as mentioned, comms with a high-speed host work totally different). Or maybe they're really particular about it and don't like our weird bitbang preamble.
@evanh said:
Ada,
Get a basic 4-port only. 4-port USB2.0 are still common as new.
I obviously already have plenty of those.
I think the truth may be that USB 3.0 hubs are only really available as 4-port due to all the extra pins required.
Also, @rogloh , having DEBUG enabled does sometimes cause issues due to the serial port being slow and messing up the timing.
True single-logical-device 7-port USB 2.0 Hubs definitely do exist. Not sure what's in the cheap ones sold these days, but I just ordered an old one on ebay that I've found reports of being true 7 port.
@Wuerfel_21 said:
Yes, it is detected, but only full-speed devices work. I haven't really debugged this at all, but my money is that the cheapo chips they're probably using don't properly handle the low-speed preamble from a full-speed host (as mentioned, comms with a high-speed host work totally different). Or maybe they're really particular about it and don't like our weird bitbang preamble.
Maybe it can be tested by plugging the USB 3.0 HUB to a USB 2.0 HUB (or port on a PC) and check if it is working correctly with low speed devices.
@Wuerfel_21 said:
Yes, it is detected, but only full-speed devices work. I haven't really debugged this at all, but my money is that the cheapo chips they're probably using don't properly handle the low-speed preamble from a full-speed host (as mentioned, comms with a high-speed host work totally different). Or maybe they're really particular about it and don't like our weird bitbang preamble.
Maybe it can be tested by plugging the USB 3.0 HUB to a USB 2.0 HUB (or port on a PC) and check if it is working correctly with low speed devices.
No, you'd have to plug it into a 1.x host port, which I'm not sure I have any. I don't think I have any old PCs from that intermediate era where that was a thing. Only XP-era ones that I think(?) have 2.0 hosts and a pre-USB one (that I installed a 2.0 controller card into... Also had to upgrade to Win98 to make the drivers work). Maybe I can find an actual pre-2.0 hub though, that should work.
Anything 2.0 or higher will switch the legacy (D+/D-) part of the hub into 480Mhz high-speed mode, which uses different signalling, as mentioned earlier. non-legacy USB (3.0 up) only uses the extra RX/TX pins and is routed separately from legacy traffic.
@Wuerfel_21 said:
Maybe I can find an actual pre-2.0 hub though, that should work.
Ebay sure does deliver on any old crap. Found a 4-port hub that explicitly claims being 1.1 FullSpeed and looks like it's NOS from 20+ years ago (translucent blue plastic, my beloved). And by "a 4-port hub", I mean they're inexplicably selling them in packs of 3 (???) for €7. Now I will be very mad if they turn out to be 2.0 anyways.
@Wuerfel_21 said:
Ebay sure does deliver on any old crap. Found a 4-port hub that explicitly claims being 1.1 FullSpeed and looks like it's NOS from 20+ years ago (translucent blue plastic, my beloved). And by "a 4-port hub", I mean they're inexplicably selling them in packs of 3 (???) for €7. Now I will be very mad if they turn out to be 2.0 anyways.
LOL, I have something quite similar, but it's clear transparent. QC sticker is dated as 2005. Funny thing was it was bought as a USB 2.0 HUB but I obviously got scammed as it was actually only USB 1.1, which is now working out nicely for the P2. The chipset is this AU9254 part - datasheet here https://pdf.dzsc.com/AU9/AU9254A21.pdf
The purported USB 1.1 Hubs (sold in quantities of 3 and with a photo of a blue unit on the listing - I recieved 3 blue ones and 1 green - how odd) are indeed actually USB 2.0.... But not High-Speed! Yes, that's a possibility. Should be fit for our purposes. I tested plugging the cheapo 3.0 hub into it, but it seems low-speed devices do work properly through that configuration, so I guess something is wrong with our P2 low-speed handling. These Hubs also work on the P2 it seems.
The ancient D-Link DUB-H7 7-port I ordered (complete in box! Apparently someone paid 39.99 for this at some point!) is infact a full fat real deal 7-port HighSpeed Hub. Inexplicably it does not want to connect to the P2, just gets stuck in a reset loop. Will have to debug this. (Do note that the "DUB-H7" model name has apparently been used for many different models, I have the silver plastic one, "H/W Ver. A5")
Also, if you were wondering why my video on LiveForum is always full of MotionJPEG artifacting, I just noticed my Webcam is a Full-Speed device (behind an actual 1.1 Hub! What is the mystery Infineon device for?)
Ok, sometimes the DUB-H7 will connect properly, but then any device I plug in gets the reset loop.
EDIT: Actually, there's more nuance to it, some devices work.
EDIT 2: It seems the startup problem can be averted by having the wall power connected to the hub.
EDIT 3: Ok I guess it works now. Just really wants the power brick to be plugged in. Good thing it isn't nearly as sketchy as the other one.
Also, the port numbers are a bit strange. The ports on the front are labeled 1 through 7, but currently ports 3,4, 6 and 7 are active as ports 1..4 (as indicated by per-port power LEDs! The reason I knew this was a true 7 port before ordering was due to some discussion around software-controlled power switching where someone posted a log to that extent. A lot of hubs actually don't have individual power switches for each port...)
Okay, first experiment is okay, just casually polling 6 devices (Kb + mouse + 4 game controllers). Need to figure out how I'll squeeze 3 extra reports into the HIDpad test.
It's supposed to be going at 500Hz currently, but I don't have a way to check that it actually gets through the poll loop before the poll timer runs out again. Not that it seems likely. These HID packets are really small (max. 8 byte for lowspeed, max. 64 byte for fullspeed - which you will notice are the same length at 1.5 vs 12 Mbaud) and the processing we're doing isn't a lot (esp. if the HID parser doesn't come into play)
Ok, it looked to me like it was originally polling each USB device at 2ms in the code, but I have some of your older code and haven't updated in a while.
No, that's exactly what it's doing. 2ms interval -> 500 Hz.
Also, interesting tidbit: The power brick doesn't actually need to be plugged in. Just inserting the barrel jack into the hub is enough to make it connect. Of course bus-powering that many devices is a crapshoot, but still interesting.
Oh thats interesting, wonder whether they have skimped on capacitors inside the hub, and the extra capacitor in the PSU is enough to get ripple under control to enable it to work. Perhaps extra capacitance on the ports would also get it across the line
No, the port power only switches on after the hub has been configured... It does work on my PC without the power supply, so I guess that has more capacitors on its side. Though as mentioned, there really isn't a reason not to have the power plugged in. 3A from the PSU vs the ~700mA the bus is able to provide.
Yeah, that's the normal switchable arrangement AFAIK.
That said, I do have one expensive "commercial grade" hub that has no upstream self-powering ability. I purchased it, after the failure (destruction) of a collection of other USB gear, hoping it could handle the spikes that result from a long cable and the devices at the end powered from a separate AC circuit than the PC. And it seems to have done the job. I no longer get the USB bus power shutting down when I power up a test circuit with the USB still attached.
Just upgraded both emulators to the new 7-port version. Thanks to implementing the aforementioned memory overlapping, the NeoYume input blob actually shrunk from 10076 bytes to 8952 bytes.
The actual benefit to this is kinda limited to reducing plug swapping, since the max player count is still 4 for Mega, 2 for Neo.
Good to hear about that code size reduction. Could a nested 4 port hub situation work too, or is that a crazy case? How much different is that configuration to poll vs a 7 port hub?
The actual device communication doesn't change, the hub only matters for device init. The main problem is that everything right now revolves around port numbers, which would need to change around when you start hotplugging nested hubs.
Yeah I could imagine nested hub port numbering would need some sort of tree traversal to enumerate. You may also need a free list/bitmap to reallocate the device addresses for the dynamic changes when entire subtrees could disappear after removal.
I tested again the new version of driver with the USB touch screen.
The device ID is 0EEF 0005
It presents itself as a pad in the hidpad to vga demo and returns something.
To discover what is this something, I modified the demo so it displays only raw reports and only when they changes.
The results:
The first long is always the device ID
When the screen is touched, it generates a continuous stream of reports:
0EEF0005 - (6 longs of zeros) - 0EEEF0005 - 00030300 - xxxxyyyy - (4 long of zeros)
When it is multi touched, it reports all touched points, one point in one report, with a "zero report" between these packets.
That means this touch screen is fully usable with the USB driver, including multi touch, it only needs a high level function to translate these reports to events. And this is a very good news for me: I have this screen in a robot.
I have only this one type of the USB touch screen available so I don't know if I am simply lucky or they have all the same report format.
Attached a cropped vga demo that displays only raw reports of only one selected device
CON
_CLKFREQ = 252_000_000
vgaBase = 8
vgaVsync = vgaBase + 4
OBJ
text: "vga/p2textdrv"
usb: "usbnew" | HAVE_HIDPAD = true, HAVE_MOUSE = true, KEYQUEUE_SIZE = 32
VAR
long iii,jjj
PUB main() | tmp, i
iii:=getrnd()
jjj:=getrnd()
text.initVga(-1,vgaBase,vgaVsync,0,text.VGA)
text.setTextColours($F,$1)
text.clear()
usb.start()
repeat
print_hidpad(5) ' replace 5 with your hub port#
PRI print_hidpad(num) | id, caps, i
if long[usb.get_hidpad_buffer+28*num+4]<>iii or long[usb.get_hidpad_buffer+28*num+8]<>jjj
iii:=long[usb.get_hidpad_buffer+28*num+4]
jjj:=long[usb.get_hidpad_buffer+28*num+8]
text.hex(long[usb.get_hidpad_buffer+28*num],8)
text.printStr(@" ")
text.hex(long[usb.get_hidpad_buffer+28*num+4],8)
text.printStr(@" ")
text.hex(long[usb.get_hidpad_buffer+28*num+8],8)
text.printStr(@" ")
text.hex(long[usb.get_hidpad_buffer+28*num+12],8)
text.printStr(@" ")
text.hex(long[usb.get_hidpad_buffer+28*num+16],8)
text.printStr(@" ")
text.hex(long[usb.get_hidpad_buffer+28*num+20],8)
text.printStr(@" ")
text.hex(long[usb.get_hidpad_buffer+28*num+24],8)
text.printStr(@" ")
That's good news pik33. I have a HDMI/VGA + USB touchscreen (GT911 based) I should try out too when I can (perhaps tomorrow). Hopefully it might work in a similar way to yours l so I can put it to some good use on a P2.
Comments
Ada,
Get a basic 4-port only. 4-port USB2.0 are still common as new.
Just have to make sure the upstream power supply and cabling is up to the job. These hubs never have their own power pack. Review pages are full of people complaining about devices cutting out during use.
Not that having a power pack is any sure thing either. I doubt there's any hubs that can truly supply full power to all ports at once.
Microchip were demoing a 7 port usb 3 hub chip at the local trade show last week. one of the ports was upward facing so I guess they were 6 port. I suspect these higher end chips are too expensive to use in your average retail hub though
The HUB is recognized by the P2 ? Because, if it is recognized then it is capable of talking upstream with full-speed hosts and it should adapt itself to that. The HUB chapter of the USB specs. talks about transactions used by USB 3.0 HUBs to comunicate with low/high speed devices, maybe it supports only that, which I believe is unusual.
FWIW, I have a 7-port USB 3.0 HUB that is a linked 2 4-ports (like yours), works well so far with the P2 and low speed devices, and an old 7-port 2.0 HUB that is really a 7-port HUB.
@macca or @Wuerfel_21 do you know why the USB driver (regularly?) fails to fully startup when debug is enabled (the code is built with -gbrk in flexspin)? I get the following debug output then nothing else when I plug in devices (either directly or via the USB hub) and the test application fails to respond to plugged in devices as well on screen. I've seen it startup and print some device information etc before but it seems sporadic and I'm unsure exactly why it fails.
EDIT: Nevermind, found the issue. My own stupidity with moving USB ports.
That seems to be changing, as people expect more faster charging from these
I think that is up to 2.4A per port, 60W total
Yes, it is detected, but only full-speed devices work. I haven't really debugged this at all, but my money is that the cheapo chips they're probably using don't properly handle the low-speed preamble from a full-speed host (as mentioned, comms with a high-speed host work totally different). Or maybe they're really particular about it and don't like our weird bitbang preamble.
I obviously already have plenty of those.
I think the truth may be that USB 3.0 hubs are only really available as 4-port due to all the extra pins required.
Also, @rogloh , having DEBUG enabled does sometimes cause issues due to the serial port being slow and messing up the timing.
I took Rayman's statement to mean all USB hubs. USB 2.0 included.
True single-logical-device 7-port USB 2.0 Hubs definitely do exist. Not sure what's in the cheap ones sold these days, but I just ordered an old one on ebay that I've found reports of being true 7 port.
Maybe it can be tested by plugging the USB 3.0 HUB to a USB 2.0 HUB (or port on a PC) and check if it is working correctly with low speed devices.
No, you'd have to plug it into a 1.x host port, which I'm not sure I have any. I don't think I have any old PCs from that intermediate era where that was a thing. Only XP-era ones that I think(?) have 2.0 hosts and a pre-USB one (that I installed a 2.0 controller card into... Also had to upgrade to Win98 to make the drivers work). Maybe I can find an actual pre-2.0 hub though, that should work.
Anything 2.0 or higher will switch the legacy (D+/D-) part of the hub into 480Mhz high-speed mode, which uses different signalling, as mentioned earlier. non-legacy USB (3.0 up) only uses the extra RX/TX pins and is routed separately from legacy traffic.
Ebay sure does deliver on any old crap. Found a 4-port hub that explicitly claims being 1.1 FullSpeed and looks like it's NOS from 20+ years ago (translucent blue plastic, my beloved). And by "a 4-port hub", I mean they're inexplicably selling them in packs of 3 (???) for €7. Now I will be very mad if they turn out to be 2.0 anyways.
Also, it does seem that microchip infact makes many-ported 3.0 hub chips: https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/00003182A.pdf
LOL, I have something quite similar, but it's clear transparent. QC sticker is dated as 2005. Funny thing was it was bought as a USB 2.0 HUB but I obviously got scammed as it was actually only USB 1.1, which is now working out nicely for the P2. The chipset is this AU9254 part - datasheet here https://pdf.dzsc.com/AU9/AU9254A21.pdf
Curious turnout from the USB hub purchase spree:
The purported USB 1.1 Hubs (sold in quantities of 3 and with a photo of a blue unit on the listing - I recieved 3 blue ones and 1 green - how odd) are indeed actually USB 2.0.... But not High-Speed! Yes, that's a possibility. Should be fit for our purposes. I tested plugging the cheapo 3.0 hub into it, but it seems low-speed devices do work properly through that configuration, so I guess something is wrong with our P2 low-speed handling. These Hubs also work on the P2 it seems.
The ancient D-Link DUB-H7 7-port I ordered (complete in box! Apparently someone paid 39.99 for this at some point!) is infact a full fat real deal 7-port HighSpeed Hub. Inexplicably it does not want to connect to the P2, just gets stuck in a reset loop. Will have to debug this. (Do note that the "DUB-H7" model name has apparently been used for many different models, I have the silver plastic one, "H/W Ver. A5")
Also, if you were wondering why my video on LiveForum is always full of MotionJPEG artifacting, I just noticed my Webcam is a Full-Speed device (behind an actual 1.1 Hub! What is the mystery Infineon device for?)
Ok, sometimes the DUB-H7 will connect properly, but then any device I plug in gets the reset loop.
EDIT: Actually, there's more nuance to it, some devices work.
EDIT 2: It seems the startup problem can be averted by having the wall power connected to the hub.
EDIT 3: Ok I guess it works now. Just really wants the power brick to be plugged in. Good thing it isn't nearly as sketchy as the other one.
Also, the port numbers are a bit strange. The ports on the front are labeled 1 through 7, but currently ports 3,4, 6 and 7 are active as ports 1..4 (as indicated by per-port power LEDs! The reason I knew this was a true 7 port before ordering was due to some discussion around software-controlled power switching where someone posted a log to that extent. A lot of hubs actually don't have individual power switches for each port...)
Okay, first experiment is okay, just casually polling 6 devices (Kb + mouse + 4 game controllers). Need to figure out how I'll squeeze 3 extra reports into the HIDpad test.
Now available in a git repo near you:
Wow lots of controllers there! What's the sample rate of each gamepad now? Is there enough time to poll everything at 60Hz?
It's supposed to be going at 500Hz currently, but I don't have a way to check that it actually gets through the poll loop before the poll timer runs out again. Not that it seems likely. These HID packets are really small (max. 8 byte for lowspeed, max. 64 byte for fullspeed - which you will notice are the same length at 1.5 vs 12 Mbaud) and the processing we're doing isn't a lot (esp. if the HID parser doesn't come into play)
Ok, it looked to me like it was originally polling each USB device at 2ms in the code, but I have some of your older code and haven't updated in a while.
Note: 500Hz/7 is still > 60Hz so that's good.
No, that's exactly what it's doing. 2ms interval -> 500 Hz.
Also, interesting tidbit: The power brick doesn't actually need to be plugged in. Just inserting the barrel jack into the hub is enough to make it connect. Of course bus-powering that many devices is a crapshoot, but still interesting.
Oh thats interesting, wonder whether they have skimped on capacitors inside the hub, and the extra capacitor in the PSU is enough to get ripple under control to enable it to work. Perhaps extra capacitance on the ports would also get it across the line
No, the port power only switches on after the hub has been configured... It does work on my PC without the power supply, so I guess that has more capacitors on its side. Though as mentioned, there really isn't a reason not to have the power plugged in. 3A from the PSU vs the ~700mA the bus is able to provide.
Yeah, that's the normal switchable arrangement AFAIK.
That said, I do have one expensive "commercial grade" hub that has no upstream self-powering ability. I purchased it, after the failure (destruction) of a collection of other USB gear, hoping it could handle the spikes that result from a long cable and the devices at the end powered from a separate AC circuit than the PC. And it seems to have done the job. I no longer get the USB bus power shutting down when I power up a test circuit with the USB still attached.
Just upgraded both emulators to the new 7-port version. Thanks to implementing the aforementioned memory overlapping, the NeoYume input blob actually shrunk from 10076 bytes to 8952 bytes.
The actual benefit to this is kinda limited to reducing plug swapping, since the max player count is still 4 for Mega, 2 for Neo.
Good to hear about that code size reduction. Could a nested 4 port hub situation work too, or is that a crazy case? How much different is that configuration to poll vs a 7 port hub?
The actual device communication doesn't change, the hub only matters for device init. The main problem is that everything right now revolves around port numbers, which would need to change around when you start hotplugging nested hubs.
Yeah I could imagine nested hub port numbering would need some sort of tree traversal to enumerate. You may also need a free list/bitmap to reallocate the device addresses for the dynamic changes when entire subtrees could disappear after removal.
I tested again the new version of driver with the USB touch screen.
The device ID is 0EEF 0005
It presents itself as a pad in the hidpad to vga demo and returns something.
To discover what is this something, I modified the demo so it displays only raw reports and only when they changes.
The results:
The first long is always the device ID
When the screen is touched, it generates a continuous stream of reports:
0EEF0005 - (6 longs of zeros) - 0EEEF0005 - 00030300 - xxxxyyyy - (4 long of zeros)
When it is multi touched, it reports all touched points, one point in one report, with a "zero report" between these packets.
That means this touch screen is fully usable with the USB driver, including multi touch, it only needs a high level function to translate these reports to events. And this is a very good news for me: I have this screen in a robot.
I have only this one type of the USB touch screen available so I don't know if I am simply lucky or they have all the same report format.
Attached a cropped vga demo that displays only raw reports of only one selected device
CON _CLKFREQ = 252_000_000 vgaBase = 8 vgaVsync = vgaBase + 4 OBJ text: "vga/p2textdrv" usb: "usbnew" | HAVE_HIDPAD = true, HAVE_MOUSE = true, KEYQUEUE_SIZE = 32 VAR long iii,jjj PUB main() | tmp, i iii:=getrnd() jjj:=getrnd() text.initVga(-1,vgaBase,vgaVsync,0,text.VGA) text.setTextColours($F,$1) text.clear() usb.start() repeat print_hidpad(5) ' replace 5 with your hub port# PRI print_hidpad(num) | id, caps, i if long[usb.get_hidpad_buffer+28*num+4]<>iii or long[usb.get_hidpad_buffer+28*num+8]<>jjj iii:=long[usb.get_hidpad_buffer+28*num+4] jjj:=long[usb.get_hidpad_buffer+28*num+8] text.hex(long[usb.get_hidpad_buffer+28*num],8) text.printStr(@" ") text.hex(long[usb.get_hidpad_buffer+28*num+4],8) text.printStr(@" ") text.hex(long[usb.get_hidpad_buffer+28*num+8],8) text.printStr(@" ") text.hex(long[usb.get_hidpad_buffer+28*num+12],8) text.printStr(@" ") text.hex(long[usb.get_hidpad_buffer+28*num+16],8) text.printStr(@" ") text.hex(long[usb.get_hidpad_buffer+28*num+20],8) text.printStr(@" ") text.hex(long[usb.get_hidpad_buffer+28*num+24],8) text.printStr(@" ")That's good news pik33. I have a HDMI/VGA + USB touchscreen (GT911 based) I should try out too when I can (perhaps tomorrow). Hopefully it might work in a similar way to yours l so I can put it to some good use on a P2.