PS/2 and USB will be separate modes and will never be used simultaneously.
In principle, D+ and D- will only be used as OUTPUT in a hypothetical future USB-OTG scenario, correct? Maybe we can drop this idea for now, or in the future, create an improved Plank if this USB-OTG-THING ever becomes a reality.
Just thinking out loud, sorry if I say anything silly! . Some ideas:
add two diodes (low cap etc for USB ) to make it unidirectional D lines
use two Zener diode (or something like that) for D lines, maybe the capacitance will be excessive…
fixed the direction 1T45s (always input)
ESD prot as drop volt?
Maybe something using a CJ431
or do nothing and just always set it as an input via firmware, although that’s riskier…
@electronic_eel You know way more about electronics than I do—whatever you decide, I trust your judgment!
NOTE: I need free pins to communicate with the PIO and for future things. If you want to keep bidirectionality, I propose using ONLY BIO6 and BIO7 for the 1T45s. I think everything should work fine with the current code…
Wouldn’t a PS/2 / USB keyboard and mouse translator be a useful feature?
Like connect a historic PS/2 keyboard to a modern PC? Or use a modern keyboard on an ancient computer that only has PS/2?
You can buy these adapters. I have used one for some time, tried like a dozen of them with different ICs on them, and they were all awful. Like sometimes hanging keys, lost keystrokes and similar things awful.
I don’t say that this has to be the first thing to implement, but designing the plank hardware in a way that would make it possible.
It adds a few basic components to the plank. I don’t really think this is an issue. I’m more concerned about the 1T45 needing extra control lines and this clashing with the PIO code requirements.
Adding a 3.3V regulator and two 1T45 to the plank (D+ and D-). The direction pins of these additonal 1T45s will have to be driven via BIO6 and BIO7 (Leaving everything else exactly as it is)
I’m no way claiming to be an USB protocol expert. But IIRC USB lowspeed (1.5 MBit/s) and fullspeed (12 MBit/s) have these 1.5k pullups to 3.3V that determine which of the speeds to use. I guess this plank and any software implementations are lowspeed only, correct?
So to be USB device we’d need one switchable pullup resistor on D- for lowspeed.
To be USB host we would need some switchable higher resistance pulldown resistors, to be able to detect that there is some device connected and has this pullup. Maybe we could cheat here and just have permanent 220k (or something in this order of magnitude) pulldowns connected. These would also be present when sniffing, but shouldn’t interfere too much with a lowspeed connection.
@electronic_eel We could add a jumper bridge or slide switch for when the Plank is used as a pure USB device (not sniffing) and no other usb device connected
This would allow the user to physically switch the D+ and D- data lines between different resistors, making it simple and easy to use.
For USB Host mode scenario, we could configure it via BP firmware, right?
USB> set FULL SPEED HOST-OTG
With this, we already know that the connected device is a Full-Speed device, so we don’t need a “sense” mechanism.
This would be the simplest approach—I’m trying not to use more BIO pins…
With these changes, the Plank could be used for the following (just off the top of my head):
Sniffing PS/2 and USB (low speed and full speed) Pure USB device USB Host OTG PS/2 Keyboard → USB Keyboard (pure PLANK conversion) USB Keyboard → PS/2 Keyboard (pure PLANK conversion) no pure PLANK conversion scenarios via Bus Pirate’s USB-C composite device
btw, @electronic_eel And let’s not forget that we can use the Plank as an input and add a new descriptor to the Bus Pirate’s USB Composite Device.
This means we could also create no pure PLANK conversion scenarios like:
PS/2 Keyboard → Plank → USB Composite Device on Bus Pirate Bus Pirate (via Bus Pirate’s USB-C) presents an additional keyboard descriptor (bridge between PS2 KEYBOARD Plank)
This opens up a lot of possibilities!
This discussion is turning out to be very productive!
If the USB C resistors set speed then maybe it’s better to revert to B?
I went through a schematic for a spark fun dev board and they do the USB C dance way way differently than I normally do. I will investigate that further as well.
Does OTG host need a license? Internet says 2001 so patents must be expired now? I know it was an issue in the past. Not that you shouldn’t do it for fun, but I can’t sell an infringing product.
I also know that OTG host in PIO is super super slow, so I imagine limited to keyboards and similar.
Generally, I start with a minimum acceptable design and then start to add in the wish list. It’s nice to have something to dog food, and it fits better into our resource budget. Could we pick some must haves and move others to the next revision?
@electronic_eel , please take a look and let me know if I’m messing anything up:
Add an additional position slide switch to set the speed (PURE PLANK USB DEVICE). We simply leave the Full-Speed or Low-Speed resistors on the data lines, depending on the switch position.
Add a 3.3V regulator and two 1T45 to the plank (D+ and D- ). The direction pins of these additonal 1T45s will have to be driven via BIO6 and BIO7. With this, we’ll have bidirectional communication on the USB data lines without any issues.
I think these changes are worth it, and they don’t seem too difficult to implement.
The last time I was using a software-emulated USB stack, lowspeed was the only thing possible. This was in Atmega-times, so not taking the capabilities of the PIO into account. So this probably has changed now.
But there is still a difference between just sniffing, which just needs something very similar to a logic analyzer function in one direction, and being a usb device, where you need to answer a request within the strict timing requirements your host sets.
So do you also have code to implement a USB Fullspeed device?
The revisions aren’t for users, they are for us. I hate getting out on a limb with no board in production.
I realize we can’t increment every two days like we could in shenzhen, but I feel that is even more reason to have boards constantly in flight. The cost is negligible. Less than a few coffees or beers at my corner cafe.
Yes, I like the idea of a physical switch. This is easier to implement than dealing with additional pins to enable FETs.
How about something like this:
The switch has 3 positions:
Sniffing / Host / no resistor
Lowspeed Device
Highspeed Device
The switch has dual poles, so we can connect the correct resistors to the correct lines and not confuse the users.
But the device decides what speed to use, not the host. So you don’t know what the device wants and the devices don’t have a label on them or something.
But we could require the user to try both.
We could also try the permanent very low pulldown approach and then just sense the state of the lines, just like a proper host would. I guess this will work. So maybe prepare footprints for these permanent pulldowns and then we can try it out. If it doesn’t work we can resort to requiring the user to set it on the commandline.
I think the OTG you are referring to means a device that can switch to host role by figuring out that it is now connected to another device. This is some special logic. But we don’t need that here because you have the slider switch and the commandline to tell the plank what to be.
Yes, we don’t need to overcomplicate it.
But the risk of frying other USB hosts or peripherals by accidently sending 5V down their data lines should be mitigated. I’d say this means using the 3v3 regulator and the two 1T45s. Also I think it would be a good idea to have these from the start because accessing such a plank is quite different than from accessing a plank without 1T45s - so it would require maintaining two different set of PIO codes. I think it would be easier to not have to do that.
Add an additional position slide switch to set the speed (PURE PLANK USB DEVICE). We simply leave the Full-Speed or Low-Speed resistors on the data lines, depending on the switch position.
Add a 3.3V regulator and two 1T45 to the plank (D+ and D- ). The direction pins of these additonal 1T45s will have to be driven via BIO6 and BIO7. With this, we’ll have bidirectional communication on the USB data lines without any issues.
Add the very low pulldown approach to sense the state of the lines
. Some ideas:
Sniffing PS/2 and USB (low speed and full speed)
PS/2 Keyboard → Plank → USB Composite Device on Bus Pirate
).