--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, Aug 3, 2016 at 7:39 AM, Albert ARIBAUD <[email protected]> wrote: > Hi Luke, > > Le Mon, 1 Aug 2016 20:31:17 +0100 > Luke Kenneth Casson Leighton <[email protected]> a écrit: > >> --- >> crowd-funded eco-conscious hardware: >> https://www.crowdsupply.com/eoma68 >> >> >> On Mon, Aug 1, 2016 at 8:21 PM, Albert ARIBAUD >> <[email protected]> wrote: >> > Le Mon, 1 Aug 2016 01:15:43 +0100 >> > Luke Kenneth Casson Leighton <[email protected]> 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. that was the logic going through my head, yes. > 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. that's kinda what i figured > 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. .... something like that :) > 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. yeahyeah. keyboards are *designed* so that the chances of these keypresses is greatly reduced > 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, yeahyeah - but that costs. > 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 :) they weren't warnings... i just don't like it or see the necessity for the complexity, i feel that if i have to use a jtag port i'm doing something wrong, but that's just me >, 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! yay! _______________________________________________ arm-netbook mailing list [email protected] http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to [email protected]
