I've been reading about RTOS and multitasking with 18F PIC micros or eventually DSPICs in mind. While I managed to understand somehow the basics I have lot of doubts.

A scenario: there is a micro continuously polling a keypad and three inputs normally high. Once one of them is found low, and after a certain delay the alarm is started: a flashing LED plus an auxiliary contact closed.

Asynchronously to the above the micro should check a serial connection, to receive a request for data and send it if certain conditions are met.

I guess a reasonable sequence could be:

Check the input.
If input is low, start debouncing.
Check input again.
If input is low, start delay.
If input still low, start the alarm.
Repeat the check for the other two channels.
Check the kepad in case the user decides to stop the flashing and open the contact.
Check the RS232 input to see if valid commands are received.
In case a valid command is received, send the information requested.
Mantain the LEDs flashing as long they are not turned off by the user.

My questions:

a- What would be the ACTUAL "tasks" to implement the above in a multitasking fashion.

b- Is it any "rule of thumb" to know how to break everything in proper "subtasks"? I feel that most of the lines above should be broken into smaller pieces. I would like to learn how to recognize them. Could you mention them in detail?

c- What is more reasonable for this case, preemptive or cooperative multitasking? Why?

d- Some books talk about "procedures" and mention the "tasks" as part of them. What is a procedure in this context?

e- Preemptive means that all tasks are given the same period to run? Or could be that different tasks get different lengths of time to run? Not doing this means that the longest one imposes the minimum for the time slice used, right?

f- What is an "hostile task"?

g- I have the feeling that trying to write my own kernel even if VERY elementary would be pretty useless but I found this subject extremely appealing. I know assembly but no C. Any advise?

Sorry for the long posting.

Replies will be appreciated. Really.

 

Originally posted by atferrari@Apr 4 2006, 12:18 AM
I've been reading about RTOS and multitasking with 18F PIC micros or eventually DSPICs in mind. While I managed to understand somehow the basics I have lot of doubts.

A scenario: there is a micro continuously polling a keypad and three inputs normally high. Once one of them is found low, and after a certain delay the alarm is started: a flashing LED plus an auxiliary contact closed.

Asynchronously to the above the micro should check a serial connection, to receive a request for data and send it if certain conditions are met.

I guess a reasonable sequence could be:

Check the input.
If input is low, start debouncing.
Check input again.
If input is low, start delay.
If input still low, start the alarm.
Repeat the check for the other two channels.
Check the kepad in case the user decides to stop the flashing and open the contact.
Check the RS232 input to see if valid commands are received.
In case a valid command is received, send the information requested.
Mantain the LEDs flashing as long they are not turned off by the user.

My questions:

a- What would be the ACTUAL "tasks" to implement the above in a multitasking fashion.

b- Is it any "rule of thumb" to know how to break everything in proper "subtasks"? I feel that most of the lines above should be broken into smaller pieces. I would like to learn how to recognize them. Could you mention them in detail?

c- What is more reasonable for this case, preemptive or cooperative multitasking? Why?

d- Some books talk about "procedures" and mention the "tasks" as part of them. What is a procedure in this context?

e- Preemptive means that all tasks are given the same period to run? Or could be that different tasks get different lengths of time to run? Not doing this means that the longest one imposes the minimum for the time slice used, right?

f- What is an "hostile task"?

g- I have the feeling that trying to write my own kernel even if VERY elementary would be pretty useless but I found this subject extremely appealing. I know assembly but no C. Any advise?

Sorry for the long posting.

Replies will be appreciated. Really.

[post=15789]Quoted post[/post]​

I'll give this a shot.
a - Not every processor out there will support an RTOS. There is considerable overhead to the implementation so that the amount of work that is perfomed in a "single" task needs to justify the expense of doing the task switch. For the types of simple I/O that you have described the RTOS overhead would absolutely kill your performance, and offer little if any benefit.

b - There are no rules of thumb with universal applicability. It might be helpful to think in terms of resources. What is a resource? The CPU, the memory, a peripheral device. You start by having tasks that manage and coordinate access to resources. That is not the whole story but it is a good place to start.

c - In the case of simple embedded applications the cooperative model has much to recommend it. In the preemptive mode there is a timer running whose main job is to switch tasks. This process needs to save and restore the machine context so that processing can resume wherever it was last suspended. Limited RAM and a fixed length hardware stack make this process extremely challenging.

d - Generally speaking a procedure is equivalent to a function or a subroutine. Well formed procedures have arguments, can allocate local storage on a stack, and return results. They generally have a SINGLE entry point, and most of the time they have a single exit point. A task on the other hand may consist of multiple procedures. A task also has some "state" variables associated with it describing various conditions such as "running", "suspended", or "waiting for an event". This state information does not show up explicitly in the procedures that make up the task, but is maintained by the RTOS.

e - Your definition of preemptive is inaccurate. It just means that you have some amount of time to run before someone else gets a chance. The amount of time is usually expressed as some interger multiple of a basic time unit. Some tasks may get three time units, while some other task may get nine units. The amount of time that a task receives is not necessarily constant. The amount it gets may change over time depending on what the task is doing. These sorts of "policy" decisions account for a large amount of the complexity of real systems. Clearly the shorter the basic time unit the more frequent the timer interrupts which means more overhead. If the basic time unit is too large then it is difficult to make fine adjustments to the amount of time that is assigned to individual tasks.

f - A "hostile" task is one that consumes resources and refuses to release them so that other tasks may use them. One good way to do this is to disable interrupts when your task gains control of the CPU. Unless there is a nonmaskable interrupt the RTOS may have trouble enforcing its will. On some processors there are modes where certain instructions like enable and disable interrupts are forbidden for exactly this reason

g - If you have a hobby project that fits the mold and you choose a processor that will support an RTOS, by all means give it a go. You could also get a copy of uCOS by Jean Lebrosse. Its written in C and would be a good way to learn the language. In a comercial environment I would buy a kernal for the processor I was using and spend my time on the application.

Note:
This is by no means an exhaustive list, but to be a candidate for an RTOS a processor should have a stack for return addresses and data. The stack pointer needs to be the same width as the program counter. The best processor choices will allow for a very fast context switch. I'm afraid most PIC's just can't meet this criteria. There also needs to be sufficient RAM memory. I think that 4K would be a bare minimum although you might get by with less. This lets out most 8051 and 6805 type processors. The AVR is probably doable but it is such a code HOG!

The Z80 type processors, the x186 processors, and maybe one of the embedded ARM processors are all good candidates for implementing an RTOS.

Hope this answers your questions

 

Hola PB,

Thanks for replying!

Let's say I have many things to consider indeed.

For the moment I don't know how to start...if one day I finally decide to do ti in assembly.

Gracias again.

 

Originally posted by atferrari@Apr 4 2006, 06:24 PM
Hola PB,

Thanks for replying!

Let's say I have many things to consider indeed.

For the moment I don't know how to start...if one day I finally decide to do ti in assembly.

Gracias again.

[post=15811]Quoted post[/post]​

de nada