Iot: Documentation should include instructions on how to use/enable I2C/SPI/PWM/1-wire/...

[krwq]

Currently we are lacking gathered place where we describe how to plug in and setup Raspberry PI with I2C/SPI/PWM and other protocols. We should write instructions and start linking samples to those docs to make people easier to start.

Work left here:

• [x] I2C instructions for Raspbian
• [x] SPI instructions for Raspbian
• [x] PWM instructions for Raspbian
• [ ] 1-wire instructions for Raspbian
• [x] Links in the samples

let me know if the list is missing anything

@MarkCiliaVincenti @shaggygi

[Frankenslag]

@krwq
Perhaps be more specific and say that it's a Pi running Raspbian. I have noticed that 64bit Debian, for example, doesn't have the same device tree configuration and so the SPI configuration instructions used for Raspian aren't appropriate.

[krwq]

@Frankenslag good point, ideally we should have couple of other common OSes but I guess that's optional here. Let's make the titles generic and start with just Raspbian

[krwq]

Should we just point people to /boot/overlays/README for now? It describes how to enable everything on the PI using /boot/config.txt

[larivierec]

I'm running this on Ubuntu 19.10 and it's not enough. It's a start because it allowed me to enable pwm through the overlays however, hardware PWM is currently unsupported within dotnet as certain pins need to be in different modes in order to operate on them.

i.e.:
gpio 18 needs to be in alternate function 5 (PWM) mode in order for it to work.

[krwq]

@larivierec I'm not sure you can change the mode without root access or if it would be appropriate for .NET to change that (although if we can do it so that you can switch between PWM/GPIO without issues then I think we should allow it). For PWM without changing settings you can use SoftwarePwm

[larivierec]

@larivierec I'm not sure you can change the mode without root access or if it would be appropriate for .NET to change that (although if we can do it so that you can switch between PWM/GPIO without issues then I think we should allow it). For PWM without changing settings you can use SoftwarePwm

I guess it's totally an opinion but I believe it's important for .NET to be able to change that also, if permissions are properly set, a user could request changing the pins state. Thanks for your input!

[krwq]

@larivierec can you please file a separate issue on that? We can figure out if we should close this one there once we have enough data. If you have any info how to actually do that with i.e. SysFs please put additional info there. I don't expect that will work for all possible cases - we can likely get the GpioController which has direct memory access to do that, not sure about the rest of them.

We need to figure out how to combine GpioController with PWM on the API level as well since they are currently not tangled in the code (but are on the hardware level).

[pgrawehr]

@krwq: For Raspbian, setting the alternate pin modes is technically easy to do (using /dev/gpiomem) and is noted in #857. The infrastructure required to do it will be part of my Board proposal (not yet, though). I don't know whether Debian or Ubuntu offer /dev/gpiomem access, though.

