cancel
Showing results for 
Search instead for 
Did you mean: 

Can software developed for NUCLEO-F0 run on an F3 or F4 without modification?

BMcKnight
Associate II

Hello,

I came across an old book in a bookstore that has some interesting bare metal C projects for a NUCLEO-F030.  Other than setting the clock speed to 80 MHz and adjusting for some pin variance, will code written for it run on a NUCLEO-F3 or -F4?

Thanks.

1 ACCEPTED SOLUTION

Accepted Solutions
mfgkw
Senior II

While a STM32F030... has an M0 core the STM32F3... and STM32F4... have M4 cores.

There are similarities, but also many differences. So you will not be able to move any code without changes between them.

(Not using LL but HAL would hide many differences though.)

View solution in original post

5 REPLIES 5
mfgkw
Senior II

While a STM32F030... has an M0 core the STM32F3... and STM32F4... have M4 cores.

There are similarities, but also many differences. So you will not be able to move any code without changes between them.

(Not using LL but HAL would hide many differences though.)

Ah... didn't consider that.  Yes, I would be using LL without HAL so there would be differences.  Looks like I'm buying yet another NUCLEO.  :)

 

Thanks. 

 

Andrew Neil
Super User

Essentially the same question here: STM32L476 vs STM32F411 vs STM32F303.

It would be a Porting exercise ...

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

Thanks, Andrew. 

I'm not porting hex code.  At the very least, I have to recompile to include the specific MCU's headers.

My question was if there are any adjustments to using the same source code for an F030 on an F411 to accommodate the differences between the MCU architectures.  For example, clocks are definitely one consideration.  Some of the signal processing projects in the book for the F030 depend on its slower native clock rate.  Running those same clock-dependent functions unmodified on an F411 would likely cause some unpredictable results in timings.

Thinking a little deeper about it gave me an idea for a project, especially since I never really cared much about clock speeds in other system designs.  I ordered a NUCLEO-F030R8 and plan doing some experiments on the effects of running timing-dependent code on a variety of MCUs.  The objective will be to see if running the same code on a faster MCU with the clock dialed back gives the same results as running on a slower MCU at its native speed.  I'm interested to see what differences there are when generating the classic square, triangle and sawtooth waves, and if the waveforms line up exactly or if the faster MCU running at slower speeds introduces distortions in the waveforms.  I suspect there may be distortions in a faster MCU due to extra hardware overhead and cumulative rounding errors when dividing the clock signal to a much slower rate.  I'm also curious to see if "faster running slower" affects interrupt timings in my DIY RTOS.  

I could probably just look up everything I need to know about clocks in the MCUs' RMs and I'm sure that ST engineers and more experienced users probably already know the answers.  My F030 will arrive next week and there's a certain joy that comes from experimenting, so no spoilers, please.  :)

Best regards,

Bruce


@BMcKnight wrote:

I'm not porting hex code. 


No, you would port the source code, and build for the new Target.

 


@BMcKnight wrote:

My question was if there are any adjustments to using the same source code for an F030 on an F411


Yes - especially as it's "bare metal"

As noted in the other thread, there are some ST App Notes covering migrations between some STM32 families.

 

Note that different STM32s aren't just "faster" or "slower" - they may have different CPU Cores, different Flash architectures, etc, etc ...

Whether & how much these impact on "speed" in a particular application will depend on the application; eg, generating a sawtooth waveform would probably be mostly down to the timers rather than the CPU...

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.