fjpanag commented on pull request #2177: URL: https://github.com/apache/incubator-nuttx/pull/2177#issuecomment-724570533
> * I did a search on were `stm32_clockenable()` is used. It is true that it is called only from start-up code. No other code in STM32 arch is using it. The only other use of this function is in `stm3210e-eval/src/stm32_idle.c`, which is a board-level function. Maybe this specific board is to be fixed? > > The calls I mention will be from IDLE loop (maybe not directly, maybe via some other function) since that is the point when the board exits sleep and needs to restart clock sources, PLLs, etc. That is the only point where there will be clock changes (besides w.r.t. default clock when booting). Can you please provide me an example of this, to better understand it? Choose the MCU that you like, and please explain me how `stm32_clockenable()` is called from IDLE. > * If we want to make this perfect (and take the most performance available from these chips), then there should also be a way to state the voltage range that the MCU works. Maybe in `board.h`? > > You mean core clock voltage? This is done according to clock frequency as per datasheet recommendations. Again, I did this for STM32L476, but I'm not sure if it is 100% enabled as I didn't trust it while I encountered the issue I mentioned, which turned out to be related to flash instead. No, I am talking about the actual voltage applied on the chip itself. See the following table (taken from the reference manual of STM32F4xx, page 80):  As you see, there should also be a way to define how the board is powering the chip. What is the voltage provided. > > * Having multiple `*_rcc.c` files is very very annoying when maintaining code. Maybe we should first try to merge all these files in one? > > This was discussed many times. Merging similarly looking code was many times not wanted since it may end up in a very complex code needs to support every variation of the SoC line and every specific chip. And if not considered right, when adding support for a chip, it may break many others. I would welcome simplification to improve maintenance, but be aware this is a very critical part of NuttX and most likely would require testing with various chips if you start modifying a lot of this part of the code. > This is one of the reasons as why the different STM32 families are separated. I think ST does not make this simple since two chips of different families may be similar in one aspect but very different in another. OK, lets forget it for the moment. When I find some time, I will try to merge them, and provide a different PR. We can then choose what we like best. --- > @fjpanag I would like to test this with all the HW I have when it is ready? Thank you very much for this! For the moment I have an STM32F427 and an STM32F103 to test it. If there is some board that we are both missing, I am wiling to buy one, or donate it. ---------------------------------------------------------------- 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: us...@infra.apache.org
