Need help with Counter/Timer application

[mister_e]

Can you be more specific... i'm not sure of what you want to do.

[RussMartin]

I need an interrupt every 100 ms, but very much as a background operation. On each, the program must check an array of stored values. When one matches the number of 100 ms intervals that have occurred, additional functions must happen.

Example: Stored in the array are the values 123 and 456. Each is a value in tenths of a second (12.3 and 45.6 seconds, respectively). The clock begins running from 0 when an input is recognized. When the clock hits 123, a small set of instructions will execute. When it hits 456, another small set of instructions will execute. When the last (highest) value has been matched, the clock resets to 0 and waits until the next input to begin the process again.

The values may change, and there will be more than two, of course, but I need to look at the array every 100 ms.

Is that clearer?

I've done this with the 8051 family but I'm very new to PIC architecture and don't know my way around it yet. I'm working my way through a couple of books on it right now. I also have the data sheet and, after I pick up a couple of extra reams of paper, I'm going to print the family reference manual.

Russ

[sayzer]

Hi Russ,

Something like below could work for you but it is just an example to show the idea.

Same concept could be applied to a Timer module of the PIC.

DEFINE OSC 20

TRISB = %00000000
PORTB = 0

Relay1     VAR PORTB.0  'A relay is driven through PORTB.0
Relay2     VAR PORTB.1
Relay3     VAR PORTB.2

RUSS_Timer var word     'A timer variable 
RUSS_Match var word     'A variable to match timer with stored variables in Lookdown Table.


Begin:

   Russ_Timer = 0
   RUSS_Match = 0


Start:

   PAUSE 100   'You need 100ms of time intervals.
   RUSS_Timer = Russ_Timer + 1
   
   LOOKDOWN RUSS_Timer ,[34,46,49,112,119,122,123,124,156,189,205,235],RUSS_Match     'Get an index value from the timer. Ad d more...

   BRANCHL  RUSS_Match, [Run_RED, Run_Green, Run_Blue, Run_last]     'Go run the matching set of instructions. Add more....
   

   goto start


Run_Red:

   high relay1
   goto start
   
Run_Green:

   high relay2
   low  relay1
   goto start

Run_Blue:

   TOGGLE relay3
   low relay2
   goto start
   
Run_Last:

   PORTB = 0
   goto begin  'Reset All.
   


END

[RussMartin]

Thanks. I wanted to try something like that, but the problem is the processor may have to do other things while the time is ticking away. Let me show it this way:

time 0.0 seconds -> We have an input, so we start counting.

time 0.1 seconds -> Is test1, test2, or test3 equal to 1? No? Let's keep counting.

. . .

time 12.3 seconds -> Is test1, test2, or test3 equal to 123? YES, test2 is! Let's quickly perform operation A while counting continues in the background. Is there any test value greater than 123? YES, test3 is, so let's just keep counting

. . .

time 45.6 seconds -> Is test1, test2, or test3 equal to 456? YES, test3 is! Let's quickly perform operation B while counting continues in the background. Is there any test value greater than 456? NO!--let's reset the counter to 0 and wait for another input.

[SteveB]

Russ,
Have a look at Darrel Taylor's Instant Interrupts. http://darreltaylor.com/DT_INTS-14/intro.html


From this (and Darrel's elapsed timer) you can get an interrupt driven timer to count out your .1sec intervals.

Then you can put the conditional tests and assosiated code either:
a) In the interrupt handler itself (OK if the code is short, but not very good for lots of code)
b) In your main loop, and poll the timer value for changes.

This should get you started in the right direction. There are otherways to do this, but Darrel Talyor has generously done all the hard work for you getting the interrupts working.

HTH,
Steve

[sayzer]

BTW - Since you are playing with time (which passes always and so quick and causes us to get older physically), how will you handle an incoming operation say B while the previous operation say A is still in progress?

Is there a possibility like that?

Here is another wish I should post to Wish list : A true Multitasking Processor – say four separate operations simultaneously.

[Melanie]

A PIC already multi-tasks...

It runs multiple Timers all independantly from each other or anything else that's happening...

It runs Multiple Comparators and Op-Amps (if fitted) all independantly from anything else...

It can Transmit and Receive on it's USART (if fitted) independantly from anything else...

It can do ADC conversion independantly from anything else...

It can do PWM Output independantly from anything else...

That's because it's got the HARDWARE to do it. However, until we get multi-core PICs, it can only execute one software instruction at a time. Even your desktop PC only executes one instruction at a time (ignoring the new dual-core CPU's), but it time-slices, so it appears like you are running multiple tasks. Time-Slicing is a kernel function of an OS which sits below any higher-level application program. PICs can time-slice too, but because until recently their Program Memory has been limited to only a few Kb, by the time you've added a true multi-tasking kernel, there's not been much room for anything else layered on top.

So until someone markets an embedded multitasking OS for the PICs, you're limited to writing clever programs that perform seemingly 'simultaneous' functions yourself.

[keithdoxey]

true Multitasking Processor – say four separate operations simultaneously.

Which is fine until you want to do six things simultaneously.

As Melanie said

Even your desktop PC only executes one instruction at a time (ignoring the new dual-core CPU's), but it time-slices, so it appears like you are running multiple tasks.

My laptop is currently running many programs in the background and appears to be a speedy machine but when I first boot it up it takes forever due to the heavy processor demands for each of the applications starting up.

To achieve the appearance of effective multitasking you must prioritise each task and ensure that a routine to service that task is performed often enough for the program to work.

eg. Task levels "Critical", "Important", "Menial"

Main:

For MenialTasks = 0 to 5
   For ImportantTasks = 0 to 3
      Gosub CriticalTask
      Select Case ImportantTasks
          Case 0 
              Gosub MostImportantTask
          Case 1 
              Gosub LessImportantTask1
          Case 2 
              Gosub MostImportantTask
          Case 3 
              Gosub LessImportantTask2
      End Select
   Next ImportantTasks
   Select Case MenialTasks
          Case 0 
              Gosub MenialTask1
          Case 1 
              Gosub MenialTask2
          Case 2 
              Gosub MenialTask3
          Case 3 
              Gosub MenialTask4
          Case 4 
              Gosub MenialTask5
          Case 5 
              Gosub MenialTask6
      End Select
Next MenialTasks

Goto Main

To complete both the nested loops takes 24 circuits.
(6 MenialTasks * 4 ImportantTasks).

If you look you will see that the subroutines called are...

CriticalTask - 24 times (once every loop of the ImportantTasks)
MostImportantTask - 12 times (every other loop of ImportantTasks)
LessImportantTask 1 & 2 - 6 times each (once per ImportantTasks loop)

Each MenialTask gets called once for every complete cycle of both loops.

You just need to figure out the most important things to do and how to keep track of what you are doing

[RussMartin]

BTW - Since you are playing with time (which passes always and so quick and causes us to get older physically), how will you handle an incoming operation say B while the previous operation say A is still in progress?

Is there a possibility like that?

Sad to say, yes there is. That's why I'm having one PIC handling the user interface, inputs, and master timing, and other PICs performing the requisite operations.

Here is another wish I should post to Wish list : A true Multitasking Processor – say four separate operations simultaneously.

As you can see, I'm kind of approaching that with primitive "distributed (or parallel) processing".

All of my prior work over the years has involved the Z80, the 8051 family, and the 68HCxx line, always with "glue" in the form of support chips (RAM, PROM, EEPROM, SPIs and/or PPIs--you know), so it's kind of fun to look at "doing it all with PICs large and small".

PS: A lot of my practical PIC education is coming from reading Melanie's posts in this forum (and in the archives). Melanie, I'd like to nominate you for goddess.