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>
Moved src include AFTER setter for PYTHONBUILD_VERSION. In this way,
the src CMakeLists has a valid PYTHONBUILD_VERSION str.
Call find_package on PythonInterp prior to finding the libs (recommended).
Signed-off-by: Noel Eck <noel.eck@intel.com>
HD44780 fails to initialize unsuccessfully without the workaround.
Adding workaround based on HD77480 datasheet for initialization
and software reset.
Signed-off-by: Akira Tsukamoto <akira.tsukamoto@linaro.org>
Signed-off-by: Abhishek Malik <abhishek.malik@intel.com>
This module implements support for the Honeywell TB7300 Communicating
Fan Coil Thermostat. It may also support the TB7200, though only the
TB7300 was available for development of this driver.
The TB7200 Series PI thermostats are designed for zoning applications,
and the TB7300 Series PI thermostats are designed for fan coil
control. Both Series are communicating thermostats with models
available in BACnet® MS/TP protocol and can be easily integrated into
a WEBs-AX building automation system based on the NiagaraAX® platform.
TB7200 and TB7300 Series thermostats are compatible with the Honeywell
Occupancy Sensor Cover. Thermostats equipped with an occupancy sensor
cover provide advanced active occupancy logic, which will
automatically switch occupancy levels from Occupied to Stand-By and
Unoccupied as required by local activity being present or not. This
advanced occupancy functionality provides advantageous energy savings
during occupied hours without sacrificing occupant comfort. All
thermostats can be ordered with or without a factory installed PIR
cover.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
This module implements support for the Amphenol Telaire Ventostat
T8100 Ventilation Controller with BACnet interface. It may also
support the T8200 and T8300 models, but they have not been tested.
The Telaire Ventostat T8100 reports Temperature, Humidity and CO2
concentrations. It supports an optional relay with a settable trigger
point. The unit this driver was tested under did not support the
optional relay. The temperature range supported is 0-50C, humidity is
0-100% non-condensing, and CO2 range is appoximately 0-2000 PPM for
the T8100. Other sensors in this family support wider ranges.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
This commit removes functionality that is now present in the
bacnetutil class. This simplifies the driver considerably. The
examples were modified to reflect the renaming of some utility
functions in bacnetutil.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
There is some functionality that will always be needed for BACnet
drivers. Here we create a new bacnetutil class, built as part of the
bacnetmstp library that can handle much of the data handling and setup
a BACnet driver will need.
The idea is that any BACnet functionality needed, that is not
device-specific, should be added to this class for all drivers to use.
The intent is that all BACnet drivers will inherit from this class.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
This reworks the data handling portion of bacnetmstp. Instead of just
handling a single data element returned from a device, we can handle
more, as in the case of BACnet arrays.
Added the ability to create BACnet enum data elements. This is needed
in order to set binary value objects.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
This module (bmx055) implements support for the following core Bosch
chipsets:
bma250e - accelerometer, 3 variants (chip id's 0x03, 0xf9, and 0xfa)
bmm150 - magnetometer
bmg160 - gyroscope
The other 3 devices are combinations of the above:
bmx055 - accel/gyro/mag
bmc160 - accel/mag
bmi055 - accel/gyro
...for 6 devices total.
For the combination devices, all of the sub-devices appear as
individual independent devices on the I2C/SPI bus.
The combination drivers provide basic configuration and data output.
For more detailed control as well as interrupt support, you should use
the core device drivers (accel/gyro/mag) directly.
These devices support both I2C and SPI communications. They must be
powered at 3.3vdc.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
