ARM OTG HID Controller anyone?

[mivanov]

Has anyone succeeded in making an ARM based keyboard? Basically one that uses Linux and is connected to a PC(the usb host port) through the ARM board's OTG usb port.

P.S don't tell me that it's an overkill, there are many legit reasons for wanting to do this, my current one being: using this to remap existing USB keyboards

[GuilleAcoustic]

More seriously, would be interested too as it could open the door to higher computation posiibilities.

P.S: Sorry for the pic, just couldn't resist .

[user 18]

There are other ways to remap existing USB keyboards -- I believe Hasu has a USB-USB converter you can use inline to achieve this very benefit.

I don't know of anyone who's done exactly what you describe off the top of my head.

[mivanov]

I am aware of Hasu's work. But there are many limitations in his design, and the cost of ARM Socs these days is low enough to make it worthwhile. Most USB host shields for the Arduino are around 20 $ and the Arduino(32u4) is like 5$, so it's like 25$ vs 35$ for some ARM SoC. The only issue is power consumption since it will need much more juice, so it's not that portable at using say 2A at 5V, but that's the theoritical max, normally I think most such Arm Socs will use around 100-200 mA which is roughly around 1W. Which isn't that bad for laptop usage.

[tufty]

I think my opinion of using a Linux computer / SoC as a keyboard controller is pretty much known.  It's stupid, and if you're thinking about doing it, you're stupid too.

However, ARM µCs are getting cheaper and faster, there's no particular reason not to use one.  It's more than possible to bitbang USB on ARM controllers, this relatively portable implementation for example.  It means giving up a pair of data lines, but given that you're talking USB to USB, who cares, right?  the downside is that it's still low-speed, but a Teensy 3.2 or similar board should be able to do this with ease, and without having to buy a separate USB shield.

There are also µCs with dual USB.  ST's STM32F407 series, for example has dual USB2.  Details here, (rather expensive) evaluation board here, and it's also available as the relatively cheap STM32F4Discovery board (cheaper, for example, than a Teensy), although it doesn't have a second port soldered in place - the pins are availabe, though.  The controllers themselves are available in various home-solderable LQFP packaging from the usual sources at relatively low prices.  There's also the LPC1837, FTDI's Vinculum II, or you could use a pair of USB-equipped controllers talking to each other via some other method.

[mivanov]

Appreciate the info.

As for why I think it's not stupid:

1. NKRO(because you need the whole HID stack for that to work)
2. Less development time - once in OTG Device mode, it should be easy to program our ARM device to do whatever we want, reusing code already written for Linux. Also allowing the usage of high level languages too.
3. What about fingerprints? We can ask our ARM SoC to remember passwords and write them when a fingerprint is matched(ofc we could use a combo of fingerprint and simple 6 digit pass).
That grants us more security because someone would need to gain access to our device's memory(hardly doable if the password storage is encrypted when locked) to get the passwords out or physically bruteforce the 6 digit pass which is a bust.
4. Integrate screen(touch is also an option to unlock our passwords).
5. A vnc/rdp client even - since ARM SoCs these days have hdmi and ethernet, why not?

So yeah, if just for remapping without NKRO, it's pointless.

But it could do so much more - Thin client, Password storage, Screen, NKRO. Not to mention Autocomplete too.

[tufty]

1. NKRO(because you need the whole HID stack for that to work)

You need the whole HID stack, host and device side, for any USB to USB converter to work.  You have far more control working at a µC level than you do with Linux. 

2. Less development time - once in OTG Device mode, it should be easy to program our ARM device to do whatever we want, reusing code already written for Linux.

Hahahahahah oh my sides.  No, really.  You're almost certainly going to have to be writing kernel level code.  For OTG controllers.  Most of which are specced in the "hand waves, and then magic occurs" form.  I've done this, it's a long way from fun.

On the other hand, most of the µC providers also give reference implementations.  ST, for example, have USB host and client reference implementations, specifically handling "reading from keyboards" and "pretending to be a keyboard", which are configurable as to which USB interface they talk on.  I haven't tried this specific case, but for the STM32F4 discovery kit it should be a case of using bits of both and putting some glue in the middle.

Also allowing the usage of high level languages too

Any language you can reasonably consider using to write controller level code under linux, you can also use to write controller-level code on an ARM µC.  And probably even stuff like the AVR if you try hard enough.

There's also the issue that your proposed converter will almost certainly have to be externally powered in order to stay within the USB spec.  The USB spec restricts non-enumerated devices (i.e. those that have just been plugged in and haven't finished starting up yet) to less than 100mA of current, and there are very few existing SoC implementations that can deal with such a low draw.  Even the raspberry pi zero needs 100mA+ at idle with a keyboard plugged in and everything else (HDMI, LED) turned off - boot requires 250mA or more.  If you try to draw too much power before enumeration, a USB controller can, and should, assume that your device is faulty, and cut all power to the port to save itself.

What you are proposing is overkill, and it's daft.

[edit] I should probably mention that, no matter what you do, you're only going to get NKRO if the "slave" keyboard already supports NKRO.  Hasu's controller doesn't do NKRO because it only goes as far as doing boot protocol for the keyboard, there's no reason it couldn't do full enumeration and thus full NKRO (again, for keyboards with NKRO) on AVR.

[GuilleAcoustic]

I agree with tufty, this will require kernel level development ... that's how drivers are done. An ARM SOC would be useful for high computation requirement though, but going to be harder to develop than a keyboard firmware for a microC.