Post by thread:[PIC]: Multitasking

part 1 498 bytes content-type:text/plain; charset="us-ascii"; format=flowedGood day to all: I'm planing to work with multitasking on a PIC 16F877A, I found a lot of useful help in PICLIST site, I'm a attaching a code I found there, it works really well for two task, does anybody know how to expand it to more tasks??? I was trying, but I can't figure it out how... any help will be apreciate!!! Thanks in advance, Gonzalo -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics part 2 2252 bytes content-type:text/plain; charset="us-ascii" ; warning: untested code. ; Is there a better way ? ; 2002-03-04:DAV: copied ideas from Scott Dattalo to make ; faster and shorter (?). ; 2001-10-19:DAV: David Cary extended to handle multiple pages. ; ???: more ideas from Scott Dattalo. ; ???: Original ideas from Rich Leggitt. ; RAM to bookmark current location in each task. context equ 0x20 ; ``switch'' overwrites the W register. switch macro continuation_lable retlw ((continuation_lable)-task_table_start) ; return pointer to where to continue task endm ;... power_on_setup: ; ... movlw (t1_1 - task_table_start) ; note task1_offset1 will run first movwf context movlw (t2_1 - task_table_start) ; task switcher call $+2 ; make a place for 'switch' to return to goto $-1 ; (i.e. here!) ;context_switcher: ; Swapping code optimized for 2 tasks. ; Code to handle 3 or more tasks ; would probably be much easier to understand. xorwf context,w xorwf context,f xorwf context,w addwf pcl,f task_table_start: t1_1 goto task1_offset1 t1_2 goto task1_offset2 t1_3 goto task1_offset3 t2_1 goto task2_offset1 t2_2 goto task2_offset2 t2_3 goto task2_offset3 task1_offset1 ... normal code blah ... switch task1_offset2 task1_offset2 fcall input_stuff movwf temp fcall get_mask andwf temp fcall output_stuff etc switch task1_offset2 task1_offset2 stuff more_stuff ; select the address at which the task ; will next begin executing. ; this is very tricky. btfss condition,condition_bit switch(task1_offset2) switch(task1_offset3) task1_offset3 blah blah blah goto task1 task2 asdf switch task2_offset2 task2_offset2 zxcz goto task2 Warning: none of these ``switch'' macros work right when used inside a subroutine. -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

You can look at multi-tasking in many different ways, what if for example Let's say that we have a recently renovated a doughnut factory with a production line that performs many processes before a frosted doughnut reaches the end of the production line. The entire production line is run by machines and each machine is controlled by a PIC that makes the machine perform automated process. When the factory was renovated they also replaced ten big old control panels with a single Master Control Panel that contains a PIC. This new Master Control Panel, that can now be controlled by one person, can also monitor and control all of the machines that perform different processes along the assembly line. This Master Control Panel displays requested data, acceps user input and sends commands to the machines on the entire production line. Each machine knows how to perform it's process and the Master Control Panel trigers the equipment to perfor The Master Control Panel tells the machines when to do a process and the equipment knows how to do the process. The Master Control Panel can direct multiple processes to be performed at the same time and also monitors all of the machines to verify that their status is ok. The PIC in the Master Control Panes shares a common data bus with all of the PIC's inside of each piece machine. Each machine is given a different address and each machine monitors the data bus for a command to perform a task or sent status info back to the Master Control Panel. I hope this helps. Tim {Original Message removed}

