Hi Luke,
Le Mon, 1 Aug 2016 20:31:17 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net a écrit:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Aug 1, 2016 at 8:21 PM, Albert ARIBAUD albert.aribaud@free.fr wrote:
Le Mon, 1 Aug 2016 01:15:43 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net a écrit:
my point is: if you've activated 2x the amount of keys because you're firing on "rows" (16 activated) instead of "columns (only 8 activated), there's now 2x the chance of having a "ghosting" problem.
*At a given time*, yes, you may think that one active column crossing 16 rows runs twice more chances of ghosting than if it only crosses 8 rows; but then, *over the course of a whole scan*,
logic flaw (i think) - each activation is independent from all others. so with 50% the keyboard's keys "activated" if you use columns instead of rows...
I /think/ I see your point now. What you mean is:
Ghosting causes keys on the active column to be seen as depressed when they are not, and the more keys per column, the more candidates for ghosting when a column goes active; so, doubling the number of rows doubles the number of keys on a column and thus doubles the number of potentially ghosted keys.
However, transposing the matrix also halves the number of columns: twice more candidate keys for ghosting per column times half less columns, the total number of candidates remains the same for the whole matrix.
Or, considered one column at a time: doubling the number of rows doubles the number of candidate keys for ghosting, but also halves the number of columns, thus halving the number of key combinations which will cause ghosting of any of this column's keys. twice more candidate keys for ghosting per column times half less combinations leading to actual ghosting : the column's ghosting risk remains unchanged, which implies that the whole keyboard's ghosting risk remains unchanged.
Anyway:
mmmm it's too much for me to think about. sorry :) perhaps best is to try it, see what happens, after all
Actually I've gotten the split (scan in timer tick context, report in main context) and row GPIO read reduction committed first, then tried ghosting with the current setup.
I've checked that ghosting happens with keys E, O, 9 and 3: any three of these depressed will show the fourth one as depressed too.
Note: my own laptop's keyboard has ghosting too; I'd just had never ever been affected by it, as I'm not a gamer and do not use emacs either. O:-)
So, whatever the orientation, we *will* have ghosting. I believe only gamer keyboards have actual anti-ghosting which they realize either by just putting each key on its own GPIO or by having a diode in series with each switch, methods which won't do with the present project (although some people might want to go and use a non-ghosting keyboard on their own custom laptop).
Ghosting reduction, OTOH, can be done by laying out the matrix so that the most current key combinations won't cause ghosting, and by jamming, that is, not reporting potentially ghost keys.
For the layout, we have to rely on the keyboard manufacturer; we don't control that.
For jamming: we can detect potential ghosts: that'w whenever all four keys are seen down on any set of two columns by two rows. I don't say it's going to be easy, but I've got a few leads.
Now, Which of the four keys we shall report will depend on our priority policy.
Also: despite dire warnings :) , I've gone and set up a debugging environment for the NUCLEO through the ST-Link interface. Took me about one hour to get it working (OpenOCD is a sensitive creature) but it now does!
Of course, there's no way I can step-debug the whole thing since as soon as I break, the USB hosts stops seeing answers from the slave, but I can inspect (possibly ad hoc) state variables and even step-debug through parts of the code.
Amicalement,