*[PiJuice - power supply for Raspberry Pi](PiJuice/README.md)
### Volatile Organic Compound sensors
*[AGS01DB - MEMS VOC Gas Sensor](Ags01db/README.md)
*[BMxx80 Device Family](Bmxx80/README.md)
*[CCS811 Gas sensor](Ccs811/README.md)
### Thermocouple devices
*[Max31856 - cold-junction compensated thermocouple to digital converter](Max31856/README.md)
*[MCP960X - device family of cold-junction compensated thermocouple to digital converter](Mcp960x/README.md)
</categorizedDevices>
## Binding Distribution
...
...
@@ -308,7 +342,7 @@ Bindings must:
* Best if you include a sample that covers usage of all available functions and properties
* Best if you create mutliple paths to show what the sensor can do
* use the System.Device API.
* (*Optional*) Include a unit test project that **DOES NOT** require hardware for testing. We will be running these tests as part of our CI and we won't have sensors plugged in to the microcontrollers, which is why test projects should only contain unit tests for small components in your binding.
* (*Optional*) Include a unit test project that **DOES NOT** require hardware for testing. We will be running these tests as part of our CI and we won't have sensors plugged in to the microcontrollers, which is why test projects should only contain unit tests for small components in your binding. Unit tests may simulate part of the device or use mocking. (Moq is automatically included as a reference to all unit test assemblies)
Here is an example of a layout of a new Binding *Foo* from the top level of the repo:
...
...
@@ -320,10 +354,11 @@ iot/
Foo.csproj
Foo.cs
README.md
Foo.sln <-- Solution should include the project itself + the samples and test and optionally reference other highly coupled bindings
samples/
Foo.Sample.csproj
Foo.Sample.cs
tests/ <-- Tests are optional, but if present they should be layed out like this.
tests/ <-- Tests are optional, but if present they should be layed out like this.
Foo.Tests.csproj
Foo.Tests.cs
```
...
...
@@ -462,3 +497,4 @@ public Dispose()
We are currently not accepting samples that rely on native libraries for hardware interaction. This is for two reasons: we want feedback on the System.Device API and we want to encourage the use of 100% portable .NET solutions. If a native library is used to enable precise timing, please file an issue so that we can discuss your proposed contribution further.
We will only accept samples that use the MIT or compatible licenses (BSD, Apache 2, ...). We will not accept samples that use GPL code or were based on an existing GPL implementation. It is critical that these samples can be used for commercial applications without any concern for licensing.
