The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
Mark, I noticed that the ST MCU (Netduino 2/Plus 2) embeds a Schmitt-trigger stage on every input stage. That is, the mentioned circuit (2nd link, figure 3) will require only the "passive" parts: resistors, capacitor and diode. It should be far simpler to implement.
However, I must admit that you should face some calculation task, and related test. As the document points out, you should also consider the parts tolerances and the different hysteresis thresholds.
Perhaps the very best solution is using a custom chip, or relying on the old-faithful NE555:
What's the easiest way to detect a dry contact state (I can use either NO or NC). it's a float switch and max frequency will be every 10 secs. Would like to use interrupt rather than polling and use on board power supply if possible.
That is the code for one of those "Auto-off" boxes where you flip a switch and a hand comes out and flips the switch back. The response is pretty darn fast. if you are doing one cycle every 10 seconds, that will work fine for you.
And that setup follows both rising and falling edge. So you can trigger from either state change.
That is the code for one of those "Auto-off" boxes where you flip a switch and a hand comes out and flips the switch back. The response is pretty darn fast. if you are doing one cycle every 10 seconds, that will work fine for you.
And that setup follows both rising and falling edge. So you can trigger from either state change.
Works great, but as expected, I get a lot of bounce.
Any idea how to disable interrupts until I've finished processing the first. For example, contact is made, I get an interrupt, I do a very small amount of processing (calculate time since last one), send message over IP or RS232 (not sure which yet) and then wait for more interrupts. Ideally, I'd like to disable interrupts from when I get the first one to about one second after it (without blocking), as any that are more frequent than every 10 seconds are duplicates. My interrupt handler should only take a few milliseconds.
I did try it with the glitch filter enabled but it seemed to make no perceivable difference (still got about 4-5 bounces)
A mechanical contact/switch will always produce bounces, which last around the millisecond. The filter glitch is working around the microsecond, thus does not have effect.
You may actually get rid of the bounces in two ways:
add an external (hardware) filter;
add an internal (software) filter
If you want to use the interrupt you must add the hardware filter. The software filter is based on a periodic sampling, so you can't use the interrupt callback.
An external hardware filter is far better other than the software one, because it typically protects the I/O from spurious discharges, noise and whatever. However, it implies *at least* a resistor and a capacitor, and sometime the people don't like adding extra components.
Tell me whether the hardware filter would be fine for you, and I'll explain how to implement it.
Biggest fault of Netduino? It runs by electricity.
A mechanical contact/switch will always produce bounces, which last around the millisecond. The filter glitch is working around the microsecond, thus does not have effect.
You may actually get rid of the bounces in two ways:
add an external (hardware) filter;
add an internal (software) filter
If you want to use the interrupt you must add the hardware filter. The software filter is based on a periodic sampling, so you can't use the interrupt callback.
An external hardware filter is far better other than the software one, because it typically protects the I/O from spurious discharges, noise and whatever. However, it implies *at least* a resistor and a capacitor, and sometime the people don't like adding extra components.
Tell me whether the hardware filter would be fine for you, and I'll explain how to implement it.
Thanks Mario, I managed to solve it by recording the time I got the first interrupt and then ignoring others for 100ms. Not sure I understand why I can't use my software filter. when i get the interrupt, I record the time and process it. If I get another and time is less than 100ms from first i just ignore it (don;t run my calcs). That said, I'm interested in how to solve in hardware
A good hardware debounce circuit (i.e. filter) actually prevents false transitions (both edges) on the input pin. That's important, because you are using the interrupt, and on every edge the handler is called. That is, a lot of useless overhead.
So, if you want to use the interrupt, I'd recommend to implement a good hardware debounce circuit (2nd link, fig. 3 is the best one).
Since you probably won't like adding lot of parts (especially whereas you have many buttons), I'd suggest to avoid the interrupt and use a trivial polling. Let a dedicated thread running for all the buttons polling, then filter in a full-software fashion the actual inputs.
I bet on the far lesser overhead than the dozens of interrupt callback calls.
Good luck!
Biggest fault of Netduino? It runs by electricity.
A good hardware debounce circuit (i.e. filter) actually prevents false transitions (both edges) on the input pin. That's important, because you are using the interrupt, and on every edge the handler is called. That is, a lot of useless overhead.
So, if you want to use the interrupt, I'd recommend to implement a good hardware debounce circuit (2nd link, fig. 3 is the best one).
Since you probably won't like adding lot of parts (especially whereas you have many buttons), I'd suggest to avoid the interrupt and use a trivial polling. Let a dedicated thread running for all the buttons polling, then filter in a full-software fashion the actual inputs.
I bet on the far lesser overhead than the dozens of interrupt callback calls.
Good luck!
Thanks mario. i can't really use polling for my application. If I can't figure out how to disable interrupts, I'll go with a hardware option
Mark, I noticed that the ST MCU (Netduino 2/Plus 2) embeds a Schmitt-trigger stage on every input stage. That is, the mentioned circuit (2nd link, figure 3) will require only the "passive" parts: resistors, capacitor and diode. It should be far simpler to implement.
However, I must admit that you should face some calculation task, and related test. As the document points out, you should also consider the parts tolerances and the different hysteresis thresholds.
Perhaps the very best solution is using a custom chip, or relying on the old-faithful NE555: