STM32F0 for new development

[MMatv]

Dear ST community,

we are planning using stm32f0 as driver for our

X-Y control Unit. with please see the attachment.

• The requirement is to update the application of stm32f0 via SPI.
• And we would like also to use the parts of the HAL library.

Is those two points are possible.

thank you for the support.

best wishes,

Mike

[berendi]

The built-in ROM bootloader doesn't support SPI, so you must develop your own. It's certainly possible, but takes a bit of FLASH and SRAM away from the main application (vector table must be in SRAM).

Using HAL is possible, just not recommended.

• It takes up a lot of memory. Twice, with the bootloader.
• Poorly documented, it's hard to anything with it that's not exactly covered in the examples.
• Too slow and unpredictable for anything that needs strict timing.

The register interface is however extensively documented in the reference manual, with step-by-step instructions in the feature description chapters, and code examples in the appendix.

[MMatv]

Thank you for the reply,

but in that case, it would take much more time than expected.

Is there an alternative uC In the same pricing and periphery range avalibale?

Thank you,

Mike

[berendi]

To be frank, this doesn't make sense to me, unless you already have a functioning SPI loader which is able to talk to the STM32 built-in bootloader.

But in this case, you wouldn't ask whether a particular MCU has an SPI bootloader, but you would already know where to look it up (AN2606).

In addition, consider the additional hardware and software requirements for the built-in bootloader activation. You might find that this approach too could take much more time as expected.

If the loader software for the host has yet to be developed, then being able to debug both sides is an immense help that might actually shorten development time.

Anyway, you can check out the STM32G0 line, same set of peripherals for roughly the same price if you know what you're doing.

[MMatv]

In addition, consider the additional hardware and software requirements for the built-in bootloader activation. You might find that this approach too could take much more time as expected.

Additional hardware means control the NSS pin.

To be frank, this doesn't make sense to me, unless you already have a functioning SPI loader which is able to talk to the STM32 built-in bootloader.

No, we don't have any of this. But with good example it would be much easier.