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

[Albert ARIBAUD]

Hi Luke and all,

Le Sat, 23 Jul 2016 17:28:09 +0100
Luke Kenneth Casson Leighton <lkcl at 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,
-- 
Albert.