These changes allow NMEA data to be read via I2C on UBLOX compliant
devices that support this capability, such as the LEA-6H based GPS
shield from DFRobot.
It adds a new init() function to the C code, and a new constructor to
the C++ code. It also adds 5 new examples for C, C++, Javascript,
Python, and Java.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
This driver will serve as a generic module for grabbing NMEA data from
various GPS devices via a serial interface. ublox6 will also be
removed in favor of using this driver going forward.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
This driver was developed with the DFRobot Light Sensor based on the
BH1750. It has a sensitivity of .5 to 65535 Lux. It supports
voltages from 3-5vdc and is connected via I2C.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
This driver implements support for the DFRobot MMA7361 analog
accelerometer. It supports 3 axes with a selectable 1.5G and 6G
sensitivity. It is not really meant for navigation, but rather for
uses such as orientation and freefall detection.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
Make sure that for all C libs, upmc-utilities is linked in. Also, do
not do this for the utilities library itself.
In addition, do not add the utilities library as a requirement for the
libupmc-utilities pkgconfig file.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
This module provides support for the VK2828U7 (ublox based) GPS module
from DFRobot. It is connected via a UART, and emits NMEA data.
Ideally this data could be fed to an external library like TinyGPS to
parse the NMEA data and provide an easier method of extracting GPS
information.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
Test commit for building C UPM modules.
* Added C include directory
* Added C utilities directory
* Rename C++ upm.h -> upm.hpp to make room for C upm.h
* Added upm_mixed_module_init function to src/CMakeLists.txt. This
function takes filesnames similar to upm_module_init and does a
bit of processing before calling upm_module_init.
* Added c example directory. Changed c++ example names.
* Added dfrph implemention for testing (C++ wraps C). Added mraa
to .pc requires for dfrph. Tested against stand-alone project.
Added dfrph c example.
* Update implemention of pkg-config file generation.
* Added two cmake cache variables: BUILDCPP and BUILDFTI
* Removed src from swig_add_module calls, added libname to
swig_link_libraries calls. Shrinks swig'ed binaries by ~13%.
* Added install target in upm/CMakeLists.txt to install C header,
directory. Is this where we want this?
* C FTI header directory is include/fti
Signed-off-by: Noel Eck <noel.eck@intel.com>
Fixed 16-bit read code to use the correct mraa function to align with
the datasheet. Added code for dew point calculation and single function
to retreive temp, humidity, and dewpoint. Other clean up as well.
Signed-off-by: Bill Penner <william.penner@intel.com>
Signed-off-by: Mihai Tudor Panu <mihai.tudor.panu@intel.com>
Exposed call to MRAA SPI frequency for those super long strips where the clock signal will degrade and introduce glitches. Slowing down will fix it without the need for extra filtering or redrivers. Batch mode also helps since only one write per frame will be required.
Added functions that control brightness only for fade effects without the need to keep an extra copy of the pixel color map.
Signed-off-by: Mihai Tudor Panu <mihai.tudor.panu@intel.com>
There are some issues using this device on the 101 with Firmata:
1. You cannot use any other ADC resolution than 1024. By default the
driver would try to set 12b resolution for improved accuracy. Doing
this on the 101 yielded nonsensical readings causing the driver to
fail. Using 10b resolution will yield less accuracy, but at least the
driver will function.
2. After the first ADC read, and for some time period after, the MRAA
aio_read() calls will always return 0. This would cause an exception
to be thrown by the driver since this is an invalid reading. Now, we
do an analog read on each channel and sleep for .5 seconds in the ctor
to get around this problem. It is a hack and should be properly fixed
somewhere else (firmata? MRAA?).
Some code was reworked/renamed to make it more clear what is actually
going on. In addition a setDebug() method was added to enable some
debugging output.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
The existing driver only supported IIO. This change adds support for
controlling the device via an I2C connection. In addition, there is a
new C++ example for it (l3gd20-i2c.cxx).
Note: Only basic functionality is supported, though a full register
map and access functions are available to fill in any desired
functionality.
Note, that some methods are only usable with specific connection
types. See the documentation.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
Changes in library:
- enableProximity() function is to enable or disable proximity sensor
- enableIlluminance() function is to enable or disable illuminance sensor
- run clang-format
Changes in example:
- proximity and illuminance kernel IIO-based driver init state is power off,
require enable before read out sensor data. Sleep time is needed after
enable, the sleep time may vary on different platform.
- run clang-format
Signed-off-by: Lay, Kuan Loon <kuan.loon.lay@intel.com>
Signed-off-by: Mihai Tudor Panu <mihai.tudor.panu@intel.com>
This will ensure that all src modules are scanned first before
examples (c++/java).
In certain cases when doing parallel builds with many cores (8), the
examples for MODBUS, BACNET, and OPENZWAVE would not be built, since
their dependant libraries had not yet been located (in the src/
dir(s) via pkg_check_modules()), by the time the examples were being
compiled.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
This commit reworks ozw somewhat and adds some device specific drivers
with examples. All of these drivers are kept in the UPM ozw library.
The OZW class has been reworked to make it a proper singleton, since
the OpenZWave::Manager() it depends on is already a singleton. This
avoids issues such as opening and initializing OpenZWave multiple
times.
A new, relatively thin base class, ozwInterface is also now present.
This class wraps some basic functionality, and handles initialization
of the OZW base class. It is intended to be inherited by device
driver classes. It operates on a node id for a device. Each OZW
device is referenced by a node id, which does not change unless the
device is removed (and possibly re-added) to a Z-Wave network.
Finally, a series of device specific drivers have been implemented.
These provide basic functionality to monitor and in some cases control
the operation of a Z-Wave device. They are the following:
ozwdump - This is a fake 'device' driver that initializes an OZW
network and dumps information on all of the nodes (devices) present.
Along with each node, available information on each valueid associated
with that node is also printed. This fake device and it's examples
replace the original ozw example.
aeotecss6 - Aeotec Smart Switch 6. This device allows control of the
switch, as well as reporting of information the switch makes
available, such as current consumption, volts, watts, and accumulated
energy use (kWh).
aeotecsdg2 - Aeotec Smart Dimmer Gen 2. This device is similar to the
Smart Switch 6, but also provides dimming functionality. It also
provides information on energy use.
aeotecdw2e - Aeotec Door/Window Sensor 2nd Edition. This device is a
magnetic switch with an embedded tamper switch used to detect the
opening/closing of windows and doors. This is a battery powered
device.
aeotecdsb09104 - Aeotec Home Energy Monitor. This device is intended
to be installed at the MAINS or Breaker box. It reports current and
cumulative energy consumption.
tzemt400 - Trane TZEMT400 Thermostat. This device is a thermostat
with Z-Wave functionality. The variant tested was the
TZEMT400BB32MAA. The driver reports various information on the status
of the thermostat, as well as the current measured temperature.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
UPM requires swig 3.0.5 which *was* offered in fenics-exp, but is
no longer available there. Switched to fenics-dev.
Signed-off-by: Noel Eck <noel.eck@intel.com>
There were api changes for iio kernel support on mraa which cascade to
UPM - setting the minimum version of mraa required.
Signed-off-by: Noel Eck <noel.eck@intel.com>
