Posts: 1049
Joined: Jul. 8, 2004
From: Buenos Aires - Argentina
Status: offline
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 and 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 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.
_____________________________
Agustín Tomás
In theory, there is no difference between theory and practice. In practice, however, there is.
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.
There have been several threads here recently discussing aspects of multi-tasking. One was going on yesterday and may still be going on.
quote:
What would be the ACTUAL "tasks" to implement the above in a multitasking fashion.
I would probably implement the command processor in a task, but everything else looks like it can be handled nicely by combinations of timer interrupts (debouncing) and a plain old event loop. Depending on how your tasking is structured, the main event loop could be just that with the command processor task "called" periodically from the event loop, or it could be a second task that yields each loop or after processing each event. For an example of the former, see my HOS example project at http://www.embedinc.com/pic.
quote:
Is it any "rule of thumb" to know how to break everything in proper "subtasks"?
No more so than how other code is broken into subroutines and modules. Like subroutine and module divisions, this is an important part of bad versus good software engineering.
quote:
I feel that most of the lines above should be broken into smaller pieces and I would like to learn how to recognize them. Could you mention them in detail?
Tasks take resources, so you want to use them only when they really simplify the software. If a task waits for a single event, then handles it quickly, then goes back and does it all again, it can be handled just fine from a main event loop for a lot less overhead. If the task is heavily state driven so that what it does on each event depends on previous history, then a separate task may be more suitable. It could be implemented as a state machine from the event loop, but particularly if there are many states and they are largely sequential, then it's easier to handle it in a task where the PC becomes the state variable. Command processors usually fall into this catagory.
quote:
What is more reasonable for this case, preemptive or cooperative multitasking?
Assuming this is on a PIC and the total set of things the PIC needs to do is well known, then cooperative is almost certainly the way to go. Most of the time multi-tasking isn't needed for a PIC project. When it is, it would be extremely rare indeed if cooperative multi-tasking couldn't solve the same problem with less overhead than preemptive. I've done somewhere between 50 and 100 PIC projects. Out of those maybe a dozen or so had at least one "task" in that there was code that looked like it was an infinite loop, but actually returned execution to the rest of the system thru what looked like a call or macro to the task. Only 3 have been true multi-tasking systems where everything was in a task, and every task called something like TASK_YIELD to let all the other tasks run for a while. And all of those were cooperative. I have yet to run into a PIC project where preemptive multi-tasking would have been a good solution.
quote:
Some books talk about "procedures" and mention the "tasks" as part of them. What is a procedure in this context?
On "big" general purpose computing systems, like PCs, there can be several programs or "procedures" running at the same time. Each of these can have multiple threads of execution. The distinction is that each procedure gets its own address space, whereas threads within a procedure run in the same address space. In other words, there is no way program A can write a word into the memory of program B unless they both cooperate to make this possible. However since all the threads of program A run in the same address space, they can trash each other's data structures at will. This is why these kinds of operating systems have special mechanisms to provide lockouts and synchronization between processes and threads. There are various types. Common names are semiphores, mutexes, and critical sections, although these are not all the same things.
quote:
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?
Preemptive only means that the system can suspend a task and let a different one run whenever it deems this appropriate. The why and when of doing that is what a task scheduler is all about.
quote:
What is an "hostile task"?
One that you have to assume might harm the system in an unacceptable way if given the opprotunity. This is an issue for general purpose computing environments, not for PIC systems which have a dedicated task to perform and are programmed to only perform that task. The most obvious example (although rather dated at this point) is a multi-user time sharing system. If I'm just one of 20 users and just want to get my job done, I'd rather take all the CPU when I need it and freeze out the other 19 dweebs if I could. Of course the other 19 dweebs have the same motivation. The system wouldn't function as a whole if any of the 20 users could take over the system completely for their own use. The operating system therefore is designed to consider the 20 user processes as hostile. This means that no matter what instructions they execute and what OS calls they make, they can't take over the system, write to critical areas of the disk, scribble on each other's memory, etc. Of course this takes a processor with some hardware protection, like excution priviledge levels. General purpose computing processors, like Pentiums, have such hardware. There are various instruction that a process running at user priveledge level just can't execute, and areas of memory it can't access. Parts of the OS run at high priveledge level, but always (where there isn't a security hole) turn down the priveledge level before resuming a user process.
quote:
I have the feeling that trying to write my own kernel would be pretty useless but I found this subject extremely appealing. I know assembly but no C. Any advise?
Not necessarily useless at all. You will learn a great deal by tring to write a multi-tasking kernel. See the other threads here that are already discussing this topic.
ORIGINAL: atferrari 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.
First off, this application does not need an RTOS. Or a dsPIC! It's probably best handled as a simple state machine.
quote:
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 and I would like to learn how to recognize them. Could you mention them in detail?
I'm not sure what you mean by subtasks. I have seen quite a few design techniques that have "processes" (i.e. simple non-blocking code implemented in functions) running in sequence inside a task.
There are several approaches to composing in tasks.
One approach is to group things into a task based on the timing requirements. Example: a simple periodic task runs every 10ms and finishes before it starts for the next period. All the "subtasks" or "processes" that run periodically with this rate can be put into this one task. Any aperiodic/sporadic subtask (i.e. one that needs to do work when some non-periodic event happens) can be put into a periodic task and then poll for the event. For a 10ms period task with a 10ms deadline (i.e. finish before re-start) then a poll can spot anything and act on it with a maximum delay of 20ms (i.e. a missed polling period then a processing period).
The art of design comes in when deciding how many periodic tasks to have, whether to create a new task (e.g. a task with a period of 20ms) or to over-sample by running sub-tasks at 10ms. Or maybe the event takes so much CPU time (e.g. 5ms) that polling is not efficient (you'd have to allow 5ms in any period for the worst-case) so maybe running that subtask as an aperiodic task (connected to an interrupt raised by the event). There are lots of possibilities.
The other approach is to choose the tasks based on the logical functions being designed. So one task (or group of tasks) might run a CODEC (sampling, coding, decoding, outputs). Another task might run a TCP/IP stack. And so on.
In my experience the first approach is the most common, if only because a system is being re-designed from a simple big loop where functions are called in sequence. These functions are then re-mapped to a task that runs at the same rate the big loop did.
If you are wanting to re-use large chunks of software (i.e. a "software component" approach) then the second approach is more useful since it allows the component designer to abstract away from the execution of the other software integrated into the microcontroller. You can see this effect with Microchip's own software library of algorithms (e.g. the soft modem, the TCP/IP stack): take a look at these. Although they don't use an RTOS they do have "run me at 10ms" functions and "call me when" functions. These are classic candidates for being made into tasks. I am sure if the designers knew they were writing for an RTOS then they'd have composed them directly into tasks.
quote:
c- What is more reasonable for this case, preemptive or cooperative multitasking? Why?
As mentioned above, you just need a timed state machine. Preemption is used when a long-deadline piece of computation is needed. Smaller, more urgent operations must take place. They can either wait (but that would be too long) or preempt. It's easy to envisage a system that has long-CPU time, long-deadline needs. For example, a task that checksummed a block of memory. It would take hundreds of milliseconds to finish, so you need to preempt it. Of course, the code could be written to offer a task-switch point by calling a scheduler directly, but that would require you to change the code (and you might not want to do that, for many different reasons).
quote:
d- Some books talk about "procedures" and mention the "tasks" as part of them. What is a procedure in this context?
I think that is the same as subtasks and tasks. Could be wrong. What books did you read?
quote:
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?
Not really. Preemptive just means "stop doing this, do that instead, come back to doing this". An interrupt is a preemption of the CPU. In fact, the dsPIC offers 8 priorities in hardware: the background level (IPL of 0) and then all the preemption to handle the different interrupts.
Time slicing is a form of preemption: it says "give this task a chunk of time and then switch to another task". In a round-robin time slicing system you give all the tasks a chunk of time, often equal. It's not a very good approach for real-time systems since an urgent task is treated no differently to a non-urgent task.
A very common preemptive approach is fixed priority preemptive scheduling. This is where each task is assigned a static priority and the RTOS switches to the highest priority "ready" task. A task is made ready by the RTOS when a timer expires (for example) or when a message arrives for the task (for example). This is a good approach because the most urgent task (the one with the shortest deadline) is given the highest priority: it jumps ahead of all the other tasks and finishes first.
There is a whole branch of maths/computing called scheduling theory that looks at these algorithms. The "optimal" algorithm is called EDF (earliest-deadline first) but that gets hard to implement (you need to keep track of absolute deadlines for each task, and the deadlines are not allowed to "wrap" so you often need to deal with 64-bit integers). Fixed priority scheduling where priorities are assigned by relative deadline (shortest deadline = highest priority) is much easier to implement and is very close to optimal. As I said above, the dsPIC implements this algorithm in its interrupt logic.
quote:
f- What is an "hostile task"?
No idea. One written by Osama bin Laden? :-)
quote:
g- I have the feeling that trying to write my own kernel would be pretty useless but I found this subject extremely appealing. I know assembly but no C. Any advise?
I would get up to speed in C. There's not much point trying to write an RTOS in assembler any more, not with C compilers doing such a good job for CPUs like the dsPIC (although you probably will need to write a few bits and pieces in assembly language).
You should come up to speed in RTOS concepts. First you need to understand what an RTOS looks like and only then how to build one. If you take a look at the OSEK OS specification (an RTOS standard originally for small microcontrollers for the automotive industry) you can get a good idea of what a simple RTOS does. You can download the spec www.osek-vdx.org.
ORIGINAL: Olin Lathrop I have yet to run into a PIC project where preemptive multi-tasking would have been a good solution.
I think it's important to distinguish between "PIC" and "PIC". The dsPIC and PIC24 are the first "big" devices Microchip have produced. They have a lot of on-chip devices, a lot of ROM and run very fast. They are capable of doing a lot of things and running some really big applications. For big applications, where lots of things are going on at the same time (talking on a CAN bus to multiple nodes whilst running a speech recognition module into a noise suppression module into a codec through a TCP/IP stack whilst operating an LCD touch panel whilst logging data to an SD card whilst taking sensor data via ANT whilst joining a ZigBee network whilst storing settings in EEPROM whilst communicating with a diagnostic tester over a LIN bus) an RTOS is a good design choice.
If you never expect it to do more than read a keypad, flash a couple of lights and throw a relay then an RTOS is overkill. But then so is using a dsPIC.
I would get up to speed in C. There's not much point trying to write an RTOS in assembler any more, not with C compilers doing such a good job for CPUs like the dsPIC (although you probably will need to write a few bits and pieces in assembly language).
I heartily disagree. If you are talking about PIC18 or the PIC 14bit cores, carefully written assembly code simply can't be matched by any available C compiler. While you can write optimized C code using ad-hoc techniques and compiler-specific coding styles, the produced code dont even reach close to the size or speed of well-written assembly. This is true for any C compiler that I have seen for the PIC18.
The dsPIC processor has a wonderful instruction set and architecture, and it is really targeted for optimized C compilers. C30 is a very good compiler, and while a good assembly programmer can still beat the compiler in performance, it is much harder to do so, so I agree that for dsPIC it makes a lot of sense to develop in C instead of in assembly. But a resourceful assembler programmer can code critical iterated functions and link the functions into the C program, to address some specific very high-performance problem.
Even for dsPICs, I would consider writing the kernel in assembly.
Even for dsPICs, I would consider writing the kernel in assembly.
Absolutely. I don't want a compiler between me and the hardware when performing unnatural acts on the stack.
This reminds me my old draftman. His schematic looks like a piece of art. His layouts were elegant AND logical. His free hand letters were far better than letter templates. In my opinion, better than machine crafted letters.
He told me his secret. Each paper has unique texture. He could feel it and adjusted the flow of ink. In other words, he had better control and he wanted nothing between his pen and the paper.
Sadly, he was forced into early retirement because clients demand digital schematic. He could not master the simple CAD.
I believe "assembly" is only quarter step behind hand drafting.
Posts: 1049
Joined: Jul. 8, 2004
From: Buenos Aires - Argentina
Status: offline
Hola Ken,
Thanks for your reply.
To your question : What books did you read?, one of them was Real-time Systems Specification, Verification and Analysis Edited by Mathai Joseph - Tata Research Development & Design Centre.
In page 61 you may read A process consists of one or more tasks.
There is at least one more saying the same.
I have to be honest; it's hard for me to grasp all what is said because of the so many new (for me) terms used. Hope I can cope with that sooner or later.
I will keep reading. Gracias again.
_____________________________
Agustín Tomás
In theory, there is no difference between theory and practice. In practice, however, there is.
Absolutely. I don't want a compiler between me and the hardware when performing unnatural acts on the stack
As you remember from our earlier discussions regarding a scheduler I am writing, I do fully agree with you that the heart of the thing is written in assembly. When it comes to explicit manipulation of internal registers, especially the stack pointer the compiler is not the way to go and you need to be in control: assembler!
There is however a lot going on in a scheduler where you really benefit from C, think about all kind of data structures etc which is much harder in assembler. Here I find that I really benefit from the great C30 compiler. This is one great piece of work. When I look at the assembler generated by this compiler it looks very efficient. Probably you can gain some more cycles hand coding in assembler but this would really hurt maintainability and extendibility of the software.
I believe "assembly" is only quarter step behind hand drafting.
That doesn't change the fact that certain things are better done in assembly. Messing with the stack is certainly one of them. And there are occasionally some truly speed-sensitive code sections. Most code is not speed sensitive, but when you do have one of those you want to know every instruction is used wisely. In other cases the number of instructions has to be accurately controlled. There is no way to do this with a compiler.
This particular thread was talking about a task scheduler. That should be done in assembly for two reasons. First, it requires messing with the stack. Second, this is a general low level capability and there is no way to know how speed or latency sensitive the app is. This is something you write once and reuse many times, so you have to assume every cycle is precious.
ORIGINAL: j_doin I heartily disagree. If you are talking about PIC18 or the PIC 14bit cores, carefully written assembly code simply can't be matched by any available C compiler. While you can write optimized C code using ad-hoc techniques and compiler-specific coding styles, the produced code dont even reach close to the size or speed of well-written assembly. This is true for any C compiler that I have seen for the PIC18.
.. which is why I posted this to the dsPIC forum, not the PIC18 one. Yes, the PIC18 C compilers don't (can't) do a good job. But the dsPIC C30 compiler can and does do a good job.
Quite frankly I don't have the time to write screeds of assembly language to beat the C compiler on mundane bits of code. Yes, there are parts of of an RTOS that can't be written in C, and those should be in assembler. There are some time-critical parts that might also justify being in assembly language. But if more than 10% of your code is in assembly language on the dsPIC then something is wrong.
Even for dsPICs, I would consider writing the kernel in assembly.
Absolutely. I don't want a compiler between me and the hardware when performing unnatural acts on the stack.
*I* don't want a compiler between me and the CPU when performing unnatural acts on the stack. It's completely outside the C language to muck with stack pointers within a C function and the consequences are undefined and unpredictable.
Actually, it's entirely predictable: nothing will go wrong in testing but some catastrophic failure will be apparent after 100,000 units have been deployed into the field.
That doesn't change the fact that certain things are better done in assembly. ... so you have to assume every cycle is precious.
I do not disagree with you on this, same as I agreed with my draftman's POV that his layouts were more logical AND elegant than the $10,000 program.
Yet, the cold facts that only him had that special skills, only him had the years of experience, only him could .... and no one could take over.
When the clients sent in changes, he had to be the one to make the changes. A simple diode change required long hours of erasing, re-routing, etc. Even he was the most hardworking in the company, staying behind night after night. He could not catch up. We could not get other to help him because others do not have his skill. He became the bottleneck.
In this fast paced world, I understand fully the need for speed. Assembly, in the hand of skilled, does beat everything else. My question to you and everyone, can you pass the code for other to continue the project and still maintain the speed advantage? How about turnaround?
< Message edited by ytlee123 -- Apr. 9, 2006 8:23:04 AM >
Posts: 2924
Joined: May 25, 2005
From: PA, now MN via NJ,AZ,OR,CA
Status: offline
Put me into the camp of those that believe that RTOSs are an academic experiment only.
I have done dozens of embedded designs ranging from a couple hundred lines of codes to multi-processor, distributed network, co-operative multi tasking with tens of thousands of lines per processor.
My first programs didn't even have an assembler associated with them. I had to type op-codes.
Once I used an RTOS (psos if I remember correctly) and the whole project was a nightmare.
I am certain that there are valid reasons for an RTOS (probably in larger systems with higher-end MCUs), but I will stick with event loops, time-slice and interrupt driven. Is my age showing?
_____________________________
PM personal questions and observations only. Keep technical questions to the forums where everyone can benefit. When it comes to binary, there are 10 kinds of people: those who understand, and those who don't.
This reminds me my old draftman. [...]Sadly, he was forced into early retirement because clients demand digital schematic. [...]I believe "assembly" is only quarter step behind hand drafting.
I use assembly language in a daily basis to code entire projects. My High-level assembly macro library has over 190 macros to deal with structured flow control, handling of typed data types, multibyte fixed point arithmetic, cooperative multitasking, interprocess communication, FIFO handling among other 'high-level' tasks.
The macro library is extensively documented, and maintenance is really easy. We have re-used this library for years.
Assembly language is much more than a bunch of binary opcodes. Your statements above are paradoxical. *My* clients demand technological edge on the competition. They demand performance, features, analog accuracy, and very low cost. I have been able to deliver products packed with functionality at a cost 1/3 of the closest competitors, and the end result was a significant market share gain.
quote:
ORIGINAL: Olin Lathrop
This particular thread was talking about a task scheduler. That should be done in assembly for two reasons. First, it requires messing with the stack. Second, this is a general low level capability and there is no way to know how speed or latency sensitive the app is. This is something you write once and reuse many times, so you have to assume every cycle is precious.
This reflects my thinking about this issue. Writing the scheduler and the system core in highly optimized code will undoubtedly extend the system usability into performance critical applications.
quote:
ORIGINAL: kt0157
quote:
ORIGINAL: j_doin If you are talking about PIC18 or the PIC 14bit cores[...]
.. which is why I posted this to the dsPIC forum, not the PIC18 one. Yes, the PIC18 C compilers don't (can't) do a good job. But the dsPIC C30 compiler can and does do a good job.
Quite frankly I don't have the time to write screeds of assembly language to beat the C compiler on mundane bits of code. Yes, there are parts of of an RTOS that can't be written in C, and those should be in assembler. There are some time-critical parts that might also justify being in assembly language. But if more than 10% of your code is in assembly language on the dsPIC then something is wrong.
I agree with you here. C30 really does a good job, and the Microchip design team deserve a big congratulation for the design of the dsPIC core. It is a superb core, with really good instruction set and low-cost silicon architecture. This core is as attractive to the assembly programmer as it is streamlined for the C compiler.
For speed critical code I would definitely consider assembly functions integrated to the project. Well described algorithms and clearly written assembly code is as maintainable as clearly written C code. For really low-level tasks like a RTOS scheduler and for highly used system functions I would definitely use assembly, for the reasons mentioned by Olin and kt0157 above.
I have not developed end-user applications on the dsPIC as yet, but I am doing internal research work. For high-speed DSP apps, what is much more important than saving performance writing directly in ASM is to make optimum use of the chip resources. A tightly optimized fixed-point math library might extend the application spectrum of dsPIC to higher performance tasks. My first target in dsPIC and PIC24 will be building a equivalent fixed point library to the existing FP libs.
For the new 16bit core chips, a good RTOS really makes sense. Applications that integrate audio, networking, complex user interfaces will benefit from a powerful multitasking kernel. Whether a fully preemptive RTOS is a requirement or not, this very much depends on the development strategy, but certainly a preemptive kernel will make easier to integrate monolithic pieces of code, like communication protocol stacks and complete signal processing paths into applications with low code rewriting need. Although larger and potentially slower, well-written preemptive RTOSes will make a difference in those applications.
Nevertheless, simpler and faster cooperative multitasking systems will still play a important role even in dsPIC and PIC24 applications. For well defined embedded control apps, it still makes sense to use tight cooperative tasking.
< Message edited by j_doin -- Apr. 9, 2006 9:59:54 AM >
Have you heard "Spontaneous Assembly"? Tightest code and best documented and well ahead its time. It is on my top shelf. It reminds me everyday that the best is not the best if it is on the path of the wheel of progress.
quote:
I have been able to deliver ..... a significant ,,,.
Posts: 2924
Joined: May 25, 2005
From: PA, now MN via NJ,AZ,OR,CA
Status: offline
quote:
ytkee123: How about your team? Take a look at the last sentence of this article.
Aside from the fact that you are linking to a political site...
My team consists of about 10 people and I am the only one writing embedded software for the end product.
We have a number of PIC projects for internal usage and I wrote the code for those as well.
I am also writing the PC-based applications for customer and technician use. There is one other person writing SPC and database software for internal use, and I assist with that.
I am also writing process control software for PLC's and PC-controlled motion systems.
I would guess that my situation is more common that having a team working on a single PIC. Perhaps a team working on a PIC each...
PM personal questions and observations only. Keep technical questions to the forums where everyone can benefit. When it comes to binary, there are 10 kinds of people: those who understand, and those who don't.
Printable Version
All Forums >> [16 bit Microcontrollers & Digital Signal controllers] >> dsPIC30F Topics >> RTOS & multitasking 
RTOS & multitasking - 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread