Enhancement: per switch debounce/hold

[tablatronix]

Is this the global debounce timing, just the schedule period ? Along with the 2 debouncing states?
20ms?

	if(switches.runLoop()) {
		taskManager.scheduleOnce(20, [] { 
			checkRunLoopAndRepeat();
		});

I see alot of notes in source on abstraction, I assume you might have some plans for some of this already.

Obviously this is a major change in how the lib works, but you might have some clue how you would do it. Not sure the best way would be, easiest would be to track each instances start, timestamping would be trivial to add a var and an evaluation, limitation would be it would have to be periodic to the global task timer, advanced would be to abstract a timer obj for each instance.

Hold time can stay a period counter, but set per instance instead of global hold time.

The reasoning for this is somewhat edge case, but different buttons have different debounce requirements, noisy buttons, crosstalk, long wires, not buttons ( say contacts etc )

This could also allow using non button things that glitch or pulse more than the bounce frequency, say detect pulse trains for linear encoders or counters, detect if something is being spun/moving etc. or capacitive touch via io charge timing etc. This might be better in the end being abstracted into different button "types" with their own class, but the library is not near that and might not want that complexity. There are some others that can do that and probably still use this library underneath it, I have not looked into how that could be done, as most of them are not capable of abstracting out digitalread writes, some are even hardcoded to avr PORT registers blegh.

[tablatronix]

I just realized for that second part, I can probably just make a new abstraction, still looking over the existing ones to understand it. I was confused for a bit because rotary encoder was combined with switches, But I now see how the other ones work, keyboard, dfrobot and joystick.. hmm

[davetcc]

In terms of making the de-bounce time configurable we can look into that. It’s all a trade off of memory for smaller boards over functionality for larger boards. Although that would only need 1 byte per switch so should be quite possible.

For specialist devices, that’s achieved by writing a different IOAbstraction and RotaryEncoder class as needed. See all the implementations that already exist. They provide for many different cases. If you had an unsupported device, then writing an IOAbstraction is not difficult for anyone with moderate C++ skills.

[davetcc]

Functionality to be added is to make the de-bounce time configurable. Step 1 is to look at the code and size up the fix. To see if it is possible to add in a minor version.

[davetcc]

I've moved a few items out of 1.5.0 to make it deliverable in a reasonable time frame. I think there's more documentation needed on how to write a new abstraction for switches, but essentially there'll always be a trade-off between functionality and complexity.

[davetcc]

1.5.1 is a patch release with only minor changes.