* 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>
There are a variety of LSM303 devices out there with various
incompatibilities and differing capabilities. The current lsm303
driver in UPM only supports the LSM303DLH variant, so it has been
renamed to lsm303dlh to avoid confusion and to make it clear which
variant is actually supported.
All examples and source files have been renamed, including header
files. In addition, the class name, LSM303, has been renamed to
LSM303DLH. No other functionality or behavior has been changed.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
C/C++ CMakeLists.txt lines are no longer needed - removed.
Converted bash script to a function to add some error checking.
Removed redundant author/copyright entry.
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>
This also provides some more functionality. get_raw() has been
deprecated in favor of using getNormalized().
Signed-off-by: Jon Trulson <jtrulson@ics.com>
The lcm1602 and jhd1313m1 drivers had been rewritten in C with a C++
wrapper some time ago, however the original lcm and jhd drivers were
still present in the lcd library. In addition, to avoid header file
conflicts, the new, separated lcm and jhd header files were renamed
with a .hxx prefix.
This patch:
- renames the new lcm1602/ and jhd1313m1/ header files to have the
usual .hpp prefix.
- removes the lcm1602, jhd1313m1, and sainsmartks drivers from the
lcd/ (i2clcd) library.
- fixes the examples to use the "new" libraries (lcm1602 and
jhd1313m1)
- changes the argument type for the createChar() (C++) to use a byte
vector (std::vector<uint8_t>) rather than a typedef'd char array.
The lcm1602_create_char() function (C) uses a standard char *. The
use of std::vector is well supported by SWIG.
- SWIG interface files changed to use upm_vectortypes.i, and removes
the carrays helpers, which should no longer be needed for these
drivers.
- removes the inclusion of the driver C .h header files into the SWIG
interface files - this should not be needed for these drivers.
- the sainsmartks driver will be placed into it's own new lcdks (LCD
Keypad Shield) library. This library should support the
SainsmartKS, DFRobot LCD Keypad Shield, and similar products from
other manufacturers in a future commit.
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>
The purpose of the templatesensor is to get contributors up and running
faster when adding a new sensor.
* Created library named 'sensortemplate'
* Added C++ source
* Added swig interface files for java, javascript, and python
* Added sensortemplate image file
* Added examples for c++, java, javascript, and python
* Updated contributions.md with steps to create a new sensor from
the sensortemplate library.
Signed-off-by: Noel Eck <noel.eck@intel.com>
This commit translates C++ interfaces to Java interfaces, previously C++ Interfaces implemented java classes.
* Added java swig interface files for all C++ interfaces to simplify swig
javaupm_iADC.i
javaupm_iCO2Sensor.i
javaupm_iHumiditySensor.i
javaupm_iLightController.i
javaupm_iLightSensor.i
javaupm_iModuleStatus.i
javaupm_interfaces.i
javaupm_iPressureSensor.i
javaupm_iTemperatureSensor.i
<example Usage>
%include"../interfaces/javaupm_iADC.i"
* Modified swig interface files for few sensors that implements interfaces
ads1x15
bmp280
bmpx8x
ds1808lc
hlg150h
lp8860
max44009
ms5611
si1132
si7005
t6713
* Removed few methods that were mentioned Protected and made them public, so that menthods can be overridden
* Made IModuleStatus virtual to avoid ambiguity in multiple inheritance
For example
class A {};
class B : public A {};
class C : public A {};
class D : public B, public C {};
This can be solved as
class A {};
class B : virtual public A {};
class C : virtual public A {};
class D : public B, public C {};
* Modified java interface files to support multiple swig versions
* Modified javaupm interface file to support standard auto load library code
* Fixed autoloadlibrary tests for interfaces
* Created one interface example separately <BME280_InterfaceExample.java>,
<example Usage>
BME280_InterfaceExample.java
since we cann't define swig versions inside java example file.
So, instaed added swig versions in Cmake.
<example Usage>
if (SWIG_VERSION VERSION_GREATER 3.0.8)
add_example_with_path(BME280_InterfaceExample bmp280 bmp280)
endif()
Signed-off-by: sisinty sasmita patra <sisinty.s.patra@intel.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>
This driver was developed with a DFRobot SHT10 Temperature and Humidity
sensor. This driver should work on all SHT1X devices.
It requires a 10K pull-up resistor connected to the data pin.
The sensor can be run at differing voltages from 2.5v to 5v.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
