Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos


Since a while, B1i has released its ECMA-Adapter (available on all hardware platforms) in order to speed up development for concrete adapters or - in the IoT world - sensor interfacing applications. But what is the fastest way in order to come up-to-speed?

This small ECMA-Adapter Cookbook blog (it also could be framed as "assisted cribbing guide") shall show up a promising path towards fast success. The groundwork for all was laid in the former posts
"B1i GY302-Adapter, Mk I: The Basics"  and "B1i GY302-Adapter, Mk II: H[e]a[n]ds on!"
As a concrete example, an implementation for a BME280 humidity-, temperature- and barometric pressure-sensor is supplied that shows up how such a project concretely can look like.

The BME280 is a breakout-board around the same named Bosch-sensor for environmental values (temperature, humidity, barometric pressure), suitable e.g. for usage in the RasPi or Arduino environment. It exposes its functionality via the I2C-Bus protocol.

There comes up the general problem about how to quickly get up-to-speed about using e.g. sensors / making adapters for them in B1i:
The very hard way is scratch-building by reading the datasheet and crafting the necessary code, as e.g. for the BME280.
As you can see (also referring to the attached C-code), this isn’t an easy way at all….

The pre-built alternative facts


So in general for sensor / adapter development in B1i, it would be worth to figure out what already is there in terms of coding:

  • If you develop in Arduino, you search in the community (the mainstream; you’d always find multiple options), as e.g. this article.

  • If you develop explicitly for Atmel micro-controllers (as in our demo machines), you also search the Arduino community, realizing that Arduino libraries are nothing else than C++ libraries exposing objects and carefully hiding the details to the audience.
    So, you transpose the C++ code to C.

  • If you’re on the Raspi and Python, you’re as well mainstream and can search the community (also finding multiple options)

  • If you’re on B1i, you’re on Java and … pretty out of luck from the first view, as Java on RasPi is not that mainstream as e.g. Python is!
    In B1i on the XxxPi, the B1i-exposed Java library PI4J exposes the hardware that in turn relies on the C-API wiringPI that b.t.w. also is the low level foundation for Python there. But that’s the end of the official paved road here…


But the situation is not that poor as it looks like:
Due to the universal ECMA (Meta-)Adapter in B1i, Javascript comes into the scene. Speaking in object-oriented programming, the ECMA-Adapter can be seen as a kind of abstract base-class for real adapters. Concretely, the ECMA-Adapter means having the Nashorn Javascript engine, basing upon ECMAScript V5, with a few preview-features of V6, as to see here. But ECMAScript and the RasPi still makes no community.
But what has a huge community and eco-system (and also has its occurrence on the RasPi) is the node.js framework: There do exist countless (and also sometimes hardware-specific) modules / libraries for sensors and whatever else.
So the very conclusion is:
If you want to do a (Javascript based) adapter in B1i (also, but NOT ONLY on the RasPi!), look for a blueprint on node.js first!

How to get node.js modules working for the ECMA-Adapter


The basic challenge in doing so is that node.js has another environment / basics than B1i. That concretely means:

  • Find an implementation / make a small glue layer for the low level technical basics:
    The technical connectivity of sensors always is similar: Using GPIO, I2C, SPI, USB, 1-Wire, RS232, RS485.
    So in most cases, it will be necessary to once supply this connectivity emulating in a suitable way a particular node.js module:
    Because these higher level modules (as e.g. the following used one for the BME280) typically also rely on such lower level transport protocol modules.
    The emulation of such a lower level transport protocol module should not be that hard as they typically are very small and have simple functionality. Once done, there is a big chance for re-use for future projects.

  • Potentially retro-fit ECMAScript 6 or better syntax to ECMAScript 5:
    node.js is one of the parties that have all of the latest ECMAScript features implemented very fast. On the other hand side, Nashorn implementing V5 always has some feature lag. So if you e.g. face a ‘class’ in your source, there needs to be done a conversion to a form implementing this in another way.
    The good message is: There are no showstopper features entirely impossible to do in another way in older ECMAScript versions.
    As the last rescue, Java can come to help (what is missing in the original node.js).

  • Design a suitable adapter specific XML <-> JSON data passing and potential adapter parameterization. This is a specific (but not rocket-science) task to do.


The supplied demo implementation


For the concrete case, the overall task best is structured into 3 distinct logical parts (means Javascript source files). They are (in the necessary dependency-order):

  • i2c_nodejs_emu.js
    This is the i2c ‘class’ that emulates the used node.js i2c module:
    On the one hand side, it emulates the required API towards the top-side. Towards the bottom side, it needs to use the I2C facilities of PI4J. For that purpose, it is necessary to dive down to Java for a bit. A concrete low-level caveat is to handle properly the conversion of raw binary bytes to a respective Javascript number.

  • CLCL_bme280.js
    This is the adopted high level BME280 module from node.js, using the low level I2C module:
    There is little to do herein, it basically contains the hardware-neutral and Javascript centric “business logic”. That would be the very place to look for non available Javascript features to back-port.

  • bme280_adapter.js
    Finally, this is the B1i specific adapter module that needs to do the data-passing and to retrieve the I2C facilities:
    In order to get them, a tiny API part of the B1i PI4J exposure (Pi4JResourceDispenser) needs to be used for a usage it in a concurrently compliant way (strange that all such sensor coding thinks that it is the single one and only thing performing on the machine).
    In fact, the concurrency compliant execution is accomplished by embedding the whole I2C activities within a before-after pattern supplied by B1i for the I2C bus.
    The data conversion (=marshaling) is done using B1i’s convenient XML <-> JSON payloadtype-conversion facilities (JSONPltConf) via the B1i interfacing API for Javascript execution (scriptIO).


From a Javascript perspective, it is of particular interest about how classes can be emulated in versions <6, as Javascript knows about objects, but not about classes.
These 3 files should be supplied in the given order as a script-group to the ECMA-Adapter, as the order reflects the established inter-dependencies / stacking.

 

Raspi3_BME280_Steckplatine

Finally, if you want to try out this example, find above the wiring diagram for attaching the sensor to the Raspi.

The BME280 is an example for a more complex sensor from the usage point of view as some pos-computation is necessary. For most other sensors, coding is much easier.
Leveraging the node.js community + code is a promising general strategy in order to quickly come up-to-speed. It's not about to prove to be able to develop the code for such a sensor, but about how quickly it is possible to get reasonable results.
Happy sensoring!

(This blog-post originally appeared on my Da Vinci Space Blog: https://davincispace.wordpress.com/2019/03/08/b1i-ecma-adapter-cookbook-feat-bme280/)