You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your enhancement proposal related to a problem? Please describe.
Our customers decide which platform to use for their needs based on (among other criteria) the table where each available sample is marked if it will fit or not on each board based on the sample's ram/rom usage. Maintaining such table will be easier if this information could be easily posessed with a single run of twister
Describe the solution you'd like
The information about ram/rom usage for each test/sample will be added to the json report from twister call. I think this can be a default option, without the need of extra args (besides --json-report).
Describe alternatives you've considered
There is a west option to show this stats but it requires calling west individually for each sample/test which is inconvenient. Parsing build logs also seems like not the cleanest solution.
Additional context
Such information can also be used for tracing and visualizing the trends of tests/samples sizes for different zephyr's versions
The text was updated successfully, but these errors were encountered:
Is your enhancement proposal related to a problem? Please describe.
Our customers decide which platform to use for their needs based on (among other criteria) the table where each available sample is marked if it will fit or not on each board based on the sample's ram/rom usage. Maintaining such table will be easier if this information could be easily posessed with a single run of twister
Describe the solution you'd like
The information about ram/rom usage for each test/sample will be added to the json report from twister call. I think this can be a default option, without the need of extra args (besides --json-report).
Describe alternatives you've considered
There is a west option to show this stats but it requires calling west individually for each sample/test which is inconvenient. Parsing build logs also seems like not the cleanest solution.
Additional context
Such information can also be used for tracing and visualizing the trends of tests/samples sizes for different zephyr's versions
The text was updated successfully, but these errors were encountered: