junambi wrote on Tuesday, September 25, 2018:
Hi,
Would like to port FreeRTOS from one controller to another. Both of them are Cortex R5 based controllers.
We have tried with the Demo project from Xilinx, are there any specific things that have to be taken care of during the porting.
Please comment.
Thank you,
Nambi
rtel wrote on Tuesday, September 25, 2018:
There are two things to take care of when porting to a Cortex-R or Cortex-A - porting to the processor core and porting to the interrupt controller. If your device uses an ARM GIC (generic interrupt controller) then chose a port that also uses a GIC as a base for your new port - then you might just have to change the base address of the GIC registers for it to work. If your device has a propriatory interrupt controller then you will need to do a little more work. The following pages document the differences for the Cortex-A, but the same holds for the Cortex-R:
https://www.freertos.org/Using-FreeRTOS-on-Cortex-A-Embedded-Processors.html
https://www.freertos.org/Using-FreeRTOS-on-Cortex-A-proprietary-interrupt-controller.html
junambi wrote on Wednesday, September 26, 2018:
Thank you Richard for the same,
WIll try these and get back to you if i have more issues.
Regards,
junambi wrote on Monday, October 01, 2018:
Hi Richard,
I have been able to port the required files to the processor that i want to use (Cortex R5). Now when i create a set of timer tasks and then call the scheduler, it does not execute any of the timers callback functions, just keeps going at the start scheduler task. Can you please let me know what i could be missing for this to happen.
Please let me know if you require more information.
Thank you,
Regards
rtel wrote on Saturday, October 20, 2018:
Does the first task start? You can test that by creating one task at
the highest priority (configMAX_PRIORITIES - 1), ensuring
configUSE_TIMERS is set to 0 (so the timer task is not the highest
priority task - you can set it back to 1 afterward), and putting a break
point at the start of the task.
Also, does the processor you use have a standard ARM GIC (generic
interrupt controller) or a device specific interrupt controller?
junambi wrote on Thursday, November 01, 2018:
Richard,
I have switched of the timers, have only one task and have tried to start this.
Yes, there is a GIC in the controller that i am using.
I see that, once i start the FreeRTOS Scheduler, my PC goes to some Reset location and then never returns.
Any thoughts on why this is happening, please.
Thank you
junambi wrote on Thursday, November 01, 2018:
Richard,
I did some more debug and see that my runs break at
xNextWakeTime = xTaskGetTickCount();
configTICK_RATE_HZ = 1000
This statement, i have disabled the timers, for now.
Please comment
Thank you,
Regards,
junambi wrote on Friday, November 02, 2018:
Richard,
I did some more debug and see that the following code
vTaskDelayUntil( &xNextWakeTime, xPeriod );
Is where the system breaks. If i step through the code, things work fine, but, if i let it run, the above line is where my code crashes and the program goes to the HW watch dog.
Please let me know if you require more information.
Please comment.
Thank you,
rtel wrote on Sunday, December 09, 2018:
I’m afraid all I can suggest is that you step through the code in the
debugger to see exactly what happens when the crash (if that is what it
is) occurs - I can only make guesses from here (for example, could be
the processor is in the wrong mode when you try a context switch, could
be that the context switch handler is not installed, etc.).
ldb wrote on Monday, December 10, 2018:
You comment with the debugger makes me suspicious because I ran into trouble with this call
vTaskDelayUntil() is rather funny (I dislike the function immensely) it returns immediately if your xNextWakeTime has already elapsed it does not wait xPeriod. It is listed in the API documentation
It should be noted that vTaskDelayUntil() will return immediately (without blocking) if it is used to specify a wake time that is already in the past.
Does your code properly allow for that behaviour?
Where I came unstuck was I set the value a long way before I used the function and a tick occured and the function would immediately exit. I remade my own procedure because I found the whole function clunky.
rtel wrote on Monday, December 10, 2018:
What would you prefer the behaviour to be if you specify a wake time
that is in the past?
ldb wrote on Tuesday, December 11, 2018:
I guess what the problem is more the concept of absolute time in a task switching enviroment.
You can easily get a series of high priority pre-empts that suddenly makes your time past.
I conceed in the simplest examples and if your tasks don’t stall it will work correctly.
Peripheral delays which may require long timeouts etc in real world complex examples however make it easy to end up in past time.
What I changed the function was what is often required more required in a complex system a minimum to maximum delay. Calling with a time past invokes the minimum delay (0 allows the current behaviour as is) and your maximum delay being the timeout as now.
The call may then be used in situations where hardware etc requires a minimum delay regardless of how past the time is. So you can more tailor the behaviour to what is required.
So I guess the addition of the extra variable gives me the ability to run the function as is or in the new minimum delay mode.
richarddamon wrote on Tuesday, December 11, 2018:
The choice between using vTaskDelay and vTaskDelayUntil is that the first is designed to delay for a certain time period from NOW, while the second is designed to delay for a certain time period from the point when the last vTaskDelayUntil call ended, so as to attempt to maintain (at least on a semi-long term) a constant rate of operations.
If you make a delay of 10 ms, then both will nominally give you 100 cycles per second. Using vTaskDelay, if the system gets busy, the rate may drop, but you will always have about 10ms (at least within 1 tick worth) between delays, If you use vTaskDelayUntil, then if the system gets busy and you fall behind, the loop will do catch cycles with no delay to try and catch up,
Which behavior is ‘right’ is very much application dependant. If you are looking for an actually minimum delay at the moment, then vTaskDelay is what you want, not vTaskDelayUntil. The main use of vTaskDelayUntil is for ‘Timekeeping’ operations.
In fact, I may have a big loop with a vTaskDelayUntil as a gatekeeper for overal rate, but also have in the loop vTaskDelays when in the processing of the big loop, I need shorted delays.