topic Re: THE 9S08 TIMER - HOWTO'S in 8-bit Microcontrollers

THE 9S08 TIMER - HOWTO'S

BooleanBob — Wed, 11 Jun 2008 22:48:53 GMT

Hello friends !

There are some cases in which using the timer gets hard for me. I've been using timers since the 68HC11 times but sometimes trying to make it work in simple tasks, combining two or three interrupts ( Input Capture, PWM Output Compare and Overflow ) all combined, things don't go right and the results are weird.

Please correct me if I'm wrong, but for me the center issue is the way the timer is designed and know the working rules exactly. Generally the problem comes when trying to set an Output Compare value that is different from the previous used value, to generate an interrupt and also to abtain an output signal from the associated timer pin. I would like to know the rules. When can I program a new valid value related to the timer TCNT overflow without missing cycles ? I have read many documents and application notes, including the datasheet for the M9S08QG8 ( in my last application ) and it say little about the timer rules. In older chip manuals such as the MC68HC908 line , there was advice about missing complete ( one or even two full timer cycles ) whenever the value of the output compare was changed before the main counter reached its overflow ( FFFF -> 0000 ).

Some questions here to be more precise in my questions:

1. is it correct ( and "neat" ) to stop and completely reset the timer to ensure a clean, new Output Compare cycle ?
2. can the next Output Compare value be programmed and be effectively valid even if there was no Overflow between these changes ?
3. is it mandatory to center all the operation in the Overflow event to get precise Output Compares without losing cycles or having erratic behaviour ?
4. is there some complete literature about these timer issues that I could read ?

Thank you in advance

Roberto

Re: THE 9S08 TIMER - HOWTO'S

Ake — Thu, 12 Jun 2008 18:23:24 GMT

Hi,

Here are the answers to your questions:

1. The clock inside the timer keeps track of the absolute clock. It should never be reset. It is like the normal clock that cannnot be reset. If you want to wait 2 hours, and it is 1 pm, you can stop waiting at 1 pm + 2 hours = 3 pm. So don't clear the clock unless something tragic occurs.

2. Yes, if you can have an interrupt at 10, 5000, 267, 1240 clock ticks.

Set up the timer for Output Compare rising/fallíng or changing clocks.

3. No, if you are only using the OC interrupt, the changes should be made at this point. If you are using the PWM function, and want to change the PWM frequency, you should do it during the OVFL interrupt.

Note that in the latest 9S08 there are two TPMs available. The V2 and the V3. They are slightly different.

If your PWM is using V2 then change the pulse time and the frequency in the OVFL interrupt, if you are using the V3, use OC interrupt to change the pulse time. The frequency is still done in the OVFL interrupt.

4. There is one old TIM08 book, that was available from Motorola. Don't even look at it. It is full of mistakes.

A better one is HCS08 Unleashed by Fabio Pereira. It is not exhaustive, but what I have seen, seems to be correct.

Regards,

Ake

Re: THE 9S08 TIMER - HOWTO'S

JimDon — Thu, 12 Jun 2008 21:01:06 GMT

There is the "main 16 bit counter" that counts at a certain rate, and all timer operations are based off this counter. This counter can be set to run at a wide range of rates, by the clock prescaler. However, once you have set that rate, you are limited to 16 bits worth of that rate. This counter also has a modulo register that determines when it will reset. Typically, you leave this to over flow at 0XFFFF or free run mode so you have the full 16 bits available.

You do need to set the channels compare register to the value of the main counter register plus your delay:

TPM1C0V = TPM1CNT + MY_DELAY;

If you need a longer delay than 16 bits worth of the period you have set for the main counter, you will have to count overflows, then set the channel compare register for the remainder.
To do this you would enable the overflow interrupt bit, count the overflows, then when the proper number of overflows was reached, set the output compare register for the difference. So if you needed 80,000 ticks, you would count one overflow, then set the output compare to TMP1CNT + 14,465.

In a case like this, would have to either reset the main counter which is done by writing any value to it, or wait until the next over flow before you start the period, otherwise it would be off based on whatever the current count in the main counter was. Note that resetting the main counter may cause other things you are doing with the TPM channel to be off or glitch. If you are doing nothing else with it, then fine. Or you could do the math to figure it out based on the current value of the main counter. In other words, if the current count is n then your overflow would occur at 0xFFFF - n, so you would use the channel interrupt instead of the overflow.

