[Arm-netbook] EOMA-68 laptop Keyboard support improvement pushed

Albert ARIBAUD albert.aribaud at free.fr
Sun Jul 31 20:34:50 BST 2016


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

> Le Sun, 31 Jul 2016 18:09:11 +0100
> Luke Kenneth Casson Leighton <lkcl at 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,
-- 
Albert.



More information about the arm-netbook mailing list