Skip to content

Commit

Permalink
upm: version 2.0.0
Browse files Browse the repository at this point in the history
Signed-off-by: Mihai Tudor Panu <[email protected]>
  • Loading branch information
Propanu committed May 8, 2019
1 parent 33d0aee commit 5cf20df
Show file tree
Hide file tree
Showing 3 changed files with 41 additions and 17 deletions.
36 changes: 19 additions & 17 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down Expand Up @@ -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.
Expand All @@ -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
Expand All @@ -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).
Expand Down
7 changes: 7 additions & 0 deletions docs/apichanges.md
Original file line number Diff line number Diff line change
Expand Up @@ -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,
Expand Down
15 changes: 15 additions & 0 deletions docs/changelog.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down

0 comments on commit 5cf20df

Please sign in to comment.