Le Sun, 31 Jul 2016 18:09:11 +0100 Luke Kenneth Casson Leighton lkcl@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.)
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... :)
Git says that was committed on 2015-12-26 round 10PM... Your loss of memory might have less to do with being busy and more to do with consequences of end-of-year celebrations. :)
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.
Either we uphold the 6-key limitation (and then we should follow the convention about sending rollover error codes as long as more than six keys are down, ignoring any new depressed key) or we weight keys by priority and send the 6 most prioritary keys among those depressed (possibly dropping a less prioritary already-depressed key when a more prioritary one is depressed).
If we go that way, then we need to define key priorities...
Candidates for priority reporting could be the W, A, S, and D keys. I would have added I, J, K and L but we have a hard 6-key limit... Player One will have a slight advantage over Player Two. :)
Amicalement,