Memory size metrics

[donnie-j]

Related area

Documentation request

Hardware specification

A (possibly small) selection of supported architectures

Is your feature request related to a problem?

My apologies if I've missed this somewhere, but I've looked around and can't find any size metrics. I did find a mention in the getting started page for for checking the size...

It's hard to know what the actual resource requirements are without hard numbers. I would suggest adding columns for "code size" and "ram required" to https://github.com/hathach/tinyusb/blob/master/docs/reference/supported.rst

Alternatively, a simple table for a common processor family for base Host and Function, plus a (possibly limited) list of adders for various supported protocol options.

Describe the solution you'd like

Ideally, one wants to be able to budget memory when designing an embedded system, before beginning development.

I have checked existing issues, dicussion and documentation

• I confirm I have checked existing issues, dicussion and documentation.

[hathach]

it is still early to document any usage, since the stack is still changing too fast. You could look at ci build linkermap, which list all resource used by each family in each examples

https://github.com/hathach/tinyusb/actions/runs/3779501216/jobs/6424805144#step:10:28

[donnie-j]

Thanks for this. It's a good starting point. In the FWIW because this it's early days dept, the numbers are not too bad.

It would be nice if certain things (DFU, minimal HID) comfortably fit in 8k flash with a small application, and others (CDC for example) fit in 16k. It looks like that might be doable with some optimization and especially removal of library functions. As always, libgcc (better part of 1k) is prob clobbering memory with unnecessarily large implementations tuned for speed :(

[hathach]

Libgcc is not part of the stack, it is only used by examples since it works with most mcus. I have no intention to optimize anything outside of files in the src folder. Admittedly, I try to keep the footprint small but never set any goals for it. Maybe later when the codebase is mature enough.