--- 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.