Soletta™ Project

<br/>

Soletta Project is a framework for making IoT devices. With Soletta Project's libraries developers can easily write software for devices that control actuators/sensors and communicate using standard technologies. It enables adding smartness even on the smallest edge devices.

Portable and scalable, it abstracts details of hardware and OS, enabling developers to reuse their code and knowledge on different targets.

General Information

Soletta Project uses sol as C namespace, so macros start with SOL_ and functions, enumerations, structures and others start with sol_.

It uses a main loop to provide single threaded cooperative tasks (co-routines) triggered by UNIX file-descriptors, timers or idlers (runs whenever there is nothing else to do). The traditional main loop is based on Glib's GMainLoop, while some smaller OS have their own implementation, see main loops documentaion.

Building from Source

Before you start, check the build requirements.

Some Soletta parts depends on projects that can be fetched via git submodules:

OIC depends on tinycbor, tinydtls and IoTDataModels
JS metatypes depends on duktape
Mavlink API depends on mavlink

To make sure all these projects are fetched and correct versions are checked out, just run:

make thirdparty-update

It requires Internet access.

The build system is based on linux kernel's kconfig. To configure it with default configuration values run:

make alldefconfig

To update the configurations using a curses based interface run:

make menuconfig

To update the configurations using a line-oriented interface run:

make config

More options and variables are available with:

make help

To compile use (from top directory)

make

or to be verbose and get all the commands being executed:

make V=1

To install run:

make install

the default behavior is to install in the root dir (namely /), but to install in a different root dir run install as:

make install DESTDIR=/path/to/install/root/

Debug

Soletta provides sol-log to provide meaningful critical, error, warning, informational or debug messages in a simple way. The following environment variables affect sol-log behavior:

export SOL_LOG_LEVEL="LEVEL"

    defines the maximum level to show messages. This affects all
    domains. The value of LEVEL can be an integer or the string
    alias such as CRITICAL, ERROR, WARNING, INFO, DEBUG, CRI, ERR,
    WRN, INF, DBG.

export SOL_LOG_LEVELS="domain1:level1,domain2:level2,...,domainN:levelN"

    the fine-grained version of $SOL_LOG_LEVEL that specifies
    different levels per domain. The specification is a key:value
    pair, the key being the domain name and the level being an
    integer or string alias.

export SOL_LOG_ABORT="LEVEL"

    if a message_level is less or equal to LEVEL, then the program
    will abort execution with abort(3). Say SOL_LOG_ABORT=ERROR,
    then it will abort on critical or error messages.
    Defaults to critical only.

export SOL_LOG_SHOW_COLORS=[0|1]

    will disable or enable the color output.
    Defaults to enabled if terminal supports it.


export SOL_LOG_SHOW_FILE=[0|1]

    will disable or enable the file name in output.
    Enabled by default.

export SOL_LOG_SHOW_FUNCTION=[0|1]

    will disable or enable the function name in output.
    Enabled by default.

export SOL_LOG_SHOW_LINE=[0|1]

    will disable or enable the line number in output.
    Enabled by default.

Note that at compile time some levels may be disabled by usage of SOL_LOG_LEVEL_MAXIMUM C-pre-processor macro, which may be set for Soletta itself (internally) by resetting it on kconfig (i.e menuconfig: Core library -> Log -> Maximum log level).

or by applications if they define that in some way. Then messages above that number will be compiled out and using $SOL_LOG_LEVEL or $SOL_LOG_LEVELS for those numbers won't have effect.

On systems where setting environment variables is not an option, both $SOL_LOG_LEVEL and $SOL_LOG_LEVELS may be defined at build time by adding them to the application's CFLAGS.

CFLAGS += -DSOL_LOG_LEVEL=\"CRIT\"
CFLAGS += -DSOL_LOG_LEVELS=\"domain1:level1,domain2:level2,...\"

Libraries

common

Main loop, logging and access to platform details such as services and state.

Main loop will allow cooperative routines to run in a single thread, they can be started from a timeout (timer), an interruption handler, file descriptor monitor (POSIX-like systems) or when nothing else is running (idlers).

Logging allows different domains to be logged independently, making it is easy to debug an application or Soletta itself.

Platform allows checking the system state, if it's ready, still booting, degraded (something failed), going to shutdown and so on. It has the concept of services that can be started or stopped as well as monitored for a dynamic lifecycle management.

comms

Comms consists on a few communication modules. It provides ways to deal with network, CoAP protocol and OIC protocol (server and client sides).

Network

Network library provides a way to handle network link interfaces, making it possible to observe events, to inquire available links and to set their states.

CoAP

Implementation of The Constrained Application Protocol (CoAP - RFC 7252). This network protocol is pretty simple and uses a HTTP-like message that is space-efficient over UDP.

OIC

Implementation of protocol defined by Open Interconnect Consortium.

It's a common communication framework based on industry standard technologies to wirelessly connect and intelligently manage the flow of information among devices, regardless of form factor, operating system or service provider.

Both client and server sides are covered by this library.

LWM2M

Lightweight Machine to Machine (LWM2M) is a protocol for communication between IoT devices defined by OMA - Open Mobile Alliance.

LWM2M is a device management protocol, designed to be able to extend to meet the requirements of applications. It's also able to transfer service / application data.

It implements the interface between M2M device and M2M server. Both sides are covered by this library.

MQTT

Wrapper around the mosquitto library implementation of the MQTT protocol.

MQTT is a machine-to-machine (M2M)/"Internet of Things" connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport.

The broker is not covered by the wrapper, only the client.

MAVLink

MAVLink or Micro Air Vehicle Link is a protocol for communicating with small unmanned vehicle. It is designed as a header-only message marshaling library.

It's a wrapper around mavlink/c_library.

flow

Implementation of Flow-Based Programming (FBP), allowing the programmer to express business logic as a directional graph of nodes connected to type-specific ports.

Main Loops

Main loops are responsible to deliver events and timers in a single thread by continuously poll and interleave registered functions. It abstracts every OS particularity and delivers common behavior to Soletta applications.

For instance, while in Linux GPIO interruptions are handled at the kernel level and dispatched to userspace by means of file-descriptors that get notification via poll(2) syscall, in RIOT you get called from the interruption service routine (ISR) and you can mess with other interruptions while you execute your code. Soletta uses mainloop to remove those differences and in RIOT you'll get an internal ISR that queues GPIO events to be later delivered by the mainloop in application's thread.

Same for timers, on some platforms they are preemptive while in others they will be delayed. Soletta will never preempt user and all timers will be queued, thus they may be delayed.

Idlers are tasks to be executed when nothing else is running. These should be implemented by short-run functions as they will not be preempted in any way, thus effectively delaying the dispatch of timers and events. Often idlers are used to implement cooperative co-routines that do a single step of a complex computation and return "true" so they can run again. They can also be used by a worker thread to schedule a fun

Soletta

Install / Use

README