--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sun, Jul 24, 2016 at 8:35 PM, Albert ARIBAUD albert.aribaud@free.fr wrote:
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
eek! ok. well if it's done there it should be ok, not too much code needed on the STM32F. got it.
Ok for "make -DSTM32F072_NUCLEO=1 and letting the Makefile pass that to the compiler (and also conditionally add chain2dfu to the source list).
that's the one