[Arm-netbook] First push to EOMA-68 firmware :)

[Albert ARIBAUD]

Hi Luke,

Le Sun, 24 Jul 2016 15:10:24 +0100
Luke Kenneth Casson Leighton <lkcl at 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,
-- 
Albert.