Jon Trulson c7b5204fe4 bacnetmstp: initial BACnet MS/TP implementation
This driver is implemented as a singleton due to it's reliance on the
bacnet-stack implementation.  This implementation does not currently
support multiple BACnet networks at the same time, though in the
future it might, depending on the future of bacnet-stack development.
The version of bacnet-stack used in developing this driver was 0.8.3.

This driver is not intended to be used directly by end users, rather
it is intended for UPM drivers supporting specific BACnet devices,
such as the Veris E50H5 Energy Meter.

Unfortunately, this means that a process can only support a single
RS-485 BACnet network, though you can support multiple devices on that
network.

No examples are provided.  Please look at the E50HX driver for an
example of how to use this class in a BACnet MS/TP device driver if
you want to write one.

When initialized, the bacnet-stack library will attach to your RS-485
based BACnet network, and start a Master Finite State Machine (FSM) in
a separate thread.  This thread will handle the details of token
passing and locating other Masters in the network (Poll For Master).

This driver will appear as a BACnet Master device on the BACnet
network, which supports only the required Device Object and any
required services (readProp) and Device Object properties.

When initializing the driver, it is important to select a Device
Object Instance ID that is unique on your BACnet network.  This is the
unique identifier that will be used to identify your Master to the
rest of the BACnet network.

In addition, it may take some time after initialization before you
will be able to communicate on the network, as the first thing that
has to happen is that all Masters on the network need to be identified
(handled by the Master FSM) and a token needs to be received before
your Master can begin transmitting (making requests).  This may take a
couple of minutes on a large network.

You can speed this process up by specifying a maxMaster (to
initMaster()) that is smaller than the default (127) -- but only if
you are CERTAIN that there are no masters with a MAC address higher
than the value you choose.  If you fail to follow this rule, you may
introduce hard to identify token passing problems on the network for
yourself and other BACnet Masters.

Currently, this driver only supports the readProperty and
writeProperty requests to other BACnet devices.  In addition, array
property reading and writing is not currently supported.

Signed-off-by: Jon Trulson <jtrulson@ics.com>
Signed-off-by: Mihai Tudor Panu <mihai.tudor.panu@intel.com>
2016-04-15 09:58:36 -07:00
2014-04-25 15:33:40 +01:00
2015-06-03 12:02:36 -07:00

UPM (Useful Packages & Modules) Sensor/Actuator repository for MRAA

UPM is a high level repository for sensors that use MRAA. Each sensor links to MRAA and are not meant to be interlinked although some groups of sensors may be. Each sensor contains a header which allows to interface with it. Typically a sensor is represented as a class and instantiated.

The constructor is expected to initialise the sensor and parameters may be used to provide identification/pin location on the board.

Typically an update() function will be called in order to get new data from the sensor in order to reduce load when doing multiple reads to sensor data.

Although implementation and API design is up to the developer, C++ interfaces have been defined for the following sensor/actuator types and developers are encouraged to implement them. Interface header files are in the src/upm folder.

  • Light controller
  • Light sensor
  • Temperature sensor
  • Humidity sensor
  • Pressure sensor
  • Analog to digital converter

Feedback on interface design and additions for new types are welcome

Example

A sensor/actuator is expected to work as such (here is the MMA7660 accelerometer API):

  // Instantiate an MMA7660 on I2C bus 0
  upm::MMA7660 *accel = new upm::MMA7660(MMA7660_I2C_BUS,
                                         MMA7660_DEFAULT_I2C_ADDR);

  // place device in standby mode so we can write registers
  accel->setModeStandby();

  // enable 64 samples per second
  accel->setSampleRate(upm::MMA7660::AUTOSLEEP_64);
  
  // place device into active mode
  accel->setModeActive();

  while (shouldRun)
    {
      int x, y, z;
      
      accel->getRawValues(&x, &y, &z);
      cout << "Raw values: x = " << x 
           << " y = " << y
           << " z = " << z
           << endl;
      
      float ax, ay, az;
      
      accel->getAcceleration(&ax, &ay, &az);
      cout << "Acceleration: x = " << ax 
           << "g y = " << ay
           << "g z = " << az
           << "g" << endl;
      
      usleep(500000);
    }

Browse through the list of all examples.

Multi-sensor samples for the starter and specialized kits can be found in the iot-devkit-samples repository.

Supported Sensors

Supported sensor list from API documentation.

You can also refer to the Intel® IoT Developer Zone.

IDE Integration

If you would like to create projects and run the UPM samples using an Intel recommended IDE, please refer to the Intel Developer Zone IDE page.

Building UPM

See building documentation here.

Making your own UPM module

Porting link has more information on making new UPM modules.

There is also an example available gfor max31855 sensor.

Guide on creating Java bindings.

Naming conventions and rules for new UPM contributions

Before you begin development, take a look at our naming conventions.

Also, please read the guidelines for contributions to UPM.

Don't forget to check the documentation section.

Make sure you add yourself as an author on every new code file submitted. If you are providing a fix with significant changes, feel free to add yourself as a contributor. Signing-off your commits is mandatory.

API Documentation

API Compatibility

Even if we try our best not to, every once in a while we are forced to modify our API in a way that will break backwards compatibility. If you find yourself unable to compile code that was working fine before a library update, make sure you check the API changes section first.

NOTE - Our C++ header files will change their extension from .h to .hpp in the upcoming version.

Changelog

Version changelog here.

Known Limitations

List of known limitations here.

Description
UPM is a high level repository that provides software drivers for a wide variety of commonly used sensors and actuators. These software drivers interact with the underlying hardware platform through calls to MRAA APIs.
Readme MIT 33 MiB
Languages
C++ 47.7%
C 46.4%
CMake 2.3%
SWIG 1.9%
Python 0.6%
Other 1.1%