TPM1C0V = 0xFFFF - TPM1CNT; // next relative over flow.

Then set the remainder of your time period after you have counted the correct number of overflows.
In a case like this, you would be best off manually toggling the bit

A note on the register names - some chips have 2 TPM Modules, and the register names will be TMPxCHx as in TMP0CH0 or TMP1CH1 while chips with only one TPM will just use TMPCHx.

Message Edited by JimDon on 2008-06-12 10:04 AM

Re: THE 9S08 TIMER - HOWTO'S

JimDon — Thu, 12 Jun 2008 21:18:59 GMT

PWM Mode

In PWM mode, the 16 bit main counter sets the period of the wave form, and the compare registers set the duty cycle. You really do not need to use an interrupt for PWM mode. In fact that is the real advantage, no over head, the waveform gets generated with no interrupts (for free, time wise).

You can set the modulo register of the main 16 bit main counter to adjust the period of the PWM signal, but this may conflict with timer applications (which is why some chips have 2 TPM modules). The fucntions are only compatible to the extent you can make a single setting of the main 16 bit counter to work with both functions. For me this typically does not work out.

So for example, if you set the main 16 bit counters module register to 0x4000, then you duty cycle counts would range from 0 for 0% duty cycle to 0x4001 or 100% - 0x2000 would give a 50% duty cycle. You can change the compare register (duty cycle) and the output will not glitch, as the are not loaded until the next cycle starts.

Message Edited by JimDon on 2008-06-12 10:21 AM

Re: THE 9S08 TIMER - HOWTO'S

BooleanBob — Sat, 14 Jun 2008 04:37:18 GMT

Thank you very much Ake and Jim.
I will read carefully your return and try to put things all together.
YES I agree that the old book that I used to "learn" about the HC08 timer was full of mistakes and contradictions. In the other hand and from the contents of your posts I beleve that Freescale has changed something ( improved ) this timer version. It was clear to me that it was impossible to get stable outputs when changing output compare values and that the timer could skip one or up to two entire overflows. This concept was taken from that old book.

In my case I need to do the following: Fire a TRIAC with phase angle.

1. Input Capture both rising and falling edges for line zero crossing timing reference on TPMCH0

2. starting from the zero crossing point input capture interrupt service routine, reset the TPMCNT and program to fire the TRIAC by using automatic pin drive of TPMCH1, with PWM edge centered - set output on compare mode, and without stopping the timer at any time. I am using a 16 pin QG8 so pin 7 ( TPMCH1 on PTB5 ) drives the TRIAC gate with suitable circuitry. Here, the TPMMOD register is loaded with the phase angle value and waits until the Overflow interrupt arrives.

3. when the Overflow interrupt comes, the TRIAC has been fired by the output pin and is going to be turned off at the end of the semicycle so I program the Output Compare register TPMC1V with the rest of the time to go until slightly before ( about 1 ms ) the semicycle ends.

4. the next Input Capture interrupt starts all over again.

I tested this and received unstable output. Not having entered in details with your reading yet ( I´ll do it right now ) I don´t see a way to make this application work without stopping the timer. Do you think that I am doing the wrong thing ?

I´ll be back to you with feedback.
Thank you again guys

Roberto

PD: for power reasons and the kind of load, it is very important to drive the TRIAC in this way, I mean all the way down to the next zero crossing point, not just a pulse. It fires after the angle, and keeps the gate fired until the next zero crossing.

Re: THE 9S08 TIMER - HOWTO'S

JimDon — Sat, 14 Jun 2008 05:26:02 GMT

Well, I recommend you do not use the PWM is this way. It is really not designed to do that, and you will have problems.

Here is what I do recommend.

You arrange for an interrupt on both 0 crossings. You could use a KBI for this, perhaps you already have this figured out.
The main 16 bit counter is in free run mode, goes to 0xFFFF.

Here is what you do on the interrupt. You see the output to 0 on the output compare that is driving the triac manually.

