Blog pessoal de Gustavo Lima.

Categoria: técnico

Every once in a while there comes the will to blog again, and this is that time. Lots of things happened since the last post here, jeez, the first of them being I joined Intel ever since. It’s been fun to work there, by the way. The thing is all of my projects were work on proprietary (and non-disclosable) software for a time, thus the silence.

I had the opportunity of working on a whole visual identity for a Tizen-based smartphone stack, which was awesome. I also had the opportunity of working on an Android fork that implemented multi-windowing. It was not as awesome, because Java gives me the cramps, but I got to learn that system’s internals and learning is always fun.

The next project I jumped onto was really exciting, though (now open source!). I was involved since the very beginning in Soletta‘s design and coding. One thing we had in mind, when starting that in this already fragmented IoT ecosystem we got, is to really make a difference in completeness and ease of use for developers of all backgrounds. There are a lot of claimed IoT solutions out there, really. But what we see is that the majority of them are too focused on a small subset of what an IoT node should be able to accomplish (communications or I/O), but not on everything altogether. Also, the things we saw out there were not portable at all. We wanted porting Soletta to different platforms a breeze from the very beginning.

So, we started our journey. In order to accomplish the ease-of-use part of our proposal, Soletta based its API in a main loop, so that it’s easy for users to hook on events by simply giving callback functions and never having to deal with threads and the like. We started with glib’s main loop as a back-end, but now we got one of our own to share among POSIX systems and we made sure writing implementations for the main loop API is straight-forward for any system (glib is still selectable as a main loop implementation, by the way).

We started with one of the main parts an IoT API must have, then—I/O. We implemented the I/O nodes a program could have by having diverse I/O classes they would inherit from, and the user was supposed to connect nodes with compatible I/O classes together, so they would exchange data.

Early on that work we realized that what we were doing was very much alike J. Paul Morrison’s Flow-based Programming, and that we could benefit from that domain-specific language to have an even more straight-forward and easy way for developers to use Soletta. So we exchanged the APIs and models we got to totally support the FBP model (we now got nodes as in FBP “black boxes” and ports and connections of them). We built a FBP parser and, with that, there was now two ways in which a user could build and run Soletta programs:

By using the C API directly and compiling or

By writing their logic in FBP and using the new sol-fbp-runner tool to run it

We did not stop there, though. Thinking back of the portability promise, we made a sol-fbp-generator tool, which would take FBP input and output equivalent C code for that. This came to aid on real IoT platforms where runnable programs do not exist and everything must be compiled and linked into a final image. Average developers still don’t have to know very deeply any details of IoT operating systems that way with Soletta—they simply write their flow, with the nodes they need, and they are good to go. One important thing is that Soletta’s flow layer is not mandatory. If the constraints dictate so, one can always write Soletta applications using the rest of its C API directly and skipping the overhead (which is already really low) of the flow.

Here is what a FBP sample looks like. One declares nodes by giving them a name (timer is the name we chose for a timer node), followed by parenthesis, the node type’s name, and (optionally) colon and the node’s instance parameters. In that case, we got a timer with a 1000 milliseconds timeout. The next important things are port nodes. We must connect output ports (always written after a node’s reference) to input ports (written before node references). There, we connect the timer’s OUT port to a toggle’s IN port. The data that flows between nodes is called packets in Soletta. Ports’ supported packet types must match, so that their connection is possible. In that case, the timer outputs the empty packet type (which is just a “pulse”), while the IN port of the toggle node expects any packet type (again, it just needs a “pulse”), so they are good as a match for a connection. The toggle node belongs in the boolean family of nodes: it will keep an internal boolean state and ouput (and change) that state every time a pulse comes into its input port. Thus, the example will just print two boolean values that will change every 1 second.

By using FBP to develop with Soletta, one is able to even make use of node meta types, where there’s even more freedom of behavior customization. As of now, Soletta exposes the JavaScript meta type, where you declare a node’s input/output ports as well as the logic gluing the former to the latter all in JavaScript, directly in the FBP file. Also, there are the meta HTTP (both client and server) nodes, where one can serve and consume a custom packet they declare directly in the flow as well.

That boolean valuen to the console sample was just a dumb example of Soletta’s capabilities, naturally. Take a look at all the nodes it has, as of now. As you can see, we’re very far from that I/O-only beginning. We’ve got nodes doing all types of communication: bluetooth, CoAP, HTTP, LWM2M, MAVLink, MQTT, OIC, etc. On I/O we cover basically everything that’s relevant for IoT: analog to digital converters, GPIO, I²C, PWM, SPI, UART. We also handle persistence/storage on a various models (EFI variables, file systems and flash-memories), have Linux IIO sensors exposed and much more. Take a look at our API for yourself.

Our ease of porting effort has proved itself very good as well. Soletta will now run on any of the following systems:

It’s for real, any FBP program (with nodes having implementations on all of them) will work on each of those systems out of the box (also architecture independent). With around 100kb of final image (operating system included), we have functionalOIC/OCF nodes running on very resource constrained SoCs, like the Arduino 101 or the Atmel SAM R21 Xplained Pro.

It’s been a fun journey (Soletta is one and a half years old now), and we’re finally calling it a version 1 soon! I hope all you developers in the search of solution for your IoT products have the chance to evaluate Soletta and give us feedback. There are a lot of things about Soletta and its infrastructure I did not talk about (it will be released as a behemoth already, it’s huge in what it encompasses!), so please take a look on all Soletta’s ecosystem as well.

Curtir isso:

This is a quick post for all of you Enlightenment developers and users (the latter also willing to adhere to that weird coding style). The named coding style, which seems to historically have come from Rasterman’s text editor, Jed, has been recently been called for a standardization/modification by means of an uncrustifyconfiguration file.

While the file itself is still not perfect (there are “indentation bugs” yet), I wanted to have my editor — Emacs — to help me to adapt to that thing. So, I present you with a crude first attempt at it: http://github.com/glima/Emacs-uncrustify. Patches are obviously welcome.

By the way, exciting news are emerging from E-land, so stay tuned for hot hot new stuff, soon.