In a previous blog post we took a brief look at the MangOH Red and what makes this new board standout. We then started to explore the Legato framework that runs on the Magoh boards (and the Raspberry Pi, instructions here).
We started off looking at a very simple application, heartbeatRed, one that has only one component, includes one source file and uses one API, to interface with two GPIOs (a button and a LED). In this blog we will move further to an application that has multiple components and various APIs. Since in the “Getting Started Guide” an app called redSensorToCloud is used to capture sensor data and post it to AirVantage, we will look at that app.
System Definition File (SDEF)
In the previous blog we started with the ADEF and explained what that is used for in the overall file system, there is however a file above the ADEF. The SDEF (system definition file) lets the overall Legato framework know what is need when the system is compiled. At this point it should be mentioned, Legato allows you to compile the full framework or compile an individual application to be loaded to the target. The SDEF is always needed to compile the framework. An SDEF can not easily be compared to any one part of a C program. The first section #include makes the file look like a regular C file but, in this case the include links in another SDEF, one used for the WiFi modules.
After the include comes the apps section. This is where the a list of all applications to be included in the compilation of the framework are listed. In the SDEF below there are 7 applications listed to be included in the build. Looking through this section we can see the application we are currently looking at, redSensorToCloud, as well as the heartbeatRed application which we explained in the previous blog post.
If any command line tools are needed when logged in as a root-user through a remote shell we need to make them accessible. In order to do so list them under commands. This works in a command name and command extension pair. The portion on the left hand side of the assignment statement is the name used to call the function from the command line. The portion on the right hand side is the location of the command we would like to make accessible. Once this has been loaded on the MangOH these commands would be accessible when logged in over SSH or through the terminal. It is possible to make an application, local to the MangOH board, executable from the command line in a similar way. The only difference is on the right hand side of the assignment, instead of the commands name (drTool or socialService in the file below) you would list the name of the application to be used.
The interfaceSearch section acts, in away, like a linker file in C. This section shows the compiler where any mksys or other files (.api, .h, etc) files are that may be needed to build the components for the framework. This allows for comments to be truly separated from their interfaces. By allowing interfaces to be stored in one location (not within or part of the component) the same file can be used for multiple components and any upgrades or fixes made would be applied to all components using the relevant interface.
The last section in the SDEF below is that for kernalModules. This shows the compiler where to find prebuilt kernel modules that may be needed or used by some of the components. Each entry in this list points to an MDEF file. The MDEF lists the files used in to build the module as well as passes any other information to the compiler that may be needed to complete these drivers for the target board. Noticeably listed are modules for the sensors on the MangOH Red board, these include the BMI160 and the BMP280.
//--------------------------------------------------------------------------------------------------
// mangOH Red system definition that extends the wifi sdef from Legato.
// Copyright (C) Sierra Wireless Inc. Use of this work is subject to license.
//--------------------------------------------------------------------------------------------------
#include "$LEGATO_ROOT/modules/WiFi/wifi.sdef"
apps:
{
$MANGOH_ROOT/apps/GpioExpander/gpioExpanderService/gpioExpanderServiceRed
$MANGOH_ROOT/apps/MqttClient/mqttClient
$MANGOH_ROOT/apps/DataRouter/dataRouter
$MANGOH_ROOT/apps/DataRouter/drTool/drTool
$MANGOH_ROOT/apps/SocialService/socialService
$MANGOH_ROOT/apps/RedSensorToCloud/redSensorToCloud
// The heartbeat app is disabled on mangOH Red because the logging messages
// from the low power microcontroller make it very difficult to use the console port.
// $MANGOH_ROOT/apps/Heartbeat/heartbeatRed
$LEGATO_ROOT/apps/tools/devMode
}
commands:
{
dr = drTool:/bin/dr
twitter = socialService:/bin/twitter
}
interfaceSearch:
{
$MANGOH_ROOT/apps/MqttClient
$MANGOH_ROOT/apps/DataRouter
$MANGOH_ROOT/apps/MuxControl
$MANGOH_ROOT/apps/SocialService/interfaces
}
kernelModules:
{
$MANGOH_ROOT/linux_kernel_modules/mangoh/9-mangoh_red_dv4
// Required for bmp280 & bmi160
$MANGOH_ROOT/linux_kernel_modules/iio/0-iio
$MANGOH_ROOT/linux_kernel_modules/iio/1-iio-kfifo-buf
// Required for bmi160
$MANGOH_ROOT/linux_kernel_modules/iio/2-iio-triggered-buffer
$MANGOH_ROOT/linux_kernel_modules/bmp280/2-bmp280
$MANGOH_ROOT/linux_kernel_modules/bmp280/3-bmp280-i2c
// Used on mangOH Red DV3 and later
$MANGOH_ROOT/linux_kernel_modules/bmi160/3-bmi160
$MANGOH_ROOT/linux_kernel_modules/bmi160/4-bmi160-i2c
// spisvc creates a spidev device which will appear as /dev/spidev0.0 once the spidev module is
// loaded.
$LEGATO_ROOT/drivers/spisvc/spisvc
}
|
While the SDEF may not be something you interact with very often it is still an important file to understand. Drivers may need to be added or altered and you may want to run applications that are not standard or remove some that are.
Application Definition File (ADEF)
The next file that is used in the compilation of a system/application is the ADEF, this is the first file that is always needed. The ADEF lists the executables to be run within this application and what components are needed for that executable. Any resources that are specified in the ADEF are also given a handle by which they can be referenced
While all ADEFs have the same basic blocks and we have previously looked at the ADEF, what's in them can differ and appear complicated. The ADEF below starts off the same as in the previous blog post with sandboxed, start and version all set the same. The first and most noticeable difference comes under executables. In this section, instead of a one to one mapping, the executable redSensorToCloud is mapped to two components. In the ADEF below the executable redSensorToCloud is mapped to two components. This means that when redSensorToCloud is executable both components (avPublisherComponent and sensorsComponent) are run and both of their COMPONENT_INIT functions are run at startup.
The next block, processes, has previously been looked at. Subsections run and envVars tell the application which executables to run as well as what environment variables are accessible from within the application. The last section bindings in this ADEF are slightly different than those previously encountered. While the section provides the same functionality, the API in this file behaves slightly differently than those found in the previous application. The previous API provided a handle to directly manipulate the internal interface. This application’s API does not provide such functionality. The first API, le_adc, connects directly to the interface, by specifying the ADC channel in the function calls the API knows what channel to read from (the exact code can be seen here and here). The second API avdata is used to send/receive data between the MangOH board and the AirVantage server. This API requires that a record object be created. Data is inserted into the record, the record is then pushed to the server. Therefore because these two APIs use objects, there is no variable name to be used in the CDEF or source files.
sandboxed: true
start: manual
version: 0.1
executables:
{
redSensorToCloud = ( avPublisherComponent sensorsComponent)
}
processes:
{
run:
{
( redSensorToCloud )
}
envVars:
LE_LOG_LEVEL = DEBUG
}
}
bindings:
{
redSensorToCloud.sensorsComponent.le_adc -> modemService.le_adc
redSensorToCloud.avPublisherComponent.le_avdata -> avcService.le_avdata
}
|
Component Definition File (CDEF)
In order to increase reusability, this application has been written using two CDEFs. This allows for the various components to be used in multiple applications without needing to rewrite code.
Individually the CDEFs are not complex and are even similar to those previously discussed. There are however, some noticeable differences. In the avPublisherComponent, there is a previously unseen subsection. The component subsection informs the compiler there is some functionality in the sensorsComponent needed by the current component. This other component is therefore required by the current component, similarly this included component or any subsequent components have required components those too will be imported. This also implies codependence is not allowed, if this does occur the application will not compile. When done correctly, the dependant components COMPONENT_INIT will be run after the non-dependant component’s has run. Other than the component section there is the previously seen api section which lets the component have access to the avdata_le API. There is also the sources section which list the C sources file needed to build this component.
cflags:
{
-std=c99
-I${CURDIR}/../sensorsComponent
}
requires:
{
api:
{
airVantage/le_avdata.api
}
component:
{
sensorsComponent
}
}
sources:
{
avPublisher.c
}
|
avPublisherComponent…
Other than the longer list of source files listed in the sensorsComponet CDEF the noticeable difference here is the file subsection. This section allows us to provide files (as defined by linux) to the application that are not part of but, are needed by the application. It also tells the application where to find the specified file within the application sandbox. These files need to be accessible at run time and not build time as that is when the application will look for them.
cflags:
{
-std=c99
}
requires:
{
api:
{
le_adc.api
}
file:
{
/sys/devices/i2c-0/0-0068/iio:deice0/in_accel_x_raw /sys/devices/i2c-0/0-0068/iio:device0/
/sys/devices/i2c-0/0-0068/iio:deice0/in_accel_y_raw /sys/devices/i2c-0/0-0068/iio:device0/
/sys/devices/i2c-0/0-0068/iio:deice0/in_accel_z_raw /sys/devices/i2c-0/0-0068/iio:device0/
/sys/devices/i2c-0/0-0068/iio:device0/in_accel_scale /sys/devices/i2c-0/0-0068/iio:device0/
/sys/devices/i2c-0/0-0068/iio:deice0/in_anglvel_x_raw /sys/devices/i2c-0/0-0068/iio:device0/
/sys/devices/i2c-0/0-0068/iio:deice0/in_anglvel_y_raw /sys/devices/i2c-0/0-0068/iio:device0/
/sys/devices/i2c-0/0-0068/iio:deice0/in_anglvel_z_raw /sys/devices/i2c-0/0-0068/iio:device0/
/sys/devices/i2c-0/0-0068/iio:device0/in_anglvel_scale /sys/devices/i2c-0/0-0068/iio:device0/
/sys/devices/i2c-0/0-0076/iio:device1/in_temp_input /sys/devices/i2c-0/0-0076/iio:device1/
/sys/devices/i2c-0/0-0076/iio:deice1/in_pressure_input /sys/devices/i2c-0/0-0076/iio:device1/
}
}
sources:
{
init.c
sensorUtils.c
lightSensor.c
pressureSensor.c
accelerometer.c
}
|
sensorsComponent…
Over all the file system started with the SDEF at the very top and is followed by the ADEF and CDEF respectively below it. Each CDEF will list the source files as well as any other system requirements it needs to build the component. Below and in away to the side of the SDEF is also the MDEF, these list/build the modules needed by the kernel. In this application MDEFs for the various onboard sensors are included and can be thought of as drivers. A full outline of this application (without the MDEFs is provided in the image below).
The next step is to build our own application, this will be looked at in future blogs. The first project will be to attempt to use a Raspberry Pi shield to measure temperature, humidity and air pressure. Once this has been accomplished a future project will look to incorporate sensor readings along with GPS data. This project's goal will be to attempt to use the MangOH Red as a standalone Weather Balloon board, with the cellular modem providing communications and the on chip GPS providing location. Sensor data will be collected via external sensors but will be relayed in semi realtime back to AirVantage via cellular networks.
No comments:
Post a Comment