The channel is set to "Set output on compare" and you load the channel register with current count plus the delay.

TPMCnV = TPMCNT + on_delay_count;

Done. It goes high after the delay, you clear it on the next zero crossing.

Re: THE 9S08 TIMER - HOWTO'S

bigmac — Sat, 14 Jun 2008 15:13:52 GMT

Hello Roberto,

Yes, it should be possible for your setup to be made to work for triac control. I assume you have one TPM channel set for input capture mode, and the other set for output compare mode (not PWM mode, as one of the other posts implied). The timer should remain free running, without any need to be reset.

Firstly, I would suggest that you should be able to use a short, fixed pulse width to fire the gate of the triac. Therefore, what is required is a short pulse that is delayed by a variable amount, relative to the zero-crossing, as detected by the input capture channel. The maximum variable delay, plus the gate pulse period, must never exceed the period between zero crossings, otherwise instability is possible.

I would suggest that the TPM channel pin be used for the triac trigger, rather than a "software only" interrupt, as this will minimize latency issues. However, some latency issues will remain, and this would be the possible cause of your timing instability.

I would assume that your code would provide the following operational sequence -

At a zero crossing of the mains waveform, you will have an input capture (IC) event, and a short time later, the input capture ISR will commence. This could be further delayed if other interrupts are already in progress, or have higher priority.
Within the IC ISR, you would read the channel register, add to this the required variable delay amount (modulo 16-bit), and write this value to the previously enabled output compare (OC) channel register. There is no need for concern about any overflow in the calculation, provided the delay period does not exceed the TPM overflow period. Assuming positive logic, the channel status and control register should be set to provide a high output on the next OC event (do not use output toggle mode). You might also check that the variable delay amount does not exceed the maximum allowable value, consistent with the timing for the next zero crossing event.
Soon after the OC event occurs (and the OC channel output automatically changes state), the output compare ISR will be entered. Again, this could be delayed for the same reasons given above.
Within the OC ISR, the current channel register value should be increased by the amount of the fixed pulse period, again with modulo addition. The channel status and control register should be set so that the next OC event causes a low output.
Soon after the output goes low, the OC ISR will again be entered. This time the channel register would not be altered (but you might optionally prepare for the next required output state).

This whole sequence would then repeat for the next half cycle.

Now consider the situation where a small variable delay is required. It is possible that the counter register of the TPM could exceed the first OC value, prior to the new value being written to the channel register. This would mean that the next output compare would not occur until the same value is reached during the next TPM cycle.

This may be the cause of the instability that you have observed. It is important to gain some idea of the possible worst case latency, from the time of the input capture event and the processing of the IC ISR, up to the point where the first OC value is written to the channel register. To achieve stability the variable delay must always be greater than this amount.

Regards,

Mac

Message Edited by bigmac on 2008-06-14 06:17 PM

Re: THE 9S08 TIMER - HOWTO'S

bigmac — Sun, 15 Jun 2008 20:24:07 GMT

Hello,

While not related to the triac triggering requirement of the OP, the attached code may also be of interest to readers of this thread.

The project demonstrates a precision gating timer for long gating periods, that makes use of the TPM output compare facility. The output gate signal from the TPM channel is a single pulse that remains active for the specified period.

The code caters for situations where the period may be many times the TPM overflow period (actually up to 65535 times), but the required resolution is one TPM clock cycle. The gate_time parameter is an unsigned long (32-bit) value for the number of TPM clock cycles representing the gate period.

The gate period will consist of a partial TPM overflow period, usually followed by an integral number of whole periods. The code takes into account interrupt latency issues that can occur when the needed partial TPM overflow period is a small number of, or even zero TPM clock cycles.

For cases where other channels of the TPM module might be utilised for PWM operation, the code will automatically cater for modulo settings that are reduced from the default setting, provided the modulo value is not so low that interrupt latency becomes an issue. The maximum allowable gate period would also be reduced proportionally to the modulo value reduction.

If anyone can see potential bugs that I have missed, or have observed other issues, I would welcome any comments.

Regards,

Mac

Message Edited by bigmac on 2008-06-15 11:35 PM

gate_timer4.zip

Message Edited by t.dowe on 2009-10-27 12:18 PM

