Can CAF/AEM handle 8 kHz USB HID on nRF54LM20A

[Lucca Morret]

Hi

I'm building firmware for the nRF54LM20A running USB HID + ESB at 8 kHz. Currently I am referring to the nRF Desktop (nrf_desktop) sample as a reference. But there are a few doubts that I would like to confirm.

1. For this workload, would you recommend building the whole application on CAF/AEM, handling it directly with Zephyr's interrupts and drivers, or a mix — CAF for the non-critical parts, direct handling for the 8 kHz USB/ESB path?
2. Can CAF/AEM's event dispatch keep up with an 8 kHz polling rate without adding delay or jitter, or is it only proven at lower rates?

Thanks!

[AHaug]

Hi,

nrf_desktop can achieve 8kHZ USB HID with everything on CAF/AEM. However (at least for now) there are no ESB support added to this reference sample so you would have to add this yourself. The config suspends Bluetooth while USB is connected to hold the report rate, which suggests the CPU headroom for a concurrent radio protocol at 8 kHz is thin.

ESB can achieve 8khz as well, but I'm a bit uncertain of the level of support in the SDK as of this point in time. I do know that it is possible to implement however. Do note that you will not be able to do acked ESB messages at 8k. If that is a requirement then 4kHz is the highest you can go. 8 kHz ESB is only reachable in one configuration (4 Mbps, unacknowledged, plain mode). If you need acknowledged delivery, the radio side caps out around 4 to 6 kHz and the architecture question becomes secondary to that. The reason is simply how fast the clock frequency can go vs how often you need to finish a TX.

The biggest constraint here is the CPU budget. You will most likely not be able to fit both USB and ESB coms simultaneously, but running each individually should work.

Leave ESB's radio and timer handlers inside the library's ISR. The one place to deviate is the handoff out of the ESB event callback: write into a k_msgq or a ring buffer there and let a HID provider module pull from it when AEM asks for a report, rather than submitting an AEM event from the ESB callback.

Can CAF/AEM's event dispatch keep up with an 8 kHz polling rate without adding delay or jitter, or is it only proven at lower rates?

There's no published numbers for this but as I read the sample CAF/AEM in the nrf_desktop reference should be able to keep up with 8kHz polling rate. In the reference, each poll produces a hid_report_sent_event, which triggers the sample, which produces a hid_report_event. That's two dispatches plus two k_malloc/k_free pairs per 125 µs slot.

And routing ESB traffic through AEM as well would roughly double the event rate, for which there's no data at all.

Kind regards,
Andreas