Possible error in 5270 EPORT documentation

[admin]

"MCF5271 Reference Manual" (MCF5271RM Rev.2 07/2006) has either error or unclear statement in Table 15-5.EPIER Field Descriptions:

"Clearing a bit in EPIER negates any interrupt request from the corresponding EPORT pin"

It is tested with 5270, that the corresponding EPFR bits must be cleared by EPFR writing in the ISR even in case of the corresponding interrupt is desabled by writing 0 to the EPIER bit.

[TomE · Accepted solution]

It all looks pretty standard to me.

The bits in the EPFR are set when the edges are detected.

Simple code can poll these bits and clear them to await the next edge if it doesn't want to use interrupts..

It is ESSENTIAL to clear the EPFR bit in order to "arm" the logic to be able to detect the next edge.

That is separate from getting interrupts. The EPIER bits enable a set EPFR bit to cause an interrupt.

*** Look at the diagram at the top of 15.1 in the MCF5271 manual. ***

The EPFR bits go through a couple of multiplexers and into an AND gate where it is combined with the EPIER bits.

As the manual states, a pending interrupt can be made to "go away" by clearing the EPIER bit.

But you have to clear the EPFR bit in order to re-arm it to detect and interrupt on the NEXT edge.

So in most cases, all you need to do is clear the EPFR bit in your interrupt and ignore EPIER.

Clearing the EPIER bit on a "pending interrupt" can only be done if the CPU is ignoring interrupts at the time. There are some situations in which this may be necessary, but in simple "get an interrupt, service it, go back to something else" code this isn't something you should need to do.

Congrats to the manual writers at Freescale by starting the chapter off with a 'circuit diagram". That makes things a lot easier to understand that just lists of register descriptions.

[admin]

 TomE,

Thanks for the clarification. The manual chapter 15 misses theory of operation.

Actually, the better title of my post will be "Unclear item in 5270 EPORT documentation"

"It is ESSENTIAL to clear the EPFR bit in order to "arm" the logic to be able to detect the next edge."

Significant (and not so evident) clarification. At least, this behavior cannot be deduced from the EPORT block diagram.

"The EPIER bits enable a set EPFR bit to cause an interrupt."

Possibly, this phrase is more clear in the following form: "Interrupt request is generated, if both EPIER and EPFR related bits are set."  At least, this form prevents incorrect understanding (especially for non-native English readers) like  "The EPIER bits enable to set EPFR bit".

"As the manual states, a pending interrupt can be made to "go away" by clearing the EPIER bit."

But, the interrupt returns with re-enable interrupt by EPIER, if EPFR isn't cleared previously.

While programming EPORT, I previously understood word "negate" in the referenced post as "clear".

"So in most cases, all you need to do is clear the EPFR bit in your interrupt and ignore EPIER.

Clearing the EPIER bit on a "pending interrupt" can only be done if the CPU is ignoring interrupts at the time. There are some situations in which this may be necessary, but in simple "get an interrupt, service it, go back to something else" code this isn't something you should need to do."

Agree for "most cases". But, my application receives the EPORT IRQ signals from a dry relay contact . By disable the interrupt for the bouncing intervaI, numerous bounce caused interrupts are eliminated.

[TomE]

---

yevgenit wrote:

 TomE,

Thanks for the clarification. The manual chapter 15 misses theory of operation.

"So in most cases, all you need to do is clear the EPFR bit in your interrupt and ignore EPIER.

Clearing the EPIER bit on a "pending interrupt" can only be done if the CPU is ignoring interrupts at the time. There are some situations in which this may be necessary, but in simple "get an interrupt, service it, go back to something else" code this isn't something you should need to do."

Agree for "most cases". But, my application receives the EPORT IRQ signals from a dry relay contact . By disable the interrupt for the bouncing intervaI, numerous bounce caused interrupts are eliminated.

---

I see. Yes, you have to disable the interrupt (IPEIR) and set a timer (software or hardware) to run after your "debounce period" to clear IPFR and set IPEIR again.

I would suggest a more "standard" way to do this that might be more predicable.  I've seen this used in a lot of automotive products. Have an "event loop" running tasks at regular intervals (10ms, 20ms usually) or have a periodic timer set to that interval. In that polling or service routine, simply READ the current state of the pin and then debounce it. The usual thing is that it has to be the same state for three times running before you accept its new value.

The neat trick here is that this can be done for all the pins on a port in the same time and with the same code used to debounce a single pin.

http://www.ganssle.com/articles/adbounce.htm

http://www.ganssle.com/debouncing.htm

Here's my version of something similar:

/* Karnaugh Map for Switch Debounce * where   A = Oldest Sample *         B = Previous Sample *         C = Current Sample *         D = Last Debounced Output * *   \ A,B *    \                Therefore Result = B.D + A.D + C.D + A.B.C *     \  00 01 11 10                   = D(A+B+C) + A.B.C *  C,D \------------| *   00 | 0  0  0  0 | *   01 | 0  1  1  1 | *   11 | 1  1  1  1 | *   10 | 0  0  1  0 | *      |------------| */uint8_t DigitalDebounce(uint8_t nCurrent){    static uint8_t nOld = 0, nPrev = 0, nOutput = 0;    nOutput = (nOutput & (nOld | nPrev | nCurrent)) |                         (nOld & nPrev & nCurrent);    nOld = nPrev;    nPrev = nCurrent;    return nOutput ;}

The normal way to use the above is to read an 8-bit port, and pass the whole thing into the above routine. It will debounce all of the pins, even the ones you don't care about - the ones that are allocated as outputs. It can easily debounce 16 or 32 bits as well.

[admin]

 TomE,

Thanks for the useful links and your solution of the debouncing item.

[TomE]

There is another reason to use a "real debounce routine" instead of detecting the first edge and then attempting to make out the "inconvenience" of the switch/relay bounce.

I assume the signal is coming from "outside". This is an external input that may be a fair distance away.

It may get ESD or EMC interference. There may be short duration interference on that line.

With the "interrupt and mask" code that would show as a closure when there wasn't one - it would reliably detect every noise pulse (unless there are hardware filters removing all of this first).

With the debounce code, you have to get a minimum of "three the same" which should remove most interference.

Also, an essential part of this sort of design is to always low-pass filter the signal in HARDWARE to the software  sampling frequency. This applies to analog signals going into an ADC or switch signals being sampled periodically. Analog signals should have an RC filter to remove the higher components to minimise aliasing, and switch inputs should have RC inputs so the signal can't change faster than it is being sampled. This also improves the ESD and EMC very cheaply, and also lets you put 12V on the relay contacts to wet them, while only needing (usually) a single 100k resistor and a few capacitors between that and the pin. You may prefer a 100k/80k divider though - you have to check the "maximum injection current specifications" for the chip you're using.

[admin]

I use well known debouching algorithm of delaying the pin read after the first pin transition. ISRof IRQ pin disables and clears interrupt, then triggers the timer delay. The pin state is read by the timer interrupt. Then, IRAQ interrupt is enabled to detect the future IRQ pin transition.

Any bunch of short noise transients at IRQ pin will result in the only single re-read the pin after the delay. The problem here can be only for long noise pulse train, which duration exceeds the delay.

Some analog filter at receiving end of the long digital line is a good idea. In my application, very short pulses are filtered out due to delay of the input photocopier.