Gonzalo Jiminez wrote: > Good day to all: > > I'm planing to work with multitasking on a PIC 16F877A, I found a lot of > useful help in PICLIST site, I'm a attaching a code I found there, it works > really well for two task, does anybody know how to expand it to more > tasks??? I was trying, but I can't figure it out how... any help will be > apreciate!!! > > Thanks in advance, > > Gonzalo Multitasking on a 16 series PIC is not trivial. For one thing you need to be careful about shared subroutines. Sometimes you may need to make copies of subroutines that are used in different tasks. Switching the task context from within a called subroutine is another problem on the 16 series PIC since you don't have read/write access to the return stack or its pointer. XCSB is a high level language that has multitasking built in. As you would expect, it allows communication between tasks using global variables, however it also allows comminication through FIFOs and the state of one or more FIFOs can be used to control task schedualing. Example programs are shown at http://www.xcprod.com/titan/XCSB/CONTRIB The XCSB compiler generates optimised native instructions for the 16 series PIC. The following: proc inline clear_bit(ubyte *ptr, int id) *ptr = *ptr & ~(1 << id) endproc proc main() clear_bit(&PORTA, 3) endproc generate just one instruction bcf PORTA,3 Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC compiler -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> I'm planing to work with multitasking on a PIC 16F877A, I found a lot > of useful help in PICLIST site, I'm a attaching a code I found there, > it works really well for two task, does anybody know how to expand it > to more tasks??? I was trying, but I can't figure it out how... PICs are not well suited for true multitasking (separate threads). Why do you think you need this? You probably don't. Step back and define the problem you are trying to solve without supposing the solution is multitasking. PICs can appear to handle multiple independent tasks simultaneously. I do this often with a single event loop architecture. Break each "task" into relatively small individual operations, with a unique event condition indicating when each operation needs to be performed. The event loop checks the event conditions in sequence. If no event conditions are triggered, then the event loop just jumps back to its start and checks the event conditions all over again. If a triggered event condition is found, the event loop jumps to an event handler. The event handler performs the unique operation, then jumps back to the start of the event loop. For example, a timer interrupt can be used to set the "start A/D reading" event flag every 100mS. This event handler starts a new A/D conversion. When the A/D conversion completes, the hardware sets the ADIF bit. This bit is used as another event condition that runs an event handler to process the new A/D reading. It could, for example, compare it to various thresholds and possibly set other event conditions. I do find pseudo threads useful for handling command input streams. It is usually easier to write a command processor that goes and "gets" the next input byte, as apposed to a subroutine that is called with each new input byte. This is where pseudo threads come in. The command processor is really an event handler for the "new input byte is available" event. Since the meaning of each command byte is dependent on its context in the stream, some state must be kept to know how to interpret each new byte. An easy way to do this is for the state to be the program memory address of the code to handle the new byte given all the previous context. In other words, the state is a thread restart address. The reason I call these pseudo threads is because this restart address must not be inside a subroutine called by the thread, due to the PIC's hardware call stack architecture (at least for the 16 family). See the HOS_CMD.ASPIC module in the HOS PIC project at http://www.embedinc.com/pic for an example of a pseudo thread used to process a the command stream from a host computer. The command processor appears to run as an infinite loop that "gets" the next input byte via the GETBYTE macro. This macro actually saves the thread restart address and returns to the event loop. At the next input byte event, the event handler loads the new byte into REG0 and jumps to the thread restart address. GETBYTE thereby appears to return with the new byte in REG0 from the thread's point of view. This type of pseudo thread appears to run concurrently with other system tasks because it is triggered by just another event condition. As long as all events are checked quickly enough, the processing for all events appears from the outside to be overlapping independent tasks. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Thanks for your help... At 04:48 p.m. 10/10/2003, you wrote: {Quote hidden}>You can look at multi-tasking in many different ways, what if for example > >Let's say that we have a recently renovated a doughnut factory with a >production line that performs many processes before a frosted doughnut >reaches the end of the production line. The entire production line is run >by machines and each machine is controlled by a PIC that makes the machine >perform automated process. > >When the factory was renovated they also replaced ten big old control >panels with a single Master Control Panel that contains a PIC. This new >Master Control Panel, that can now be controlled by one person, can also >monitor and control all of the machines that perform different processes >along the assembly line. > >This Master Control Panel displays requested data, acceps user input and >sends commands to the machines on the entire production line. > >Each machine knows how to perform it's process and the Master Control >Panel trigers the equipment to perfor >The Master Control Panel tells the machines when to do a process and the >equipment knows how to do the process. > >The Master Control Panel can direct multiple processes to be performed at >the same time and also monitors all of the machines to verify that their >status is ok. > >The PIC in the Master Control Panes shares a common data bus with all of >the PIC's inside of each piece machine. Each machine is given a different >address and each machine monitors the data bus for a command to perform a >task or sent status info back to the Master Control Panel. > > > >I hope this helps. > >Tim > > > >{Original Message removed}

