--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sun, Jul 31, 2016 at 6:04 PM, Albert ARIBAUD albert.aribaud@free.fr wrote:

Hi Luke,

Le Sun, 31 Jul 2016 16:48:58 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net a écrit:

...

---

crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sun, Jul 31, 2016 at 3:03 PM, Albert ARIBAUD albert.aribaud@free.fr wrote:

...

Hi all,

I have gone ahead and pushed my latest round of improvements for keyboard support in the EOMA-68 laptop EC firmware.

The new feature is support for modifiers (ctrl, shift, alt, GUI).

hooray! awesome, albert. oh, one other thing, you probably noticed, i do polling not any kind of interrupt-driven stuff. i'd like to keep it that way for now as it would massively complicate adding other hardware support (I2C, etc.)

Agreed re interrupts; I don't intend to introduce any interrupt.

ack.

There is one structural change I'd like to make, though, and it is to split the handling into a GPIO scanning part which would be *very* tight and *very* short code running directly from the timer tick (that would allow getting rid of the udelay() call BTW) and a USB reporting part which would run in the main loop. Roughly, the scanning part would raise a flag to tell the reporting part as soon as it sees a raw scan difference, and the reporting part would lower that flag wenever it sends the report for the last scan available.

sounds really sensible

But before I get there, I want to finish optimizing GPIO use. I've already lowered column GPIO writes from 18 down to 2 per column, so right now, scanning the whole matrix requires 16*(2 writes + 8 reads)= 160 GPIO accesses (down from an original 416).

But all rows could be read in two global GPIO bank reads, then matched against the individual GPIO masks in the row table; that would shave 6 GPIO reads per column, lowering the total to 16*(2 writes + 2 reads) = 64 GPIO accesses.

Better still: transposing the matrix, that is, using 8 columns (ex rows) as outputs and 16 rows (ex columns) as inputs over three banks (GPIOA, B and C), a full scan would need 8*(2 writes + 3 reads) = 40 GPIO accesses.

mmmm.... you have to think about the implications of that, first, as to whether key-combinations would end up being mis-detected. if double the number of keys are "activated" because you pull "rows" high instead of "columns".... you see what i mean? or does it not matter?

From there, there is still a way to lower that to 32 GPIO accesses by setting and clearing output GPIOs in a single write using BSRR, but it would require extending LIBOPENCM3 with an added "gpio_set_clear() function. Hey, why not, after all. :)

:)

...

one thing that would be really good would be support for several key-presses. the USB-HID "stack" of 6 zeros you are supposed to fill up and send whenever *any* keypress goes up *or* down. at the moment i am only sending *one* keypress (and 5 zeros).

Actually, this is already handled in the current FW (and that was in before I started working on it): try 'sudo usbhid-dump -d 0483:5710 -e a' (with*out* the KBD_DEBUG macro) and successively depress Q W E R T Y. You'll see the report filling in.

i... ehn? i implemented that already?? maaan i must have been busy to have forgotten about it already... :)

What is not handled now is rollover error reporting: when a 7th key is depressed, the report should contain 0x01 in all six places; right now, the 7th key generates no report.

yeahyeah i know about that one. not sure what to do though.

l.

Le Sun, 31 Jul 2016 19:44:47 +0200 Albert ARIBAUD albert.aribaud@free.fr a écrit:

Le Sun, 31 Jul 2016 18:09:11 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net a écrit:

...

...

Better still: transposing the matrix, that is, using 8 columns (ex rows) as outputs and 16 rows (ex columns) as inputs over three banks (GPIOA, B and C), a full scan would need 8*(2 writes + 3 reads) = 40 GPIO accesses.

mmmm.... you have to think about the implications of that, first, as to whether key-combinations would end up being mis-detected. if double the number of keys are "activated" because you pull "rows" high instead of "columns".... you see what i mean? or does it not matter?

It doesn't. The matrix is really a 16x8 mechanical switch matrix; switches just connect one "row" and one "column", but "rows" and "columns" don't have different physical properties; in fact, even the names "row" and "column" are misnomers. You could switch those names and the device would work the same.

So really, it's just "a group of 8 lines, and a group of 16 lines, and up to 128 switches, each switch connecting one member of one group to one member of the other group", and it's how we use either group that makes one "a set of outputs" and the other "a set of inputs". The only constraint is to use all members in each group the same way: either all columns are outputs and all rows are inputs, or all columns are inputs and all rows are outputs.

