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] [September 2007 Threads] When will the configKERNEL_INTERRUPT_PRIORITYPosted by Frank Andersen on September 25, 2007 When will the configKERNEL_INTERRUPT_PRIORITY be implemented in the ARM7 ports?
Best regards,
Frank Andersen
RE: When will the configKERNEL_INTERRUPT_PRIORITYPosted by Richard on September 25, 2007 The ARM7 is a pain on this front as the interrupt controller is not part of the core - so there is not one solution for all ARM7 devices. The normal way is to use the FIQ, but I think you have already indicated that this is not an option on your processor.
To implement the configKERNEL_INTERRUPT_PRIORITY feature you need to change the enable/disable interrupt macros to only enable/disable interrupts below the kernel priority. I think this should be straight forward. You can keep the kernel at the lowest priority to make it easier.
Regards.
RE: When will the configKERNEL_INTERRUPT_PRIORITYPosted by Frank Andersen on September 27, 2007 Well, yes I agree that the ARM7 intrrupt controller is a pain.
But if I get my USB bulk interrupt to run outside the FreeRTOS, it will still be delayed a bit by eg. the TimerTick interrupt, as interrupts still not are nested?
And then I would need a Task to monitor a global variable to signal form the interrupt, runing outside of FreeRTOS, right?
Best regards,
Frank Andersen
RE: When will the configKERNEL_INTERRUPT_PRIORITYPosted by Richard on September 27, 2007 If you define the disable interrupt/enter critical section macro to only disable interrupts below a certain priority, and your USB interrupt is above this priority, then the USB will not get delayed by the kernel activity. This is how the ports that use the configKERNEL_INTERRUPT_PRIORITY feature work. For example, on the Cortex-M3 demo I have a 20KHz interrupt running at a higher priority than the 1KHz RTOS tick - and measure the jitter in the timing. The jitter is no greater than can be calculated from the datasheet as the maximum due to the processor itself - a matter of a few instruction cycles.
Regards.
RE: When will the configKERNEL_INTERRUPT_PRIORITYPosted by Frank Andersen on October 1, 2007 Hi Richard,
Well mabye the Cortex-M3 is different from the ARM7 interrupt controller.
If the ARM7 is going to execute a interrupt of a higher priority, while executing another interupt, the mode has to change to system and interrupts to be enabled again. (Nested Interrupts)
But I think it might would help to let the USB bulk run outside the FreeRTOS, by changing the interrupt enable / disable functions.
Best regards, Frank Andersen
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|