* Examples for C/C++/Python/Java/JavaScript
* Add Java example to CMakeLists
Signed-off-by: Assam Boudjelthia <assam.boudjelthia@fi.rohmeurope.com>
Signed-off-by: Mihai Tudor Panu <mihai.tudor.panu@intel.com>
- Examples for C/C++/Python/Java/JavaScript
- Add build line for java BH1792_Example
Signed-off-by: Assam Boudjelthia <assam.boudjelthia@fi.rohmeurope.com>
Signed-off-by: Mihai Tudor Panu <mihai.tudor.panu@intel.com>
The hardcoded frequency of 10kHz was much slower than the capacity of the device
Signed-off-by: Antoine W. Campagna <AntoineW@Campagna.org>
Signed-off-by: Noel Eck <noel.eck@intel.com>
Added explicit error for sign compares to CMake. Updated a handful of C
source which compared unsigned vs signed.
Signed-off-by: Noel Eck <noel.eck@intel.com>
Adding STMicro LIS3DH sensor support. This module is based on
the one for lis2ds12 (thanks, jontrulson!), but as sensors are
noticeably different, the contents underwent major rework.
Examples and basic API are left the same.
Tested on Intel Edison with Arduino board using both I2C and SPI.
Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.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>
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>
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>
Updated the examples to comprehend transitive dependencies. This means
that each example target will no longer have a giant list of -I includes
(the examples at the end of the list had includes for all previous
examples, upwards of 200 -I's on the command line).
* Created a CMakeLists.txt in the upm/examples directory, moved
common functionality to this level.
* C/C++ examples now look to the filename for their dependency
target name, ie; gas-mq2.cxx adds a dependency to the 'gas' target
* Updated a handful of C/C++ example names to reflect this
* Example CMake flow - glob the list of files, add targets for any
special case examples, then att targets for all the rest
Signed-off-by: Noel Eck <noel.eck@intel.com>
This driver has been rewritten from scratch.
See docs/apichanges.md for a list of API compatibility changes
compared to the original driver.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
The sainsmartks driver has been reimplemented in it's own, new C/C++
library: lcdks (LCD Keypad Shield).
In addition, support for an optional backlight GPIO was added.
This was tested with the SainsmartKS and DFRobot LCD Keypad Shields.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
This commit enables the ABP Honeywell sensor. Java examples is
yet to be tested and has not been provided with the current commit
and will be provided in a future commit.
Signed-off-by: Abhishek Malik <abhishek.malik@intel.com>
Some private methods (relating to calibration/compensation) are no
longer exposed. In addition, the driver auto-detects the chip (BMP280
or BME280) and acts accordingly, rather than requiring the
specification of a chip id in the ctor.
The getHumidity() method no longer accepts an arguement representing
pressure at sea level. A new method is provided to specify this.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
The API has been changed in some cases - see the apichanges.md
document.
In addition, this driver uses a new upm_vectortypes.i SWIG interface
file to provide a mechanism for methods that return a vector of floats
and ints instead of a pointer to an array.
This works much nicer than C array pointers, and results in Python/JS/Java
code that looks much more "natural" to the language in use.
The Python, JS, and Java examples have been changed to use these
methods. Support for the "old" C-style pointer methods are still
provided for backward compatibility with existing code.
As an example - to retrieve the x, y, and z data for Euler Angles from
the bno055, the original python code would look something like:
...
x = sensorObj.new_floatp()
y = sensorObj.new_floatp()
z = sensorObj.new_floatp()
...
sensor.getEulerAngles(x, y, z)
...
print("Euler: Heading:", sensorObj.floatp_value(x), end=' ')
print(" Roll:", sensorObj.floatp_value(y), end=' ')
...
Now the equivalent code is simply:
floatData = sensor.getEulerAngles()
print("Euler: Heading:", floatData[0], ...
print(" Roll:", floatData[1], end=' ')
...
Additionally, interrupt handling for Java is now implemented
completely in the C++ header file now rather than the .cxx file, so no
special SWIG processing is required anymore. See Issue #518 .
Signed-off-by: Jon Trulson <jtrulson@ics.com>
These changes add the ability to intialize a speaker instance to use a
PWM pin instead of a standard GPIO pin in order to emit sounds.
The current GPIO functionality is fairly constrained by the
implementation -- it only permits playing cerain hardcoded "notes".
The PWM support allows one to emit specific frequencies (currently
between 50-32Khz) using a PWM pin. Of course, you may still be
constrained by the limits of your PWM hardware in the end.
There are a few new functions provided to support this PWM mode. To
use the PWM mode of speaker, use the speaker_init_pwm() initialization
routine instead of speaker_init() (for C). For C++ and the SWIG
languages, pass "true" as the second argument to the constructor to
enable PWM mode. The default is "false", to match current default
behavior (GPIO).
Functions that are not related to a given mode (GPIO vs. PWM) will do
nothing if not usable in that mode.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
uartat is the underlying UART driver, specifically for use with
AT-style command driven devices like modems.
The le910 support is provided in the form of examples that make use
of the uartat driver to interact with the device.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
Previously, the C++ and C versions of this driver were separate. Now
the C++ implementation wraps the C implementation.
In addition, the C++ init() function has been deprecated. It
currently does nothing, and examples have been modified to remove it's
calls. This function will be removed in a separate release.
The examples have been further modified to update all detected devices
and print their respective temperatures, instead of only reporting the
on the first device detected.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