Re: THE 9S08 TIMER - HOWTO'S

BooleanBob — Mon, 16 Jun 2008 03:28:46 GMT

Dear forum friends:

Thank you very much for your posting and for the different examples, explanations and code ( Mac ) about the timer howto`s. Of course this information opens my mind and makes me think in many ways to use the timer. I would like to point you out that my initial goal ( and probably still is ) to make the timer work with the less amount of software involved by using the automatic pin driving functions offered. YES I could make this work many times by operating the pin manually but it is just that I wanted to climb one more step. Any way, I can live with the manual option too. I believe that preserving the modulo and not stopping the counter is always the best option, because the free running timer could be needed for something else.

I will read your code Mac ... it sound very interesting no matter the TRIAC issue. I will be back to you guys with some experiments done based upon all these kind contributions.

Thank you again
Roberto

Re: THE 9S08 TIMER - HOWTO'S

BooleanBob — Fri, 20 Jun 2008 06:20:51 GMT

Dear friends, it´s me again. Well ... I have made some research on this and this is my first attempt. I works fine but unfortunately I yet couldn´t find the way to leave the main timer running al the time.

Here is the code ... it is just an osciloscope test. I used the MTIM to simulate the 50 Hz mains zero crossing input. This interrupt should be changed to be Input Capture on channel 0 in real life, signal that is taken from the zero crossing detector. Somebody may find the "timer.h" module useful. This is my two pennies. My test runs in a DEMO9S08QG8 board. PTB6 outputs a "line sync" signal and PTB7 is output for the TRIAC.

I will keep on reading and researching, but here is my comment at this point. With all my respect, my conclusion is that this timer has a very important functional consideration regarding the main counter overflow synchronism dependency. There is an extremely important paragraph taken from the MC68HC908AP64 Rev. 3 8/2005 manual @ page 138 9.4.3.1 " Unbuffered Output Compare" , that is also repeated in many other manuals. It was obviously removed from the new chip versions. The text is confusing, but one can understand what it means using a bit of imagination and navigating among the poor, not revised semantics. This explains why this timer - in the way it has been designed - cannot take full advantage of a wide range of applications and other many possibilities. It has been thought just for PWM use. IMHO I would have added a couple of bits in some register to allow some "extras" to sometimes disengage the logic from the overflow event at the moment of reloading the new compare value. Allow me to copy (literally) this small paragraph here, that can be perfectly applied to the QG8 with some imagination and can help somebody else:

"Any output compare channel can generate unbuffered output compare pulses as described in 9.4.3 Output Compare. The pulses are unbuffered because changing the output compare value requires writting the new value over the old value currently in the TIM channel registers. An unsichronized write to the TIM channel registers to change an output compare value could cause incorrect operation of up to two counter overflow periods. For example, writing a new value before the counter reaches the old value but after the counter reaches the new value prevents any compare during that counter overflow period. Also, using a TIM overflow interrupt routine to write a new, smaller output compare value may cause the compare to be missed. The TIM may pass the new value before it is written.

Use the following methods to synchronize unbuffered changes in the output compare value on channel x:

* When changing to a smaller value, enable channel x output compare interrupts and write the new value in the output compare interrupt routine. The output compare occurs at the end of the current output compare pulse. The interrupt routine has until the end of the counter overflow period to write the new value.

* When changing to a larger output compare value, enable TIM overflow interrupts and write the new value in the TIM overflow interrupt routine. The TIM overflow interrupt occurs at the end of the current overflow period. Writing a larger value in an output compare interrupt routine ( at the end of the current pulse ) could cause two output compares to occur in the same counter overflow period."

I don´t mean that correct behaviour cannot be achieved, it is just that it takes a certain amount software overload to analize these exceptions. Some of my questions here are:

1. considering this explanation, what means unsynchronized ? ( I think it is related to the overflow event )
2. what is smaller value /larger value , are these absolute values or they consider the overflow modulo ?

My next step is using the overflow interrupt ( absent in my code example ) to monitor these exceptions and splitting the desired results scenario in 3 phases that must be considered to reload the compare register and avoid stopping the timer.

I apologize for having used so much space and time, and please correct me if I am wrong in any of my thoughts.

Kind regards
Roberto Berner

Triac_test1.zip

Message Edited by t.dowe on 2009-10-27 12:17 PM

Re: THE 9S08 TIMER - HOWTO'S

bigmac — Fri, 20 Jun 2008 15:49:57 GMT

Hello Roberto,

I think I should make a few comments about input capture and output compare operation of the TPM module, where there might possibly be be some confusion.

The IC and OC operates quite independently of overflow, and its associated interrupt, provided the period between capture events, and between compare events is always less than the overflow period. For intermediate periods, up to 10 ms in your case, this can be achieved with suitable setting of the TPM prescaler. The timer overflow interrupt could be disabled or enabled, depending on other requirements of the project.
You cannot exactly simulate input capture operation using the MTIM since the two modules use different counters (so are asynchronous). Input capture mode provides the counter value when the capture event actually occured (a hardware event, and different from the case where the current counter value is read from within the ISR). Using the input capture value will avoid the effects of any (potentially variable) latency in the handling of the interrupt after each event has occurred. Directly reading the current counter value is likely to result in inaccuracy and jitter of the intended firing angle for the triac.
This stability of the trigger waveform is the primary advantage of using input capture over other triggering methods. The only drawback that needs to be considered is that there will be a minimum allowable delay from the zero crossing until the start of the trigger waveform. But this should not be too onorous for your application, when using a relatively fast bus frequency.
If you wish to "simulate" operation without using a zero crossing detector, you will need to alter the input capture channel to operate in output compare mode, using 10 or 8 ms between compare events. You would need to use the current channel reading, as the equivalent of the input capture reading, prior to updating the channel for the next compare event.

The attached project is intended to demonstrate the the input capture/output compare approach. The code is untested, but might represent a starting point for experiment. The project will accommodate variation of mains frequency (the half-period is measured), and allows to stipulate the required conduction angle for the triac.

Regards,

Mac

phase_ctrl6.zip

Message Edited by t.dowe on 2009-10-27 12:16 PM

Re: THE 9S08 TIMER - HOWTO'S

BooleanBob — Fri, 20 Jun 2008 20:40:58 GMT

Hello Mac:

Thank you for your kind reply. Maybe my last posting has been written confusingly, and I have badly expressed what the goal is in my application. I suggest to take a look at my attached code and the Freescale's manual paragraph, which is the simplest working example of what my application exactly needs and cannot ( at this time ) be generated by simply reprogramming the Output Compare register without stopping the timer and without using the Overflow event as a reference. You can see the results using two channels of an osciloscope.

1. The Output Compare ( not the Input Capture ) subsystem is totally dependent of the Overflow event, as is explained in the paragraph taken from the older AP64 manual, and in your own words. I have noticed that the overflow event is in charge of reloading the Output Compare internal register ( not the one you write the value in ), and its contents is transferred on main counter overflow. This is the reason why the Output Compare event can be missed depending on the moment and absolute value loaded in the Output Compare register, in relation to the overflow event. If you keep this value constant, you will never miss a Compare. If the new resultant reload value falls before or after the overflow event, you will have to make calculations because the overflow will reload the next value for the next compare. In resume, you can't use this timer just as a one shot retriggereable monostable Flip Flop to produce output pulses. You can do it but you need to calculate your position every time, and that means extra software and the use of the overflow interrupt. Now that I know this, I will try to find the way to make it work.

2. Generating PWM is an easy task in which you don't need to stop the timer, because usually you don't need to synchronize the PWM signal to any external event, which is not my application's case. PWM generation is simple because the Output Compare value is always loaded in a moment in which the Overflow event has recently occured, so you cannot have conflicts. In my application, an external signal ( mains zero crossing ) is the master event and all the rest comes after this. For my application to work properly, I would need to synchronize the TPMCNT counter Overflow event with the zero crossing event, which is impossible unless you stop the timer and reset the counter on the Input Capture event that I use for the external signal.

3. YES you can use ANY interrupt to simulate the power line zero crossing, if you don't need to fire a real TRIAC by phase shift and you only want to see the complete scene on an osciloscope. This won't work in real life because, as I said before, you need to sync the power line to the timer, but is enough to see how the timer system responds to Output Compare in relation with the Overflow event.

4. The input Capture is very handy to take an instant picture of your counter by hardware to catch the moment in which some event happened in the outside world. Many applications are sensitive to software and interrupt(s) latency time, but it is not normally the case in a power line application, in which you have 10 ms events and you are using 478 uS timer tics. So The input Capture interrupt is being used just because of the double edge hardware detection capability and not because of the latching action of the register. Even if you get the value "by hand", it will also work fine in this case.

Resuming: it would be nice to leave the timer running free and obtain the result of the attached example without using extra software and Overflow events.

Again, thank you for your help.

Roberto Berner

Re: THE 9S08 TIMER - HOWTO'S

JimDon — Fri, 20 Jun 2008 22:43:55 GMT

Bob,

First, could you clarify which chip you are using?
Are you using HCS08, or HC908 family?

You can not mix the two. All I say refers to the HCS08 family, S08TPMV3,

What you are saying about the output compare registers is generally not true, and would make the feature pretty useless. In OC mode, the data is transfered:

If (CLKSB:CLKSA not = 0:0 and in output compare mode) then the registers are updated after the
second byte is written and on the next change of the TPM counter (end of the prescaler counting).
In other words, in OC mode the overflow has nothing to do with the transfer of the register data.

This means that the next time the counter counts, it gets loaded.

How ever if you have the PWM enabled then:
If (CLKSB:CLKSA not = 0:0 and in EPWM or CPWM modes), then the registers are updated after
the both bytes were written, and the TPM counter changes from (TPMxMODH:TPMxMODL - 1)
to (TPMxMODH:TPMxMODL). If the TPM counter is a free-running counter then the update is
made when the TPM counter changes from 0xFFFE to 0xFFFF.

As for using say the KBI interrupt, there is no reason why this will not work, as the purpose is to sync the one shot to the line frequency.

Re: THE 9S08 TIMER - HOWTO'S

BooleanBob — Fri, 20 Jun 2008 23:12:12 GMT

Dear JIm:

1. In my previous posts and in my software attachment it is clear that I am using the 9S08QG8.

2. The timer functionality REFERRED TO OVERFLOW AND LOADING is the same on both families, even in the HC11, where all this started.

3. You are talking about the way you write a value to a register. YES is true that that in the 9S08 famiIy you can now write the register in any order to optimize for eg: C languaje code. I am talking about the way the values once stored in their registers, take effect. It is not true that the value takes effect that simple and works right away, as I exposed before.

4. I don't understand what you mean with the keyboard interrupt. In my case and as I explained before, this is inmaterial because any source of interrupt will do for me. Please understand that just in case somebody could be interested in this case and would like to exercise the problem, it is better to simulate the scene with any interrupt to watch the process in a single osciloscope and using a demo board. I don't pretend that you are going to set up a TRIAC :smileyhappy: If it works this way, then you can switch to the interrupt you like better to sync to the power line.

What I am trying to solve here is quite a lot more deep and precise, not just a matter of how to write in a register. If what you say is true, then please be so kind to upload a working piece of code to demonstrate that my point is wrong, trying to read the previous material that includes the details that you are asking for in your post. To be precise: do you know how to achieve this ( all what I have been exposing ) without stopping the timer ? Please teach me how to do it or tell me where is may reasoning flaw. I am willing to learn , based upon facts.

Believe me that the timer - sometimes - is not as easy as it should ...

Kind regards

Roberto Berner

Re: THE 9S08 TIMER - HOWTO'S

JimDon — Sat, 21 Jun 2008 00:30:15 GMT

No, I am not talking about the way you write a value.
This quote from the spec sheet makes it quite clear that the compare register is loaded from the buffer register on the next clock to the counter, not the overflow of the counter (in OC mode):

"If (CLKSB:CLKSA not = 0:0 and in output compare mode) then the registers are updated after the
second byte is written and on the next change of the TPM counter (end of the prescaler counting)."

Of course writing to the registers is a pre-condition for the value to be transfered to the compare register, but that is not the point I am making.

There is no need to stop the timer.

TPM1C0V = TPM1CNT + MY_DELAY;

On the next clock to the counter, the new delay value will be loaded to the compare register, and the OC will happen when the value in the compare register is equal to the value in the counter. If MY_DELAY happend to be very small, I suppose it could be that the count you set would be missed, but I don't think that is the case here.

I can assure you that this works, and you need to make sure that your code is setting the OC mode correctly and loading values as expected

Re: THE 9S08 TIMER - HOWTO'S

BooleanBob — Sat, 21 Jun 2008 01:30:37 GMT

No offense Jim, please don´t take it bad. I already tested your point of view during last weekend. I can upload the bad code and this is why I am taking the forum´s valuable time.

It does not work. For sure I am doing something wrong but I am used to have it beautiful in the manual and there is always the other side of the coin.

Please write a piece of working code for me to test it. I was also sure that it had to work fine when I first RTFM. To my knowledege, it is the same old story from the HC11 up to our days.

Best regards
Roberto

Re: THE 9S08 TIMER - HOWTO'S

kef — Sat, 21 Jun 2008 02:29:25 GMT

Don't talk about HC11 bad :smileyhappy:. Perfect timer, which never had problems you are talking about. Did you read HC11 pink book? Here it is, with great examples how to generate pulses, how to measure time periods longer than 2^16 timer ticks etc ect http://www.freescale.com/files/microcontrollers/doc/ref_manual/M68HC11RM.pdf

Take advantage of free running counter. HC11/12 had/have single counter and 8 channels. That's equivalent to 8 independent timers. Long (>2^16 ticks) pulses/periods generation has nothing to do with overflow flag, and Mac has showed how to use that in S08. Measurement of long (>2^16 ticks) pulses/periods requires having shared overflows counter. This is what for overflow interrupt may be required..

You also don't take it bad, but are you reading what others say? Mac and Jim are right and you are looping at something obvious. Didn't Jim said that you should set TPMCH relative to TPMCNT? Why then in your macros-obfuscated code, in MTIM overflow handler, you are writing absolute value to TPMCH and not TPMCNT relative value?:

m_QG8_set_TPMCH1_value(angle);

Where's +TPMCNT? It should be simple. Counter is free running. So you should synchronize to it adding current counter value to your angle.

Please stop telling horror stories about TPM and HC11. That's simply not true.

Regards

Message Edited by kef on 2008-06-20 10:30 PM

Message Edited by kef on 2008-06-20 10:32 PM

Re: THE 9S08 TIMER - HOWTO'S

BooleanBob — Sat, 21 Jun 2008 03:36:26 GMT

Ok friends, I see that I have been wrong for a lifetime. I am 53 and I started 6800 at 19. I agree that he timers since HC11 are very good. I have meade a living out of HC11. Respectfully , I still feel that you really are not paying attention at the problem here. I don´t know why, but you are insisting in a mode that works for PWM but you are probably not understanding what I am talking about. I´ll try to gather some more information.

Do you really think I cannot tell the difference between the absolute value or the value related to the module ? Do you think that this timer really works as you are saying ? Again: please probe it. Write a simple program and show your point.

I don´t want to bother with my questions here, so I will try to consult somewhere else. I am sorry if I had upset you and your friends, but my style is cooperation and facts, which I don´t feel is yours.

Take care !

Roberto

Re: THE 9S08 TIMER - HOWTO'S

JimDon — Sat, 21 Jun 2008 04:12:38 GMT

I certainly said quite the oppsite. You DO NOT want to use PWM mode. You DO want to use OC mode.

Nothing I have said applies to PWM mode. Do not use PWM mode.

CPWMS should be 0 and MSnA should be 01.

If you were setting anything other than this, it will not work as I have said.

Re: THE 9S08 TIMER - HOWTO'S

allawtterb — Sat, 21 Jun 2008 04:59:49 GMT

Jim, kef and bigmac are all correct. There should be no reason to reset the counter. On input capture add it to the time you want to wait until the turning on of the triac and set the output compare to this value. I don't see any reason to not have the output compare to set the pin automatically, setting it manually just adds an extra delay. The method described by bigmac is the exact method I use to dim lights on my high voltage dimmer boards(I work for a company that makes lighting controls). I can post an example of the code that I use but it is exactly as bigmac has described.