From 5cf20df96c6b35c19d5b871ba4e319e96b4df72d Mon Sep 17 00:00:00 2001 From: Mihai Tudor Panu Date: Tue, 7 May 2019 18:01:46 -0700 Subject: [PATCH] upm: version 2.0.0 Signed-off-by: Mihai Tudor Panu --- README.md | 36 +++++++++++++++++++----------------- docs/apichanges.md | 7 +++++++ docs/changelog.md | 15 +++++++++++++++ 3 files changed, 41 insertions(+), 17 deletions(-) diff --git a/README.md b/README.md index 92c6bed05..75a78b97a 100644 --- a/README.md +++ b/README.md @@ -14,21 +14,21 @@ Programmers can access the interfaces for each sensor by including the sensor’ corresponding header file and instantiating the associated sensor class. In the typical use case, a constructor initializes the sensor based on parameters that identify the sensor, the I/O protocol used and the pin location of the sensor. +As of UPM 2.0, sensor initialization can also be done, in most cases, via +overloaded constructors that accept string identifiers. We endorse additions that implement the generic C and C++ interfaces provided -with the libraries. Multiple sensor and actuator types have been defined, for -instance: +with the libraries. With the 2.0 release, UPM introduces the following sensor +interfaces: iAcceleration, iAngle, iButton, iClock, iCollision, iDistance, +iDistanceInterrupter, iEC, iElectromagnet, iEmg, iGas, iGps, iGyroscope, +iHallEffect, iHeartRate, iHumidity, iLight, iLineFinder, iMagnetometer, +iMoisture, iMotion, iOrp, iPH, iPressure, iProximity, iTemperature, iVDiv, +iWater. -* Light controller -* Light sensor -* Temperature sensor -* Humidity sensor -* Pressure sensor -* Gas sensor -* Analog to digital converter +The developer community is invited to propose new interfaces for actuator types. -The developer community is welcome to submit feedback on existing categories or -suggest new ones. +The UPM project is joining the Eclipse Foundation as an Eclipse IoT project. +You can read more about this [here](https://projects.eclipse.org/proposals/eclipse-upm). ### Example @@ -97,12 +97,16 @@ See building documentation [here](docs/building.md). A quick way to add a new sensor driver is to port existing code from another platform (e.g. Arduino) and swap the IO calls to the MRAA API. This of course -assumes either ownership of the original code or licensing that allows -unrestricted redistribution. +assumes either ownership of the original code or a MIT compatible license that +allows unrestricted redistribution. The [porting](docs/porting.md) section has more information on this process, and there is an example available based on the max31855 [sensor](docs/max31855.md). +We have an [on demand webinar](https://software.seek.intel.com/IoT_WebinarSeries_Reg) +available that covers using an IDE to develop for the UPM project along with other +considerations for new contributions. + Read more on creating Java [bindings](docs/creating_java_bindings.md) for your new driver. @@ -114,7 +118,8 @@ The name you pick for a newly added sensor needs to be unique in the UPM library Then, please go over this short set of rules for new [contributions](docs/contributions.md). 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. +as a contributor. Signing-off your commits is mandatory and acts as an +acknowledgment of the committer agreement. Documenting your code is also a big part of the task. We have a strict set of tags used to classify our sensors and their capabilities. You can find out more @@ -137,9 +142,6 @@ 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](docs/apichanges.md) section first. -**NOTE** - Several important API changes are currently underway for some of our -widely used libraries including `libupm-grove` - ### Changelog Version changelog [here](docs/changelog.md). diff --git a/docs/apichanges.md b/docs/apichanges.md index 6848dd3c9..54b5767a0 100644 --- a/docs/apichanges.md +++ b/docs/apichanges.md @@ -4,6 +4,13 @@ API Changes {#apichanges} Here's a list of other API changes made to the library that break source/binary compatibility between releases: +# v2.0.0 + * Sensors implementing the old interfaces (bme280, bmpx8x, si7005, si1132, + max44009, lp8860, ds1808lc, hlg150h) have been updated to use the new ones, + hence some function names and parameters will be different. + * Removed deprecated basic grove classes from project, see API changes for + v1.1.0 and prior for a complete list + # v1.7.0 * The interface of **kx122** has been modified to return values instead of receiving pointers. This applies to member functions: getWhoAmI, diff --git a/docs/changelog.md b/docs/changelog.md index 85d50ea5f..bb16a6aec 100644 --- a/docs/changelog.md +++ b/docs/changelog.md @@ -4,6 +4,21 @@ Changelog {#changelog} Here's a list summarizing some of the key undergoing changes to our library from earlier versions: +### v2.0.0 + + * Reworked existing interfaces and extended the list to include iAcceleration, + iAngle, iButton, iClock, iCollision, iDistance, iDistanceInterrupter, iEC, + iElectromagnet, iEmg, iGas, iGps, iGyroscope, iHallEffect, iHeartRate, iHumidity, + iLight, iLineFinder, iMagnetometer, iMoisture, iMotion, iOrp, iPH, iPressure, + iProximity, iTemperature, iVDiv, iWater + * Provided overloaded string based constructors for a good number of sensors, + allowing initialization from external frameworks without type knowledge + * Removed deprecated basic grove classes from project + * Replaced 6 unsafe occurrences of sprintf() usage + * Cleaned-up build system around target arch detection and cpack usage, added + detection and resolution of tinyb library when used as a dependency + * New sensors: 2jciebu01_ble, 2jciebu01_usb + ### v1.7.1 * Bumped library compatibility to new MRAA 2.0 APIs