AVR Freaks

>> what happens if you activate the interrupt by a signal generated from the io of another micro so it's  guaranteed "clean".

I did not try that; however, as I wrote, I'm generating the signal with a signal generator. This input signal looks certainly 'clean', also when viewed with an analog channel on the scope.

You can see the input in the attached screenshot, labelled "PIN0" (which should be better labelled "PB0")

First, thanks for your reply!

and the chip is running at 128/8 = 16kHz

Sorry, that was a bit short. The low fuse was 0x24, so

- clock source is the internal 128kHz oscillator

- CKDIV8 is in effect

-> resulting in a clock of 128kHz / 8 = 16kHz.

I'm running at this frequency mostly because signals in the kHz range are so much cleaner and easier to show on  the scope than signals in the MHz range.

It also makes it a lot easier to check out clawson's idea (another controller, running in the MHz range, produces the input signal for the slow controller running in the kHz range).

I just tried your suggestion - switched the low fuse to 0xa2. Now the chip is running at full 8MHz.

I adapted the input signal accordingly, for 8Mhz == 125ns clock period (steady low - high for 60ns - low for 60ns - steady high) -> same problem: if the rising edge hits when CLK is high, the pin change is missed.

Now, no switch will bounce in the 60ns range. Just for fun I tried 400ns peaks, and the pin change is detected reliably.

But, as I said, this is not so much about properly sampling a bouncing switch, it's about the pin change interrupt not firing.

I just can't believe that such a simple input makes the "pin change detection' logic fail.

Thanks for your suggestions!

I don't know how to get this timer idea '64MHz' working, so I did what clawson suggested - use another tiny to generate the signal.

The setup is this:

- a 'master' ATTiny, running at 1MHz with the software below

- a 'slave' ATTiny, running at 16kHz with the software from my first post. This slave is providing its clock signal at CLKO (pin 3)

- the master PB0 is connected to the slave CLKO for synchronization

- the slave PB0 is connected to the master PB1 to get the input signal

The idea:

- the master generates a signal with about 16 edges per second (nicely visible with a LED)

- however, each edge is preceded (or followed - equivalent) by a short 30+30usec pulse

- the edge is synchronized with the slave clock: the master waits for a rising slave clock edge,

  then delays the signal by 0...100% of a slave clock width

- the slave's PB0 and PB1 have an LED attached.

Since each input edge should result in an output edge we'd expect both LEDs to flicker in sync. In reality,

the input LED flickers constantly, while the output LED flickers for a few seconds, then is constant for a few seconds,

then repeats.

About half of the input pin changes are lost.

Is there a contact with Microchip that might be interested in this?

-------------------------------

This is the edge at high time resolution; compare with slave clock of 16kHz:

Many edges at millisecond scale; edge is offset by 0...100% of slave clock cycle. About half of the input edges are not detected.

Here the master software, compiled with "avr-gcc.exe -nostartfiles -mmcu=${AVR_TYPE_GCC} -Wa,-L -Os -o obj.o tiny.c"

//
// software to demonstrate pin change detection failure
//
// Two ATtinys are used. This is the code for the 'master' chip.
// The master is running with a 1MHz clock,
// the slave is running with a 16kHz clock.
// The master will toggle PB1 about 16 times a second.
// Each such edge is preceded by a short pulse of about 30usec;
// that is just half the clock period of the slave chip.
// The pulses are synchronized with the slave clock: the master waits
// for the slave clock's rising edge, then delays by a varying amount of
// time before generating the test signal.
// This way, the effect of 'when exactly, during the slave clock's
// cycle, does the edge hit' is checked.

#include <../include/avr/io.h>

// with all overhead this amounts to about 30usec == 1/2 slave cycle
#define PULSE_LEN 9

// about 1/16s, 60msec
#define TIME_BETWEEN_EDGES 16000

#define PIN_SLAVE_CLOCK_IN	PB0
#define PIN_OUT			PB1

void inline busyWait1(unsigned char volatile c) 	{ while(--c); }
void inline busyWait2(unsigned short volatile s) 	{ while(--s); }

void main()
{
	DDRB = 1 << PIN_OUT;

	unsigned char edgePosition = 0;
	while(1)
	{
		// Edge shift from 0...63 master cycles; loop takes 3 cycles
		if(++edgePosition > 64/3)
			edgePosition = 1;

		// Wait for rising edge of slave clock
		while(   (PINB & (1 << PIN_SLAVE_CLOCK_IN)));
		while( ! (PINB & (1 << PIN_SLAVE_CLOCK_IN)));

		// Shift edge over all of slave clock's period
		busyWait1(edgePosition);

		// The signal sent to the slave.
		// A short pulse followed by a normal edge.
		// Pulse length is 1/2 slave cycle
		PINB |= 1 << PIN_OUT; busyWait1(PULSE_LEN);
		PINB |= 1 << PIN_OUT; busyWait1(PULSE_LEN);
		PINB |= 1 << PIN_OUT;

		// busy-wait for about 1/16s
		busyWait2(TIME_BETWEEN_EDGES);
	}
}

I opened a case with microchip, here's the prelim reply:

Hi Manfred,
Thank you for taking time to test this and providing such a detailed description.
This is interesting! and your assessment seems valid to me. I have forwarded this details to the design team. Let me hear back from them and update
you accordingly.
Regards,Sadik

As for my practical problem with the pin change not detected, I went with Who-me's suggestion, a cap parallel to the switch - works like a charm.

Hi, all,

I finally got a comment from microchip support which is not really satisfying... :(

Hi Manfred,

 

I heard back from our internal team that the pin change interrupt section in the data sheet didn't mention this behavior (glitch causes the perfectly normal edge to be lost), but fortunately, in the block diagram, it describes that this glitch may happen.

 

The solution could be to use RC-filter.

 

Thank you for testing this! Your observation is correct and this is the expected behavior.

What block diagram is he mentioning?

Thanks,

-manfred