9S08QE8 Event Timer Options

[Rodo55]

Hello,

I'm new to the 9S08QE8 MCU and I have a question about timing events.

To save battery power I have the QE8 enter stop3 mode for 1 second and then wake up and check one of it's pins for a high input. If the high input pulse is longer than one second and less than two seconds it looks for two follow-up pulses of less than one second each. If it sees this code it continues on and does the rest of the program. If it doesn't see this code it goes back to sleep for one second and wakes up and checks again.

My question is about the QE8 timers. I'm not sure of how use them to check the duration of the pulses or even if it is better to use the Real Time Clock (RTC) or the Timer and PWM module (TPM) to time the events.

You may say it would be better to wait for the pin to go high and then use an interrupt to wake up the MCU but I don't do that because I use the MCU to (power-up/control) additional circuits to conserve power. The QE8 puts the other circuits to sleep then goes into Stop3 mode. When the QE8 wakes up, it turns the power on to the additional circuits and then looks for the high on the input.

I'm working in assembly but if I need to, I can use C.

I would appreciate any thoughts or guidence.

Thanks,

Rodo

[bigmac]

Hello Rodo,

The best solution will probably depend on how critical are the measured pulse timing intervals.  With a wakeup interval of one second, it would always be uncertain how long the pulse had been active prior to the current sample, which could be nearly one second.

A possibly better approach might be to wakeup the MCU at more frequent intervals, sample the input state, and then immediately revert back to STOP3 mode until the required pulse timing conditions are met.  For example, for a timing uncertainty of five percent over a one second interval, the sample rate would need to be every 50 milliseconds.  If a greater uncertainty is acceptable, this interval could be somewhat increased.  I assume that the clock source for the RTC wakeup would have sufficient accuracy for your purpose.

The advantage of this approach, for lengthy pulse durations, is that the MCU does not need to remain awake for the whole pulse period, so this should further minimise the average current draw.  The duration of the pulse would be measured by incrementing a counter during each sample, and perhaps using flags to keep track of whether the first, second or third pulse.

Regards,

Mac

[Rodo55]

Thanks Mac,

The timing is not that critical on the first pulse at all. It's about a two and a quarter second pulse that is there just to indicate the start of the code.

So if the two second pulse was to start just after the Stop3 mode starts there would be at least one second of it left when the MCU wakes up and starts checking. Which would meet the criteria of a minimum of one second. On the other  hand if the pulse is longer than two and a half seconds it's not the start of the code and it's to be ignored. But if the first pulse meets the criteria look for additional pulses.

I have the logic down to capture the pulses but where I'm having trouble is getting the pulse lengths captured. I found several examples of creating a PWM but I haven't found any examples of measuring the pulse length of a signal. I even bought Fabio Pereira's "HCS08 Unleashed" book but I don't see any examples of how to measure a pulse width. It seems that everything in the QE8 is set for either trigger on either rising or falling edge but not for determine the actual length of a pulse and timing out if it's too long.

Basic logic for counting pulses is measure length of first pulse (If meets criteria) set flag for second measurement and then wait one second for a second pulse. If second pulse arrives within one second and meets criteria then set flag for third pulse. If third pulse arrives within one second and meets criteria execute program. If any of the pulses don't meet the criteria or the third flag doesn't get set within two seconds, reset variables and go to sleep for one second. 

I'm new to MCUs and I've read so much including Fabio's book that maybe I'm in information overload and I'm not picking up the logic of how to measure the length of a pulse with the QE8. I'm used to one very simple general purpose counter but the QE8 has so many options and timers it's confusing to me.

Are you saying the RTC would be the best timing source for this scenario? What is the basic flow to setup the RTC and capture a pulse length on say PTA0?

I appreciate your help.

Rodo

[bigmac]

Hello Rodo,

Let's assume that you were to use the RTC to wakeup the MCU, and then use a TPM channel for measurement of pulse width, perhaps using input capture.  I can still see a fundamental problem with using a wakeup sampling interval of one second.

You say that the initial start pulse will have a nominal duration of 2.25 seconds, and will not exceed 2.5 seconds.  Since you do not know when the start pulse commenced relative to wakeup, a 2.25 second pulse could give a measured period from wakeup somewhere between 1.25 and 2.25 seconds.  Any interval between these limits would need to be interpreted as a valid start pulse.

However, it would also be possible for a pulse of up to 3.25 seconds duration to sometimes be interpreted as a valid start, but this does not meet your stated requirements.  For pulse duration greater than 2.5 seconds to always be treated as an invalid start, the wakeup sampling interval would need to have a maximum value of 0.25 seconds.  Using this interval, a period measurement of between 2.0 and 2.25 seconds would indicate a valid start.  Pulse widths of less than 2.0 seconds, and greater than 2.5 seconds would always be rejected.

In practice, the sampling interval might be somewhat less than 0.25 seconds, to allow for a tolerance on the RTC period.

Since your pulse durations are quite long, the TPM input capture may be less suited for your pulse measurement.  For simple input capture operation, the pulse period should preferably be less than the TPM overflow period.  If this is achievable, it will involve large prescale divider settings, but will restrict the TPM to no more than a single overflow during the measurement period.

When it is possible for multiple timer overflows to occur, these must additionally be counted (within the TPM overflow ISR code).  Combining input capture results and timer overflow count will provide best timing resolution, but can be quite complex.

For the measurement of longer periods, it may suffice to use the overflow count only (and not bother with the input capture readings).  For example, if the TPM overflow period were set for, say 10ms, this would be the resolution that could be achieved for each period measurement.  I suspect this might be sufficient for all your pulse width measurements.

In addition to the pulse width measurement, I assume you will also need to measure the gaps between the various pulses.  Minimum limits may be needed, in addition to maximum timeout limits.

