Hi all,
Just did a quick "git push" to test that I can actually push onto the EOMA-68 EC firmware repo. Changes are trivial: on branch master, I just did some cleanup of main.c; more to come soon.
Also, I created a new branch, "aaribaud/nucleo-f072rb", for stuff which allow/help developing the EC firmware on the NUCLEO dev board. That branch is intended to stay rebased on top of "master".
Luke: right now I intend to keep on pushing onto master; but maybe you prefer that I push onto a dev branch (e.g. "aaribaud/master"), and from time to time you or I do a merge into master?
Amicalement,
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Jul 19, 2016 at 11:30 AM, Albert ARIBAUD albert.aribaud@free.fr wrote:
Hi all,
Just did a quick "git push" to test that I can actually push onto the EOMA-68 EC firmware repo. Changes are trivial: on branch master, I just did some cleanup of main.c; more to come soon.
awesome. btw please don't remove things that are commented out, #if 0 them out instead - they're usually there for some sort of debug or experimentation purposes.
also: there is a chromebook using the STM32F072 with keyboard controller firmware as well, it's quite hard to understand.
one major thing that needs doing is to add a 2nd USB-HID "mouse" endpoint, starting possible with the mouse usb-hid example which makes the cursor move backwards and forwards. i happen to have a dual-keyboard-and-mouse logitech thing so the dual endpoint is attached just so we don't lose track... i'll also add it here
http://rhombus-tech.net/community_ideas/laptop_15in/pcb2/usbhid.txt
Also, I created a new branch, "aaribaud/nucleo-f072rb", for stuff which allow/help developing the EC firmware on the NUCLEO dev board. That branch is intended to stay rebased on top of "master".
Luke: right now I intend to keep on pushing onto master; but maybe you prefer that I push onto a dev branch (e.g. "aaribaud/master"), and from time to time you or I do a merge into master?
naah, haven't got time to mess about with branches, unless it's a really big rewrite that needs everyone to work *in* that branch.
Hi Luke,
Le Tue, 19 Jul 2016 17:44:17 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net a écrit:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Jul 19, 2016 at 11:30 AM, Albert ARIBAUD albert.aribaud@free.fr wrote:
Hi all,
Just did a quick "git push" to test that I can actually push onto the EOMA-68 EC firmware repo. Changes are trivial: on branch master, I just did some cleanup of main.c; more to come soon.
awesome. btw please don't remove things that are commented out, #if 0 them out instead - they're usually there for some sort of debug or experimentation purposes.
I'll put them back, see below.
Still, some conditionally compiled code *can* be cleaned up. One obvious example is the code in main.c which sets up the system tick: we know the EC microcontroller is going to be the STM32F072 no matter what, so __ARM_ARCH_6M__ is going to always be defined and we can do away with the inner #if/#else/#endif; and we need the system tick, so the outer #if 1 / #endif can go away too.
also: there is a chromebook using the STM32F072 with keyboard controller firmware as well, it's quite hard to understand.
Noted, thanks.
one major thing that needs doing is to add a 2nd USB-HID "mouse" endpoint, starting possible with the mouse usb-hid example which makes the cursor move backwards and forwards. i happen to have a dual-keyboard-and-mouse logitech thing so the dual endpoint is attached just so we don't lose track... i'll also add it here
http://rhombus-tech.net/community_ideas/laptop_15in/pcb2/usbhid.txt
Thanks. I'll add that to my TODO list. :)
Also, I created a new branch, "aaribaud/nucleo-f072rb", for stuff which allow/help developing the EC firmware on the NUCLEO dev board. That branch is intended to stay rebased on top of "master".
Luke: right now I intend to keep on pushing onto master; but maybe you prefer that I push onto a dev branch (e.g. "aaribaud/master"), and from time to time you or I do a merge into master?
naah, haven't got time to mess about with branches, unless it's a really big rewrite that needs everyone to work *in* that branch.
OK -- I'll rollback my initial change and commit back a version with test code kept in (and timer tick code simplified).
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!
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... :) 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. :)
Amicalement,
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sat, Jul 23, 2016 at 4:52 PM, Albert ARIBAUD albert.aribaud@free.fr wrote:
Hi Luke,
Le Tue, 19 Jul 2016 17:44:17 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net a écrit:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Jul 19, 2016 at 11:30 AM, Albert ARIBAUD albert.aribaud@free.fr wrote:
Hi all,
Just did a quick "git push" to test that I can actually push onto the EOMA-68 EC firmware repo. Changes are trivial: on branch master, I just did some cleanup of main.c; more to come soon.
awesome. btw please don't remove things that are commented out, #if 0 them out instead - they're usually there for some sort of debug or experimentation purposes.
I'll put them back, see below.
thanks albert
Still, some conditionally compiled code *can* be cleaned up. One obvious example is the code in main.c which sets up the system tick: we know the EC microcontroller is going to be the STM32F072 no matter what, so __ARM_ARCH_6M__ is going to always be defined and we can do away with the inner #if/#else/#endif; and we need the system tick, so the outer #if 1 / #endif can go away too.
can't remember why i put it in...
also: there is a chromebook using the STM32F072 with keyboard controller firmware as well, it's quite hard to understand.
Noted, thanks.
one major thing that needs doing is to add a 2nd USB-HID "mouse" endpoint, starting possible with the mouse usb-hid example which makes the cursor move backwards and forwards. i happen to have a dual-keyboard-and-mouse logitech thing so the dual endpoint is attached just so we don't lose track... i'll also add it here
http://rhombus-tech.net/community_ideas/laptop_15in/pcb2/usbhid.txt
Thanks. I'll add that to my TODO list. :)
:)
Also, I created a new branch, "aaribaud/nucleo-f072rb", for stuff which allow/help developing the EC firmware on the NUCLEO dev board. That branch is intended to stay rebased on top of "master".
Luke: right now I intend to keep on pushing onto master; but maybe you prefer that I push onto a dev branch (e.g. "aaribaud/master"), and from time to time you or I do a merge into master?
naah, haven't got time to mess about with branches, unless it's a really big rewrite that needs everyone to work *in* that branch.
OK -- I'll rollback my initial change and commit back a version with test code kept in (and timer tick code simplified).
awesome
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
l.
Where can the code be found? I probably can't do anything valuble with it but so far curiosity hasn't killed this cat :)
/fuumind
lör 2016-07-23 klockan 17:28 +0100 skrev Luke Kenneth Casson Leighton:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma 68
On Sat, Jul 23, 2016 at 4:52 PM, Albert ARIBAUD <albert.aribaud@free. fr> wrote:
Hi Luke,
Le Tue, 19 Jul 2016 17:44:17 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net a écrit:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Jul 19, 2016 at 11:30 AM, Albert ARIBAUD albert.aribaud@free.fr wrote:
Hi all,
Just did a quick "git push" to test that I can actually push onto the EOMA-68 EC firmware repo. Changes are trivial: on branch master, I just did some cleanup of main.c; more to come soon.
awesome. btw please don't remove things that are commented out, #if 0 them out instead - they're usually there for some sort of debug or experimentation purposes.
I'll put them back, see below.
thanks albert
Still, some conditionally compiled code *can* be cleaned up. One obvious example is the code in main.c which sets up the system tick: we know the EC microcontroller is going to be the STM32F072 no matter what, so __ARM_ARCH_6M__ is going to always be defined and we can do away with the inner #if/#else/#endif; and we need the system tick, so the outer #if 1 / #endif can go away too.
can't remember why i put it in...
also: there is a chromebook using the STM32F072 with keyboard controller firmware as well, it's quite hard to understand.
Noted, thanks.
one major thing that needs doing is to add a 2nd USB-HID "mouse" endpoint, starting possible with the mouse usb-hid example which makes the cursor move backwards and forwards. i happen to have a dual-keyboard-and-mouse logitech thing so the dual endpoint is attached just so we don't lose track... i'll also add it here
http://rhombus-tech.net/community_ideas/laptop_15in/pcb2/usbhid. txt
Thanks. I'll add that to my TODO list. :)
:)
Also, I created a new branch, "aaribaud/nucleo-f072rb", for stuff which allow/help developing the EC firmware on the NUCLEO dev board. That branch is intended to stay rebased on top of "master".
Luke: right now I intend to keep on pushing onto master; but maybe you prefer that I push onto a dev branch (e.g. "aaribaud/master"), and from time to time you or I do a merge into master?
naah, haven't got time to mess about with branches, unless it's a really big rewrite that needs everyone to work *in* that branch.
OK -- I'll rollback my initial change and commit back a version with test code kept in (and timer tick code simplified).
awesome
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
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
Hi fuumind,
Le Sun, 24 Jul 2016 08:28:28 +0200 fuumind fuumind@openmailbox.org a écrit:
Where can the code be found? I probably can't do anything valuble with it but so far curiosity hasn't killed this cat :)
See http://rhombus-tech.net/community_ideas/laptop_15in/pcbs/pcb2/
NOTE: there is a typo in the git repo address. Where it says:
git clone http://git.rhombus-tech.net/?p=eoma-firmware.git
You should actually type:
git clone http://git.rhombus-tech.net/eoma-firmware.git
Luke: ^
Also, in case you feel like tinkering with the firmware on a NUCLEO board, the rhombus-tech repo has the master branch as updated by me, but not the aaribaud/nucleo-f072rb branch which /might/ be useful.
Luke: maybe the rombus repo should carry the aaribaud/nucleo-f072rb branch?
/fuumind
Amicalement,
Thanks!
I've got about 10 minutes total of soldering experience so trying to set up a NUCELO board won't be the first thing on the list but taking a peak on the code will be very interesting!
/fuumind
sön 2016-07-24 klockan 09:18 +0200 skrev Albert ARIBAUD:
Hi fuumind,
Le Sun, 24 Jul 2016 08:28:28 +0200 fuumind fuumind@openmailbox.org a écrit:
Where can the code be found? I probably can't do anything valuble with it but so far curiosity hasn't killed this cat :)
See http://rhombus-tech.net/community_ideas/laptop_15in/pcbs/pcb2/
NOTE: there is a typo in the git repo address. Where it says:
git clone http://git.rhombus-tech.net/?p=eoma-firmware.git
You should actually type:
git clone http://git.rhombus-tech.net/eoma-firmware.git
Luke: ^
Also, in case you feel like tinkering with the firmware on a NUCLEO board, the rhombus-tech repo has the master branch as updated by me, but not the aaribaud/nucleo-f072rb branch which /might/ be useful.
Luke: maybe the rombus repo should carry the aaribaud/nucleo-f072rb branch?
/fuumind
Amicalement,
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sun, Jul 24, 2016 at 8:18 AM, Albert ARIBAUD albert.aribaud@free.fr wrote:
Hi fuumind,
Le Sun, 24 Jul 2016 08:28:28 +0200 fuumind fuumind@openmailbox.org a écrit:
Where can the code be found? I probably can't do anything valuble with it but so far curiosity hasn't killed this cat :)
See http://rhombus-tech.net/community_ideas/laptop_15in/pcbs/pcb2/
NOTE: there is a typo in the git repo address. Where it says:
git clone http://git.rhombus-tech.net/?p=eoma-firmware.gitYou should actually type:
git clone http://git.rhombus-tech.net/eoma-firmware.gitLuke: ^
done. wiki is editable btw
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,
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sun, Jul 24, 2016 at 8:20 AM, Albert ARIBAUD albert.aribaud@free.fr wrote:
Hi Luke and all,
hii albert,
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).
#ifdef STM32F072_NUCLEO
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.
yeahyeah exactly
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?
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)
Also: video of the whole thing in the works! :)
_great_
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,
--- 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
arm-netbook@lists.phcomp.co.uk
-
Albert ARIBAUD -
fuumind -
Luke Kenneth Casson Leighton