michallenc commented on PR #19004: URL: https://github.com/apache/nuttx/pull/19004#issuecomment-4591513519
This is a huge change and I will need some time to dig deep in and understand all the consequences. Just some initial thoughts. > STM32 families can use the STM32 common directory, which allows them to use common drivers and common hardware definitions shared between families. So far I am sceptical towards this. One of the greatest NuttX design characteristics is the simplicity of source code and its arch section. Having a directory with common drivers with various compile time or runtime conditions deciding what code should be run breaks this simplicity. Yes, the current approach can bring some duplicity, but I still think it's a better approach. I would cite NuttX principles here: `Sometimes is better to duplicate some logic than to introduce coupling`. We need to really consider this, because the architectural design is what makes NuttX accessible. It's super easy to explain someone the driver's organization and the relation between boards and arch section. You just call `stm32_adc_initialize` from your BSP and go to `arch/arm/stm32l4/stm32_adc.c` if you want to know what the function does. No need to figure out what file in common section is for my chip and what code actually applies because of various ifdef guards. > STM32 boards can use common board drivers. This on the other hand is something I agree with. I will need to take a detailed look, but I like the idea BSPs would serve mainly for pin definitions and would call the common init functions. After all, these functions are nothing more than arch init call and character device driver registration. > Kconfig files have been split into smaller ones, which makes them much easier to manage. This was proposed several times for new STM32 ports before, but doing it for one STM32 port and leaving the rest untouched didn't make sense. Now it's done for all STM32 ports, as it should be. +1 this is great, searching in or editing one large Kconfig file is a pain. Maybe I would just move all those `Kconfig.adc`, `Kconfig.pwm` and so on files to a subdirectory and keep the root directory for main `Kconfig` file and drivers. I think we could apply the same logic to all MCUs in the future. -- 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]
