drjohsmith
- Joined Dec 13, 2021
- 852
HiAs drj says, this is just for discussion and thinking out loud.
I cannot see a reason why the Arduino got fried.
100Ω pull-up to Vcc would not kill a GPIO if it is always set to input mode.
Pullup to +12V would destroy the chip.
Enabling the GPIO in output mode would also kill the chip.
I can see that debouncing the input in software could alleviate the problem if the code only responds to sustained constant level. Debouncing code commonly waits for 50ms for the switch to settle. We would have to determine the impact of this long delay knowing the linear speed of the translation motor. The purpose of limit switches is to stop the motor dead in its tracks as soon as the limit is reached. This is a fault condition.
As for input threshold voltages, I am going by the Atmel ATmega328 data sheet.
At Vcc = 5V, high level threshold is 2.6V, low level threshold is 2.1V.
In the picture, there is no proper place for resistor termination.
At the switch, the signal line is grounded.
At the Arduino, the input pin sees a very long antenna with 50kΩ input termination. It would be impractical to put resistor termination to GND at the input. The proper solution is to use an optocoupler.
yes, Opto is the way to go
QED: don't put low value resistor to ground on the wires.
Debounce
As far as I understand things,
the debounce code, switches its output on the first edge, then disregards any further edges for a time
i.e as I understand things, the debounce library code does not add a delay till the output is detected, over a few machine code cycles, certainty a lot less than the inherent delay a RC input filter as described above would produce