Implement class framing protocol

[mchack-work]

In the new world order with both HID and CDC USB classes in the TKey we introduce a small protocol between the USB controller and the TKey CPU to differ between the two classes. See the branch:

https://github.com/tillitis/tillitis-key1/tree/ch552_hid_cdc

No PR yet.

This means that both firmware and device apps will have to use this protocol when talking to the UART.

To emulate this when using qemu, to be able to run unchanged firmware and device apps, we have a few alternatives:

1. Let qemu handle the internal protocol itself and expose two endpoints outside of qemu, probably just two ptys.
2. Let something outside of qemu handle the protocol. Keep exposing only one pty from qemu.

1

For 1, we need to open two ptys instead of just one, and then implement something in qemu that waits for all data necessary to parse the protocol and get the payload before sending it on the right pty.

2

For 2, no changes to qemu. Instead, we run an external program that attaches to qemu's pty and does all the parsing and waiting. It shows up as two devices on the client:

• a serial port, probably just another pty.
• a HID, using the Linux uhid framework.

2b

We can also use alternative 2 but just expose two ptys, without the uhid part. Then it can be used in other systems other than Linux. Let's call this 2b.

Standalone Soft HID

For both 1 & 2b we might want to have a small program that does only the Soft HID thing, and looks to the OS as a HID.

[mchack-work]

Comments from @dehanj @agren @jthornblad ?

[agren]

I have a few thoughts on the benefits of the different alternatives:

1

One benefit with 1 is that it is similar to how a TKey will behave. You get two interfaces: CDC and HID. In QEMU you get two interfaces: a CDC-pty and a HID-pty. Another nice thing about 1 is that the interface to the CDC can be the same whether you run a QEMU machine that support CDC+HID or CDC only.

2

A benefit of 2 is that it becomes easy to connect an external CH552 to QEMU. Instead of running an external program that creates a HID and serial port, a CH552 connected to a USB-to-UART dongle is used. The CH552 provide the CDC and HID devices and the USB-to-UART dongle is connected to the QEMU pty.

2b

2b has the same benefit as 2.

[dehanj]

My thoughts.

1

Benefits of this option is that if you don't care about HID and just develop something using CDC you only have to care about one pty, you also don't need anything external running compared to option 2.

The negative parts is that it complicates the QEMU model, and is no longer "just" emulating the TKey, but also parts of the CH552.

2

This is a very tempting option regarding being able to debug the CH552 a lot easier, compared to doing it directly on target. I think regardless if we chose option 1, we might want to have the option to turn it "off" and just send everything to one pty to be able to have the CH552 in the loop to debug and implement features on it.

2b

This gives the benefit of both option 1 and option 2, and more or less just separates the UHID part from the external program. We then need, as you write, another external program that creates the Soft HID things, at least for Linux.

From a perspective of not Linux users, this may benefit in more portability, or an option of creating a virtual HID on other OS as well.

2c

Adding another option (maybe overkill) where you can chose to filter the output. One pty, where you at start of the machine can chose to only have CDC data, or the full protocol. Something like protocol=[cdc|both].

This is more or less option 2b, but inside of QEMU. It may complicate things in the model, but it would give us all options of above, and make it easier to use for the ones who just care about CDC since they won't' need an external program. You have to upload the app with CDC, so only having HID makes no sense (yet).

Conclusion: I think the best candidate, so far, is option 2b or 2c.