-
just for safety I'd make sure you switch the pins to inputs before you set the other pins to outputs...
I had intended that - ...crucial... that no output conflicts are there... - but obviously missed to code it properly... :(
Blind or continuous polling is not - practically never - sustainable, especially when not the only thing that has to go on - not just in regard of (battery) power consumption, but more so for wasting cycles. Was going for touch begin and end detection in a later state when having figured out the calculation stuff. For now, I just have the counters. I'll definitively try the provided code...
When I thought about the edge-event drivenness, I was not sure if I would get always a clean edge-trigger because of the voltage divider circuitry of the powered plane edges preset to supply and ground voltage. Your code I read the solution: you set both C2 AND C3 to high, C1 to a float (free, 'un-pulled input), and C0 to (pulled-down) input with (one time only) edge trigger (interrupt set to be fire only once). I see no reason why this should not work for a touch begin-detection. After a begin has been detected, the pin settings for polling and polling will take place until end-detection. End-detection is required - because the trigger has to be setup again (you may notice that in my code has only begin-detection).
When timeout can be dropped, then there is no need for callback pattern either. Callback was only introduced to make delayed reading possible. Some testing could show if the code execution creates enough delay for the outputs and inputs to stabilize / settle.
Looks great - it could make a really handy module...
About pins, what you've got looks good. Personally, I'd change the code to use the multiple digitalRead/Write functionality - and just for safety I'd make sure you switch the pins to inputs before you set the other pins to outputs...
I'm not sure if using digitalRead (instead of analogRead) will work for setting state, but it's worth a try.
Also it's worth trying without the setTimeouts - as the code takes a while to execute anyway, you'll probably find you don't need them.
or with multiple reads:
One neat addition would be to detect taps without polling, and then to only poll when you know a finger is pressed. I'm not 100% sure if this works, but what about:
That'd effectively stop using CPU cycles when a finger wasn't pressed. For other applications where you want long battery life it'd be handy too.