attachInterrupt(Pin,RISING) trigging when falling too…. Visa-verser

Well hi again, another new issue has come up.
I have pin 20 running as in input. I have input_pullup on, an opto isolator is buffering the input from the 12v signal

But instead of the interrupt only triggering when a signal is applied to the indicator input it triggers when the signal is being taken off too…

I have the interrupt set to trigger when the pin is falling as the opto pulls the pin to ground when a signal is applied.

Why is it doing this? its proving to be a total pain. I can program a way around it by avoiding using an interrupt and just read off pin value in a function but there are other inputs that are behaving the same. Is this a bug in the libmaple core?

I checked with a visual output and serial print. The pins values are showing correct, 0 or 1… So its not earth floating.

Any ideas?

Not sure if it may have anything to do with the problem, but I was wondering why are you setting the pin as input_pullup if you use a pull up resistor R15?
Could you try using only one or the other too see if there is any difference?
One more thing, even if the pin is 5V tolerant, perhaps the pull up resistor to 5V is causing the issues with the interrupts?

Also, have you checked with an oscilloscope to make sure the signal is not bouncing up and down?
Other than those 2 things, may be worth checked the code in the core to confirm it doesn’t have a bug and is not setting the interrupt edge correctly.

I have tried with both the internal pull up on and off… Same issue.

The work around I have going is a one line if statement that sets a boolean to true or the previous value of the boolean. The boolean gets reset to false in another function when that function has finished its thing, this being the function the pin is meant to trigger…

Its a bit of a crappy way of doing it but it stops the strange state change effect of the pin.

Even when you are using an optocoupler it may need debouncing.. Are you talking a “motorbike” electronics? Optocoupler’s leds driven by a relay contacts or by the board electronics?

I am pretty certain this will be a switch bounce issue, but the only way to know that for certain would be to watch the signal on the gpio pin with an oscilloscope. I suspect it will be very noisy at both the press and release events. A little bit of low pass filtering on the switch end will probably clean things up.

ahull wrote:I am pretty certain this will be a switch bounce issue, but the only way to know that for certain would be to watch the signal on the gpio pin with an oscilloscope. I suspect it will be very noisy at both the press and release events. A little bit of low pass filtering on the switch end will probably clean things up.

lol Yeah i need his ocili

Maybe it is noise… The noise being so fast the input state doesnt get printed out…. but is fast enough for the interrupt to trigger…

At the moment im just testing the inputs by applying 12v to the wires… Its not on the motorbike yet.

so if im to change the circuit diagram in the future version… I add a small cap between the pin and ground?

victor_pv wrote:ahull wrote:I am pretty certain this will be a switch bounce issue, but the only way to know that for certain would be to watch the signal on the gpio pin with an oscilloscope. I suspect it will be very noisy at both the press and release events. A little bit of low pass filtering on the switch end will probably clean things up.

Nutsy wrote:lol Yeah i need his ocili

Maybe it is noise… The noise being so fast the input state doesnt get printed out…. but is fast enough for the interrupt to trigger…

At the moment im just testing the inputs by applying 12v to the wires… Its not on the motorbike yet.

so if im to change the circuit diagram in the future version… I add a small cap between the pin and ground?

Harxwads Debouncing was discussed in the rotary encoder thread,

It’s worth reading that thread as there are some simple schematics showing the resistors and capacitors

ahull wrote: but laziness suggests trying a few from the junk box to see what works best.

Perhaps the addition of a schmitt trigger to clean up the signal may also help.

I’m building something similar to correct a vehicle speedo signal, I used this resource as a start point -> http://members.rennlist.com/tom86951/Sp … Page1.html

Different input circumstance however, floating to earth, but similar principal.

My project so far is here -> https://github.com/BennehBoy/ArduinoSpeedoCorrection

Yeah I have a Schmitt on my RPM signal line…