--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sun, Aug 7, 2016 at 11:17 PM, Albert ARIBAUD albert.aribaud@free.fr wrote:
Le Fri, 5 Aug 2016 01:33:52 +0100 Luke Kenneth Casson Leighton lkcl@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.
bleugh!
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).
awesome
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.
that's pretty damn good... 0.000115 seconds...
All the code is in the repo now.
I /think/ there might be some finer improvements to make.
... is it worth it at this phase?
l.