Simultaneous control of delay operated LEDs

[TokTok]

Hi all,
Apologies if this sound trivial but currently I’m stuck in terms of figuring out the logic to complete what I suspect is a fairly easy task.

I’m currently turning on my LEDs for a certain amount of time using the output_toggle() method as seen in my code at the end of my post but I’d like to move on to turning on another relay when I’ve got the first LED currently engaged. So essentially simultaneous operation of the LEDs is what I’m after.

How does one go about this in an efficient way?

I’m running the code on my PIC18F2580 PIC MCU and as I mentioned it runs fine but I would like to engage the LED simultaneously not sequentially.

Note: As I come from a java background is there any threading within the CCS library?

Any help is appreciated.

TokTok

[PCM programmer]

Do a search for these two words and you'll find sample code
which shows how to do it:

[asmboy]

since you are using A6,A7 for the oscillator -

bit mapping your led on/off commands into a shadow BYTE
for port A would do what you want in a very clean way

[Mike Walne]

This is not quite the same as true multi-tasking, but may do what you want.

Set up one of the timers to give (say) a 1ms tick.
Use the tick to trigger an ISR.
Set up a tick_counter for each of your tasks.
In the ISR, decrement all the tick_counters.

In main() you simply poll each tick_counter in turn, and do the necessary.

OR

You can increment counters. Whichever you are most comfortable with.
I prefer to set tick_counters to a value for the delay needed, and watch for reaching zero.
In the ISR I also prevent the tick_counters going below zero.

Mike

[TokTok]

Hi all,
Following the advice from Mike Walne plus the sample code in the CCS C compiler manual the code below is my first attempt to enable the multiple operation of relays using a timer and its interrupt.

Apologies if the below approach sounds silly but I’m learning about interrupts as I try to use them to provide a solution to my task.

[Ttelmah]

OK.

First problem is speed. Your timer is counting in single machine instructions. Loading with FC4F, means it'll trigger next just 945 instructions later (counter counts _up_ and interrupt fires when it wraps from FFFF to 0000. 945 instructions is just under 1mSec. You are not going to see much....

Then your four instructions selecting the different things to do, are all executed before the timer triggers even once. So LED+flag gets to 5, before the timer gets called...
You need to have each change wait till the interrupt is triggered.

Then the code 'drops off the end'. Classic problem here. Remember _your code is the only thing running_. When writing code on a PC, you are running 'inside' an operating system. When the code drops off the end, you go back to running the OS. On the PIC, there is nothing else in the chip, and when the code runs off the end, everything stops (the chip goes to sleep).

Then in a couple of your states, you toggle the output twice. You are probably never going to see this. Just a couple of uSec apart....
If you mean these to be separated by 1mSec, then they need to become new states.

Best Wishes

[TokTok]

Hi Ttelmah,

Thanks for the reply.

I don't fully get the following bit of your suggestion below:


Then your four instructions selecting the different things to do, are all executed before the timer triggers even once. So LED+flag gets to 5, before the timer gets called...
You need to have each change wait till the interrupt is triggered.


From my code below when LED_flag == 1, how should I look to set my delay in the ISR i.e. using set_timer() to toggle REL_1 and REL_2 assuming the delay between setting the value of LED_flag in the infinite while loop in the main varies.

[Mike Walne]

The following code flashes two LEDs at slightly different rates.
They start off in step, slowly go out of step then back in step after ~2 minutes.
I've used a '458 and 16MHz because that's what happens to be plugged into my PICDEM2 board.
The PIC is a close relative of the one you're using, so should not be a problem.

[Jerson]

I prefer to write it this way.

[Ttelmah]

Yes, and it is also slightly more code efficient. Forcing sign to be used, is a little extra work....

[TokTok]

Hi All,

@Mike Walne:

Thanks for the reply. I really appreciate the code.

There's just one bit I need to clearly understand is the 249 setup_timer_2(T2_DIV_BY_16, 249, 1);

Based on the CCS C compiler manual, 249 is an int 0-255 that determines when the clock value is reset hence the first time it counts does it count from 249 to 255?

Note: I played around with the 249 and the smaler the values the faster the flashes and vice versa.

Apologies if my reasoning sounds basic.

I get more clearly the other two arguments i.e. T2_DIV_BY_16 being the prescaler and 1 - the postscaler.



Thanks.

[Mike Walne]

This is microchip's version of how PR2 affects Timer2.

The Timer2 module has an 8-bit period register, PR2.
Timer2 increments from 00h until it matches PR2 and
then resets to 00h on the next increment cycle. PR2 is
a readable and writable register. The PR2 register is
initialized to FFh upon RESET.

So in my case Timer2 counts from 0 to 249 then resets.
That's a total count between resets of 249 + 1 i.e. 250.

The second parameter in the CCS set_up_timer2 goes into the PR2 register

To completely understand what's going on you need to read the microchip manual as well as the CCS one.

Mike

[Mike Walne]

[Ttelmah]

The 249 value loads 'PR2' (a register in the PIC). Timer2, counts from 0 to PR2 (so gives PR2+1 counts). It is the only timer in the normal PIC's that has the ability to automatically reset 'at' a count.

[TokTok]

Hi Mike and all,

Having read the PIC 18F2580 data sheet and the CCS C manual regarding the TIMER 2, I still cant seem how to piece together how the three arguments that go into the setup_timer_2(); method affect the counting.

Essentially below is what I would like to achieve specifically as per my comments: