@@ -14,21 +14,21 @@ Programmers can access the interfaces for each sensor by including the sensor’
14
14
corresponding header file and instantiating the associated sensor class. In the
15
15
typical use case, a constructor initializes the sensor based on parameters that
16
16
identify 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.
17
19
18
20
We 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.
21
27
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.
29
29
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 ) .
32
32
33
33
### Example
34
34
@@ -97,12 +97,16 @@ See building documentation [here](docs/building.md).
97
97
98
98
A quick way to add a new sensor driver is to port existing code from another
99
99
platform (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.
102
102
103
103
The [porting](docs/porting.md) section has more information on this process,
104
104
and there is an example available based on the max31855 [sensor](docs/max31855.md).
105
105
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
+
106
110
Read more on creating Java [bindings](docs/creating_java_bindings.md) for your
107
111
new driver.
108
112
@@ -114,7 +118,8 @@ The name you pick for a newly added sensor needs to be unique in the UPM library
114
118
Then, please go over this short set of rules for new [contributions](docs/contributions.md).
115
119
Make sure you add yourself as an author on every new code file submitted.
116
120
If 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.
118
123
119
124
Documenting your code is also a big part of the task. We have a strict set of
120
125
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
137
142
unable to compile code that was working fine before a library update, make sure
138
143
you check the [API changes](docs/apichanges.md) section first.
139
144
140
- **NOTE** - Several important API changes are currently underway for some of our
141
- widely used libraries including `libupm-grove`
142
-
143
145
### Changelog
144
146
Version changelog [here](docs/changelog.md).
145
147
0 commit comments