Replies: 1 comment
-
building descriptor is considered as application work, since it is application specific. Descriptor Macro only serves as template, if application need more than those template. They could build their own descriptors. I am open to enhanced approach, but it has to be pure C and take zero-footprint like existing macro. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Currently, the configuration uses macros that create a giant byte array, and careful math to ensure all the sizes line up. Given how well defined USB is, I'd like to propose a compile-time or AOT-compilable configuration with typechecking, automatic length computation, better IDE autocomplete, and other such niceties.
There are several ways such a thing can go, being either completely done at runtime (unhelpful for very constrained environments, though good for dynamic endpoint configuration), compile time (static, but requires no extra resources on the device), or as some sort of pre-compile/ahead of time configuration builder (static, no extra resources, may require learning new languages, toolkits, etc).
I've implemented a proof of concept of this, with just a few descriptors for CDC, MIDI, and the RPI Reboot interface. Mine is completely done at compile time using C++ constexpr, which also gives the opportunity for runtime use too. However, string wrangling does require a pre-compilation step right now, as I haven't figured out how to do that inline yet.
The gist above shows how it works, and on the RP2040 compiles down to an identical byte array in the
.o
files and the final.elf
has none of the builders or templates required to compute it at compile time. Several areas are not fully type safe, and I wanted to see if there is interest for this before putting in the loads of work required to polish this. I'm open to other approaches too.Beta Was this translation helpful? Give feedback.
All reactions