On 26.04.19 16:42, Enrico Weigelt, metux IT consult wrote:
On 26.04.19 15:36, Jan Kiszka wrote:
At the same time, there are no real alternatives - to my> knowledge - for the value it brings (various bindings) to simply
switch> the engine.
Which value exactly does that collection of crude wrappers and broken
attempts to buypass the kernel (driving gpios via /dev/mem *facepalm*)
provide ?
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++.
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
... We will exploit that when moving to a completely different base hardware
with the next revision or our IOT2000.
mraa belongs to the category of software, I would never put onto any
production system. (yes, I already had a client who asked me to repair
his mraa-based software. finally, I've replaced mraa w/ a few LoC ...)
You also have to keep the class of "cool, I've just created my first Node.RED
node!" IoT newbies in mind. 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!"). By far not all of them have consultants at hand.
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.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
