I have a standard problem of repeated INT0 executions due to a 'not optimal' design: I am currently using the rising-edge to trigger an interrupt upon a reed-switch event.
I think I'llhave to use hardware-debounced input in the final solution.
However, besides design questions I wonder whether a different gcc code-generation could mitigate the problem.
The gcc generated INT0 assembler-code looks like this:
00001172 <__vector_1>: 1172: 1f 92 push r1 1174: 0f 92 push r0 1176: 0f b6 in r0, 0x3f ; 63 1178: 0f 92 push r0 117a: 11 24 eor r1, r1 117c: 2f 93 push r18 117e: 3f 93 push r19 1180: 4f 93 push r20 1182: 5f 93 push r21 1184: 6f 93 push r22 1186: 7f 93 push r23 1188: 8f 93 push r24 118a: 9f 93 push r25 118c: af 93 push r26 118e: bf 93 push r27 1190: 2f b7 in r18, 0x3f ; 63 1192: f8 94 cli 1194: 80 91 56 01 lds r24, 0x0156 1198: 90 91 57 01 lds r25, 0x0157 119c: a0 91 58 01 lds r26, 0x0158 ...
and I ask myself, why the cli does appear so late in the code. With all the push-operations being placed before the cli, it takes more than two dozen cycles before further interrupts are blocked.
Why is this so?
Wouldn't it make sense to place cli closer to the beginning of the ISR?
Are there any gcc-attributes/pragmas to control code-generation?
You opinion is very much appreciated.