felis / USB_Host_Shield_2.0

Revision 2.0 of USB Host Library for Arduino.
https://chome.nerpa.tech
1.8k stars 779 forks source link

documentation, examples: How to use attached HID keyboards e.g. by scanf(), gets(), std::cin? #791

Open dsyleixa opened 11 months ago

dsyleixa commented 11 months ago

neither in the documentation nor in examples folder I can see .ino code files how to use attached HID keyboards e.g. by scanf(), gets(), getchar(), getc(), std::cin - (e.g. for users to enter passwords or either strings to be then processed): How is that supposed to work?

sample code e.g., by additional lcd display, stand-allone, plugged USB-HID-keyboard, no PC-Serial connection, this should work immediately out of the box, no extra code required:

  int c;
  String s="";
  lcd.println ("Enter text, press [Enter] to terminate: ");
  do {
    c=getchar();
    lcd.print(c);
    s += c;
  } while (c != '\n');
xxxajk commented 10 months ago

There are several... Note that keyboards do not output ASCII, they output the value of the key. getchar? really? If you are using a more modern MCU, and it is supported, there's UHS3, which takes care of most of the dirty work behind the scenes.

If not, then: This one works with everything that is standard: https://github.com/felis/USB_Host_Shield_2.0/blob/master/examples/HID/USBHIDBootKbd/USBHIDBootKbd.ino This one works with a mouse too: https://github.com/felis/USB_Host_Shield_2.0/tree/master/examples/HID/USBHIDBootKbdAndMouse And finally: https://github.com/felis/USB_Host_Shield_2.0/tree/master/examples/HID/USBHIDMultimediaKbd

No examples indeed.

dsyleixa commented 10 months ago

thank you for your reply! (UHS3? really? I know that as a SD speed class...) actually I just want to use common C/C++ API functions to directly read from stdin when plugged to USB (via stdio.h, std::cin - getchar just was an arbitrary example among others) and I don't want to fiddle around with keystates or keycodes for pressed, up, hold, additional shift, ctrl or alt keys, or anything. Frankly, the examples given are an overgrown and unusable concoction of hodgepodge and tohuwabohu, tbh. OTOH it just should work like using a common USB HID keyboard on Linux or Windows: plug in, and get going. I am using an ESP32 which is capable of stdio.h and std::cin IIRC.

xxxajk commented 10 months ago

Technically, you could write the connections for STDIN/STDOUT, most users of MCUs don't bother because this tends to be too memory intensive. I suggest using it as intended. The idea of that is to save memory and as a bonus makes your code technically faster as it does not have additional abstraction layers.

UHS3.0 is indeed a set of libraries that I mostly wrote on my own. https://github.com/felis/UHS30

dsyleixa commented 10 months ago

I am just a hobby user, writing such libs is far beyond my skills. Finally I also do not write something like the Serial or the Wire libs by myself: They are available, I just use them, and I also can use some standard C libs (e.g. for sprintf) additionally. Same about the required USB libs and USB functionality: plug in a keyb USB cable and immediately one may use it, no extra threads or interrupts or anything. And now additionally all about getchar(), gets(), scanf(), std::cin should be useable at any time for either arbitrary or optional user input when wishful or required. After all, also on my RaspberryPi I just have to plug in a USB keyboard and apart from #include <stdio.h> a/o <iostream> I don't have to care about anything additional beneath or beyond, it's just there and it just works. That's the way it should work for Arduino as well, plug and play, at least for ARM and ESP boards.

dsyleixa commented 10 months ago

just now I observed that this shield uses far too many GPIO pins additionally to SPI, and it also must be compatible to my SPI touch screen which also uses many extra pins, so I'm afraid I don't have enough left. OTOH, just using i2c should be enough to make HID keyboards work.

xxxajk commented 10 months ago

I am just a hobby user, writing such libs is far beyond my skills. Finally I also do not write something like the Serial or the Wire libs by myself: They are available, I just use them, and I also can use some standard C libs (e.g. for sprintf) additionally. Same about the required USB libs and USB functionality: plug in a keyb USB cable and immediately one may use it, no extra threads or interrupts or anything. And now additionally all about getchar(), gets(), scanf(), std::cin should be useable at any time for either arbitrary or optional user input when wishful or required. After all, also on my RaspberryPi I just have to plug in a USB keyboard and apart from #include <stdio.h> a/o <iostream> I don't have to care about anything additional beneath or beyond, it's just there and it just works. That's the way it should work for Arduino as well, plug and play, at least for ARM and ESP boards.

That's not how it is within the scope of MCU use. There's no operating system, and there simply isn't enough resources in the lower end ones even if you wanted to do that. MCUs aren't designed or intended for such things. They are only intended to control signals, nothing more. C/C++ on an MCU is actually relatively a new thing. Everything used to be written in assembler.

xxxajk commented 10 months ago

just now I observed that this shield uses far too many GPIO pins additionally to SPI, and it also must be compatible to my SPI touch screen which also uses many extra pins, so I'm afraid I don't have enough left. OTOH, just using i2c should be enough to make HID keyboards work.

If your display's code is properly written, SPI can be shared without any issues.

dsyleixa commented 10 months ago

my ESP32 has got an OS (freeRTOS) which is also available for other MCUs. OTOH Arduino always is using C++ which includes a C subset. All about USB host plug+play may be executed by a proprietary suitable shield-MCU, and communicating to the main cpu (which may be even a Nano or Uno) e.g. via i2c (which needs just 2 shareable pins). As stated, USB HID p+p is indispensable, but I understand that this USB_Host_Shield_2.0 is not capable of that task. Thank you for your contributions!