[Arm-netbook] Keyboard news

[Albert ARIBAUD]

Le Fri, 5 Aug 2016 01:33:52 +0100
Luke Kenneth Casson Leighton <lkcl at lkcl.net> a écrit:

> > I'll push the changes tomorrow.  
> 
>  awesome.

Did it only now, because of a slight annoyance: sometimes the build
would not run at all on the target, in a reproducible way: a given
state of the source code would either always work, or never work. And
the change that would make a working source code stop working could be
as simple as declaring a static uint8_t variable even without using it,
which made me look for alignment issues.

So I set up non-working case, broke with GDB into it, found the core
in a hardfault indeed, and did a bit of climbing up and down the stack.

Turns out the uint8_t array usbd_control_buffer[] declared in
usbifaces.c is sometimes cast to an uint16_t array, and so undergoes
word accesses. However, an array of uint8_t does not have alignment
constraints, so depending on the size and alignment of other globals or
static locals, usbd_control_buffer could begin on an odd address, which
would make the uint16_t alias misaligned, and the first read or write
to it would hardfault.

I fixed this by aligning usbd_control_buffer on a 4-byte boundary (so
that even a cast to uint32_t would not cause misaligments).

I then rebuilt and measured the transposing of the keyboard (using
Timer2 as a free-running 1/48th-of-a-microsecond counter, see branch
aaribaud/kbd_timing for an example).

Before transposing, a whole keyboard scan would be 16 columns times
about 425 cycles per column, total about 141 us. After transposing, it
is 8 columns times about 686 cycles per column, that is, about 115 us,
an 18% reduction.

All the code is in the repo now.

I /think/ there might be some finer improvements to make.

Amicalement,
-- 
Albert.