~20 UPM modules have multiple I2C calls in them. As per MRAA API
the I2C address is set in the MRAA I2C context and used from there
for all I2C transactions. Setting the I2C address alone does not
actually result in an I2C transaction. This makes multiple set
address calls pointless. This commit removes these superflous set
address calls from the UPM modules. Setting the address once per
context per device should be enough, unless there are multiple
addresses or multiple devices with different addresses.
Signed-off-by: Abhishek Malik <abhishek.malik@intel.com>
The IMS library will now change its I2C address after resetting the HW to a new
address. It will attempt to close the mraa context and re-init each
time.
Signed-off-by: Noel Eck <noel.eck@intel.com>
Both the .pc and .pom file creation flows rely on the per-target property
BINARY_DIR. This target property was added in CMake 3.4 so .pc and .pom
file generation was broken for CMake versions < 3.4. This commit
creates a new per-target property (TARGET_BINARY_DIR) which is set to
${CMAKE_CURRENT_BINARY_DIR} so that it's usable on CMake versions before
3.4.
Signed-off-by: Noel Eck <noel.eck@intel.com>
and example
LIDAR-Lite v3, a compact, high-performance optical distance measurement
sensor from Garmin™. It is the ideal solution for drone, robot or unmanned
vehicle applications.
The library provided is libupm-lidarlitev3.so
The example provided is lidarlitev3.cxx where it will print the distance
of object/obstacle from the sensor.
The image of the sensor is at docs/images/lidarlitev3.jpg
Signed-off-by: Saloni Jain <saloni.jain@tcs.com>
Signed-off-by: Niti Rohilla <niti.rohilla@tcs.com>
Signed-off-by: Abhishek Malik <abhishek.malik@intel.com>
Standardized the usage path for carrays_uint32_t.i in bacnetmstp and
e50hx libraries. Fixes some small mix-ups with java documentation when
looking for carrays_uint32_t.i.
Signed-off-by: Noel Eck <noel.eck@intel.com>
This commit provides a basic driver for the Vishay VEML6070 UV
Sensor. Some functionality might be missing. Binding examples have
not been tested as of now.
Signed-off-by: Abhishek Malik <abhishek.malik@intel.com>
When generating pom files from CXX targets for JAVA, check against the
JAVA blacklist file. Remove any targets in the blacklist prior to
generating the pom file.
Signed-off-by: Noel Eck <noel.eck@intel.com>
Since src/utilities now builds a C/C++ library, other targets which were
using symbols from utilities now need to include the correct target
dependency. This is mainly for upm_delay* functions. Added utilities-c
target to all sensor library CMakeLists.txt which require it.
Moved macro for __FILENAME__ from upm_utilities.h to upm_fti.h since
ONLY the FTI headers used this.
Signed-off-by: Noel Eck <noel.eck@intel.com>
* Updated pom file generation: Generate pom files after all sensor
library targets have been created - allows for dependencies
* Changes for compiling on Android
* Check for mraa build options: Look at symbols in mraa library to
determine UPM build options (example: mraa_iio_init, mraa_firmata_init)
* Add per target summary for C/C++/java/nodejs/python
* Added hierarchy to fti include directory...
old: #include "upm_voltage.h"
new: #include "fti/upm_voltage.h"
* Removed unimplemented methods from mpu9150 library and java example
* Add utilities-c target for all c examples. Most of the C examples
rely on the upm_delay methods. Add a dependency on the utilities-c
target for all c examples.
* Updated the examples/CMakeLists.txt to add dependencies passed via
TARGETS to the target name parsed from the example name. Also updated
the interface example names to start with 'interfaces'.
* Updated src/examples/CMakeLists.txt to ALWAYS remove examples from the
example_src_list (moved this from end of function to beginning).
Signed-off-by: Noel Eck <noel.eck@intel.com>
* Renamed version.c to version.hpp
* Updated CMakelist file
* Updated upm.i file to support version
* Updated/modified src Cmakelists to support base upm and wrapper dependency
Signed-off-by: sisinty sasmita patra <sisinty.s.patra@intel.com>
Previously, gyroscope were lumped in with compasses (magnetometers).
This isn't really proper as a gyroscope measures rotation rates in a
given axis, and has nothing to do with a magnetometer's use case.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
