--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sun, Jul 31, 2016 at 6:04 PM, Albert ARIBAUD <[email protected]> wrote: > Hi Luke, > > Le Sun, 31 Jul 2016 16:48:58 +0100 > Luke Kenneth Casson Leighton <[email protected]> a écrit: > >> --- >> crowd-funded eco-conscious hardware: >> https://www.crowdsupply.com/eoma68 >> >> >> On Sun, Jul 31, 2016 at 3:03 PM, Albert ARIBAUD >> <[email protected]> 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. _______________________________________________ arm-netbook mailing list [email protected] http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to [email protected]
