--- In 68HC12@68HC..., "Uwe Arends" <nospam@u...> wrote:
> Amr,
>
> > > > I know that modulus counter can achieve this task but for
only one
> > > > channel. What if I need more than
one channel, e.g. eight
channels?
> > >
> > > well, I think I didn\'t and still don\'t understamd
what you mean
by
> > > general purpose timer then!
> > >
> >
> > Sorry for being vague. I mean that how can I setup the eight
channels
> > of the ECT as continous timers? I dont want
to use one shot
timers I
> > need them continous. Is it now clear?
>
> With eight channels, do you mean eight more or less independent
timebases
> causing interrupts, triggering actions? What are
you trying to
achieve?
In Breif, I want to generate eight independent timers. Each timer is
working in continous mode which means it generates periodic
interrupt. That\'s All,
Thanx,
Amr
>
> > Thanx for your patience,
>
> No patience involved as of yet :o)
>
> -uwe
How to use HC12's ECT as a general purpose Timer?
Started by ●May 18, 2005
Reply by ●May 18, 20052005-05-18
Reply by ●May 18, 20052005-05-18
On Wednesday, May 18, 2005 9:27 AM (BST),
"Amr M. Adel" <amradel_79@amra...> wrote: - > Hi all,
> I am a new member in this group. I hope to gain new knowledge and
> share my konwledge with you.
>
> I need to implement a general purpose timer on HC12 microcontroller
> and as U know it is not provided in HC12. ECT, Enhanced Capture
> Timer, is the only thing that can be used for this purpose.
>
> I have an idea to use ECT as a General Purpose Timer. This can be
> achieved by changing the value of the comparator of a channel each
> time a it finishs its period. The main disadvantage of this technique
> is that periods may be irrigular because of the adjustement of the
> comparator is depending on ISR which may ba masked or delayed!
>
> Any Suggestion or documentation describing how to achieve this?
>
> Thanx for your interest,
> Amr
Why not use the Real Time Interrupt (RTI), which is part of the Clock
and Reset Generator (CRG)? This is derived from OSCCLK via a
divisor register. To get this to work with a seconds time-base you may
need a non-standard crystal frequency or an adjustment in your
interrupt routine.
Mike.
Reply by ●May 18, 20052005-05-18
You can use the free running counter as your "tick" generator and
configure it to suit your needs (lets say to roll over every 1ms).
When the timer expires have it generate an interrupt.
You can use this interrupt to drive a pretty nice timer task with as
many timers as you wish. If you need long (lets say 500 ms) and
short timers (1ms) you can set two timer channels in the HCS12 to
suit the tick requirements so you don't have to keep globals in your
ISR's.
I have used this method successfully to create a pool of timers,
both long and short. How many of these you will be able to create
will depend on how much ram you are willing to reserve for this
purpose. I have set my pools for 10 timers each, so I have a total
of 20 timers which consume less tan a couple 100 bytes (don't recall
the exact numbers cause I don't have the code here).
If you need HL code examples for the task in C (including examples
of what to do when the interrupt arrives), I can send you something,
just let me know.
Sal.
--- In 68HC12@68HC..., "Amr M. Adel" <amradel_79@h...> wrote:
> Hi all,
> I am a new member in this group. I hope to gain new knowledge and
> share my konwledge with you.
>
> I need to implement a general purpose timer on HC12 microcontroller
> and as U know it is not provided in HC12. ECT, Enhanced Capture
> Timer, is the only thing that can be used for this purpose.
>
> I have an idea to use ECT as a General Purpose Timer. This can be
> achieved by changing the value of the comparator of a channel each
> time a it finishs its period. The main disadvantage of this
technique
> is that periods may be irrigular because of the adjustement of the
> comparator is depending on ISR which may ba masked or delayed!
>
> Any Suggestion or documentation describing how to achieve this?
>
> Thanx for your interest,
> Amr
configure it to suit your needs (lets say to roll over every 1ms).
When the timer expires have it generate an interrupt.
You can use this interrupt to drive a pretty nice timer task with as
many timers as you wish. If you need long (lets say 500 ms) and
short timers (1ms) you can set two timer channels in the HCS12 to
suit the tick requirements so you don't have to keep globals in your
ISR's.
I have used this method successfully to create a pool of timers,
both long and short. How many of these you will be able to create
will depend on how much ram you are willing to reserve for this
purpose. I have set my pools for 10 timers each, so I have a total
of 20 timers which consume less tan a couple 100 bytes (don't recall
the exact numbers cause I don't have the code here).
If you need HL code examples for the task in C (including examples
of what to do when the interrupt arrives), I can send you something,
just let me know.
Sal.
--- In 68HC12@68HC..., "Amr M. Adel" <amradel_79@h...> wrote:
> Hi all,
> I am a new member in this group. I hope to gain new knowledge and
> share my konwledge with you.
>
> I need to implement a general purpose timer on HC12 microcontroller
> and as U know it is not provided in HC12. ECT, Enhanced Capture
> Timer, is the only thing that can be used for this purpose.
>
> I have an idea to use ECT as a General Purpose Timer. This can be
> achieved by changing the value of the comparator of a channel each
> time a it finishs its period. The main disadvantage of this
technique
> is that periods may be irrigular because of the adjustement of the
> comparator is depending on ISR which may ba masked or delayed!
>
> Any Suggestion or documentation describing how to achieve this?
>
> Thanx for your interest,
> Amr
Reply by ●May 18, 20052005-05-18
Ok, I am going to take a leap here based on the other postings:
Set up an accurate single timer interrupt, at your least common denominator
of time slices, say 10mS. Make sure it is nice and jitterless by testing an
I/O pin.
Then in the interrupt, handle several count-down to zero counters:
__interrupt void timerInterrupt(void) {
//Update timer registers here
critical10mSTask(); //The least common
denominator task that must be executed accurately and constantly
if (countdown1) countdown1--;
if (countdown2) countdown2--;
if (countdown3) countdown3--;
//clear mask
}
In your main routine:
While (TRUE) {
If(!countdown1) {
countdown1 = 1000; //Value for next execution
x interrupt rate, in this case 1000 x 10mS
ExecuteTask1();
}
If(!countdown2) {
dountdown2 = 5000; //Value for next execution
x interrupt rate
ExecuteTask2();
}
}
While the above example doesn't guarantee that tasks execute at just the
right time if any task takes longer than your minimum time, they will always
execute, but is great for non-critical timing of tasks since it is very easy
to manage.
If you need better time accuracy, execute tasks right in the interrupt:
__interrupt void timerInterrupt(void) {
//Update timer registers here
critical10mSTask(); //The least common
denominator task that must be executed accurately
if (countdown1) countdown1--; //Decrement all individual
timers first
if (countdown2) countdown2--;
if (countdown3) countdown3--;
if (!countdown1) { //Execute all tasks
that have hit zero.
countdown1 = 1000;
executeTask1();
}
if (!countdown2) {
countDown2 = 5000;
executeTask2();
} //clear mask
}
However again the sun all of your tasks must execute faster than the minimum
time, in this case 10mS, or else you will get a cascade timing error.
Otherwise make sure and stagger the timers so only one task may execute in
any given interrupt hit.
While this is very simplistic, it shows there are many ways to tackle
multiple timers with a single timer interrupt.
Some of the drawbacks are that executeTask1() has highest priority and it's
execution time will impact when executeTask2() will be able to execute. Say
task1 takes 5-7mS, task 2 will begin to execute 5-7mS+ a little after the
interrupt was hit so it's execution may vary from 0-7mS from the initial
interrupt.
This is unavoidable since you only have a single core processor. You can
increase accuracy of the start of your routines by multi-tasking, but then
you run into the problems of unpredictable execution rates of routines, and
the added overhead of task switching.
Look at some RTOS's out there for more info on this subject, I doubt they
use more than 2 times for handling many tasks at a time.
-Mark W
_____
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf Of
Amr M. Adel
Sent: Wednesday, May 18, 2005 4:27 AM
To: 68HC12@68HC...
Subject: [68HC12] How to use HC12's ECT as a general purpose Timer?
Hi all,
I am a new member in this group. I hope to gain new knowledge and
share my konwledge with you.
I need to implement a general purpose timer on HC12 microcontroller
and as U know it is not provided in HC12. ECT, Enhanced Capture
Timer, is the only thing that can be used for this purpose.
I have an idea to use ECT as a General Purpose Timer. This can be
achieved by changing the value of the comparator of a channel each
time a it finishs its period. The main disadvantage of this technique
is that periods may be irrigular because of the adjustement of the
comparator is depending on ISR which may ba masked or delayed!
Any Suggestion or documentation describing how to achieve this?
Thanx for your interest,
Amr
_____
> Terms of Service.
Set up an accurate single timer interrupt, at your least common denominator
of time slices, say 10mS. Make sure it is nice and jitterless by testing an
I/O pin.
Then in the interrupt, handle several count-down to zero counters:
__interrupt void timerInterrupt(void) {
//Update timer registers here
critical10mSTask(); //The least common
denominator task that must be executed accurately and constantly
if (countdown1) countdown1--;
if (countdown2) countdown2--;
if (countdown3) countdown3--;
//clear mask
}
In your main routine:
While (TRUE) {
If(!countdown1) {
countdown1 = 1000; //Value for next execution
x interrupt rate, in this case 1000 x 10mS
ExecuteTask1();
}
If(!countdown2) {
dountdown2 = 5000; //Value for next execution
x interrupt rate
ExecuteTask2();
}
}
While the above example doesn't guarantee that tasks execute at just the
right time if any task takes longer than your minimum time, they will always
execute, but is great for non-critical timing of tasks since it is very easy
to manage.
If you need better time accuracy, execute tasks right in the interrupt:
__interrupt void timerInterrupt(void) {
//Update timer registers here
critical10mSTask(); //The least common
denominator task that must be executed accurately
if (countdown1) countdown1--; //Decrement all individual
timers first
if (countdown2) countdown2--;
if (countdown3) countdown3--;
if (!countdown1) { //Execute all tasks
that have hit zero.
countdown1 = 1000;
executeTask1();
}
if (!countdown2) {
countDown2 = 5000;
executeTask2();
} //clear mask
}
However again the sun all of your tasks must execute faster than the minimum
time, in this case 10mS, or else you will get a cascade timing error.
Otherwise make sure and stagger the timers so only one task may execute in
any given interrupt hit.
While this is very simplistic, it shows there are many ways to tackle
multiple timers with a single timer interrupt.
Some of the drawbacks are that executeTask1() has highest priority and it's
execution time will impact when executeTask2() will be able to execute. Say
task1 takes 5-7mS, task 2 will begin to execute 5-7mS+ a little after the
interrupt was hit so it's execution may vary from 0-7mS from the initial
interrupt.
This is unavoidable since you only have a single core processor. You can
increase accuracy of the start of your routines by multi-tasking, but then
you run into the problems of unpredictable execution rates of routines, and
the added overhead of task switching.
Look at some RTOS's out there for more info on this subject, I doubt they
use more than 2 times for handling many tasks at a time.
-Mark W
_____
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf Of
Amr M. Adel
Sent: Wednesday, May 18, 2005 4:27 AM
To: 68HC12@68HC...
Subject: [68HC12] How to use HC12's ECT as a general purpose Timer?
Hi all,
I am a new member in this group. I hope to gain new knowledge and
share my konwledge with you.
I need to implement a general purpose timer on HC12 microcontroller
and as U know it is not provided in HC12. ECT, Enhanced Capture
Timer, is the only thing that can be used for this purpose.
I have an idea to use ECT as a General Purpose Timer. This can be
achieved by changing the value of the comparator of a channel each
time a it finishs its period. The main disadvantage of this technique
is that periods may be irrigular because of the adjustement of the
comparator is depending on ISR which may ba masked or delayed!
Any Suggestion or documentation describing how to achieve this?
Thanx for your interest,
Amr
_____
> Terms of Service.
Reply by ●May 18, 20052005-05-18
Amr,
It sounds like you aren't using the same interrupt-masking assumptions for
the "general-purpose" and ECT timer cases. I think that if you
carefully use the same assumptions in both cases, you'll find they fail
in similar ways.
The case that could cause the HC12 timer to keep bad time is if interrupts
are masked for longer than one timer interval. That exact case would
cause the "general-purpose" timer to drop an interrupt. In other words,
if interrupts are masked too long, both kinds of timer break.
The solution is simple: Don't mask interrupts for so long! It doesn't
matter what kind of timer you have. Dropped interrupts are bad.
(...but further down in this message, I'll show you how to use the ECT
to handle lost interrupts better than a "general-purpose" timer can.)
When using the ECT, do the updates as suggested earlier in this thread:
TCx = TCx + interval
The effects of interrupt masking on this technique is *exactly* the same
as on the "general-purpose" timer. Suppose, for example, you needed an
interval of 1000 timer counts, you're using TC1. To keep things simple,
let's assume that TCNT is 50. To start the interrupt, your code does
the following:
TC1 = TCNT + 1000;
Now TC1 is 1050. At TCNT == 1050, an interrupt is generated, but
suppose interrupts are masked for the moment, so TCNT == 1075 when the
TC1 interrupt handler is called.
One of the first things the interrupt handler should do is to increment
TC1:
TC1 = TC1 + 1000;
Now TC1 is 2050. The time is at TCNT == 1075 by now, so the next
interrupt will be 975 counts later. That's right on time, at 2050,
which is exactly 1000 counts after when this interrupt was generated.
That's the behavior you wanted from the general-purpose timer. Generate
an interrupt exactly once every 1000 counts. Thus, the two approaches
to a timer are equivalent.
Now, the only time this will break down is if interrupt masking causes
the TC1 interrupt handler to be called more than 1000 ticks late.
That's the same case that would cause your general-purpose timer to lose
an interrupt. Thus, it's a bad situation with either kind of timer.
It is best to code so that it can't happen.
However, as we all know, bugs happen. If your application is one where
you could "catch up" from lost timer ticks, and if your desired interval
is less than 32768 timer counts (use the prescaler), here's the solution.
Write the interrupt handler like this:
...
while ((int)(TCNT - TC1) > 0) {
TC1 = TC1 + 1000;
/* Process the timer tick here */
}
...
The while loop works out just how far we are behind, if at all.
It iterates once for every cycle that otherwise would have been dropped.
The reason for the subtraction and cast to int is to handle cases where
the timer has wrapped around. For example, a simple (TCNT > TC1) won't
work as intended when TCNT == $0000 and TC1 == $FFFF.
If "catching up" isn't right, but your system needs to know when
interrupts might have been dropped, do the same loop, but simply tally
the lost time:
int count = 0;
while ((int)(TCNT - TC1) > 0) {
TC1 = TC1 + 1000;
count++
}
/*
* Process the timer tick here.
* "count" holds the number of ticks to process.
*/
This approach is good if the code needs to know that interrupts were
handled late, but shouldn't "catch up" from late interrupts by iterating.
If nothing else, it permits the code to log the late interrupts to help
you debug the error.
Both of these solutions push out the threshold of dropped timer interrupts
to ~65535 counts. If you use the prescaler appropriately, that can be a
long time. It's certainly longer than the one-timer-interval threshold
of a "general-purpose" timer.
I use one or the other of these techniques whenever I can, even if
I don't expect dropped interrupts. The small cost of an extra while
statement adds a lot of robustness to my code.
It took me a while to accept that the HC12 STM and ECT were equivalent
to older-style timers with a seperate counters per channel, but now I'm
a big fan. The HC12 timers are versatile and capable of amazing tricks.
They may well be superior to the older kind.
Stephen
--
Stephen Trier
Technical Development Lab
Cleveland FES Center
sct@sct@...
It sounds like you aren't using the same interrupt-masking assumptions for
the "general-purpose" and ECT timer cases. I think that if you
carefully use the same assumptions in both cases, you'll find they fail
in similar ways.
The case that could cause the HC12 timer to keep bad time is if interrupts
are masked for longer than one timer interval. That exact case would
cause the "general-purpose" timer to drop an interrupt. In other words,
if interrupts are masked too long, both kinds of timer break.
The solution is simple: Don't mask interrupts for so long! It doesn't
matter what kind of timer you have. Dropped interrupts are bad.
(...but further down in this message, I'll show you how to use the ECT
to handle lost interrupts better than a "general-purpose" timer can.)
When using the ECT, do the updates as suggested earlier in this thread:
TCx = TCx + interval
The effects of interrupt masking on this technique is *exactly* the same
as on the "general-purpose" timer. Suppose, for example, you needed an
interval of 1000 timer counts, you're using TC1. To keep things simple,
let's assume that TCNT is 50. To start the interrupt, your code does
the following:
TC1 = TCNT + 1000;
Now TC1 is 1050. At TCNT == 1050, an interrupt is generated, but
suppose interrupts are masked for the moment, so TCNT == 1075 when the
TC1 interrupt handler is called.
One of the first things the interrupt handler should do is to increment
TC1:
TC1 = TC1 + 1000;
Now TC1 is 2050. The time is at TCNT == 1075 by now, so the next
interrupt will be 975 counts later. That's right on time, at 2050,
which is exactly 1000 counts after when this interrupt was generated.
That's the behavior you wanted from the general-purpose timer. Generate
an interrupt exactly once every 1000 counts. Thus, the two approaches
to a timer are equivalent.
Now, the only time this will break down is if interrupt masking causes
the TC1 interrupt handler to be called more than 1000 ticks late.
That's the same case that would cause your general-purpose timer to lose
an interrupt. Thus, it's a bad situation with either kind of timer.
It is best to code so that it can't happen.
However, as we all know, bugs happen. If your application is one where
you could "catch up" from lost timer ticks, and if your desired interval
is less than 32768 timer counts (use the prescaler), here's the solution.
Write the interrupt handler like this:
...
while ((int)(TCNT - TC1) > 0) {
TC1 = TC1 + 1000;
/* Process the timer tick here */
}
...
The while loop works out just how far we are behind, if at all.
It iterates once for every cycle that otherwise would have been dropped.
The reason for the subtraction and cast to int is to handle cases where
the timer has wrapped around. For example, a simple (TCNT > TC1) won't
work as intended when TCNT == $0000 and TC1 == $FFFF.
If "catching up" isn't right, but your system needs to know when
interrupts might have been dropped, do the same loop, but simply tally
the lost time:
int count = 0;
while ((int)(TCNT - TC1) > 0) {
TC1 = TC1 + 1000;
count++
}
/*
* Process the timer tick here.
* "count" holds the number of ticks to process.
*/
This approach is good if the code needs to know that interrupts were
handled late, but shouldn't "catch up" from late interrupts by iterating.
If nothing else, it permits the code to log the late interrupts to help
you debug the error.
Both of these solutions push out the threshold of dropped timer interrupts
to ~65535 counts. If you use the prescaler appropriately, that can be a
long time. It's certainly longer than the one-timer-interval threshold
of a "general-purpose" timer.
I use one or the other of these techniques whenever I can, even if
I don't expect dropped interrupts. The small cost of an extra while
statement adds a lot of robustness to my code.
It took me a while to accept that the HC12 STM and ECT were equivalent
to older-style timers with a seperate counters per channel, but now I'm
a big fan. The HC12 timers are versatile and capable of amazing tricks.
They may well be superior to the older kind.
Stephen
--
Stephen Trier
Technical Development Lab
Cleveland FES Center
sct@sct@...
Reply by ●May 22, 20052005-05-22
--- In 68HC12@68HC..., "Salvador Tenorio"
<salvador_tenorio@y...> wrote:
> You can use the free running counter as your "tick" generator and
> configure it to suit your needs (lets say to roll over every 1ms).
> When the timer expires have it generate an interrupt.
>
> You can use this interrupt to drive a pretty nice timer task with
as
> many timers as you wish. If you need long (lets say 500 ms) and
> short timers (1ms) you can set two timer channels in the HCS12 to
> suit the tick requirements so you don't have to keep globals in
your
> ISR's.
>
> I have used this method successfully to create a pool of timers,
> both long and short. How many of these you will be able to create
> will depend on how much ram you are willing to reserve for this
> purpose. I have set my pools for 10 timers each, so I have a total
> of 20 timers which consume less tan a couple 100 bytes (don't
recall
> the exact numbers cause I don't have the code here).
>
> If you need HL code examples for the task in C (including examples
> of what to do when the interrupt arrives), I can send you
something,
> just let me know.
>
> Sal.
Sal,
Sorry for the late reply. I will be so grateful if U send me some
resources regarding this issue.
Thanx alot,
Amr
>
> --- In 68HC12@68HC..., "Amr M. Adel" <amradel_79@h...>
wrote:
> > Hi all,
> > I am a new member in this group. I hope to gain new knowledge and
> > share my konwledge with you.
> >
> > I need to implement a general purpose timer on HC12
microcontroller
> > and as U know it is not provided in HC12. ECT, Enhanced Capture
> > Timer, is the only thing that can be used for this purpose.
> >
> > I have an idea to use ECT as a General Purpose Timer. This can be
> > achieved by changing the value of the comparator of a channel each
> > time a it finishs its period. The main disadvantage of this
> technique
> > is that periods may be irrigular because of the adjustement of the
> > comparator is depending on ISR which may ba masked or delayed!
> >
> > Any Suggestion or documentation describing how to achieve this?
> >
> > Thanx for your interest,
> > Amr
<salvador_tenorio@y...> wrote:
> You can use the free running counter as your "tick" generator and
> configure it to suit your needs (lets say to roll over every 1ms).
> When the timer expires have it generate an interrupt.
>
> You can use this interrupt to drive a pretty nice timer task with
as
> many timers as you wish. If you need long (lets say 500 ms) and
> short timers (1ms) you can set two timer channels in the HCS12 to
> suit the tick requirements so you don't have to keep globals in
your
> ISR's.
>
> I have used this method successfully to create a pool of timers,
> both long and short. How many of these you will be able to create
> will depend on how much ram you are willing to reserve for this
> purpose. I have set my pools for 10 timers each, so I have a total
> of 20 timers which consume less tan a couple 100 bytes (don't
recall
> the exact numbers cause I don't have the code here).
>
> If you need HL code examples for the task in C (including examples
> of what to do when the interrupt arrives), I can send you
something,
> just let me know.
>
> Sal.
Sal,
Sorry for the late reply. I will be so grateful if U send me some
resources regarding this issue.
Thanx alot,
Amr
>
> --- In 68HC12@68HC..., "Amr M. Adel" <amradel_79@h...>
wrote:
> > Hi all,
> > I am a new member in this group. I hope to gain new knowledge and
> > share my konwledge with you.
> >
> > I need to implement a general purpose timer on HC12
microcontroller
> > and as U know it is not provided in HC12. ECT, Enhanced Capture
> > Timer, is the only thing that can be used for this purpose.
> >
> > I have an idea to use ECT as a General Purpose Timer. This can be
> > achieved by changing the value of the comparator of a channel each
> > time a it finishs its period. The main disadvantage of this
> technique
> > is that periods may be irrigular because of the adjustement of the
> > comparator is depending on ISR which may ba masked or delayed!
> >
> > Any Suggestion or documentation describing how to achieve this?
> >
> > Thanx for your interest,
> > Amr
Reply by ●May 22, 20052005-05-22
Stephen,
I am so sorry for the late reply. I didn't have an access to the net
in the previous days. I appreciate your detailed reply. I may need
some time to study the reply and I will tell you what I found.
Thanx,
Amr
--- In 68HC12@68HC..., "Stephen Trier" <sct@p...> wrote:
> Amr,
>
> It sounds like you aren't using the same interrupt-masking
assumptions for
> the "general-purpose" and ECT timer cases. I think that if you
> carefully use the same assumptions in both cases, you'll find they
fail
> in similar ways.
>
> The case that could cause the HC12 timer to keep bad time is if
interrupts
> are masked for longer than one timer interval. That exact case
would
> cause the "general-purpose" timer to drop an interrupt. In other
words,
> if interrupts are masked too long, both kinds of timer break.
>
> The solution is simple: Don't mask interrupts for so long! It
doesn't
> matter what kind of timer you have. Dropped interrupts are bad.
> (...but further down in this message, I'll show you how to use the
ECT
> to handle lost interrupts better than a "general-purpose" timer
can.)
>
> When using the ECT, do the updates as suggested earlier in this
thread:
>
> TCx = TCx + interval
>
> The effects of interrupt masking on this technique is *exactly* the
same
> as on the "general-purpose" timer. Suppose, for example, you
needed an
> interval of 1000 timer counts, you're using TC1. To keep things
simple,
> let's assume that TCNT is 50. To start the interrupt, your code
does
> the following:
>
> TC1 = TCNT + 1000;
>
> Now TC1 is 1050. At TCNT == 1050, an interrupt is generated, but
> suppose interrupts are masked for the moment, so TCNT == 1075 when
the
> TC1 interrupt handler is called.
>
> One of the first things the interrupt handler should do is to
increment
> TC1:
>
> TC1 = TC1 + 1000;
>
> Now TC1 is 2050. The time is at TCNT == 1075 by now, so the next
> interrupt will be 975 counts later. That's right on time, at 2050,
> which is exactly 1000 counts after when this interrupt was
generated.
> That's the behavior you wanted from the general-purpose timer.
Generate
> an interrupt exactly once every 1000 counts. Thus, the two
approaches
> to a timer are equivalent.
>
> Now, the only time this will break down is if interrupt masking
causes
> the TC1 interrupt handler to be called more than 1000 ticks late.
> That's the same case that would cause your general-purpose timer to
lose
> an interrupt. Thus, it's a bad situation with either kind of timer.
> It is best to code so that it can't happen.
>
> However, as we all know, bugs happen. If your application is one
where
> you could "catch up" from lost timer ticks, and if your desired
interval
> is less than 32768 timer counts (use the prescaler), here's the
solution.
> Write the interrupt handler like this:
>
> ...
>
> while ((int)(TCNT - TC1) > 0) {
> TC1 = TC1 + 1000;
>
> /* Process the timer tick here */
> }
>
> ...
>
> The while loop works out just how far we are behind, if at all.
> It iterates once for every cycle that otherwise would have been
dropped.
> The reason for the subtraction and cast to int is to handle cases
where
> the timer has wrapped around. For example, a simple (TCNT > TC1)
won't
> work as intended when TCNT == $0000 and TC1 == $FFFF.
>
> If "catching up" isn't right, but your system needs to know when
> interrupts might have been dropped, do the same loop, but simply
tally
> the lost time:
>
> int count = 0;
>
> while ((int)(TCNT - TC1) > 0) {
> TC1 = TC1 + 1000;
> count++
> }
>
> /*
> * Process the timer tick here.
> * "count" holds the number of ticks to process.
> */
>
> This approach is good if the code needs to know that interrupts were
> handled late, but shouldn't "catch up" from late interrupts by
iterating.
> If nothing else, it permits the code to log the late interrupts to
help
> you debug the error.
>
> Both of these solutions push out the threshold of dropped timer
interrupts
> to ~65535 counts. If you use the prescaler appropriately, that can
be a
> long time. It's certainly longer than the one-timer-interval
threshold
> of a "general-purpose" timer.
>
> I use one or the other of these techniques whenever I can, even if
> I don't expect dropped interrupts. The small cost of an extra while
> statement adds a lot of robustness to my code.
>
> It took me a while to accept that the HC12 STM and ECT were
equivalent
> to older-style timers with a seperate counters per channel, but now
I'm
> a big fan. The HC12 timers are versatile and capable of amazing
tricks.
> They may well be superior to the older kind.
>
> Stephen
>
> --
> Stephen Trier
> Technical Development Lab
> Cleveland FES Center
> sct@p...
I am so sorry for the late reply. I didn't have an access to the net
in the previous days. I appreciate your detailed reply. I may need
some time to study the reply and I will tell you what I found.
Thanx,
Amr
--- In 68HC12@68HC..., "Stephen Trier" <sct@p...> wrote:
> Amr,
>
> It sounds like you aren't using the same interrupt-masking
assumptions for
> the "general-purpose" and ECT timer cases. I think that if you
> carefully use the same assumptions in both cases, you'll find they
fail
> in similar ways.
>
> The case that could cause the HC12 timer to keep bad time is if
interrupts
> are masked for longer than one timer interval. That exact case
would
> cause the "general-purpose" timer to drop an interrupt. In other
words,
> if interrupts are masked too long, both kinds of timer break.
>
> The solution is simple: Don't mask interrupts for so long! It
doesn't
> matter what kind of timer you have. Dropped interrupts are bad.
> (...but further down in this message, I'll show you how to use the
ECT
> to handle lost interrupts better than a "general-purpose" timer
can.)
>
> When using the ECT, do the updates as suggested earlier in this
thread:
>
> TCx = TCx + interval
>
> The effects of interrupt masking on this technique is *exactly* the
same
> as on the "general-purpose" timer. Suppose, for example, you
needed an
> interval of 1000 timer counts, you're using TC1. To keep things
simple,
> let's assume that TCNT is 50. To start the interrupt, your code
does
> the following:
>
> TC1 = TCNT + 1000;
>
> Now TC1 is 1050. At TCNT == 1050, an interrupt is generated, but
> suppose interrupts are masked for the moment, so TCNT == 1075 when
the
> TC1 interrupt handler is called.
>
> One of the first things the interrupt handler should do is to
increment
> TC1:
>
> TC1 = TC1 + 1000;
>
> Now TC1 is 2050. The time is at TCNT == 1075 by now, so the next
> interrupt will be 975 counts later. That's right on time, at 2050,
> which is exactly 1000 counts after when this interrupt was
generated.
> That's the behavior you wanted from the general-purpose timer.
Generate
> an interrupt exactly once every 1000 counts. Thus, the two
approaches
> to a timer are equivalent.
>
> Now, the only time this will break down is if interrupt masking
causes
> the TC1 interrupt handler to be called more than 1000 ticks late.
> That's the same case that would cause your general-purpose timer to
lose
> an interrupt. Thus, it's a bad situation with either kind of timer.
> It is best to code so that it can't happen.
>
> However, as we all know, bugs happen. If your application is one
where
> you could "catch up" from lost timer ticks, and if your desired
interval
> is less than 32768 timer counts (use the prescaler), here's the
solution.
> Write the interrupt handler like this:
>
> ...
>
> while ((int)(TCNT - TC1) > 0) {
> TC1 = TC1 + 1000;
>
> /* Process the timer tick here */
> }
>
> ...
>
> The while loop works out just how far we are behind, if at all.
> It iterates once for every cycle that otherwise would have been
dropped.
> The reason for the subtraction and cast to int is to handle cases
where
> the timer has wrapped around. For example, a simple (TCNT > TC1)
won't
> work as intended when TCNT == $0000 and TC1 == $FFFF.
>
> If "catching up" isn't right, but your system needs to know when
> interrupts might have been dropped, do the same loop, but simply
tally
> the lost time:
>
> int count = 0;
>
> while ((int)(TCNT - TC1) > 0) {
> TC1 = TC1 + 1000;
> count++
> }
>
> /*
> * Process the timer tick here.
> * "count" holds the number of ticks to process.
> */
>
> This approach is good if the code needs to know that interrupts were
> handled late, but shouldn't "catch up" from late interrupts by
iterating.
> If nothing else, it permits the code to log the late interrupts to
help
> you debug the error.
>
> Both of these solutions push out the threshold of dropped timer
interrupts
> to ~65535 counts. If you use the prescaler appropriately, that can
be a
> long time. It's certainly longer than the one-timer-interval
threshold
> of a "general-purpose" timer.
>
> I use one or the other of these techniques whenever I can, even if
> I don't expect dropped interrupts. The small cost of an extra while
> statement adds a lot of robustness to my code.
>
> It took me a while to accept that the HC12 STM and ECT were
equivalent
> to older-style timers with a seperate counters per channel, but now
I'm
> a big fan. The HC12 timers are versatile and capable of amazing
tricks.
> They may well be superior to the older kind.
>
> Stephen
>
> --
> Stephen Trier
> Technical Development Lab
> Cleveland FES Center
> sct@p...
Reply by ●May 22, 20052005-05-22
Mark and Robmilne,
sorry for the late response. I didn't have an access to the net in
the prev. days. I will study your replies and will send U my feedback.
Thanx,
Amr
--- In 68HC12@68HC..., "Mark Wyman" <mark@r...> wrote:
> Ok, I am going to take a leap here based on the other postings: >
> Set up an accurate single timer interrupt, at your least common
denominator
> of time slices, say 10mS. Make sure it is nice and jitterless by
testing an
> I/O pin. >
> Then in the interrupt, handle several count-down to zero counters: >
> __interrupt void timerInterrupt(void) { >
> //Update timer registers here >
> critical10mSTask(); //The least
common
> denominator task that must be executed accurately and constantly >
> if (countdown1) countdown1--;
>
> if (countdown2) countdown2--;
>
> if (countdown3) countdown3--; >
> //clear mask
>
> } >
> In your main routine: >
> While (TRUE) {
>
> If(!countdown1) {
>
> countdown1 = 1000; //Value for next
execution
> x interrupt rate, in this case 1000 x 10mS
>
> ExecuteTask1();
>
> }
>
> If(!countdown2) {
>
> dountdown2 = 5000; //Value for next
execution
> x interrupt rate
>
> ExecuteTask2();
>
> }
>
> } >
> While the above example doesn't guarantee that tasks execute at
just the
> right time if any task takes longer than your minimum time, they
will always
> execute, but is great for non-critical timing of tasks since it is
very easy
> to manage. >
> If you need better time accuracy, execute tasks right in the
interrupt:
> __interrupt void timerInterrupt(void) { >
> //Update timer registers here
>
> critical10mSTask(); //The least
common
> denominator task that must be executed accurately >
> if (countdown1) countdown1--; //Decrement all
individual
> timers first
>
> if (countdown2) countdown2--;
>
> if (countdown3) countdown3--; >
> if (!countdown1) { //Execute all
tasks
> that have hit zero.
>
> countdown1 = 1000;
>
> executeTask1();
>
> } >
> if (!countdown2) {
>
> countDown2 = 5000;
>
> executeTask2();
>
> } > //clear mask
>
> }
>
> However again the sun all of your tasks must execute faster than
the minimum
> time, in this case 10mS, or else you will get a cascade timing
error.
> Otherwise make sure and stagger the timers so only one task may
execute in
> any given interrupt hit. >
> While this is very simplistic, it shows there are many ways to
tackle
> multiple timers with a single timer interrupt. >
> Some of the drawbacks are that executeTask1() has highest priority
and it's
> execution time will impact when executeTask2() will be able to
execute. Say
> task1 takes 5-7mS, task 2 will begin to execute 5-7mS+ a little
after the
> interrupt was hit so it's execution may vary from 0-7mS from the
initial
> interrupt. >
> This is unavoidable since you only have a single core processor.
You can
> increase accuracy of the start of your routines by multi-tasking,
but then
> you run into the problems of unpredictable execution rates of
routines, and
> the added overhead of task switching. >
> Look at some RTOS's out there for more info on this subject, I
doubt they
> use more than 2 times for handling many tasks at a time. >
> -Mark W >
> _____
>
> From: 68HC12@68HC... [mailto:68HC12@68HC...] On
Behalf Of
> Amr M. Adel
> Sent: Wednesday, May 18, 2005 4:27 AM
> To: 68HC12@68HC...
> Subject: [68HC12] How to use HC12's ECT as a general purpose Timer? >
> Hi all,
> I am a new member in this group. I hope to gain new knowledge and
> share my konwledge with you.
>
> I need to implement a general purpose timer on HC12 microcontroller
> and as U know it is not provided in HC12. ECT, Enhanced Capture
> Timer, is the only thing that can be used for this purpose.
>
> I have an idea to use ECT as a General Purpose Timer. This can be
> achieved by changing the value of the comparator of a channel each
> time a it finishs its period. The main disadvantage of this
technique
> is that periods may be irrigular because of the adjustement of the
> comparator is depending on ISR which may ba masked or delayed!
>
> Any Suggestion or documentation describing how to achieve this?
>
> Thanx for your interest,
> Amr >
> _____
>
> > Terms of Service. >
>
sorry for the late response. I didn't have an access to the net in
the prev. days. I will study your replies and will send U my feedback.
Thanx,
Amr
--- In 68HC12@68HC..., "Mark Wyman" <mark@r...> wrote:
> Ok, I am going to take a leap here based on the other postings: >
> Set up an accurate single timer interrupt, at your least common
denominator
> of time slices, say 10mS. Make sure it is nice and jitterless by
testing an
> I/O pin. >
> Then in the interrupt, handle several count-down to zero counters: >
> __interrupt void timerInterrupt(void) { >
> //Update timer registers here >
> critical10mSTask(); //The least
common
> denominator task that must be executed accurately and constantly >
> if (countdown1) countdown1--;
>
> if (countdown2) countdown2--;
>
> if (countdown3) countdown3--; >
> //clear mask
>
> } >
> In your main routine: >
> While (TRUE) {
>
> If(!countdown1) {
>
> countdown1 = 1000; //Value for next
execution
> x interrupt rate, in this case 1000 x 10mS
>
> ExecuteTask1();
>
> }
>
> If(!countdown2) {
>
> dountdown2 = 5000; //Value for next
execution
> x interrupt rate
>
> ExecuteTask2();
>
> }
>
> } >
> While the above example doesn't guarantee that tasks execute at
just the
> right time if any task takes longer than your minimum time, they
will always
> execute, but is great for non-critical timing of tasks since it is
very easy
> to manage. >
> If you need better time accuracy, execute tasks right in the
interrupt:
> __interrupt void timerInterrupt(void) { >
> //Update timer registers here
>
> critical10mSTask(); //The least
common
> denominator task that must be executed accurately >
> if (countdown1) countdown1--; //Decrement all
individual
> timers first
>
> if (countdown2) countdown2--;
>
> if (countdown3) countdown3--; >
> if (!countdown1) { //Execute all
tasks
> that have hit zero.
>
> countdown1 = 1000;
>
> executeTask1();
>
> } >
> if (!countdown2) {
>
> countDown2 = 5000;
>
> executeTask2();
>
> } > //clear mask
>
> }
>
> However again the sun all of your tasks must execute faster than
the minimum
> time, in this case 10mS, or else you will get a cascade timing
error.
> Otherwise make sure and stagger the timers so only one task may
execute in
> any given interrupt hit. >
> While this is very simplistic, it shows there are many ways to
tackle
> multiple timers with a single timer interrupt. >
> Some of the drawbacks are that executeTask1() has highest priority
and it's
> execution time will impact when executeTask2() will be able to
execute. Say
> task1 takes 5-7mS, task 2 will begin to execute 5-7mS+ a little
after the
> interrupt was hit so it's execution may vary from 0-7mS from the
initial
> interrupt. >
> This is unavoidable since you only have a single core processor.
You can
> increase accuracy of the start of your routines by multi-tasking,
but then
> you run into the problems of unpredictable execution rates of
routines, and
> the added overhead of task switching. >
> Look at some RTOS's out there for more info on this subject, I
doubt they
> use more than 2 times for handling many tasks at a time. >
> -Mark W >
> _____
>
> From: 68HC12@68HC... [mailto:68HC12@68HC...] On
Behalf Of
> Amr M. Adel
> Sent: Wednesday, May 18, 2005 4:27 AM
> To: 68HC12@68HC...
> Subject: [68HC12] How to use HC12's ECT as a general purpose Timer? >
> Hi all,
> I am a new member in this group. I hope to gain new knowledge and
> share my konwledge with you.
>
> I need to implement a general purpose timer on HC12 microcontroller
> and as U know it is not provided in HC12. ECT, Enhanced Capture
> Timer, is the only thing that can be used for this purpose.
>
> I have an idea to use ECT as a General Purpose Timer. This can be
> achieved by changing the value of the comparator of a channel each
> time a it finishs its period. The main disadvantage of this
technique
> is that periods may be irrigular because of the adjustement of the
> comparator is depending on ISR which may ba masked or delayed!
>
> Any Suggestion or documentation describing how to achieve this?
>
> Thanx for your interest,
> Amr >
> _____
>
> > Terms of Service. >
>
Reply by ●May 23, 20052005-05-23
Hi Stephen,
First of all, I'd like to thank you for your detailed explanation.
I understand all what you mentioned in your email however I will be
grateful if you tell me about the advantages of using ECT.
The Only problem I face in using ECT is that I have to adjust the
period by software, in continuous mode, which is done automatically
by hardware in some General Purpose Timers in other controllers.
Thanx,
Amr
--- In 68HC12@68HC..., "Stephen Trier" <sct@p...> wrote:
> Amr,
>
> It sounds like you aren't using the same interrupt-masking
assumptions for
> the "general-purpose" and ECT timer cases. I think that if you
> carefully use the same assumptions in both cases, you'll find they
fail
> in similar ways.
>
> The case that could cause the HC12 timer to keep bad time is if
interrupts
> are masked for longer than one timer interval. That exact case
would
> cause the "general-purpose" timer to drop an interrupt. In other
words,
> if interrupts are masked too long, both kinds of timer break.
>
> The solution is simple: Don't mask interrupts for so long! It
doesn't
> matter what kind of timer you have. Dropped interrupts are bad.
> (...but further down in this message, I'll show you how to use the
ECT
> to handle lost interrupts better than a "general-purpose" timer
can.)
>
> When using the ECT, do the updates as suggested earlier in this
thread:
>
> TCx = TCx + interval
>
> The effects of interrupt masking on this technique is *exactly* the
same
> as on the "general-purpose" timer. Suppose, for example, you
needed an
> interval of 1000 timer counts, you're using TC1. To keep things
simple,
> let's assume that TCNT is 50. To start the interrupt, your code
does
> the following:
>
> TC1 = TCNT + 1000;
>
> Now TC1 is 1050. At TCNT == 1050, an interrupt is generated, but
> suppose interrupts are masked for the moment, so TCNT == 1075 when
the
> TC1 interrupt handler is called.
>
> One of the first things the interrupt handler should do is to
increment
> TC1:
>
> TC1 = TC1 + 1000;
>
> Now TC1 is 2050. The time is at TCNT == 1075 by now, so the next
> interrupt will be 975 counts later. That's right on time, at 2050,
> which is exactly 1000 counts after when this interrupt was
generated.
> That's the behavior you wanted from the general-purpose timer.
Generate
> an interrupt exactly once every 1000 counts. Thus, the two
approaches
> to a timer are equivalent.
>
> Now, the only time this will break down is if interrupt masking
causes
> the TC1 interrupt handler to be called more than 1000 ticks late.
> That's the same case that would cause your general-purpose timer to
lose
> an interrupt. Thus, it's a bad situation with either kind of timer.
> It is best to code so that it can't happen.
>
> However, as we all know, bugs happen. If your application is one
where
> you could "catch up" from lost timer ticks, and if your desired
interval
> is less than 32768 timer counts (use the prescaler), here's the
solution.
> Write the interrupt handler like this:
>
> ...
>
> while ((int)(TCNT - TC1) > 0) {
> TC1 = TC1 + 1000;
>
> /* Process the timer tick here */
> }
>
> ...
>
> The while loop works out just how far we are behind, if at all.
> It iterates once for every cycle that otherwise would have been
dropped.
> The reason for the subtraction and cast to int is to handle cases
where
> the timer has wrapped around. For example, a simple (TCNT > TC1)
won't
> work as intended when TCNT == $0000 and TC1 == $FFFF.
>
> If "catching up" isn't right, but your system needs to know when
> interrupts might have been dropped, do the same loop, but simply
tally
> the lost time:
>
> int count = 0;
>
> while ((int)(TCNT - TC1) > 0) {
> TC1 = TC1 + 1000;
> count++
> }
>
> /*
> * Process the timer tick here.
> * "count" holds the number of ticks to process.
> */
>
> This approach is good if the code needs to know that interrupts were
> handled late, but shouldn't "catch up" from late interrupts by
iterating.
> If nothing else, it permits the code to log the late interrupts to
help
> you debug the error.
>
> Both of these solutions push out the threshold of dropped timer
interrupts
> to ~65535 counts. If you use the prescaler appropriately, that can
be a
> long time. It's certainly longer than the one-timer-interval
threshold
> of a "general-purpose" timer.
>
> I use one or the other of these techniques whenever I can, even if
> I don't expect dropped interrupts. The small cost of an extra while
> statement adds a lot of robustness to my code.
>
> It took me a while to accept that the HC12 STM and ECT were
equivalent
> to older-style timers with a seperate counters per channel, but now
I'm
> a big fan. The HC12 timers are versatile and capable of amazing
tricks.
> They may well be superior to the older kind.
>
> Stephen
>
> --
> Stephen Trier
> Technical Development Lab
> Cleveland FES Center
> sct@p...
First of all, I'd like to thank you for your detailed explanation.
I understand all what you mentioned in your email however I will be
grateful if you tell me about the advantages of using ECT.
The Only problem I face in using ECT is that I have to adjust the
period by software, in continuous mode, which is done automatically
by hardware in some General Purpose Timers in other controllers.
Thanx,
Amr
--- In 68HC12@68HC..., "Stephen Trier" <sct@p...> wrote:
> Amr,
>
> It sounds like you aren't using the same interrupt-masking
assumptions for
> the "general-purpose" and ECT timer cases. I think that if you
> carefully use the same assumptions in both cases, you'll find they
fail
> in similar ways.
>
> The case that could cause the HC12 timer to keep bad time is if
interrupts
> are masked for longer than one timer interval. That exact case
would
> cause the "general-purpose" timer to drop an interrupt. In other
words,
> if interrupts are masked too long, both kinds of timer break.
>
> The solution is simple: Don't mask interrupts for so long! It
doesn't
> matter what kind of timer you have. Dropped interrupts are bad.
> (...but further down in this message, I'll show you how to use the
ECT
> to handle lost interrupts better than a "general-purpose" timer
can.)
>
> When using the ECT, do the updates as suggested earlier in this
thread:
>
> TCx = TCx + interval
>
> The effects of interrupt masking on this technique is *exactly* the
same
> as on the "general-purpose" timer. Suppose, for example, you
needed an
> interval of 1000 timer counts, you're using TC1. To keep things
simple,
> let's assume that TCNT is 50. To start the interrupt, your code
does
> the following:
>
> TC1 = TCNT + 1000;
>
> Now TC1 is 1050. At TCNT == 1050, an interrupt is generated, but
> suppose interrupts are masked for the moment, so TCNT == 1075 when
the
> TC1 interrupt handler is called.
>
> One of the first things the interrupt handler should do is to
increment
> TC1:
>
> TC1 = TC1 + 1000;
>
> Now TC1 is 2050. The time is at TCNT == 1075 by now, so the next
> interrupt will be 975 counts later. That's right on time, at 2050,
> which is exactly 1000 counts after when this interrupt was
generated.
> That's the behavior you wanted from the general-purpose timer.
Generate
> an interrupt exactly once every 1000 counts. Thus, the two
approaches
> to a timer are equivalent.
>
> Now, the only time this will break down is if interrupt masking
causes
> the TC1 interrupt handler to be called more than 1000 ticks late.
> That's the same case that would cause your general-purpose timer to
lose
> an interrupt. Thus, it's a bad situation with either kind of timer.
> It is best to code so that it can't happen.
>
> However, as we all know, bugs happen. If your application is one
where
> you could "catch up" from lost timer ticks, and if your desired
interval
> is less than 32768 timer counts (use the prescaler), here's the
solution.
> Write the interrupt handler like this:
>
> ...
>
> while ((int)(TCNT - TC1) > 0) {
> TC1 = TC1 + 1000;
>
> /* Process the timer tick here */
> }
>
> ...
>
> The while loop works out just how far we are behind, if at all.
> It iterates once for every cycle that otherwise would have been
dropped.
> The reason for the subtraction and cast to int is to handle cases
where
> the timer has wrapped around. For example, a simple (TCNT > TC1)
won't
> work as intended when TCNT == $0000 and TC1 == $FFFF.
>
> If "catching up" isn't right, but your system needs to know when
> interrupts might have been dropped, do the same loop, but simply
tally
> the lost time:
>
> int count = 0;
>
> while ((int)(TCNT - TC1) > 0) {
> TC1 = TC1 + 1000;
> count++
> }
>
> /*
> * Process the timer tick here.
> * "count" holds the number of ticks to process.
> */
>
> This approach is good if the code needs to know that interrupts were
> handled late, but shouldn't "catch up" from late interrupts by
iterating.
> If nothing else, it permits the code to log the late interrupts to
help
> you debug the error.
>
> Both of these solutions push out the threshold of dropped timer
interrupts
> to ~65535 counts. If you use the prescaler appropriately, that can
be a
> long time. It's certainly longer than the one-timer-interval
threshold
> of a "general-purpose" timer.
>
> I use one or the other of these techniques whenever I can, even if
> I don't expect dropped interrupts. The small cost of an extra while
> statement adds a lot of robustness to my code.
>
> It took me a while to accept that the HC12 STM and ECT were
equivalent
> to older-style timers with a seperate counters per channel, but now
I'm
> a big fan. The HC12 timers are versatile and capable of amazing
tricks.
> They may well be superior to the older kind.
>
> Stephen
>
> --
> Stephen Trier
> Technical Development Lab
> Cleveland FES Center
> sct@p...
Reply by ●May 23, 20052005-05-23
Amr,
Most HCS12 devices are limited in this specific point you ask about with
the ECT (Enhanced Capture Timer):
With the 8 channel ECT, there is a way to adjust the period of the ECT
automatically by hardware, over and over again, using the settings for ECT
Channel 7 only. In this way you shorten the ECT time-out count from 2^16
down to your desired time-out count. This new shorter time-out is then in
effect also for all the rest of the ECT channels 0 - 6. Any different
time-out period for channels 0-6 cannot then be achieved purely in hardware
and must have some software to achieve and manage them after each and every
time-out.
Assuming what you are looking for is ability to generate periodic
interrupts with several different periods, you may have more success with
the following HC12 parts:
1)
The MC9S12E128 has 3 independent timers, each with 4 channels. I belive
each of the 3 independent timers of the S12E128 can be programmed using
Timer-Channel 7 to generate a different user-defined time-out period, for a
total of 3 different and independent time-out periods managed purely by
hardware (after the initial set-up), and automatically reloaded by hardware
over and over again after each time-out.
I believe the MC9S12E128 is now available for general market customers, in
both small and large quantities.
2)
The new MC9S12XDP512 (the S12X family) has a PIT (Periodic Interrupt Timer)
unit, with 4 independent timers that can be programmed to generate 4
different periodic interrupts all handled purely in hardware after the
initial setup.
I believe the S12X devices are now only sampling to large customers (mainly
automotive). They should sample to general market users later on this year.
If you final quantities are large, you may be able to obtain a few S12X
samples now, otherwise, you will need to wait a few months.
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
At 08:05 23/05/2005 +0000, you wrote:
>Hi Stephen,
>First of all, I'd like to thank you for your detailed explanation.
>I understand all what you mentioned in your email however I will be
>grateful if you tell me about the advantages of using ECT.
>
>The Only problem I face in using ECT is that I have to adjust the
>period by software, in continuous mode, which is done automatically
>by hardware in some General Purpose Timers in other controllers.
>
>Thanx,
>Amr
Most HCS12 devices are limited in this specific point you ask about with
the ECT (Enhanced Capture Timer):
With the 8 channel ECT, there is a way to adjust the period of the ECT
automatically by hardware, over and over again, using the settings for ECT
Channel 7 only. In this way you shorten the ECT time-out count from 2^16
down to your desired time-out count. This new shorter time-out is then in
effect also for all the rest of the ECT channels 0 - 6. Any different
time-out period for channels 0-6 cannot then be achieved purely in hardware
and must have some software to achieve and manage them after each and every
time-out.
Assuming what you are looking for is ability to generate periodic
interrupts with several different periods, you may have more success with
the following HC12 parts:
1)
The MC9S12E128 has 3 independent timers, each with 4 channels. I belive
each of the 3 independent timers of the S12E128 can be programmed using
Timer-Channel 7 to generate a different user-defined time-out period, for a
total of 3 different and independent time-out periods managed purely by
hardware (after the initial set-up), and automatically reloaded by hardware
over and over again after each time-out.
I believe the MC9S12E128 is now available for general market customers, in
both small and large quantities.
2)
The new MC9S12XDP512 (the S12X family) has a PIT (Periodic Interrupt Timer)
unit, with 4 independent timers that can be programmed to generate 4
different periodic interrupts all handled purely in hardware after the
initial setup.
I believe the S12X devices are now only sampling to large customers (mainly
automotive). They should sample to general market users later on this year.
If you final quantities are large, you may be able to obtain a few S12X
samples now, otherwise, you will need to wait a few months.
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
At 08:05 23/05/2005 +0000, you wrote:
>Hi Stephen,
>First of all, I'd like to thank you for your detailed explanation.
>I understand all what you mentioned in your email however I will be
>grateful if you tell me about the advantages of using ECT.
>
>The Only problem I face in using ECT is that I have to adjust the
>period by software, in continuous mode, which is done automatically
>by hardware in some General Purpose Timers in other controllers.
>
>Thanx,
>Amr
