Hi Luke and all,
Le Sat, 23 Jul 2016 17:28:09 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net a écrit:
BTW, I now have the keyboard, and have soldered the FPC connector to a breakout flat wire ribbon which I will be able to connect to the board!
yay!
Of course, I goofed up when I set out soldering, and every pair of wires on the ribbon is swapped, i.e. FPC pin #1 is ribbon wire #2, FPC pin #2 is ribbon wire #1, FPC pin #3 is ribbon wire 4, FPC pin #4 is wire #3, etc... :)
aw doh
Still, despite my terrible soldering inability, no wire is cut or shorted to another one, so as long as I keep the swapping in mind while plugging the ribbon's wires onto the board, everything should work fine. :)
looking forward to hearing how you get on man
Things went quite well actually. :)
On the first run, almost all keys were detected. Going through the whole set, I found that keys on lines 13 and 14 on the FPC connector -- which due to my swapping were actually... lines 14 and 13 :) -- were totally undetected.
After checking that they were working on the ribbon cable, I went through the EOMA-68 EC schematics to find out that these lines are mapped to PA2 and PA3, which on the NUCLEO schematics are not bridged by default to the morpho connectors; that explained why the associated matrix row and column seemed dead. :)
I could have solder-bridged PA2 and PA3 (and un-bridged PA5 while at it), but they are used for ST-Link/V2-1 and LD2. I prefer to keep the NUCLEO untouched so that others can use theirs out of the box, so I reworked my existing NUCLEO-specific git branch to replace PA2, PA3 and PA5 with PA13, PA14 and PA15 in the keyboard matrix code. That's not a perfect solution as the EC hardware uses PA13 as LCD_RESET and PA15 as SPI1_NSS, but it Works For Now(tm).
Once that was done, all keys were detected -- as QWERTY of course, i.e. key labeled "A" sends KEY_Q, key labeled "&" sends KEY_1, etc. My PC has a Linux system which maps QWERTY codes to an AZERTY layout, so I could have actually typed this very post on the Chicony keyboard through the NUCLEO... If modifiers (alt, shift, ctrl...) were handled by the EC firmware, which they're not for now. :)
So, once modifier support is added in the EC firmware (working on it right now!) an EOMA-68 running Linux could support an AZERTY keyboard (or any keyboard for which a translation table exists) as much as any other Linux laptop -- assuming the final keyboards are the Chicony QWERTY and AZERTY keyboards we're toying with right now.
But I still want to write an AZERTY EC firmware, because it will allow "native" use of the keyboard with *any* software on the EOMA-68, not just those which can translate QWERTY to AZERTY; bootloaders, for instance, typically don't do keyboard table translation.
But an AZERTY EC firmware will require more than just rewriting the key code matrix: for instance, there is no "KEY_&" code, so that one will have to be emulated with a "modifier SHIFT + KEY_1" combination, and so on for the rest. Nothing unfeasible, mind you, or terribly difficult either. It'll just eat up a bit more resources than I initially thought it would; my ballpark estimate is about 256 added bytes for code plus 128 added bytes for read-only data in FLASH, and a few added bytes in RAM.
BTW: it might be a good idea to provide written instructions for people to reconfigure their NUCLEO board for EOMA-68 EC hardware compatibility by filling solder bridges SB62 and SB63, and clearing SB13, SB14 and SB21. Is there a separate EOMA-68 doc repo somewhere where I could put this, or can/should I create eoma68/laptop_15in_pcb2/doc/ under the eoma-firmware repo and put that info in there, say as a MarkDown format README-NUCLEO.md file?
Also: video of the whole thing in the works! :)
Amicalement,