Updating the USB stacks

[eltang]

Here and here are updated versions of the USB stacks originally used by this project. Many functionalities which had to be implemented by hand or have yet to be implemented in this project are built into them. Are there any plans to change over to them?

[haata]

Hmm.

At this point the USB Keyboard implementation here is likely of a much higher quality than in the Teensy stack. The tricky part with USB keyboards is that in order to get NKRO functionality you must tune such that it will work across multiple OSs without knowing which OS you are connected to.

Are there any particular features that are missing here? Or are you wondering if I'm going to port them back to the Teensy stack?

[eltang]

It looks like mouse keys and media keys are not yet supported on AVR, and if changing that is as simple as updating the USB stack to a newer version I don't see much reason not to. I think Paul would indeed appreciate it if you contributed any improvements you've made.

[eltang]

I am also looking for a USB stack for Keystrokes, my new custom keyboard firmware. I am trying to use Teensyduino's AVR USB stack, but I'm not exactly sure how to use it outside of the Arduino IDE and I'd love to see an example.

[eltang]

On a side note, Paul wrote this about a modification to the stack which you may be able to use to allow macro keys do do their job more quickly.

Generally, the way USB endpoints work is you write a packet into a buffer and give it to the USB to use next time the host requests data (sends an IN token) from that endpoint. On these AVR USB chips, that's done by writing to the UEINTX register, as you can see if you read through the code. From there, the USB hardware takes are of everything. You just compose the packet, give it to the hardware, and don't worry about it anymore.

Perhaps with some work, you could find a way to infer if the host has requested the data and the hardware as responded to the IN token. That all happens automatically under hardware control, so you'd have to infer if it's happened by looking for clues you are able to observe. In these older AVR chips, each endpoint is either single or double buffered. You can't implement more buffers as you can with the newer parts, or get much info. But if you configure the hardware is single buffer mode, whether the hardware tells you a new buffer is available for writing would probably be a pretty good indication it's completed the prior packet transmission. Maybe there are other ways? Honestly, I've never really put any effort into that, at least not on AVR where the hardware manages a 1 or 2 deep packet queue for you.

[haata]

I haven't been maintaining the AVR code much over the past couple years as the processors. I've moved over to ARM for all new projects at this point as they are just nicer to work with.

It would take a bit of work to just copy over directly (as I treat things as modules and sub-modules defined by custom CMake scripts). But in theory all you need is Output/pjrcUSB directory.

The API is defined in ttps://github.com/kiibohd/controller/blob/master/Output/pjrcUSB/output_com.h The hardest part would be removing the dependency on KLL as I use that to set C defines throughout the code depending on which device I'm compiling for.

As far as macros go, I'm not really sure how much it would help. I've tuned the USB stack to only send updates when (a) something has changed (b) update is requested. I handle the next macro "step" on the next full processing loop and then populate the next USB packet to go out.

In practice, this is already far too fast for most applications to handle. And well within the 1000 Hz for Full-speed USB 2.0. So I'm not sure if there's any benefit to gaming the hardware even more. Unless, the idea is to output paragraphs of data into, say, a text editor at high efficiency (even then, not useful if using a faster MCU).

[eltang]

It was really nice talking to you at the meetup! I learned a lot and I don't think there's any better alternative to your USB stack after hearing your description of it. Can you go over how I would go about using it in my project again?

[haata]

The basics are:

• Copy this directory over -> https://github.com/kiibohd/controller/tree/master/Output/pjrcUSB
• Add a compile-time define for your MCU https://github.com/kiibohd/controller/blob/master/Output/pjrcUSB/output_com.c#L34
• You may need to add some additional defines (just a few) to get it to compile.
  • https://github.com/kiibohd/controller/blob/master/Output/pjrcUSB/avr/usb_keyboard_serial.h#L266 VENDOR_ID PRODUCT_ID
  • This is where some info comes from in my firmware https://github.com/kiibohd/controller/blob/master/Output/pjrcUSB/capabilities.kll
• I also define a virtual serial port, you may or may not want it (it's useful for debugging) https://github.com/kiibohd/controller/blob/master/Output/pjrcUSB/avr/usb_keyboard_serial.c#L166
• Include output_com.h when you want to send USB codes
• These capabilities are the API
  • https://github.com/kiibohd/controller/blob/master/Output/pjrcUSB/output_com.c#L175
  • You'll need to add the functions to output_com.h as I use KLL to automatically generate the header file

[eltang]

I remember you mentioning that you were looking for a way to emulate the behavior of Apple keyboards. I think you might want to take a look at tmk/tmk_keyboard#370.