Migration from F4 to F0 - Resource Request?

[######]

Hello,

Are there any resources similar to AN3364, that describe the migration directly from F4 to F0?

Thanks.

[Andrew Neil]

Doesn't combining Tables 2 & 4 give you F4 vs F0:

See also Table 1;

 

Going from F4 to F0 is a "downgrade"

 

[######]

"Doesn't combining Tables 2 & 4 give you F4 vs F0:"

Sort of... :smiling_face_with_smiling_eyes:

Taking the ADCs as an example:

F1 vs F0

F1 vs F4

This tells me that the ADC is different to the F1 on both the F0 and F4. But it doesn't tell me if the F0 and F4 are the same (I suspect not).

Another example, I know the SPI on the F0 and F4 are different, as the F0 uses version 1.3 of the SPI peripheral, rather than the 1.2 version in F1 and F4 (as described in AN5543).

This is covered in the tables, and can be understood, but only because the F1 and F4 are fully software compatible (hence I assume they operate the same, but are de-featured at the lower IC):

As per my previous post, I was wondering if there were any extra resources that either explained the F0 advances (if it is a newer generation of IC) or an updated comparison, or an overview summary of the peripheral against the STM32 type?

Thanks for your comment though.

[Pavel A.]

@###### F0 is newer than F4 by release date, this explains that its peripheral IPs are newer. But its CPU is M0 (not even M0+) compared to M4-FPU of the F4.

Summary of peripherals unfortunately is not easy to find.  Please refer to the RM and DS documents of the specific parts. Some people managed to dig this information out of CubeMX database.

 

 

[waclawek.jan]

Migration documents are made only for families, where migration (which means, "making the same or very similar application using different parts, here different mcu") makes sense.

'F0 and 'F4 are at the very opposite ends of the spectrum, it does not make sense to migrate an application from 'F4 to 'F0.

Cube/HAL is said to be a vehicle to move portions of designs seamlessly across the whole STM32 family. I don't use Cube/HAL.

The obvious difference between 'F4 and 'F0 is the processor (Cortex-M4 vs. M0); one very straightforward consequence is the strict requirement for aligned accesses in 'F0.

'F4 also has (besides higher max clock) a FLASH accelerator.

ADC is different in every family, but the 'F2/'F4/'F7 ADC differs from others' even more e.g. by the lack of need for calibration.

SPI and I2C are quite different between 'F4 and 'F0 (and UART is partially different, too), as there was a relatively major rework of these peripherals exactly between 'F4 and 'F0.

DMA, USB are very different.

'F0 and 'F3 are of the same generation i.e. they share the SPI/I2C/UART design, while having different processors.

JW

[Andrew Neil]

---

@waclawek.jan wrote:

Cube/HAL is said to be a vehicle to move portions of designs seamlessly across the whole STM32 family.

---

Oh yes, I'd forgotten about that - CubeMX is supposed to be able to move a design from one target to another.

Although it might move the initialisation code, it wouldn't help with the user/operation stuff?

 

https://community.st.com/t5/stm32-mcus/mcu1-to-mcu2-migration-option-within-stm32cubeide/ta-p/49650

 

 

[waclawek.jan]

I didn't mean CubeMX, but Cube, the "library" (i.e. CubeF4 vs. CubeF0).

Those are reportedly designed so that all functions (which are not of the "ex" variety) are compatible across every family (that's what "HAL" is supposed to stand for, right?)

And this is touted by ST as the major reason for pushing Cube as the only source of examples.

JW

[waclawek.jan]

> We now want to make a low, low, low cost variant

If you'd omit one "low", maybe a lower-end 'F4 like 'F410 might provide a tradeoff between cost and simpler migration path. But prices are a volatile thing.

JW

[Andrew Neil]

Indeed.

Depending on volume, the cost saving of the simpler migration might outweigh the cost benefit of the F0 part...