Reply by William R. Elliot May 23, 20052005-05-23
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.

Happy S12Xing!
Oliver

Elektronikladen | ELMICRO
http://elmicro.com
------
Yahoo! Groups Links

a.. To


Reply by Oliver Thamm May 23, 20052005-05-23

> 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


Reply by Amr M. Adel May 23, 20052005-05-23
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...