@larivierec If you can use overlays, it should work, actually. For Raspbian, it is now also required to enable an overlay (don't recall the exact name) to make PWM initialy work. You can also use the gpio mode command from the wiringpi package.

[larivierec]

@krwq: For Raspbian, setting the alternate pin modes is technically easy to do (using /dev/gpiomem) and is noted in #857. The infrastructure required to do it will be part of my Board proposal (not yet, though). I don't know whether Debian or Ubuntu offer /dev/gpiomem access, though.

@larivierec If you can use overlays, it should work, actually. For Raspbian, it is now also required to enable an overlay (don't recall the exact name) to make PWM initialy work. You can also use the gpio mode command from the wiringpi package.

I can confirm that /dev/gpiomem is available on Ubuntu (unsure about debian).

For PWM channels, pwm-2chan must be enabled in the /boot/config.txt with dtoverlay. I also saw you referenced an issue I'll look over that documentation and thanks for that. Secondly, I don't believe going through wiringpi is the correct way to set the mode. The iot project currently offers a way to set gpio modes therefore it should probably support changing it to the alternate functions

[pgrawehr]

@larivierec : I fully agree that we should support that (and as stated above, I've already got a plan on how to implement it). The wiringpi notice was just a possible workaround.

[tardisgallifrey]

I just finished enabling I2C with the Ads1115 from Iot.Device.Bindings. The original setup just to add the package I got from here: https://darenmay.com/blog/net-core-and-gpio-on-the-raspberry-pi---leds-and-gpio/

His works. The .NET CLI version on the main Iot README didn't, at least for me.

I got the main test program on using the ADS115 from this github. However, it doesn't tell you which "using" namespaces are necessary. I was able to figure those out from thumbing through different folders, but it took several tries. .NET Core tells me that I'm missing them, but not which ones. As expected from a compiler.

Had no idea that the Iot.Device.Binding was specific to the device, not just to I2C. Handy that, once I figured it out.

Please consider that a sample program needs all of it's sections complete instead of just the main function. I'd be glad to submit the final working one of mine, if I knew how. Not sure of the proper order to fork/pull/push in order to submit such.

Almost forgot, I'm using the AdS1115 on a Raspberry Pi 4B/1G. I've loaded .NET Core 3.1 onto Raspbian buster (that took effort). I code native on the board using Visual Studio Code and the SSH extension. My first use of the ADS1115 was through C.

[pgrawehr]

@tardisgallifrey Can you give a bit more information about which errors you got? I'm using the ADS1115 in many places, and it always worked fine. All bindings have examples that show the usage.

[tardisgallifrey]

At this time, I've figured out all my problems. My suggestion was:
couldn't we work on the documentation so noobs (such as myself) could
actually use your repo? It's very unclear what needs to be in your I2C
program.

For the record, I'm programming I2C on a raspberry pi 4B, using dotnet and
the remote SSH extension of Visual Studio Code.

I'll start at the beginning and go down the list:

This add package command:
nuget install System.Device.Gpio -PreRelease -Source
https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet5/nuget/v3/index.json

Requires one to install nuget, which is not mentioned in the readme.md
displayed on the front page of the IOT repo. Once I did get it installed,
the readme.md does not say that this needs to be called while in your
dotnet project folder. Additionally, once that's figured out, the nuget
command returns a 404 error.

The .NET CLI instructions to add the packages for the IOT repo also do not
work, but I've forgotten why.

On this page:
https://darenmay.com/blog/net-core-and-gpio-on-the-raspberry-pi---leds-and-gpio/

I found these instructions to add the packages:
dotnet add package System.Device.Gpio --source
https://dotnetfeed.blob.core.windows.net/dotnet-iot/index.json
dotnet add package Iot.Device.Bindings --source
https://dotnetfeed.blob.core.windows.net/dotnet-iot/index.json

They worked, but only added the version 1.0.0 of both System.Device.Gpio and
Iot.Devices.Bindings. I was able later to get the nuget packages to
install by visiting the nuget package home page from the link in your
readme.md. There I was able to figure out how to load the Prelease
packages.

Still with me? I hope so.

Your home page README.md isn't bad in sorting out where a user needs to go
to use standard GPIO pins. However, it is quite cryptic in trying to find
things you've built like the bindings for the ADS115. I had to fumble
around quite a bit to find that section. Once I did, I found this page:
https://github.com/dotnet/iot/tree/master/src/devices/Ads1115

It had these instructions on how to use the bindings in order to access the
ADS1115:
// set I2C bus ID: 1
// ADS1115 Addr Pin connect to GND
I2cConnectionSettings settings = new I2cConnectionSettings(1,
(int)I2cAddress.GND);
I2cDevice device = I2cDevice.Create(settings);

// pass in I2cDevice
// measure the voltage AIN0
// set the maximum range to 6.144V
using (Ads1115 adc = new Ads1115(device, InputMultiplexer.AIN0,
MeasuringRange.FS6144))
{
// read raw data form the sensor
short raw = adc.ReadRaw();
// raw data convert to voltage
double voltage = adc.RawToVoltage(raw);
}

However, unless one stumbles around in the ADS folder enough to find this
information:
using System;
using System.Device.I2c;
using System.Diagnostics;
using System.Threading;
using System.Device.Gpio;
using Iot.Device.Ads1115;
using UnitsNet;

You'll only get errors from your build about needing a namespace. It won't
tell you which one, which is obvious but frustrating. Both of these
sections should be listed in the "how to use this code" block on the main
README.md page of the ADS1115 repo, in my opinion.

Once I finally got the program in C# to build, it worked; yet, I was also
getting the 'error 121' messages. I was able to deduce from the bug
discussion that my ADS1115 is probably damaged. I had the same that the
guy for a different board had, reads sometimes, but not others. Might read
three times in a row and then fail. To be clear, mine wasn't even high
speed. I had a two second delay in between readings.

Sorry to be long winded, but I think it is necessary. Y'all have done a
great work with the repo. It covers tons of ground that someone like
myself would rather not cover, just to see a temperature show up on
screen. I've worked through the same thing using C and a starter program
from someone else. That's how I eventually figured out it was my board.
Both were giving random errors.

I am a noob to C#. I am not the quickest programmer out there. I just
think that if you publish something for us in the field to use, it should
really be clear. It should state everything I need to do to install and
manage the work. It also needs to be tested (the instructions) to see if it is understandable
by folks that don't work with it everyday. Though I was able to eventually
figure out what I needed, I had to dig around a lot on your repo and many
other web pages just to make the software complete a build.

I'm pretty good at writing. I'd be willing to show you some of it if
needed. I wrote up my own 'how to' in a Dev.to post just so I would
remember how this works. I'd be glad to help with your documentation as I
think this is a big thing y'all are doing for the raspberry pi community
(among others). But, we out in the world aren't really interested in
spending whole days just finding out how to get one thing working. We'd
like to go one place and have clear, bulletproof instructions that work
right every time.

Thanks for responding.
Dave
Dev.to - at.tardisgallifrey
Twitter - at.abigmanrunning
WP - tardis1.wordpress.com

--Bigmanrunning
http://bigmanrunning.wordpress.com

On Mon, Jul 6, 2020 at 12:18 AM Patrick Grawehr [e-mail]
wrote:

@tardisgallifrey https://github.com/tardisgallifrey Can you give a bit
more information about which errors you got? I'm using the ADS1115 in many
places, and it always worked fine. All bindings have examples that show the
usage.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/iot/issues/802#issuecomment-654019665, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ADNQUEV6Q4L2XQQOPLJRM63R2FNB3ANCNFSM4JBBPZ2Q
.

[Ellerbach]

Some improvements with #1197 and #1168

[tardisgallifrey]

Thanks, those look good. Looking forward to seeing the same on I2C.

[Ellerbach]

@tardisgallifrey , for all bindings, you also have an example on how to use them. Did that help as well? The samples are always in the same place explaining how to use the sensor with all the using and all what is necessary.

Thanks, those look good. Looking forward to seeing the same on I2C

Thanks, will work on I2C as well then. I2C is much easier than the others!

[Ellerbach]

@tardisgallifrey I2C documented :-)

[Ellerbach]

As we will most likely not support the OneWire implementation and have built in one for DHT sensors, I'll close this issue as all the SPI, I2C and PWM plus included minimal example is now documented.