The link in your e-mail works but not from the original post (the one
missing the /en/).
Bill
At 04:32 PM 5/23/2005, you wrote: >Hi Jim,
>
>strange - I just clicked on the link below and it showed up (again).
>In the end, you will land at http://elmicro.com/en/hcs12tb.php but this
>is an automatic redirection....
>
>Anybody else having problems with the original link?
>
>Thanks all!
>Oliver
Reply by William R. Elliot●May 23, 20052005-05-23
I tried it as well (after Jim's message) and found it broken.
Bill
At 04:32 PM 5/23/2005, you wrote: >Hi Jim,
>
>strange - I just clicked on the link below and it showed up (again).
>In the end, you will land at http://elmicro.com/en/hcs12tb.php but this
>is an automatic redirection....
>
>Anybody else having problems with the original link?
>
>Thanks all!
>Oliver
>
Reply by Oliver Thamm●May 23, 20052005-05-23
Hi Jim,
strange - I just clicked on the link below and it showed up (again).
In the end, you will land at http://elmicro.com/en/hcs12tb.php but this
is an automatic redirection....
Anybody else having problems with the original link?
Thanks all!
Oliver
> Oliver,
>
> Broken link!
>
> Jim
> www.freegeeks.net
> ----- Original Message -----
> From: Oliver Thamm
> To: 68HC12@68HC...
> Sent: Monday, May 23, 2005 9:17 PM
> Subject: Re: [68HC12] Re: How to use HC12's ECT as a general purpose
Timer?
>
> > 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.
>
> Elektronikladen offers the S12X T-Board, which is a special version of
> the HCS12 T-Board (see http://elmicro.com/hcs12tb.html) equipped with an
> 9SS12XDP512, and modified oscillator. Available right now - though still
> only in small qty's.
>
> Happy S12Xing!
> Oliver
>
> Elektronikladen | ELMICRO
> http://elmicro.com
>
> ------
> Yahoo! Groups Links
>
> a.. To
> Yahoo! Groups Links
Reply by ●May 23, 20052005-05-23
Oliver,
Broken link!
Jim
www.freegeeks.net
----- Original Message -----
From: Oliver Thamm
To: 68HC12@68HC...
Sent: Monday, May 23, 2005 9:17 PM
Subject: Re: [68HC12] Re: How to use HC12's ECT as a general purpose Timer?
> 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.
Elektronikladen offers the S12X T-Board, which is a special version of
the HCS12 T-Board (see http://elmicro.com/hcs12tb.html) equipped with an
9SS12XDP512, and modified oscillator. Available right now - though still
only in small qty's.
> 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.
Elektronikladen offers the S12X T-Board, which is a special version of
the HCS12 T-Board (see http://elmicro.com/hcs12tb.html) equipped with an
9SS12XDP512, and modified oscillator. Available right now - though still
only in small qty's.
Doron,
It is now clear to me the different alternatives ECT, PIT, etc...
Thank U for clarification,
Amr
--- In 68HC12@68HC..., Doron Fael <doronf@n...> wrote: > 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
>
Reply by Doron Fael●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
Reply by Amr M. Adel●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...
Reply by Amr M. Adel●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.
>
>
Reply by Amr M. Adel●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...