Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.
Hmm, I would have said you can do some multi-tasking with a PIC, although its architecture probably isn't ideal for it. I see that is also the opinion in reply to your question elsewhere.
forum.allaboutcircuits.com/showthread.php?t=46486
If you write a complex program with a lot if interrupts going on then in a way it is multi-tasking i.e. doing more than one thing at once, although not strictly simultaneously.
I think u can use timer interrupts for dividing total time for the 2 jobs ie u can give one job in interrupt routine ....
Any way, u can't do same job at the same time...
I think u can use timer interrupts for dividing total time for the 2 jobs ie u can give one job in interrupt routine ....
Any way, u can't do same job at the same time...
His question is about multitasking, using timer interrupt does not cause multitasking.
You need "Real Time Operating system", whose basic requirement is to do multitasking. they can be ported on microcontrollers now-a - days.
You can use (mikroc or mikropascal built in) interupt routine to execute 2 different codes at the same time.
This will simulate "multitasking" exactly what you need.
Any Computer that has interupt capability can do some form of mutitasking. The simplest form is the background/forground where one thread/task runs in the Interupt Service Routien (ISR) and the other runs out of interupts.
The essential feature for multitasking is being able to switch from one task/thread to another this can be preemptive or nonpreemptive. To do it preemptivly requires that you be able to reliably context switch.
However you may wish to do it nonpreemptivly or cooperativly. To do this each task/thread has to yield control of the CPU to another task/thread.
There are two types of basic task or thread those that are effectivly "one shot" executing and those that have a control loop that calls two or more other tasks or thread that can be of either type.
The basic form is,
1, Initialisation / setup
2, Payload
3, Exit.
Where the Payload is either a one shot task or a control loop
This structure is fundemental not just to tasks/threads but all programs including operating systems.
So your OS can just conceptually be a control loop calling one shot tasks in turn. The tasks should be independent of each other (registers, RAM, I/O) and only communicate via a well defined mechanism of which there are many to chose from.
Alternativly you can have the CPU run an idle task and a timer interupt launch tasks/threads in turn to get a semblance of RTOS ability. Obviously each task/thread has to compleate within the interupt time interval and not muck about with other tasks resources thus any subs have to be fully reentrant.
You can expand the idle task to do basic task scheadualing and I/O functions etc that you would expect from a limited functionality OS.
The main problem with this method is that interupt driven I/O cannot happen whilst an ISR task is running unless you have hierarchical interupts where a low priority ISR can be interupted by a higher level ISR, to do this usually means you have to implement your own partial context switch where the higher level interupt has to push and pop registers onto the CPU stack on entry/exit as well as not mucking up any other tasks memory etc.
When you get to this level you need to start thinking about buffers for I/O comms and how you are going to manage them. After some consideration you will realise that each communicatios stream needs to be atleast double (and oftentripple) buffered usually with a circular buffer. That is the stream head writes into a circular buffer, the OS copies from this buffer into an internal buffer and performs some action on it it then copies from the internal buffer to the circular buffer the stream tail reads from. The important thing to remember with circular buffers is that you update pointers the in the right order depending on the stream direction and which task can interupt another to prevent over or underrun either overwriting unread data or reading old data that has not yet been overwriteen with the correct new data.
If however you are doing more than half a dozen threads (or do not need RTOS but do need high CPU utilisation) and you can do full context switching then you turn every thing around and implement a pre-emptive OS with general tasks running out of ISR's. However you then need to rewrite I/O drivers to have top and bottom handlers or as once called fast and slow interupts. The when the I/O device triggers an interupt the fast ISR copies data to/from a buffer or the hardware, sets a flag and exits. The fast ISR makes no attempt to process the data in any way it just copies data. When a slow (timer) ISR comes along the various fast ISR flags are checked and data is copied in/out of the fast buffer into the kernel buffer and the fast interupt flag cleared. The OS kernel then deals with any basic data processing (such as a line discipline or copying into a specific task buffer from a shared I/O source such as a disk or network interface).
Context switching ranges from simple to difficult depending on the CPU and how you are usuing memory and your code is written.
To do a context switch as a minimum you need to,
1, Save the current registers and stack info
2, Load the new task registers and stack info
3, Jump to the next instruction in the new task
This is usually most easily done through an ISR as the CPU will do a big chunk of the context switch for you.
Unfortunatly not all CPU's have a software interupt which is the favourd way of using the kernel services in a preemptive OS.
Then there is the issue of memory...
In a general OS task code is loaded on demand this usually requires the use of a Memory Managment Unit (MMU) as it makes loading linking and memory allocation way way simpler. But in an embedded system esspecialy a Harvard architecture you will not be loading code into execution memory and as the code is likley to be a single image it will all be linked etc so you only need take care of memory allocation.
I hope this helps you decide which way you want to go.
If it were not possible with a microcontroller, then it would not be possible
either with an RTOS. There is no magic in an RTOS beside the fact that it
does a lot of work for you.
Normal Micro-controllers does not support this. Go for controllers that support RTOs
Basically _ANY_ processor can support an RTOS. For instance Pumpkin software makes
one that can run with as low as 50 extra bytes, so you can run it on a very tiny device.
As for 2 jobs at the same time, as long as you have only one core (which is the case
for all microcontrollers), then you cannot do 2 tasks at the same time. For instance
on a single processor PC, you have the impression that everything runs at the same time
(the clock, your word processor, etc) but it works in fact in time sharing.
Now that said, of course it is possible to do multitasking on a PIC or a 8051
or whatever. I'm making measurement devices with recording features. In any of
the devices I build, there are at least 4 tasks running together:
Note that I cannot run the tasks in a loop: there is not enough time between 2 measurements
to write a full sector in an SD card for instance, or to do a full refresh of the screen.
So yes, it's definitely possible.
There were already a few threads saying it's not possible, but in fact it _IS_ possible
to do multitasking with any CPU.
If it were not possible with a microcontroller, then it would not be possible
either with an RTOS. There is no magic in an RTOS beside the fact that it
does a lot of work for you.
Then why are RTOs in market. can you tell me how to run 2 parallel threads in 8051 simulataneously. with the least context switch or setting stack size or priority other than manufacturer defined for controller, or inheritance property or real multitasking are difficult in 8051. And whatever pumpkin software you are referring are not easily available all over the world. You cannot rule out the truth so easily just because you are not using/ or not used RTOS anytime or at least in your project. RTOS are capable of many things that even controllers cannot do. Its only assumption that controllers can do multitasking based on our knowledge. but in reality we need to see practical constraint that controller cannot handle.
RTOS are capable of many things that even controllers cannot do. Its only assumption that controllers can do multitasking based on our knowledge. but in reality we need to see practical constraint that controller cannot handle.
An operating system (RTOS windows OS2 anything) is just a program that runs
on the micro. It isnt capable of doing anything the micro can't do.
Any micro that is capable of having it's state saved and restored can run a multi-tasking operating system. Or a multi-tasking application.
1 Process is running
2 Another signals or is allowed to take over
3 Original process saves its state
4 New process initialises its state and runs
5 New process relinquishes or is requested to or ends or keeps running
6 Depending on 5 state may be saved again and another task take over
The task taking over at any point may be an application or it may be an OS
routine. The micro neither knows nor cares.
There is nothing magic about multi-tasking. The only variations and complications arise from how you signal a task change. Appart from that they
all work the same way no matter what hardware they run on.
A processor can only do one thing at once no matter what operating system is running on it.
Personally I suspect running an OS on a microcontroler may be overkill but
be aware I've never done it so others may find them useful somehow.
I did look at a couple when I first started with PIC's but decided their overhead
just added complexity and bug potential I didn't need.
That being said - I would consider a really good implementation of Forth or
some similar TIL to be a benefit - these are often considered multi-tasking OS's
in their own right. The ones I've seen for PIC's aren't up to much sadly.
On the other hand microcontrolers can have hardware timers/ports/modules
running independantly on chip - this could be thought of as a sort of "true"
multi-tasking.
If you want genuine multi-tasking computers you need multiple processors
with multiple buses and ... well you need a processor farm. (See PS3 and USGOV for a fun farm)
My simple question is can you run two threads simultaneously on a controller and measure the execution of each of them. if not then is it multitasking. Multitasking is misinterpreted by many people in their own way. Can a controller handle or preempt two threads
---------- Post added at 20:51 ---------- Previous post was at 20:49 ----------
The magic of multitasking will be seen in more high ended and critical systems not on simple projects on 8051 or pic
---------- Post added at 20:53 ---------- Previous post was at 20:51 ----------
I am not trying to prove anybody wrong here but, trying to tell that dont consider RTOS as a waste and it has nothing to do and major part is handled by controllers.
The simple answer is then no. You cannot run two threads simultaneously
on any processor be it a microcontroler or whatever the latest Intel doo dah
happens to be. Even a multi core processor cannot really do this because at some stage the buses need to be accessed and those are limited and shared.
Actually I suspect what you are working towards is the concept of task latency.
If you time thread 1
Then you time thread 2
Then you time the period it takes to switch back and forth between them
you have some figures that make sense and could be very useful to you.
(Just drop the concept of "simultaneous" completely - nothing works that way)
the discussion is getting more and more interesting an i am learning a lot from this thread. thanks to all who are in this thread.
I like doraemon skills and technique used in his project. 123jack has a point to prove, but i agree with ckshivaram on his comments. my vote to ckshivaram
---------- Post added at 17:41 ---------- Previous post was at 17:36 ----------
Thats all. controllers DO NOT SUPPORT MULTITASKING
If you mean that multitasking is doing simultaneously 2 calculations then it is not possible unless you have 2 cores but since we consider windows a multitasking os and this was also true before the 2 or 4 core processors were produced then multitasking is generally translated to multiple jobs done simultaneously with only one of them using the cpu core at any given moment and each one having different priority (cpu time).
In my experience it's hard to do even the simplest program without using some kind of multitasking. As vinodstanur and djanib pointed, if you use interrupts you already make multitasking. Let's take the doraemon's example. There , an RTOS would be a waste of time and resources , why save in blind a context that you don't need or switch to a task that does nothing ? Let's say that you need a blinking led using RTOS. The program for this task will look like that : LED ON , WAIT , LED OFF, WAIT , GO BACK. In this time RTOS will switch the context thousands of times just to see if the wait time is ended. Without using RTOS you set the timer interrupt to wait time then in the interrupt routine just complement the LED output. Using an RTOS especially for low range microcontrollers is like asking somebody else to do the job, you will not allways get what you wanted.
actually for my problem is regrading a three phase system.
Now I have a three phase system, I try to step down all the voltage by using the transformer to 12V. In here the three phase system is in 50 Hz, which mean that every half cycle is 0.01s and we know that the every phase of the line is just vary 60 degree. therefore, it is just a 3.33ms different. since it is quite fast between the phase, therefore i am thinking to multitasking the entire three phase into three different ports. in these three different port I am trying detect the zero crossing. after I successful to detect the zero crossing, I am try to delay 1.667ms to sent a pulse to trigger the gate of the three phase rectifier SCR. As my opinion is quite need the multitasking to build it. Can someone teach me is that possible I try to detect three phase zero crossing at the same time and can delay 1.667ms to sent a pulse.
Actually very thank to above threat, it is very help a lot. especially the RTOS system, i will try it soon once I have understand what is RTOS. because I have read through some document that regrading the RTOS, it seem like an external OS for the microcontroller to help it do the task. and it is totally different from the programming that inside the microcontroller, so i have a litter bit confuse. Can anyone can explain more detail on it?
Basically here is a (very simplified) explanation of multitasking.
Suppose you want to run 2 tasks "simultaneously", or at least give the
user the impression that they run simultaneously:
1. You need a scheduler which is a software object that can record
a list of tasks.
2. You define a time slot for your scheduler (for example 5 ms).
3. For each of the tasks you have recorded to your scheduler, you run
the first task for 5 ms, then you save the temporary results (the state of
all the registers that have been used, and then you switch to the next
task (get the registers back to the state they were the last time you
have run this task, and then continue this task) and so on.
This being said, you can either say that there is no processor capable
of running 2 simultaneous tasks (at least no single core processor),
you can even say as somebody pointed out, that even a multicore processor
at some times needs some synchronization and therefore cannot use the
same bus at the same time, or you can also say that any processor can do
multitasking, which means in fact running pseudo-simultaneous tasks, or in
other words running tasks that give the user the impression that they are
smultaneous. There is no absolute "truth", everything depends on how you
look at your system. But in the common knowledge in this field, multitasking
does not mean that all the tasks run simultaneously, it just means that
the tasks are sliced by a scheduler and that they run one slice at a time.
You may be interested in reading this wiki.
Now why are RTOS on the market: because the RTOS just keeps track of all
the tasks that were added, and takes care of the register saving / restoring
(which is also called context switching), therefore making development
a lot easier.
Now is it mandatory to use a RTOS to do mulititasking? No. You can save the
registers yourself "by hand" and you will probably have less overhead.
That's what I do for simple designs, but of course I use an OS for systems
with many asynchronous IOs.
RTOS are capable of many things that even controllers cannot do.
An RTOS is a piece of software that runs on a processor. RTOS cannot
do more than the processor / microcontroller can do. There is no magic in it.
Dora
Then why are RTOs in market. can you tell me how to run 2 parallel threads in 8051 simulataneously. with the least context switch or setting stack size or priority other than manufacturer defined for controller, or inheritance property or real multitasking are difficult in 8051. And whatever pumpkin software you are referring are not easily available all over the world. You cannot rule out the truth so easily just because you are not using/ or not used RTOS anytime or at least in your project. RTOS are capable of many things that even controllers cannot do. Its only assumption that controllers can do multitasking based on our knowledge. but in reality we need to see practical constraint that controller cannot handle.
If this is all you have to do you don't need multitasking. Keep track of only one phase zero crossing , wait 1.667ms , send the pulse to phase 1, wait ( 3,33ms - pulse ) , send the pulse to phase 2, wait ( 3,33ms - pulse ) , send the pulse to phase 3, wait for zero crossing on phase one and repeat for ever. If you have something else to do in the main program you can use interrupt on pin change for zero crossing detection and timer interrupt for delay .
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
exactly what you need.
