resyfer commented on PR #18499: URL: https://github.com/apache/nuttx/pull/18499#issuecomment-4009295429
Hi @linguini1 @acassis. The reason why I have each pin's alternate functions listed is because of a personal opinion of a OS letting the user do what they want with their device (using the full capability), rather than dictating what they can do. However, if it conflicts in the way NuttX does it for other boards then I'll change it back. Also, I had made changes according to the suggestions made by Alan on this...making this feature-centric rather than pin-centric. However, KConfig can cause conflicts in that. If, for example, I write a config where people can switch on features (say, UART 0 or 2) with a menu for all the unspecified pins to be chosen as input or output as well. However, due to cyclic dependencies in KConfig, I can't ensure that UART 2 (for eg.) and GPIO 3 OUTPUT (for eg.) are mutually exclusive. I can make it one way...selecting UART 2 disables GPIO 3 OUTPUT option, but the other way is not possible (cyclic dependencies... A can depend on !B, but B can't depend on !A too). So I reverted back to being pin-centric. This way allows the user to chose what they want, and also, if improperly configured, will not enable features (for eg. UART 0 will not be enabled if one of its pins are not configured for UART). I was experimenting this approach however. My reasons for adding full configurability is simply academic and allowing full usage of the the board. If you foresee this to cause maintainability issues or scaling issues, I'm fine with reverting the KConfig stuff. Let me know your feedback, thanks! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
