
This commit attempts to use a more cmake-friendly approach when handling inter-target dependencies. A combination of macros and include_directories usage provided overzealous compile -I/blah entries which equates to large catch-all build commands. For example, the last CXX target contains include directories for nearly all preceeding targets (~190). Library dependencies were also often wrong or missing. * Removed nearly all used of include_directories (swig cmake commands still appear to need these for generating the swig command line) * Updated usage of target_link_libraries in upm_module_init, also changed to using target_include_directories per target. This greatly simplifies upm/mixed_module_init usage for libraries which depend on other libraries (in this project). example (src/tb7300/CMakeLists.txt) old: # upm-libbacnetmstp will bring in libbacnet, I hope set (reqlibname "upm-bacnetmstp") include_directories(${BACNET_INCLUDE_DIRS}) include_directories("../bacnetmstp") upm_module_init() upm_target_link_libraries(${libname} bacnetmstp) new: upm_module_init(bacnetmstp) The reason here, is that tb7300 depends on bacnetmstp, which depends on BACNET includes/libs, so tb7300 gets the headers and libraries transitively via its dependency on bacnetmstp. * Updated pkg-config .pc file generation flow to reflect changes with dependencies. * Create a real target for the interfaces (CXX abstract sensor classes). Renamed the directory from 'upm/src/upm' to 'upm/src/interfaces' Also changed the install location of the interface headers to include/upm/interfaces. Updated interface header usage to reflect this. * Updated a few sensor libs to use fwd declarations for mraa. Ideally the UPM libs would do more of this which eases the burden on anyone building on top of the sensor libraries since they would not need to know about mraa headers. * Fixed examples which use symbols not defined in local includes Signed-off-by: Noel Eck <noel.eck@intel.com>
UPM (Useful Packages & Modules) Sensor/Actuator repository for MRAA
The UPM repository provides software drivers for a wide variety of commonly used sensors and actuators. These software drivers interact with the underlying hardware platform (or microcontroller), as well as with the attached sensors, through calls to MRAA APIs.
Programmers can access the interfaces for each sensor by including the sensor’s corresponding header file and instantiating the associated sensor class. In the typical use case, a constructor initializes the sensor based on parameters that identify the sensor, the I/O protocol used and the pin location of the sensor.
C++ interfaces have been defined for the following sensor/actuator types, but they are subject to change:
- Light controller
- Light sensor
- Temperature sensor
- Humidity sensor
- Pressure sensor
- Gas sensor
- Analog to digital converter
The developer community is encouraged to help expand the list of supported sensors and actuators and provide feedback on interface design.
Example
A sensor/actuator is expected to work as such (here is the MMA7660 accelerometer API):
// Instantiate an MMA7660 on I2C bus 0
upm::MMA7660 *accel = new upm::MMA7660(MMA7660_I2C_BUS,
MMA7660_DEFAULT_I2C_ADDR);
// place device in standby mode so we can write registers
accel->setModeStandby();
// enable 64 samples per second
accel->setSampleRate(upm::MMA7660::AUTOSLEEP_64);
// place device into active mode
accel->setModeActive();
while (shouldRun)
{
int x, y, z;
accel->getRawValues(&x, &y, &z);
cout << "Raw values: x = " << x
<< " y = " << y
<< " z = " << z
<< endl;
float ax, ay, az;
accel->getAcceleration(&ax, &ay, &az);
cout << "Acceleration: x = " << ax
<< "g y = " << ay
<< "g z = " << az
<< "g" << endl;
usleep(500000);
}
Browse through the list of all examples.
Multi-sensor samples for the starter and specialized kits can be found in the iot-devkit-samples repository.
Supported Sensors
Supported sensor list from API documentation.
You can also refer to the Intel® IoT Developer Zone.
IDE Integration
If you would like to create projects and run the UPM samples using an Intel recommended IDE, please refer to the Intel Developer Zone IDE page.
Building UPM
See building documentation here.
Making your own UPM module
Porting link has more information on making new UPM modules.
There is also an example available gfor max31855 sensor.
Guide on creating Java bindings.
Naming conventions and rules for new UPM contributions
Before you begin development, take a look at our naming conventions.
Also, please read the guidelines for contributions to UPM.
Don't forget to check the documentation section.
Make sure you add yourself as an author on every new code file submitted. If you are providing a fix with significant changes, feel free to add yourself as a contributor. Signing-off your commits is mandatory.
API Documentation
API Compatibility
Even if we try our best not to, every once in a while we are forced to modify our API in a way that will break backwards compatibility. If you find yourself unable to compile code that was working fine before a library update, make sure you check the API changes section first.
NOTE - Our C++ header files changed extension from .h to .hpp!
Changelog
Version changelog here.
Known Limitations
List of known limitations here.