Regards,

Mac

[fabio]

Hi Rodo,

I agree with you, but the point is: I tried to make sure that all the basic examples could be tested directly on the demo boards. Unfortunatelly, some demo boards have limited features, for example: from the boards I have here, only the DEMO LC60 has a key attached to a TPM channel pin, for the other boards, I would have to use external hardware (which I avoided).

I know that the more examples the better it is. But the beauty of the HCS08 devices is that the peripherals work in the same way, no matter the device (and that includes the Coldfire v1 devices). It is very easy to make that example to work on a QE8 device: just select the desired TPM channel input and change the TPM configurations accordingly.

Best regards,

[fabio]

Hello Rodo55,

The TPM channels can be set to capture on rising/falling or both edges.

The book covers what you want on topic "9.4.2.1. Capture Mode". Example 9.8 shows how to measure the total time a key is pressed. This can be easily modified to capture other pulses.

Best regards,

[Rodo55]

Thanks Fabio,

I didn't take the time to relate that example to the QE8 MCU because it required translation between the LC60 and the QE8. Also it uses user defined definitions which I didn't take the time to translate to the QE8  either. That's my fault for not taking the time to do that.

Just a little feedback on your book which has taught me a lot by the way. The only down side that I have found, is the fact that you do use so many different MCU's and DEMO boards that I get confused. Like with that example you used the LC60 MCU and demo board just because the DEMO board had a switch. If you would have been consistent with just a couple of DEMO boards or MCU's it would have been easier for me to follow.

I am biased though because I'm I am very new to MCU's and I'm trying to learn the QE8 and QG8. I have both of the demo boards for them and it takes me a while to convert some of your examples to make them compatible.

Now to be fair that is just my opinion being very new to FreeScale MCU's. Someone that has had more experience with them is probably much more comfortable with the examples than I am. I'm sure you were shooting for a happy medium between experienced and newbies like me. With that being said I want to restate that your book has helped me understand the FreeScale MCU's a lot and I am very glad I purchased it. It has saved me many hours learning MCU's.

I'll try to convert that example to the QE8 MCU and I'll define a time out period so if it doesn't see a trailing edge within my time requirements it exits and enters the Stop3 mode.

Thanks Again for your help and great book.

Rodo

[JimDon]

Well obviously you can't give an example for every demo board for every module. If you had the the LC60 and the demo had been for the QE8, then you would been of the opposite opinion. :--)

Also, since the QE8 was not out when the book was written, it would have been hard to provide a specific example. Although the modules are the same as the QE128, not all the defines are.

The whole reason for the user defines is to help you translate the example with a minimum of effort. No matter how many examples you have, in the end you will need to understand the module to some degree.

I can name other books that just rehash the spec sheet and have almost no examples. At least with these great examples, you see what registers in general need to be set up. Also there is some explanation of the registers.

If you have trouble, ask some more!

[Rodo55]

Jim,

You are absolutely right if I had more experience with different MCU's or demo boards I probably wouldn't have made any comment at all. But being new and trying to learn some of the newest MCU's from FreeScale (QE and QG) that is my observation and I did qualify it by saying that I am new to MCU's. Someone with more experience probably wouldn't have made the same comment. I was just trying to give a little feedback to Fabio from a newbie point of view. Sometimes when you've been around stuff long enough you forget the newbie perspective and before I got out of the newbie phase I wanted to provide a little newbie insight. Be it right or wrong it was just my observation.

Fabio's book has saved me many questions and many, many hours of time learning MCU's. I use both his book and the spec sheets to perform many experiments. His book does have great examples and I have used several of them. I credit his book for getting me this far. But like you said he can't give examples of every module with every MCU so I still had questions.

I've learned a lot but I still had the question about timers because I'm used to a general purpose timer in programs that simply counts up. The QE MCU has several different timers and several options with each timer and it was unclear to me as to which one would be the best for my use and the proper way to set it up. Even after reading Fabio's book and looking at the spec sheets it wasn't very clear. That's why I did asked the question by starting this thread. Mac responded to use the RTC and Fabio's example uses the TPM so I still have two ways to complete the timing of the pulse. I was hoping by asking the question that maybe someone had completed a project similar and would say, here's how they solved the issue of counting the duration of a pulse. 

I don't ask questions lightly on this forum because people are busy and I try not to ask simple or easy questions that I should be able to solve on my own. Maybe I should have been able to solve this one on my own but I didn't see a clear solution after I researched the timer issue with Fabio's book, the spec sheets and I searched this forum as well. I found debouncing switches, leading edge, trailing edge and PWM examples but nothing I found clearly explained what I was trying to do with the QE8 and it's timers.

Rodo

[JimDon]

Rodo,

It is always hard to decide what to include and what not to include in a book. Some texts will have serveral chapters on asm and "C" programming, but the are a wast of space since you can't really cover those subjects in a few chapters. Fabio did give a review chapter on "C" but it was really more for the people who know "C" and is just a review.

I think Fabio did a superior job of making those decisions. As being very experienced, I still find it a handy reference, yet a beginner like you still found it useful. Hard to do.

Don't worry about asking easy questions, but I do admire that you taking the time to read up on something.
Some post here saying "Hey, could you write all this code for me?".

I don't know if you saw these examples yet for the QE family, but there is a TPM example. I have not looked them over, so maybe you would and tell us if they are worth while. This is a PDF that goes with them.

I will give a hint when looking for sample code on the FSL site. Sometimes you have to go to other chips to find it. I wish they had a one stop sample code page, usually code even for another processor helps get the idea of how it should work.



BTW Did you consider that if you made the RTC happen a bit more frequently, you could just use a counter there to decide that you have been activated?