@@ -14,21 +14,21 @@ Programmers can access the interfaces for each sensor by including the sensor’
1414corresponding header file and instantiating the associated sensor class. In the
1515typical use case, a constructor initializes the sensor based on parameters that
1616identify the sensor, the I/O protocol used and the pin location of the sensor.
17+ As of UPM 2.0, sensor initialization can also be done, in most cases, via
18+ overloaded constructors that accept string identifiers.
1719
1820We endorse additions that implement the generic C and C++ interfaces provided
19- with the libraries. Multiple sensor and actuator types have been defined, for
20- instance:
21+ with the libraries. With the 2.0 release, UPM introduces the following sensor
22+ interfaces: iAcceleration, iAngle, iButton, iClock, iCollision, iDistance,
23+ iDistanceInterrupter, iEC, iElectromagnet, iEmg, iGas, iGps, iGyroscope,
24+ iHallEffect, iHeartRate, iHumidity, iLight, iLineFinder, iMagnetometer,
25+ iMoisture, iMotion, iOrp, iPH, iPressure, iProximity, iTemperature, iVDiv,
26+ iWater.
2127
22- * Light controller
23- * Light sensor
24- * Temperature sensor
25- * Humidity sensor
26- * Pressure sensor
27- * Gas sensor
28- * Analog to digital converter
28+ The developer community is invited to propose new interfaces for actuator types.
2929
30- The developer community is welcome to submit feedback on existing categories or
31- suggest new ones .
30+ The UPM project is joining the Eclipse Foundation as an Eclipse IoT project.
31+ You can read more about this [ here ] ( https://projects.eclipse.org/proposals/eclipse-upm ) .
3232
3333### Example
3434
@@ -97,12 +97,16 @@ See building documentation [here](docs/building.md).
9797
9898A quick way to add a new sensor driver is to port existing code from another
9999platform (e.g. Arduino) and swap the IO calls to the MRAA API. This of course
100- assumes either ownership of the original code or licensing that allows
101- unrestricted redistribution.
100+ assumes either ownership of the original code or a MIT compatible license that
101+ allows unrestricted redistribution.
102102
103103The [porting](docs/porting.md) section has more information on this process,
104104and there is an example available based on the max31855 [sensor](docs/max31855.md).
105105
106+ We have an [on demand webinar](https://software.seek.intel.com/IoT_WebinarSeries_Reg)
107+ available that covers using an IDE to develop for the UPM project along with other
108+ considerations for new contributions.
109+
106110Read more on creating Java [bindings](docs/creating_java_bindings.md) for your
107111new driver.
108112
@@ -114,7 +118,8 @@ The name you pick for a newly added sensor needs to be unique in the UPM library
114118Then, please go over this short set of rules for new [contributions](docs/contributions.md).
115119Make sure you add yourself as an author on every new code file submitted.
116120If you are providing a fix with significant changes, feel free to add yourself
117- as a contributor. Signing-off your commits is mandatory.
121+ as a contributor. Signing-off your commits is mandatory and acts as an
122+ acknowledgment of the committer agreement.
118123
119124Documenting your code is also a big part of the task. We have a strict set of
120125tags 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
137142unable to compile code that was working fine before a library update, make sure
138143you check the [API changes](docs/apichanges.md) section first.
139144
140- **NOTE** - Several important API changes are currently underway for some of our
141- widely used libraries including `libupm-grove`
142-
143145### Changelog
144146Version changelog [here](docs/changelog.md).
145147
0 commit comments