Blackpill F303 vs BluepillF103CB: ADC speed performance

[Alteregoxxx]

Hello, experimenting with both MCUs, I've noticed that, using your core, F303CC adc speed performance Is about 50% slower than that achievable on F103CB, even manipulating all the possibile settings for F303CB (such as ADC clock division, sampling time).
Looking at the hardware specs, It should be exactly the opposite, considering that F303 has an ADC capable of 5Msample/s, while F103 has a 1Msample/s adc...
Tests have been performed on the same sketch: the sketch simply does N conversions in a for loop and measures the time required to complete It.
Looking at both the analogRead() implementations in your core, It seems that for the F303 there are much more code instructions than for the F103 hence, probably, the bad F303 performances are due to code overhead.

[fpistm]

analogRead is for Ardunio API compatibility and is really not optimized and does a complete init, single ended measure then deinit.
If you want optimize the speed you would have to wrote your own code using HAL.
On the forum, I've put an example how to use ADC with DMA for F103 porting from the CubeExample:
https://www.stm32duino.com/viewtopic.php?f=41&t=110
There is an issue already open to perform ADC optimization (#5).
Any contribution are welcome 😉

As this is a duplicated issue, I close it.

[Alteregoxxx]

analogRead is for Ardunio API compatibility and is really not optimized and does a complete init, single ended measure then deinit.
If you want optimize the speed you would have to wrote your own code using HAL.
On the forum, I've put an example how to use ADC with DMA for F103 porting from the CubeExample:
https://www.stm32duino.com/viewtopic.php?f=41&t=110
There is an issue already open to perform ADC optimization (#5).
Any contribution are welcome 😉

As this is a duplicated issue, I close it.

Hello Frederic,
just to clarify: if my comment did sound unpolite and/or unappreciative, I'm sorry, it was absolutely not my intention! It's just that english is not my native language!
I absolutely appreciate your outstanding work on this core and it was not even remotely my intention to underestimate it!

Now, I'll try to explain better myself: I know that the Arduino API is not intended for performances, and also know that it does perform init, calibration, measure, deinit, for each call, and that this will never be even remotely comparable to what one can obtain using HAL directly and/or LL_HAL (I did that for the STM32F303, I've been also successful in using the ADC in DMA mode, gotting almost all the full 5Msamples/s promised in its datasheet, very very impressive!) , nevertheless:

• considering that both, STM32F103 and STM32F303, pay the overhead price of init, calibration, measure, deinit, for each analogRead() call

• considering that STM32F303 have a much more faster ADC (5Msample/s VS 1Msample/s for the F103)

• considering they have the same CPU clock speed (72MHz)

I was simply asking why STM32F303 got such a massive fall in terms of speed compared to STM32F103 and if it was possible or not to try to optimize it to match the STM32F103 performances, that's all :-)

Consider that using your latest core version, the STM32F303 performances are almost 30-40% slower than the ones of a modest Arduino Nano (ATMEGA328P mcu @16mhz cpu clock) while, using this same core version on a STM32F103, the latter is 10-20% faster than Arduino Nano.

P.S. Regarding a mine eventual contribution on the core, it's sure it's on my intention, however I'm still trying to have a good, complete "overview" and general understanding on how you core is constructed and still fighting with all the STM HAL intricacies, hence I'm not still confident I can be a good contributor for this repo, sorry! :-)

[fpistm]

@Alteregoxxx

No worries ;)
I've several stuff in // to answer, fix, analyse,... so I try to answer all as best as I can and bring a first feedback quickly.
Digging to how analogRead manages the ADC does not explain why the STM32F303 is slowest than you expect. It is almost the same way to call the HAL. The only difference I can see is the ADC clock config, on STM32F103 the ADC clock is set in the system clock config with a prescalser of /6, so the Freq is 12 MHz (max is 14 MHz).
For F303, there is no specific prescaler which means the ADC use the synchronous clock derived from AHB clock and the ADC_CLOCK_SYNC_PCLK_DIV4 is used. So the freq is 18 MHz.
You can redefine the ADC_CLOCK_DIV to ADC_CLOCK_SYNC_PCLK_DIV1 to reach 72 MHz using the build_opt.h (see the wiki).

I will not change this as it is a generic API common for all series.
As said, an issue is opened for AD optimization and this will be part of this.

[Alteregoxxx]

@fpistm
Hello Frederic, thanks a lot for your feedback!
I already tried playing with the ADC_SAMPLINGTIME and the ADC_CLOCK_DIV and compared the speed performances when it is set at ADC_CLOCK_SYNC_PCLK_DIV1, ADC_CLOCK_SYNC_PCLK_DIV2, ADC_CLOCK_SYNC_PCLK_DIV4, at all the possible ADC_SAMPLINGTIME allowed settings: despite choosing the lowest sampling time and the smallest clock division,ADC_CLOCK_SYNC_PCLK_DIV1,(that will be unusable nevertheless, due to very poor and inaccurate readout, despite using a very very low impedance voltage source, read an opamp buffer), the speed increment is very very very marginal, practically irrilevant, suggesting that the bottle neck isn't the time the adc spend to perform a conversion (sampling time + conversion time) but, reasonably, a software "overhead". I remember some months ago I did a little bit of investigation on the execution time required by all various HAL functions involved when performing a conversion and, going by memory, I remember that the calibration function was the most time consuming one.
Still, looking at your core implementation, the latter is performed on both, STM32F103 and STM32F303, hence I really do not understand such a large differences on their conversion speed performances: is it reasonable to speculate something could be "wrong" in the STMicroelectronics HAL implementations of adc functions for STM32F303 ?

[fpistm]

In that case, this is related to HAL and could not help on this as I'm (like you) a user of those API.
I guess, the best way is to test with a Cube IDE tests programs to compare and open an issue to the STM32CubeFwFx GitHub to track this point.