[freertos - Open Discussion and Support] CORTEX M4 vs CORTEX M3

Visto 13 veces
Saltar al primer mensaje no leído

SourceForge.net

no leída,
11 may 2011, 6:33:4811/5/11
a nor...@sourceforge.net

Read and respond to this message at:
https://sourceforge.net/projects/freertos/forums/forum/382005/topic/4525844
By: under003

Hello,

I have been studying the Architectures of Cortex M3 and the Cortex M4, ARM V7-M
and ARM V7-EM and I haven´t found lots of differences. I have to do something
for the university, and my question is if I can use the FreeRTOS DEMO for Cortex
M3, with a Cortex M4, because I want to have the Free RTOS in my Cortex M4.
Thank you very much.

regards

_____________________________________________________________________________________
You are receiving this email because you elected to monitor this topic or entire forum.
To stop monitoring this topic visit:
https://sourceforge.net/projects/freertos/forums/forum/382005/topic/4525844/unmonitor
To stop monitoring this forum visit:
https://sourceforge.net/projects/freertos/forums/forum/382005/unmonitor

SourceForge.net

no leída,
11 may 2011, 16:49:2211/5/11
a nor...@sourceforge.net
By: richardbarry

As far as the kernel is concerned, if there is no FPU (Floating Point Unit)
on the M4, then they are the same and the FreeRTOS M3 port runs fine on the
M4 too. If there is an FPU, then the M3 port cannot be used if the MPU is used.

Regards.

SourceForge.net

no leída,
6 oct 2011, 9:01:346/10/11
a SourceForge.net
By: koalakoker

Hello
I have tried to run Free RTOS on a M4 + FPU microcontroller and I get a hardfault
error inside PendSV_Handler.
I have tried also to disable the compiler option in IAR (FPU none) with the
same result.
It is plan to extend the support of the free RTOS to M4+FPU architecture?

SourceForge.net

no leída,
6 oct 2011, 9:39:116/10/11
a SourceForge.net
By: richardbarry

[quote]It is plan to extend the support of the free RTOS to M4+FPU
architecture?[/quote]

Definitely. An efficient implementation is not as simple as you might think
though.

[quote]I have tried also to disable the compiler option in IAR (FPU none) with
the same result.[/quote]

If you are sure that the compiler is not outputting any floating point instructions,
and you are sure you have not accidentally turned the floating point unit on,
then it is very likely your problem is not connected to the device being an
M4F, as the M3 code does not itself use any floating point instructions and
should (does) run on M4F silicon (without the FPU being used).

Regards.

SourceForge.net

no leída,
14 nov 2011, 5:05:0514/11/11
a SourceForge.net
By: petersmith27

I have just started to look at ARM CM4+MPU+FPU and was wondering when a port
of FreeRTOS might be available?

Also can some one clear up why you can't enable the FPU if you are using the
MPU on a CM4 please?

SourceForge.net

no leída,
14 nov 2011, 5:46:5614/11/11
a SourceForge.net
By: richardbarry

The Cortex-M4F can be configured to use the FPU in several ways.

0) Turn the FPU off. Then you can use the M3 port.

1) Turn the FPU on, but set the hardware not to save its context.

This is fine if only one task uses the FPU, and no interrupts use the FPU.
It is also fine if you want to save the FPU context manually for just those
tasks that have registered as FPU users. It breaks when interrupts start using
the FPU too, and is inefficient whatever as most of the time the FPU context
is being saved and restored unnecessarily.

1) Set the processor to save the entire FPU context on every interrupt.

This is a really easy way of using it. You would require some changes to the
port layer to setup the initial stack to have an FPU context, but that is not
difficult. However, it is [b]*massively*[/b] inefficient and [b]*horrendous*[/b]
in run time and RAM usage, especially when you consider that very few tasks
will actually use the FPU, and when interrupts start nesting and each has its
own FPU context.

2) Set the processor to use the lazy save mechanism so space is allocated to
the stack for the FPU context, but a context save is only triggered if an FPU
instruction is actually executed.

This is a clever and brilliant mechanism for efficient FPU usage, with interrupts,
in a [b]*single threaded*[/b] environment. Think through the consequences in
a mult-threaded environment, with nested interrupts that also use FPU instructions,
and you will soon see this is [b]*massively*[/b] complex, with lots of corner
cases, and near impossible to test, and almost unworkable with any sort of reasonable
code base, size, run time limits, etc..

Then take into account that you need to inspect the output of your compiler
extremely carefully, as some versions will output FPU instructions in the prologue
and epilogue of function calls, even when the task makes no use of the FPU at
all.

There is a plan to support M4F however, it is just a matter of finding
the time.

Regards.

SourceForge.net

no leída,
14 nov 2011, 6:03:4814/11/11
a SourceForge.net
By: petersmith27

Thanks for the comprehensive answer....

Responder a todos
Responder al autor
Reenviar
0 mensajes nuevos