rtel wrote on Friday, September 16, 2005:
The scheduler locking mechanism within the FreeRTOS kernel implementation along with the small code size means interrupts are disabled less often than with comparable RTOS implementations. However some overhead is unavoidable. Here are some notes:
+ Dont have the tick frequency any faster than necessary. See configTICK_RATE_HZ within FreeRTOSConfig.h.
+ Use the queue/semaphore mechanisms within ISRs sparingly, only where really necessary. The serial port demo drivers make heavy use of these functions primarily to test their functionality. A faster ISR can be created by using the ISR to place received data within a simple circular buffer, then simply waking the task that is to process the characters.
+ Dont make a queue or semaphore function call on every received byte. Instead make the call at the end of the frame, or at the end of the ISR if multiple bytes are received within a single ISR.
+ Use of the kernel means the ISR can be kept really short, just buffer the data and clear the interrupt. Let a task do any further processing required.
+ Stating the obvious, how your application uses interrupts will make a difference. Dont have lots of code within ENTER/EXIT_CRITICAL sections. If you dont want the scheduler to run while you access something use scheduler suspends and resumes instead. This way interrupts remain enabled.
I have had interrupt driven serial comms, USB comms and Ethernet comms running simultaneously with no problem but have not tried the CAN. However, should it become necessary you could implement some interrupt nesting although this is a bit more tricky on ARM.
How fast are you running the processor? What baud rate are you using? Does the LPC interrupt on every frame, or every byte?
Regards.