tinnedkarma commented on issue #17004: URL: https://github.com/apache/nuttx/issues/17004#issuecomment-3287684826
I am sorry, I find it hard to understand this pushback, it's just my opinion, another view on the problem. I hoped we can talk about it, not dismiss it, I am not the one that will take the last decision anyway. @cederom True, but that still makes it a board configuration. I'm sure you know the stm performance line mcus. The clock tree is a hassle. Changing the clock, regardless if it is from 8Mhz to 16Mhz, or to any non multiple value is not just a divisor switch, almost always there needs re-clocking. So you end up passing through all of the defines in the board.h file, another define during that process will, most of the time make it easier to get the timing correctly. Also, different configs of the same board, aiming at different board revisions may be also lead to discrepancies, as we are facing right now, all of the `CONFIG_BOARD_LOOPSPERMSEC` configs should be kept in sync because they are set by the board's hardware mostly, having different values makes no sense, not the board configuration (I do not think this is an issue, but there is feedback about duplication for the nuttx codebase) @acassis Again, it's not my intention to quarrel, we can keep things as they are, my suggestion is still a define, so the optimizations will act exactly the same way regardless if it is a kconfig define or a manual define. We already do the same kind of configuration in the board.h, from changing clocks to selecting dma channels, although the way I suggest is faster, cleaner, as you do not have to move the config back to the boards config after changing it. Other things, such as recompilation after each change and the fact that a define, so it's resolved by the preprocessor stays the same. The optimization issue, although I feel like barking right now, may come from the fact that the compiler unwraps the loops, so no jmp instruction, specific to every kind of loops, and it can do that easily as the number of loops is set at build time, and cannot change during runtime. Nevertheless, I am not here to argue. If you do not want my input that is fine, in the end you are the ones choosing, if not, you can take my suggestions into account for what they are, another point of view. -- 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]
