Date:   Mon, 29 Apr 2019 13:09:20 +0200
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     Jan Kiszka <jan.kiszka@...mens.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-gpio@...r.kernel.org, linux-acpi@...r.kernel.org,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: [PATCH 2/2] gpio: sch: Add interrupt support

On 26.04.19 18:03, Jan Kiszka wrote:

> Leaving that blunt hack aside:
> 
> import mraa
> 
> pin = mraa.Gpio(13)
> pin.dir(mraa.DIR_OUT)
> pin.write(1)
> 
> And the same goes for nodejs, java and c++.

Such trivial wrappers are easy write in the coffe break.
For those usecases the good old sysfs interface is really sufficient.

(I'm frequently replacing those kind of "abstraction layers" of sevaral
10kLoC in various client projects by just a few lines of really tiny
shim ...)

And relying on numeric gpio ids is generally a bad idea.
(exactly one of the kind of problems why certain clients call me in
great despair, when it broke again :p)

> Moreover, this allows you to abstract away where "Pin 13" actually came
> from on that board if the kernel changes (BSP -> upstream...) or the
> extension board or ... 

As said: numeric pin IDs are a *bad* idea.
If it's a *name* (=string), then that seems to be a usecase for labels.
For convenience, you could just pupulate the fs w/ proper symlinks that
are named by the pin names from the schematics.

> We will exploit that when moving to a completely
> different base hardware with the next revision or our IOT2000.

When doing that, you could also kick out Intel and move to ARM, as quite
everybody else does ;-)

<snip>

> You also have to keep the class of "cool, I've just created my first
> Node.RED node!" IoT newbies in mind.

As said above: writing a small js wrapper for that is just a coffee
break job.

> These higher abstraction help to
> keep them away from the wrong lower APIs - or enable them to do
> something at all ("Cool, I've just connected my first two nodes!"). 

gpio's are already very low-level. Highlevel would be things like keys,
leds, etc.

That's one of the things I frequently have to teach my clients: first
make yourself clear about what you're *actually* doing with these pins
and then pick the right drivers.

Okay, we could talk about creating some nice oftree-overlay generators,
to make it easier for newbies. Or create some small DSL, perhaps w/ some
tiny GUI editor. But don't let them play w/ raw gpio's - this quickly
goes horribly wrong (I've seen that in the field, many times).

It's nice, that you folks (Siemens) are now doing your own controller,
so you can finally throw out the ugly AMX+co crap. But please don't
repeat their mistakes. We don't need yet another raspi for building
automation - we need a different programming model than the old PLC-
style spaghetti configuration :p

(oh, and if you add ATEX and railways certification, I might have a new
customer for you ;-))

Okay, that's getting far OT, so maybe we should continue off-list ;-)

> By far not all of them have consultants at hand.

They better should :p

> And while we only ship our IOT2000 image with mraa and all the fun as
> reference image, it's way more for quite a few users. Even if you do not
> want to look behind the curtains of certain software components (that we
> primarily inherited and then started to clean up), they are working, or
> we would have heard.

Maybe because some field techs rather grab some beers and go to some
friend who happens to be a linux hacker, instead of burning their time
on the official channels those big corporate structures ;-)


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287

Powered by blists - more mailing lists