FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [April 2017 Threads] FreeRTOS Port for NXP Kinetis with MPU extensionPosted by marcbe on April 10, 2017 I am trying to get FreeRTOS with MPU support to run on NXP Kinetis MK66F.
Unfortunately I found out the MPU delivered with K66 isn't the one provided by ARM. Instead it's an implementation from Freescale/NXP which isn't supported yet by FreeRTOS, is it?
FreeRTOS comes with a port for Cortex-M4F with MPU but this one doesn't work on K66.
Is there a port for Kinetis Series with MPU Support available? If not, how can it be ported? Freescale provides peripheral drivers for MPU - could these be used for porting FreeRTOS?
Thanks
FreeRTOS Port for NXP Kinetis with MPU extensionPosted by rtel on April 10, 2017 It is possible that NXP have an example, but I don't know. We only
provide examples for the ARM MPU.
How different is the NXP MPU? The ARM one is not very flexible, which
makes it hard to use in a system that only has a small amount of RAM.
It might be the NXP one gives you more flexibility.
FreeRTOS Port for NXP Kinetis with MPU extensionPosted by marcbe on April 12, 2017 Yes the NXP MPU indeed is more flexible. It allows up to 12 regions to be declared on 32 byte boundaries with rwx attributes for supervisor and user mode.
Furthermore the NXP MPU allows to include a process identifier for in access permission evaluation.
How can I modify the task creation / scheduler in a way which allows Definition of a process identifier (PID) per task (e.g. when using xTaskCreateRestricte) and setting this PID with each context switch?
FreeRTOS Port for NXP Kinetis with MPU extensionPosted by rtel on April 12, 2017
How can I modify the task creation / scheduler in a way which allows
Definition of a process identifier (PID) per task
Do you just want a unique identifier per task? The task's handle is
unique to the task. If that is not appropriate then perhaps you could
use thread local storage?
http://www.freertos.org/thread-local-storage-pointers.html
FreeRTOS Port for NXP Kinetis with MPU extensionPosted by marcbe on April 13, 2017
Do you just want a unique identifier per task? The task's handle is
unique to the task.
Can I explicitly set the task handle to a defined value? I would like to use predefined PIDs for each task. The task itself doesn't need to know its PID but the scheduler does.
Where exactly is the context switch performed? I need a function which will be called each time a task is set to running, which is running in supervisor mode and knows the PID of the next task.
FreeRTOS Port for NXP Kinetis with MPU extensionPosted by rtel on April 13, 2017 Context switches are only ever performed in the PendSV handler.
If you want a user function to execute then you have a couple of options:
1) You could use a task hook
http://www.freertos.org/xTaskCallApplicationTaskHook.html
2) You could define either the traceTASKSWITCHEDIN or
traceTASKSWITCHEDOUT trace macros - in the first case pxCurrentTCB
will point to the task that executed previously, and in the second
pxCurrentTCB will point to the task that is going to execute next (which
could be the same task). http://www.freertos.org/rtos-trace-macros.html
FreeRTOS Port for NXP Kinetis with MPU extensionPosted by marcbe on April 18, 2017
You could define either the traceTASKSWITCHEDIN
I will use the traceTASKSWITCHEDIN macro together with the task tag.
I assume the macro runs in privileged mode?
in the first case pxCurrentTCB
will point to the task that executed previously, and in the second
pxCurrentTCB will point to the task that is going to execute next
Isn't it vice-versa? In case of the traceTASKSWITCHEDIN the pxCurrentTCB will point to the task about to enter the Running state.
FreeRTOS Port for NXP Kinetis with MPU extensionPosted by rtel on April 18, 2017
I assume the macro runs in privileged mode?
Yes, correct.
Isn't it vice-versa? In case of the traceTASKSWITCHEDIN the
pxCurrentTCB will point to the task about to enter the Running state.
Also correct.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|