[Arm-netbook] Keyboard news

[Albert ARIBAUD]

Hi all,

For those following dev on the EC, I've just tested transposing the
matrix rows and columns, which worked as expected, that is, exactly
the same as before transposing (including ghosting), but doing 40 GPIO
accesses for a whole scan instead of 64.

The only problem I hit was specific to the NUCLEO: I had already
replaced keyboard GPIOs PA2, PA3 and PA5, which are used on the NUCLEO,
with PA13, PA14 and PA15, but I only just noticed that PA13 and PA14 are
also used (for ST-Link/V2.1) so I had to change again, this time for
PA8, PA9 and PA10 which are unused as far as I can tell from scrubbing
the NUCLEO reference manual.

I'll push the changes tomorrow.

I have not started implementing priority policy or ghost jamming yet,
because I'm still thinking over how to implement both in the most
economic way.

Amicalement,
--
Albert.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachme

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Thu, Aug 4, 2016 at 10:40 PM, Albert ARIBAUD <***@free.fr> wrote:
> Hi all,
>
> For those following dev on the EC, I've just tested transposing the
> matrix rows and columns, which worked as expected, that is, exactly
> the same as before transposing (including ghosting), but doing 40 GPIO
> accesses for a whole scan instead of 64.

ah fantastic.

> The only problem I hit was specific to the NUCLEO: I had already
> replaced keyboard GPIOs PA2, PA3 and PA5, which are used on the NUCLEO,
> with PA13, PA14 and PA15, but I only just noticed that PA13 and PA14 are
> also used (for ST-Link/V2.1) so I had to change again, this time for
> PA8, PA9 and PA10 which are unused as far as I can tell from scrubbing
> the NUCLEO reference manual.

oops :)

> I'll push the changes tomorrow.

awesome.

> I have not started implementing priority policy or ghost jamming yet,
> because I'm still thinking over how to implement both in the most
> economic way.

would you be happy to do a quick video, put it on youtube? maximum 90 seconds.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachm

[KillerKink Goh]

Any chance that there will be ubuntu-based computer card shipped as default?

There is already debian/fedora based.

[m***@gmail.com]

2016-08-05 7:44 GMT+02:00 KillerKink Goh <***@hotmail.sg>:

>
>
> Any chance that there will be ubuntu-based computer card shipped as
> default?
>
> There is already debian/fedora based.
>
I Don't think so. Ubuntu is in no way FSF endorsable. Ubuntu has one-click
access to non-free drivers and apps or even automated.

Debian is already on the tipping point hence the "Practically Perfect" name.

But Since Debian is running, installing Ubuntu should be possible.

>
> _______________________________________________
> arm-netbook mailing list arm-***@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-***@files.phcomp.co.uk
>

[Christian Kellermann]

* KillerKink Goh <***@hotmail.sg> [160805 07:45]:
> Any chance that there will be ubuntu-based computer card shipped as default?
> There is already debian/fedora based.

Hm, that would need a plethora of work atm. While there is an Ubuntu
ARM system targeted at ARMv7+ architectures one would need to add a
custom kernel package to it amonst other things. As noone has done so,
you'd either have to do it yourself or look for someone doing it.

This might be a lot of work or it might not, depending on the state of
the Ubuntu ARM release.

But I would not expect Luke to put in this effort at this stage, since
there are a plethora of options available already, most respecting
your freedom better than Ubuntu.

Kind regards,

Christian

--
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large a

[m***@gmail.com]

2016-08-05 8:37 GMT+02:00 Christian Kellermann <***@pestilenz.org>:

> * KillerKink Goh <***@hotmail.sg> [160805 07:45]:
> > Any chance that there will be ubuntu-based computer card shipped as
> default?
> > There is already debian/fedora based.
>
> Hm, that would need a plethora of work atm. While there is an Ubuntu
> ARM system targeted at ARMv7+ architectures one would need to add a
> custom kernel package to it amonst other things. As noone has done so,
> you'd either have to do it yourself or look for someone doing it.
>

> This might be a lot of work or it might not, depending on the state of
> the Ubuntu ARM release.
>

http://linux-sunxi.org/Bootable_OS_images (none for EOMA-68 off course)
http://linux-sunxi.org/Build_Instructions_for_Ubuntu


>
> But I would not expect Luke to put in this effort at this stage, since
> there are a plethora of options available already, most respecting
> your freedom better than Ubuntu.
>

I think so too


>
> Kind regards,
>
> Christian
>
> --
> May you be peaceful, may you live in safety, may you be free from
> suffering, and may you live with ease.
>
> _______________________________________________
> arm-netbook mailing list arm-***@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-***@files.phcomp.co.uk
>

[Ralf-Peter Rohbeck via arm-netbook]

On 04.08.2016 23:47, ***@gmail.com wrote:
> 2016-08-05 8:37 GMT+02:00 Christian Kellermann <***@pestilenz.org
> <mailto:***@pestilenz.org>>:
>
> * KillerKink Goh <***@hotmail.sg
> <mailto:***@hotmail.sg>> [160805 07:45]:
> > Any chance that there will be ubuntu-based computer card shipped as default?
> > There is already debian/fedora based.
>
> Hm, that would need a plethora of work atm. While there is an Ubuntu
> ARM system targeted at ARMv7+ architectures one would need to add a
> custom kernel package to it amonst other things. As noone has done so,
> you'd either have to do it yourself or look for someone doing it.
>
>
> This might be a lot of work or it might not, depending on the state of
> the Ubuntu ARM release.
>
>
> http://linux-sunxi.org/Bootable_OS_images (none for EOMA-68 off course)
> http://linux-sunxi.org/Build_Instructions_for_Ubuntu
>
>
> But I would not expect Luke to put in this effort at this stage, since
> there are a plethora of options available already, most respecting
> your freedom better than Ubuntu.
>
>
> I think so too
I just saw in the rumor mills that AMD Zen APUs are planned to go down
to 4W.
Now I don't know how open those will be and if they'll run without
microcode blobs but one can dream...

[Luke Kenneth Casson Leighton]

On Wed, Aug 10, 2016 at 9:10 PM, Ralf-Peter Rohbeck via arm-netbook
<arm-***@lists.phcomp.co.uk> wrote:

> I just saw in the rumor mills that AMD Zen APUs are planned to go down to
> 4W.

that would be nice. it'd need to be run at around 60% of its max
speed (on average) to fit within the power budget

> Now I don't know how open those will be and if they'll run without microcode
> blobs but one can dream...

if AMD are continuing their current design strategy... mmm.... no.
but yeah we can always dream :)

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
S

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Fri, Aug 5, 2016 at 6:44 AM, KillerKink Goh <***@hotmail.sg> wrote:
>
>
> Any chance that there will be ubuntu-based computer card shipped as default?

you're aware that any company that violates the GPL [1] is no longer
a company but is actually operating outside the law - i.e. is
classified as a Criminal Cartel, also known as an Organised Crime
Syndicate? given that i have not seen any reports indicating that
canonical has fixed their flagrant GPL violations despite repeatedly
being told about them, what you're in effect asking me is that you'd
like me to endorse a criminal cartel called "Canonical" that *also*
has a track record of abusing the privacy of its users [2] [3]?

i'm running this campaign along ethical lines (where RYF endorsement
is just one part of that). _why_ would i want to endorse *any*
company that operates in a completely unethical way??

the reason why i'm including debian is because their hearts are in
the right place, even if they've had to go through some rough times
recently [4] [5]. they're not controlled by any one organisation
(government or corporation, each with vested interests). they have a
Social Charter: it's not perfect, but it's a hell of a lot better than
any of the alternatives (and a lot better than not having a Charter at
all).

apologies if you weren't aware of these things and that they come as a
bit of a shock.

l.