Just in case: At 11:59 a.m. 10/10/2003, you wrote: >Good day to all: > >I'm planing to work with multitasking on a PIC 16F877A, I found a lot of >useful help in PICLIST site, I'm a attaching a code I found there, it works >really well for two task, does anybody know how to expand it to more >tasks??? I was trying, but I can't figure it out how... any help will be >apreciate!!! > >Thanks in advance, > >Gonzalo ; RAM to bookmark current location in each task. context equ 0x20 temp equ 0x77 ; ``switch'' overwrites the W register. switch macro continuation_lable retlw ((continuation_lable)-task_table_start) ; return pointer to where to continue task endm power_on_setup: ; ... movlw (t1_1 - task_table_start) ; note task1_offset1 will run first movwf context movlw (t2_1 - task_table_start) ; task switcher call $+2 ; make a place for 'switch' to return to goto $-1 ; (i.e. here!) ;context_switcher: ; Swapping code optimized for 2 tasks. ; Code to handle 3 or more tasks ; would probably be much easier to understand. xorwf context,w xorwf context,f xorwf context,w addwf PCL,f task_table_start: t1_1 goto task1_offset1 t1_2 goto task1_offset2 t1_3 goto task1_offset3 t2_1 goto task2_offset1 t2_2 goto task2_offset2 t2_3 goto task2_offset3 task1 NOP NOP switch task1_offset1 task1_offset1 NOP NOP NOP switch task1_offset2 task1_offset2 ; fcall input_stuff NOP movwf temp ; fcall get_mask NOP andwf temp ; fcall output_stuff NOP switch task1_offset3 task1_offset3 NOP NOP ; select the address at which the task ; will next begin executing. ; this is very tricky. ; btfss condition,condition_bit ; switch(task1_offset2) ; switch(task1_offset3) ;task1_offset3 goto task1 task2 NOP NOP switch task2_offset1 task2_offset1 NOP NOP NOP switch task2_offset2 task2_offset2 NOP NOP NOP NOP switch task2_offset3 task2_offset3 NOP NOP goto task2 -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Thanks all for your answers, Well I was trying to do multitasking just becasuse it seems to be better than a "super loop" even though a "super loop" can work very well, thanks for your ideas, I guess I could modify the code I posted before to work with more tasks at least in one page it seems to work :) My idea is to store two register for each task, one to store the address where it must continue working and the other to store the addrees it must work next time the task is called, with that you can yield control everywhere anytime inside a task, at least in simulations it worked... Thanks again, tim, Segio, Olim... if I miss somebody I'm sorry... Greatings, Gonzalo -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

On Sat, Oct 11, 2003 at 09:34:03PM -0500, Gonzalo Jim?nez wrote: > Thanks all for your answers, > > Well I was trying to do multitasking just becasuse it seems to be better > than a "super loop" even though a "super loop" can work very well, From a programming abstraction point threads can give an advantage if all things are equal. But in a PIC since the interrupt stack/stack pointer is hidden from the programmer, all things are not equal. So generally the effort require to implement threading by hand isn't worth the effort. Next year, once I finally finish my dissertation, I plan to dust off my NPCI interpreter http://www.finitesite.com/d3jsys/README-NPCI.html and implement threading. Since I expose my interpreter stack, it should be fairly easy to do. But the super loop as you call it, coupled with any interrupts required for faster processing, is a perfectly acceptable way to handle an application that requires multiple tasks. BAJ {Quote hidden}>thanks > for your ideas, I guess I could modify the code I posted before to work > with more tasks at least in one page it seems to work :) > > My idea is to store two register for each task, one to store the address > where it must continue working and the other to store the addrees it must > work next time the task is called, with that you can yield control > everywhere anytime inside a task, at least in simulations it worked... > > Thanks again, tim, Segio, Olim... if I miss somebody I'm sorry... -- http://www.piclist.com hint: To leave the PICList spam_OUTpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu