"My question what is the complexity of the code required compared to just using the schmitt trigger? If I have to write and test complex code to do this than I much rather just do it in hardware and be done with it. There is always multiple ways to do something, but which one requires less resources and is a more practical application. "
First, need to address this again, I think you are confusing 'Schmitt trigger' with an RC filter. It does not matter if you are using ha hardware or software debounce, you still need a schmitt trigger on the input. Arduino's have them built in on all GPIO pins so it is a non-issue if you only need the number of I/O pins the Arduino has. If you need more I/O than that, you'll need to add something like a 7417 or other Schmitt trigger, or find a shift register or port expander that has them built in.
As for the software solution, the code looks something like this:
// Define variables:
byte MB1_State; // current pin state - high/low
byte MB1_StateLast; // pin state on last read - high/low
byte ManualButtonOnePin = 2; // pin of Arduino input is connected to
unsigned long CurrentTime; // clock variable for current cpu clock time
unsigned long ManualButtonOneClock; // clock variable for input debounce
byte DebounceTime = 20; // time to wait before declaring a state after a change of input (ms)
byte ManualButtonOneCurrentState; // debounced value for the rest of the sketch to use for the input state.
// Actual routine:
CurrentTime = millis(); // set the clock to the current time
MB1_State = digitalRead(ManualButtonOnePin); // read the input pin
if (MB1_State != MB1_StateLast) ManualButtonOneClock = CurrentTime; // if it's not the same as it was last time reset the clock
if (CurrentTime >= ManualButtonOneClock + DebounceTime) ManualButtonOneCurrentState = MB1_State; // if the clock runs out reset the state the rest of the program uses.
MB1_StateLast = MB1_State; // Save the input pin's state to compare with on the next cycle.
This routine takes 894 bytes of memory as opposed to the 742 bytes it takes just to read the pin without the debounce. Some of that is also overhead that is not repeated in additional instances of the debounce for other inputs. There are other variations on the theme here, but this method gives the results I like.
"I would keep track power & ground separated from 5V DC power."
My plan is to have the ground of my ATX supply connected to track common anyway to use the 12v rail for triggering. It's already connected so it doesn't matter. You only need isolation if there is a current path available. in this case there is no way for spikes to travel across the void of space/air between the AC hot and 12VDC + connections, nor between +12 and +5, so a spike is effectively isolated from any of the electronics. You can connect the ground of 800 different power sources together without a problem. it's only an issue when you start trying hook the high ends together.
"Where it makes told sense the Arduino boards themselves. Paying $5 from China vs. spending $20. Same with Servos. "
I actually own one genuine Arduino board for each type of knock off I own, that sit on a shelf and never end up getting used for anything. I buy these to support the research and development of the project. I don't think Microchip technology Inc is going to get a kickback from LadyA for selling a part they designed, so I'll just buy it right from the source. I prefer to spend my money to support development, not supply chains. For something like the MCP23017, it's not really a big deal. for many jellybean components, however, the markup is rather insane, even over digikey or mouser.
"The library does depend on the wire library and automatically includes it within the library. Wait, you are going to tell me that you wouldn't use the library because it depends on the wire library? A few lines back you are arguing hardware vs. software debouncing, which proves my point that there has to be some limit on the software side. "
Yes. the limit is how much memory your microprocessor has to store the program. Libraries eat up memory like crazy. The wire library alone chews up over 1200 bytes of space. If you're using a Mega, or a raspberry Pi, then memory is probably not a problem. On an Uno, Nano, or ProMini you've only got about 30K bytes to work with. Then you have Up's like the ATtiny's that often have a whopping 1KB of space, less than the wire library alone. I admit my code is sloppy most of the time by professional standards, by trying my best not to waste space is something that was beat into me. If you have a simple sketch it won't matter, but when things get complex, shaving a couple kilobytes can save you.
On the shift registers, the extra wire is pretty meaningless since you get a practically unlimited number of IO pins off of those 3 wires. There are also a number of easy to use libraries out there to handle the code, if you are not worried about the overhead.
"I KNOW that the schmitt trigger does not store a state (I don't know how you got that from what I said). What I was saying was that I much rather use the hardware over the software. "
From this line: "Besides the software can get tied up and eventually miss the train in the non-derail block." It sounds like you think a schmitt trigger will somehow help speed things up or hold a value until the processor gets to it. it takes the same amount of software with or without the Schmitt trigger. Just one way gives you useable inputs, and the other gives you chatter in the data. Using or not using a Schmitt trigger isn't really on the table, it's a needed component to the system for predictable operation.
" The Arduino can WALK and CHEW gum at the same time by doing this (see here). Meaning that it is multitasking, so it is doing what the library needs to and processing through the loop."
The ATmega, unfortunately, can only do one thing at a time. It has just one processor and processes one instruction at a time. In the world of computers it is slow and dumb. It can not actually multitask. Fortunately, humans and mechanical devices are slower and dumber. The arduino Can do one thing and then do another fast enough for us not to be able to tell that the first thing stopped, but it is still just a list of one thing after another, never two things at once. Now there are some things that can happen all at once, but the processor can only make one change at a time.
One other factor not really discussed is board space. when prototyping on solder-less breadboard it really doesn't matter, but if you're trying to do a PCB layout or even fit everything on a perf board, it makes a difference. A resistor may cost a tenth of a penny but the board space under it costs 5 cents. If the cost of the PCB is too high, there's no point in reinventing the wheel as there are already store bought solutions out there if you want to spend the money. The goal here was to replace 8 $20 boards with one that costs $20-30. As stated in a previous post, the two main design factors are cost and ease of assembly for someone with limited skills. We deal with through hole parts to make it easy to assemble, but use as few of them as possible.
Anyway, six hour drive ahead of me. got to run.
JGL