[1] https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/
[2] https://fixubuntu.com/
[3] https://www.eff.org/deeplinks/2012/10/privacy-ubuntu-1210-amazon-ads-and-data-leaks
[4] https://lists.debian.org/debian-devel/2014/11/msg00174.html
[5] https://lists.debian.org/debian-ctte/2014/11/msg00091.html

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.

[Albert ARIBAUD]

Le Fri, 5 Aug 2016 01:33:52 +0100
Luke Kenneth Casson Leighton <***@lkcl.net> a écrit:

> > I'll push the changes tomorrow.
>
> awesome.

Did it only now, because of a slight annoyance: sometimes the build
would not run at all on the target, in a reproducible way: a given
state of the source code would either always work, or never work. And
the change that would make a working source code stop working could be
as simple as declaring a static uint8_t variable even without using it,
which made me look for alignment issues.

So I set up non-working case, broke with GDB into it, found the core
in a hardfault indeed, and did a bit of climbing up and down the stack.

Turns out the uint8_t array usbd_control_buffer[] declared in
usbifaces.c is sometimes cast to an uint16_t array, and so undergoes
word accesses. However, an array of uint8_t does not have alignment
constraints, so depending on the size and alignment of other globals or
static locals, usbd_control_buffer could begin on an odd address, which
would make the uint16_t alias misaligned, and the first read or write
to it would hardfault.

I fixed this by aligning usbd_control_buffer on a 4-byte boundary (so
that even a cast to uint32_t would not cause misaligments).

I then rebuilt and measured the transposing of the keyboard (using
Timer2 as a free-running 1/48th-of-a-microsecond counter, see branch
aaribaud/kbd_timing for an example).

Before transposing, a whole keyboard scan would be 16 columns times
about 425 cycles per column, total about 141 us. After transposing, it
is 8 columns times about 686 cycles per column, that is, about 115 us,
an 18% reduction.

All the code is in the repo now.

I /think/ there might be some finer improvements to make.

Amicalement,
--
Albert.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large at

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Sun, Aug 7, 2016 at 11:17 PM, Albert ARIBAUD <***@free.fr> wrote:
> Le Fri, 5 Aug 2016 01:33:52 +0100
> Luke Kenneth Casson Leighton <***@lkcl.net> a écrit:
>
>> > I'll push the changes tomorrow.
>>
>> awesome.
>
> Did it only now, because of a slight annoyance: sometimes the build
> would not run at all on the target, in a reproducible way: a given
> state of the source code would either always work, or never work. And
> the change that would make a working source code stop working could be
> as simple as declaring a static uint8_t variable even without using it,
> which made me look for alignment issues.
>
> So I set up non-working case, broke with GDB into it, found the core
> in a hardfault indeed, and did a bit of climbing up and down the stack.
>
> Turns out the uint8_t array usbd_control_buffer[] declared in
> usbifaces.c is sometimes cast to an uint16_t array, and so undergoes
> word accesses. However, an array of uint8_t does not have alignment
> constraints, so depending on the size and alignment of other globals or
> static locals, usbd_control_buffer could begin on an odd address, which
> would make the uint16_t alias misaligned, and the first read or write
> to it would hardfault.

bleugh!

> I fixed this by aligning usbd_control_buffer on a 4-byte boundary (so
> that even a cast to uint32_t would not cause misaligments).

awesome

> I then rebuilt and measured the transposing of the keyboard (using
> Timer2 as a free-running 1/48th-of-a-microsecond counter, see branch
> aaribaud/kbd_timing for an example).
>
> Before transposing, a whole keyboard scan would be 16 columns times
> about 425 cycles per column, total about 141 us. After transposing, it
> is 8 columns times about 686 cycles per column, that is, about 115 us,
> an 18% reduction.

that's pretty damn good... 0.000115 seconds...

> All the code is in the repo now.
>
> I /think/ there might be some finer improvements to make.

... is it worth it at this phase?

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.c