Hi Luke,
Le Sun, 24 Jul 2016 15:10:24 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net a écrit:
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.
hmm is KEY_& specific to azerty?
Well, "KEY_&" does not exist, but it represents semantics of KEY_1 which are specific to AZERTY: while for QWERTY, "KEY_1" means "1" when unshifted and "!" when shifted, the same key in AZERTY means "&" when unshifted and "1" when shifted. USB HID has no key code for this; it is emulated at the OS layout level
Which leads to a problem with keyboard-level AZERTY support: simply put, it can only be done for AZERTY keys or combinations whose meaning is also that of a USB HID keyboard key code plus possible modifier(s). For instance, a USBHID keyboard can emulate the French "&" by combining modifier "shift" plus key "7", and can emulate the French combination "shift &" by sending key "1" and releasing shift; but, for instance, "ù" cannot be emulated at all, as no QWERTY combination can produce it. It does not even have a key combination. It only appears on my screen because my OS knows that the code for the "quote" key should produce "ù".
Note that basic emulation at keyboard level would be enough for the purpose of controlling a bootloader, where accented characters are not that important; suffice that letters, digits and punctuation are produced like an AZERTY user expects them to be.
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?
yeah drop it into the wiki, it's editable. suggest doing a #ifdef STM32F072_NUCLEO (make -D ST.... option, not in the Makefile or source code)
Ok for "make -DSTM32F072_NUCLEO=1 and letting the Makefile pass that to the compiler (and also conditionally add chain2dfu to the source list).
Amicalement,