Is there an example that shows an interrupt event striggering a background task?

[davepfaltzgraff]

I am building a project that uses the KSDK with MQX on a FRDM-K22F platform. In this project there is an external interrupt that is to trigger a background task

I was wondering if there is an example that might show this specific arrangement.

I've looked at the example in C:\Freescale\KSDK_1.2.0\rtos\mqx\mqx\examples\demo where Event A task uses an event flag to trigger the Event B task. This is fairly clear in that Event A just uses the MQX service time to kick it off. In my case, I need to be able to have the event flag be "visible" to the hardware interrupt routine.

Thanks for the pointers.

[danielchen]

Hi David:

Please check the following demo

C:\Freescale\KSDK_1.2.0\rtos\mqx\mqx\examples\event

The event example code shows how a task waits for a event. This event can be set by any other process or interrupt in the system. The example simulates an IAR event using another simple task

Regards

Daniel

[davepfaltzgraff · Accepted solution]

Hi Daniel,

If you read my third paragraph, you'll see that's where I started. The problem with this as an example is that the variable Event1_handle in the EventA code is defined locally and thus is not available anywhere else. In the case of an interrupt service routine, you do not want to be making a connection to the event every time there's an interrupt.

I worked at this and came up with the attached code which is based on the Freescale MMA8453 accelerometer. I have placed all of the I2C code in a separate module, but this module shows the essence of what I wanted. The Motion_Handler() routine is a task that's kicked off in the main code. This calls a routine that initializes the MMA8453 into the state that I need - namely interrupt when motion over a certain amount is detected. This calls MotionInit() which sets up the event queue. Note that Motion_Handle is defined globally. This makes it accessible to the interrupt routine. After that's set up, then the Motion_Handler connects to the event with it's own handle and just waits. Since this handle is defined locally, this allows the Motion_Handler() routine itself to be moved to another module if necessary.

The interrupt routine at the top, PORTB_IRQ_Handler(), acknowledges the interrupt and then queues up the event. Note that the main-line program turns on/off the interrupt enable for this as required by the application.

The key point to the application is that Motion_Handle, which is set up by MotionInit() and used by PORTB_IRQ_Handler() must be defined so that both have access to this variable. Note: For better coding, it should be declared static to this module.