v01d commented on pull request #1788: URL: https://github.com/apache/incubator-nuttx/pull/1788#issuecomment-692890361
> On some architectures you can just achieve GPIO_DISABLED by setting the pin configuration to 0, but that won't work for NRF52. But that's not really documented is it? Sounds more like a side-effect. If you look in stm32_gpio.h there's no such definition either and from what I see stm32_configgpio wouldn't deal with it normally (it would error out when it doesn't find the pin/port in it). > > As I know PSEL is always configured at the runtime because there is no hardcoded pinmux for NRF52. We can avoid this by creating definitions for all possible peripheral pin configurations, but we'll probably agree that it doesn't make sense. But besides the pinmux (which would be simply predefined _1, _2 values for a given pin), pins are always mapped at buid-time with macros. It is not necessary to define all possible values for nRF52, the macros allow a peripheral to know what pin to use, not the other way around. So you don't need all possible peripheral cases for a pin. > I'm still not sure if we should deal with it at the SPIM side or the GPIO side as proposed, but GPIO_DISABLE is a useful new feature that I'm fine with. Dealing with it on the peripheral side will also be more complicated. I'm not fond of the idea of adding such flag for just one arch (changing it for all, would be another point). Let try to consider the broad case as well when introducing changes in one arch that differ in semantics from other arch's, just for the sake of consistency. IMHO the code I suggested allows for the desired ability to not use MISO and it is not hard to do the same for other peripheral if needed so I don't really see the need for such change at GPIO. ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected]
