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] [March 2015 Threads] CCS - source/portable/CCS/ARM_Cortex-R4 port.c questionPosted by westmorelandeng on March 22, 2015 Hello,
I have a question of the significance of a #if vs. #ifdef in *pxPortInitialiseStack() in port.c -
The first statement with TIVFPSUPPORT has an #if - the second has an #ifdef - is this done on purpose to get a certain behavior out of the preprocessor or is that just a typo?
For instance, if I did #define TIVFPSUPPORT 0
then that may end up with a behavior I don't want; or is that done on purpose?
I searched the project and I don't find any #define TIVFPSUPPORT anywhere and I haven't located anything (yet) in the project settings.
Thanks,
John W.
CCS - source/portable/CCS/ARM_Cortex-R4 port.c questionPosted by rtel on March 22, 2015 Both are wrong according to the coding standard really - only #if( test
== condition ) should be used. Other than that there is no real
significance in the two you highlight. I think
portPRELOADTASKREGISTERS is not a constant provided to the user, and
is just their to assist development, so it is not necessarily defined
anywhere, hence it uses a #ifdef.
You are better off copying the Cortex-A port rather than that port though.
Regards.
CCS - source/portable/CCS/ARM_Cortex-R4 port.c questionPosted by westmorelandeng on March 22, 2015 For the Cortex R4F? I will take look at the Cortex-A port.
Thanks,
John
CCS - source/portable/CCS/ARM_Cortex-R4 port.c questionPosted by rtel on March 22, 2015 Yes - the new Cortex-R port (not yet published) is basically the same as
the A port.
Regards.
CCS - source/portable/CCS/ARM_Cortex-R4 port.c questionPosted by westmorelandeng on March 23, 2015 Hmmm, do you mind telling me specifically under which tool set?
The Atmel Cortex-A5 IAR port looks close.
Also - What kindof shape is the code in HALCoGEN? I tried to put a couple of ports together with that with limited success.
Thanks,
John
CCS - source/portable/CCS/ARM_Cortex-R4 port.c questionPosted by rtel on March 23, 2015 Does your R4 device use a standard ARM GIC (Generic Interrupt
Controller)? If so then look at a Cortex-A9 port (there is one for GCC,
IAR and ARM compilers if I recall correctly). If your R4 device does
not use a GIC then look at the Atmel Cortex-A5 port as that is more
generic (uses callbacks into the application for interrupt controller
handling, rather than assuming a GIC is available).
Regards.
CCS - source/portable/CCS/ARM_Cortex-R4 port.c questionPosted by westmorelandeng on March 23, 2015 It's an R4F using a VIC - Vectored Interrupt Controller.
The port I have is 'working' as long as the tasks are all the same priority (IDLE task is starving) and I don't have the FPU working correctly yet with the flop test/task.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|