From multiprocessing to multitasking ?

[i.A7med]

Hello,
I have a project on an ALTERA FPGA that includes two softcore NIOS II processors, the first processor runs an image processing algorithm that produces and output each 2 seconds (hope to improve it) and sends this output to another processor . This second processor controls a USB chip and finally sends the output to PC using USB.

The first process is straightforward but the second process is interrupt driven and an interrupt should happen and handled each 8 ms , so what I want to do is using only 1 processor and multitasking between those 2 tasks using uc/os-II but I am beginner to RTOS and I want to know if there will be a problem if one of the 2 tasks is highly interrupt driven .Is my idea possible ? Will this task interrupt latency be affected badly by the context switching ? How should I begin ?

 

[willis...]

Hello,
I have a project on an ALTERA FPGA that includes two softcore NIOS II processors, the first processor runs an image processing algorithm that produces and output each 2 seconds (hope to improve it) and sends this output to another processor . This second processor controls a USB chip and finally sends the output to PC using USB.

The first process is straightforward but the second process is interrupt driven and an interrupt should happen and handled each 8 ms , so what I want to do is using only 1 processor and multitasking between those 2 tasks using uc/os-II but I am beginner to RTOS and I want to know if there will be a problem if one of the 2 tasks is highly interrupt driven .Is my idea possible ? Will this task interrupt latency be affected badly by the context switching ? How should I begin ?

Yes it should be possible; while interrupts are a crucial part of every embedded system, interrupts and RTOS(s) are at war with each other, so to speak; an RTOS wants to maintain complete control over the system, allowign it to execute preemptively and deterministically. Interrupts, however, need to be serviced at a high priority as soon as they occur, taking "control" away from the os. While what you want to do is certainly possible, there might be a better option. If you create two tasks, you could make the USB task highest priority and the other task (I'm guessing processing the data or something?) lower priority. If you make the USB task pend on a queue, then it will be idle until there is data for it to send via USB. Since it is higher priority, this task will run as soon as there is data in the queue; once the data is sent, the task yields and the 2nd task can execute. This method might be more RTOS friendly, but it will still ensure that your "interrupt-driven" task gets executed promptly withou the need for actual interrupts.

-Willis