(there is actually a second constraint: "use pull-up inputs, and above all, use open-drain outputs or else pray that the GPIO pins on the STM32 are fool-resistant", but that's slightly beside the point.)

Thinking more about it, maybe you were thinking about up to 16 keys being depressed rather than 8, and the inputs' fan-ins adding up to twice more and the output's fan-out not being able to cope, leading to the input voltage not falling low enough for the keys to be detected as down.

Looking at the data sheet, and taking the worst case:

- V(IL) is either 1.06V or 1.46V depending on the pin. Worst case: 1.06V.

- V(OL) is 0.4V across all output configurations for | I(IO) | < 8 mA and V(DDIO) > 2.7V.

We have V(DDIO) = VDD = 3.3V, so V(DDIO) > 2.7V is covered; we need to check if we have | I(IO) | < 8 mA.

I(IO) will be proportional to the number of switches closed on a given column when that column is drained to VSS. Worst case is all 8 (for the current firmware) switches closed. From the datasheet:

- Pull-up resistances are between 25 and 55 kOhm. Worst case, 25 kOhm.

- 8 parallel pull-ups would yield 25/8 = 3.12 kOhm.

- 3.3V / 3.12 kOhm ~ 1.06 mA, way below 8 mA.

With 16 inputs, we halve the overall impedance down to 1.6 kOhm and double the current to 2.12 mA, still way below the 8 mA.

(also, we are far below the total power consumption of 120 mA. Just being exhaustive here.)

I haven't found any other constraint.

Technically, I should have taken the switches' impedance (about 200 Ohm) into account in case it worsens things; but those 200 Ohms would increase the pull-up impedance and reduce the current, so actually a 0 Ohm switch impedance is the worst case already.

So I think that's OK, but you know what? Let me try it. :)

Amicalement,

Bonjour,

Le Sun, 31 Jul 2016 20:51:51 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net a écrit:

On Sun, Jul 31, 2016 at 8:34 PM, Albert ARIBAUD albert.aribaud@free.fr wrote:

...

Thinking more about it, maybe you were thinking about up to 16 keys being depressed rather than 8, and the inputs' fan-ins adding up to twice more and the output's fan-out not being able to cope, leading to the input voltage not falling low enough for the keys to be detected as down.

not quite... maybe i was but hadn't quite got it through from subconscious into words.. but that's a good point - i was thinking if you used 8 fan-in and press 9 keys... if you have 16 fan-in and press 9 keys...

basically the 16 fan-in it "activates" 50% less of the matrix.

Hmm... Not getting what you're hinting at. Can you develop?

...

Technically, I should have taken the switches' impedance (about 200 Ohm) into account in case it worsens things; but those 200 Ohms would increase the pull-up impedance and reduce the current, so actually a 0 Ohm switch impedance is the worst case already.

So I think that's OK, but you know what? Let me try it. :)

:)

I'll do that tomorrow evening, though. Real World is looming. :)

Amicalement,

Le Sun, 31 Jul 2016 21:56:13 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net a écrit:

...

Hmm... Not getting what you're hinting at. Can you develop?

it's related to mis-detection of keys. if you press certain combinations in certain ways, you get "ghost" keys that you can't tell if they were actually pressed or not. by reducing the number of keys that are "live" (16 fan-in only activates up to 8 maximum where as 8 fan-in could activate up to 16 maximum) you reduce the possibility of "ghosting".

there was an article online about it... ah! found it: http://pcbheaven.com/wikipages/How_Key_Matrices_Works/

Ok, got your point now.

Too late today to do probabilities (heck, even in the morning right after my coffee shot I would not trust my skills in probabilities). Still, I intuitively (yeah, I know) think there is no reduction in the risk of ghosting when transposing the matrix, because there is no asymmetry in the ghosting problem; ghosting occurs as soon as three of the four connections between two rows and two columns are closed: at that point, there is no way to tell whether the fourth connection is open or closed, and this, regardless of any notion of "row", "column", or "activity".

IOW, whether or not a given state of the keyboard matrix will exhibit ghosting is only defined by the distribution of the depressed keys on the matrix, not by the rotation with which we look at that matrix or whether it currently has an active column.

Amicalement,

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*, 16 columns run twice more chances of ghosting than 8 columns do; it cancels out.

Or you can consider this exercize:

Consider our QWERTY laptop keyboard's columns 8 and 9 and rows 2 and 3. Here they are represented with the keys at their intersections :

8 9 | | | | KEY_E | | KEY_O ----------------X-----------X------------ 2 | | | | | | KEY_3 | D | KEY_9 ---------------- -----------X------------ 3 | | | | | |

The "X" marks at intersections denote a depressed key, which connects its row and column; so in the example above, the three keys E, O and 9 are depressed.

First exercize: let's "activate" column 8 and read rows 2 and 3, "Activating" column 8 means pulling it down hard, which drags row 2 down, which drags column 9 down, which drags row 3 down, so we read both rows 2 and 3 down and conclude that keys E and 3 are down: key 3 is ghosted.

Second exercize: same keyboard with same depressed keys, but instead of activating column 8 and reading rows, we activate row 3 and read columns. Pulling row 3 down hard drags column 9 down, which drags row 2 down, which drags column 8 down, so we read both columns 8 and 9 down and conclude that keys 3 and 9 are down: key 3 is ghosted.

You can try this exhaustively if you like: for every keyboard state defined by which of its keys are down, you will end up with exactly the same set of ghosted keys whether you activate columns and read rows or activate rows and read columns.

i think.

too much for my brain to cope with....

:)

Amicalement,

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,