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
While working on an for me unknown board, let's say for example FRDM k64f, it would be excellent to have all the possible board specific Kconfig options listed. I was looking for UART support, and figured out from the header file that the asynchronous UART API would be the best fit for my project.
Unfortunately the only way of figuring out whether said example board supports this particular UART API is to dig through several orders of Kconfig files in order to learn whether the #ifdef in the include file is supported or not or whether to redesign ones project to use the more basic API.
In order to solve this, I propose a script crawling through the board specific Kconfig options and other included Kconfig files that would output decently formatted documentation added for each board. That way the connection between the APIs documented in include/ can be mapped to board specific support - or actually vice versa.
The text was updated successfully, but these errors were encountered:
This is already in menuconfig or guiconfig. A list would be extremely long and not hierarchical, so I am not sure this would be usable. Closing for now, if you have a concrete proposal please reopen it.
While working on an for me unknown board, let's say for example FRDM k64f, it would be excellent to have all the possible board specific Kconfig options listed. I was looking for UART support, and figured out from the header file that the asynchronous UART API would be the best fit for my project.
Unfortunately the only way of figuring out whether said example board supports this particular UART API is to dig through several orders of Kconfig files in order to learn whether the #ifdef in the include file is supported or not or whether to redesign ones project to use the more basic API.
In order to solve this, I propose a script crawling through the board specific Kconfig options and other included Kconfig files that would output decently formatted documentation added for each board. That way the connection between the APIs documented in include/ can be mapped to board specific support - or actually vice versa.
The text was updated successfully, but these errors were encountered: