Which Cortex-M3 interrupts can I use for general purpose work?

Question

I\'d have some code that needs to be run as the result of a particular interrupt going off.

I don\'t want to execute it in the context of the interrupt itself but I

Answer 1

Are you using an RTOS? Generally this type of thing would be handled by having a high priority thread that gets signaled to do some work by the interrupt.

If you're not using an RTOS, you only have a few tasks, and the work being kicked off by the interrupt isn't too resource intensive, it might be simplest having your high priority work done in the context of the interrupt handler. If those conditions don't hold, then implementing what you're talking about would be the start of a basic multitasking OS itself. That can be an interesting project in its own right, but if you're looking to just get work done, you might want to consider a simple RTOS.

Since you mentioned some specifics about the work you're doing, here's an overview of how I've handled a similar problem in the past:

For handling received data over a UART one method that I've used when dealing with a simpler system that doesn't have full support for tasking (ie., the tasks are round-robined i na simple while loop) is to have a shared queue for data that's received from the UART. When a UART interrupt fires, the data is read from the UART's RDR (Receive Data Register) and placed in the queue. The trick to deal with this in such a way that the queue pointers aren't corrupted is to carefully make the queue pointers volatile, and make certain that only the interrupt handler modifies the tail pointer and that only the 'foreground' task that's reading data off the queue modified the head pointer. A high-level overview:

• producer (the UART interrupt handler):

  1. read queue.head and queue.tail into locals;
  2. increment the local tail pointer (not the actual queue.tail pointer). Wrap it to the start of the queue buffer if you've incremented past the end of the queue's buffer.
  3. compare local.tail and local.head - if they're equal, the queue is full, and you'll have to do whatever error handing is appropriate.
  4. otherwise you can write the new data to where local.tail points
  5. only now can you set queue.tail == local.tail
  6. return from the interrupt (or handle other UART related tasks, if appropriate, like reading from a transmit queue)

• consumer (the foreground 'task')

  1. read queue.head and queue.tail into locals;
  2. if local.head == local.tail the queue is empty; return to let the next task do some work
  3. read the byte pointed to by local.head
  4. increment local.head and wrap it if necessary;
  5. set queue.head = local.head
  6. goto step 1

Make sure that queue.head and queue.tail are volatile (or write these bits in assembly) to make sure there are no sequencing issues.

Now just make sure that your UART received data queue is large enough that it'll hold all the bytes that could be received before the foreground task gets a chance to run. The foreground task needs to pull the data off the queue into it's own buffers to build up the messages to give to the 'message processor' task.