linguini1 commented on PR #18499: URL: https://github.com/apache/nuttx/pull/18499#issuecomment-4013066123
> Hi @linguini1 @acassis. The reason why I have each pin's alternate functions listed is because of a personal opinion of an 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. That's a good opinion to have, but it does conflict with how NuttX works with other boards. I would go as far as to say the NuttX still lets the user do what they want with their device without this method of defining pins. The currently adopted method allows the user to declaratively select the interfaces they want enabled (i.e. I2C0) and adjust the pin assignments for that interface as well. This method exposes the user to every option for the pins, yes, but probably 80% of those options are not supported by the OS anyways. It gives a false impression to the user that functionality is available (at least, from my point of view) > 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). Yeah, this is a big limitation with Kconfig. The options most boards take are: - Assume the user knows what they're doing and don't check conflicts - Use preprocessor logic to compile-time check conflicts, like ```c #if defined(CONFIG_UART2) && CONFIG_UART2_RX_PIN == 3 && CONFIG_GPOUT_PIN3 #error "Pin conflict" #endif ``` This gets very verbose in a case like yours though, where you have 27 possible GPIO output pins to check conflicts against. > 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! I see your reason for this approach here, but I think for now it is best to revert to the "old way", because this method will be different from every other board in the tree and that will be confusing for users & maintainers. It is also a little bit easier to think about enabling interfaces as a whole instead of pin-by-pin in my opinion, although it is harder to compile-time check. -- 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]
