linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Kent Gibson <warthog618@gmail.com>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>
Subject: Re: [PATCH 0/8] gpiolib: add an ioctl() for monitoring line status changes
Date: Wed, 4 Dec 2019 13:32:31 +0100	[thread overview]
Message-ID: <d0f29707-cbb6-fbee-3d54-f336a11442ad@metux.net> (raw)
In-Reply-To: <CACRpkdaW8YxjEBN0jX5AYmzGyftGv=b-KOCsjMMxoqqESBDsyA@mail.gmail.com>

On 29.11.19 13:57, Linus Walleij wrote:

Hi,

> My own pet peeve is the industrial automation and control use
> case: here we have the design space where people today use
> either PLC:s or RaspberryPi's or Beagle boards, or even some
> custom computers.
> 
> For me personally that is a design space we should cover and
> if this helps the RaspberryPi to do that better I'm all for it.

Yeah, I also have clients in that field. The main problem here,
IMHO is their way of thinking: no device abstraction at all, but all
pretty much hardwired for specific installations (also the reason,
why they'll fail miserable on the new IOT field :p). These folks are
still used to the ancient pure PLC way, where there isn't even anything
like an operating system.

IMHO, it's an educational problem: people need to understand that
there're device abstractions for good reasons, and they should respect
and use them. Basically, they have to understand the concept of
modularization and abstractions. IEC 1131-3 obviously isn't made for
that.

For example, take simple heating installation. Pumps won't be controlled
by raw inverter configuration anymore, but rpm or m²/sec. Temp or flow
sensors don't give raw numbers, but degress Kelvin or m^/sec, etc.
In that case, the corresponding subsystem would be IIO - no need to ever
care about gpios, pwms, etc, directly.

Following this modular approach, everything suddenly gets much easier,
eg. replacing a pump by a different model just requires a minor
reconfiguration instead of rewriting huge parts of the plc code.

I've managed to teach this to an Siemens field technician in one evening
with a few beers, so it can't be that hard to understand.

> An especially interesting case is multiple GPIO expanders
> plugged in on pluggable busses such as PCI or USB. I think
> that kind of discoverability and dynamically expandable GPIO
> blocks is something people in the industry are quite keen to
> get.

Smells like a case for oftree overlays ...

> What we need to do is to make it dirt simple to use GPIOs for
> custom hacks and construction of factories and doorstops
> and what not, while at the same time strongly discouraging
> it to be used to manage hardware such as laptops, tablets
> or phones from userspace. That's maybe hard, and we might
> be victims of our own success ...

I contradict. We should encourage industrial/construction folks to
do decently structured, professional engineering - IOW: use
modularization and highlevel drivers, instead of tinkering with
raw gpios directly like a school kid.


--mtx

-- 
Dringender Hinweis: aufgrund existenzieller Bedrohung durch "Emotet"
sollten Sie *niemals* MS-Office-Dokumente via E-Mail annehmen/öffenen,
selbst wenn diese von vermeintlich vertrauenswürdigen Absendern zu
stammen scheinen. Andernfalls droht Totalschaden.
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

  reply	other threads:[~2019-12-04 12:32 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-27 13:35 [PATCH 0/8] gpiolib: add an ioctl() for monitoring line status changes Bartosz Golaszewski
2019-11-27 13:35 ` [PATCH 1/8] gpiolib: use 'unsigned int' instead of 'unsigned' in gpio_set_config() Bartosz Golaszewski
2019-11-27 13:35 ` [PATCH 2/8] gpiolib: have a single place of calling set_config() Bartosz Golaszewski
2019-11-27 13:35 ` [PATCH 3/8] gpiolib: convert the type of hwnum to unsigned int in gpiochip_get_desc() Bartosz Golaszewski
2019-11-27 13:35 ` [PATCH 4/8] gpiolib: use gpiochip_get_desc() in linehandle_create() Bartosz Golaszewski
2019-11-27 13:35 ` [PATCH 5/8] gpiolib: use gpiochip_get_desc() in lineevent_create() Bartosz Golaszewski
2019-11-27 13:35 ` [PATCH 6/8] gpiolib: actually protect the line event kfifo with mutex Bartosz Golaszewski
2019-11-27 13:35 ` [PATCH 7/8] gpiolib: add new ioctl() for monitoring changes in line info Bartosz Golaszewski
2019-11-27 15:24   ` Kent Gibson
2019-11-27 15:50     ` Bartosz Golaszewski
2019-11-27 23:23       ` Kent Gibson
2019-11-28  9:45         ` Bartosz Golaszewski
2019-11-28 14:10           ` Kent Gibson
2019-11-28 14:36             ` Bartosz Golaszewski
2019-11-28 15:02               ` Kent Gibson
2019-11-29  9:43                 ` Bartosz Golaszewski
2019-11-29 13:49                   ` Kent Gibson
2019-12-01 15:25                     ` Bartosz Golaszewski
2019-12-01 23:43                       ` Kent Gibson
2019-12-02 17:11                         ` Bartosz Golaszewski
2019-12-03  2:09                           ` Kent Gibson
2019-12-03  8:58                             ` Bartosz Golaszewski
2019-11-27 13:35 ` [PATCH 8/8] tools: gpio: implement gpio-watch Bartosz Golaszewski
2019-11-29 10:04 ` [PATCH 0/8] gpiolib: add an ioctl() for monitoring line status changes Linus Walleij
2019-11-29 10:58   ` Bartosz Golaszewski
2019-11-29 12:57     ` Linus Walleij
2019-12-04 12:32       ` Enrico Weigelt, metux IT consult [this message]
2019-12-04 12:06     ` Enrico Weigelt, metux IT consult
2019-12-04 16:26       ` Bartosz Golaszewski
2019-12-06 12:52         ` Enrico Weigelt, metux IT consult
2019-12-06 15:57           ` Bartosz Golaszewski
2019-12-06 15:44       ` Linus Walleij
2019-12-06 17:50         ` Enrico Weigelt, metux IT consult

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d0f29707-cbb6-fbee-3d54-f336a11442ad@metux.net \
    --to=lkml@metux.net \
    --cc=bgolaszewski@baylibre.com \
    --cc=brgl@bgdev.pl \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=warthog618@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).