nobody wrote on Wednesday, December 06, 2006:
I modeled an ISR handler on the serial.c example (for the dual UARTs on
the Atmel AT91SAM7X256).
I have 2 tasks in my system - one which talks on the Ethernet (lwIP), the
other for an RS-232 console user. This, and the several ISRs (timer,
uarts, etc.) The Ethernet task is essentially idle as the cable is
unplugged.
When I write a long message to the console, I need to have a queue at
least as large as the largest screen paint I do (> 2K) in order for it to
work. If I don’t, the task waits forever for the queue to clear, but the
queue doesn’t clear even though the interrupt is enabled if I use a
non-zero timeout in the xQueueSend call. The application was ported from
a PIC18 (no OS) and I had no trouble putting out messages larger than the
buffer size.
I found the same problem early on with serial.c, not realizing it was
something inherent rather than a mistake in my code.
I’m wondering - is there something I’m missing here? It seems that it
would be a most basic function to allow other tasks (especially
interrupts) to run while another is blocked for a resource. We’re not
talking about priority inversion, just having interrupts operate while a
task is blocked.