Get sensor data on Raspberry Pi?

Hi,

Is there a way to read sensor data from a BME280 (i.e. temperature, altitude, pressure) that’s connected over i2c to a Raspberry Pi, directly from an openFrameworks project, running on the same Pi?

I was thinking of getting the sensor data with a Python script. The script would be run at regular intervals with crontab and update a text file that then could be read by my openFrameworks project. However, I’m open to more elegant suggestions!

I think there is a few options for it:
like this one or that one.

You must just add the correct flags to the config.make:

PROJECT_LDFLAGS=-Wl,-rpath=./LibPathToBmeDotH,-lwiringPi

Hope this helps.

Best,

P

1 Like

Thanks, the links look promising.

Is this to link the bme280 library (i.e. cpp + h) to my openFrameworks project?

yes that’s it.

Could you please briefly explain what PROJECT_LDFLAGS=-Wl and -lwiringPi are doing?
I tried searching online but I didn’t really find anything. I’m only familiar with the very basics of makefiles.

Also does it matter where I put this in the config.make?

Maybe you already know,
First thing is enable GPIO pins access in raspi-config

Not really, no. :wink:

Really? I didn’t find anything about the -Wl flag, but PROJECT_LDFLAGS generally seems to be something between the compiler and linker.

-lwiringPi on the other hand seems to refer to Gordon’s Arduino wiring-like WiringPi Library, mainly written in C. Do I need to get that too?

I’m confused.

lwiringPi stands for libwiringPi which needs to be included in your path somewhere.
So for example when you install a library, you need to
make -j$(nproc)
then
sudo make install
so the library will be install in a location which is already in your path.

In the case of wiringPi :

git clone https://github.com/WiringPi/WiringPi
cd WiringPi/
./build

Then to enable GPIO : sudo raspi-config then navigate to the right section (probably the one referning to input output then enable GPIOs).
I don’t have a PI with me right now, so can’t really tell you, can help this evening, but there is also loads of documentation online.

-Wl i can’t remember what it’s used for.
@dimitre do you know what this is used for ?

1 Like

I’m pretty sure that wiringPi comes with Raspbian now; at least it did with Stretch.

OK, I believe I get it now. You include libwiringPi, because it’s a dependency of the first bme280 “driver” you posted above, right?
By the way, I’ll probably use that one, because the Adafruit one has a ton of dependencies that I’m not too eager to all track down and install.

What exactly do you mean by “in your path”?
What does make -j$(nproc) do exactly? What is nproc?

Do you mean enable Remote GPIO (Enable/disable remote access to GPIO pins)?

It seems that @TimChi is right. libwiringPi already seems to be installed on my RPi.
I did a quick apt search wiringpi and the following popped up:

Screenshot 2021-12-10 at 18.44.54

Hey as Pierre mentioned, raspi-config enables various functionality in Raspbian. So I always turn on things like: SSH; I2C; SPI; Serial; Remote GPIO. They’re not typically “on” by default. Raspi-config has a gui these days, but you can also access (all of) the settings thru the terminal with sudo raspi-config. You’ll reboot the pi after you make the changes and exit.

The wiringPi library is awesome and it provides code for interacting with the GPIO (and I2C, SPI, etc), so #include "wiringPi.h" Then you also typically need to include a library of some kind for whatever sensors, leds, etc you have attached to the GPIO. Adafruit often writes these in either python or c++, but you can usually find c++ ones on the internet too.

Then if I remember right (ugh its been a few years), I amended config.make to link the wiringPI library as mentioned above.

PROJECT_LDFLAGS += -lwiringPi

Edit: the wiringPi library resides in /usr/include/ on my older Pi3 with Stretch

1 Like

Yes, I know about that. I was just asking, whether Remote GPIO was what he meant, since he only wrote about “GPIO”. :slight_smile:

Pierre has linked to two options for the bme 280 above. It’s a temperature sensor with a few other features.

On my RPi Zero 2 W, wiringPi.h is also located there. Thanks for pointing that out.

I’m not really accustomed to dealing with external libraries. I’m only used to handling my own cpp and header files.

Should I for instance move the driver cpp and header files from GitHub to my src folder or place them elsewhere? Are there any conventions about this?

I think there are a few options for handling external libraries that aren’t part of a linux distro. If you think you might want to use it again in the future, you could make an add-on out of it. If its just a 1-time thing, then adding the headers to the project src folder will work too. Linux tends to put its package headers into /usr/include/ or maybe /usr/local/include/. It seems like these paths are searched automatically when the project compiles, so you don’t have to tell the linker where to look for header files if they’re in these directories. And then the libraries themselves end up in /usr/lib/, which the linker also seems to find by default.

1 Like

nproc is the amount of cores you have:
echo $nproc will tell you 4.

Remote GPIO isn’t enabling the GPIOs pins, it’s enabling remote GPIO.
GPIOs should be enabled by defautl actually.

#include <wiringPi.h>

class printOnTouch{
    public:
    printOnTouch(int _pinNbr):pinNbr(_pinNbr){
        setup();
    }

    void setup(){
        
        wiringPiSetup();
        pinMode(pinNbr, INPUT);
        pullUpDnControl(pinNbr, PUD_UP) ;

    }

    void update(){

        if(digitalRead(pinNbr) == LOW)
        {	

            
            std::cout << "==== contact on the PI ====" << std::endl;
        }
    }

    private:
    int pinNbr;
};

You can use this mini class in OF with the modification of the config.make, to double check that you get a print out in the console when connecting a pin (pinNbr in the code).

use gpio readall to check the pinout:

 +-----+-----+---------+------+---+---Pi 4B--+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 |     |     |    3.3v |      |   |  1 || 2  |   |      | 5v      |     |     |
 |   2 |   8 |   SDA.1 |   IN | 1 |  3 || 4  |   |      | 5v      |     |     |
 |   3 |   9 |   SCL.1 |   IN | 1 |  5 || 6  |   |      | 0v      |     |     |
 |   4 |   7 | GPIO. 7 |   IN | 1 |  7 || 8  | 1 | IN   | TxD     | 15  | 14  |
 |     |     |      0v |      |   |  9 || 10 | 1 | IN   | RxD     | 16  | 15  |
 |  17 |   0 | GPIO. 0 |   IN | 0 | 11 || 12 | 0 | IN   | GPIO. 1 | 1   | 18  |
 |  27 |   2 | GPIO. 2 |   IN | 0 | 13 || 14 |   |      | 0v      |     |     |
 |  22 |   3 | GPIO. 3 |   IN | 0 | 15 || 16 | 0 | IN   | GPIO. 4 | 4   | 23  |
 |     |     |    3.3v |      |   | 17 || 18 | 0 | IN   | GPIO. 5 | 5   | 24  |
 |  10 |  12 |    MOSI |   IN | 0 | 19 || 20 |   |      | 0v      |     |     |
 |   9 |  13 |    MISO |   IN | 0 | 21 || 22 | 0 | IN   | GPIO. 6 | 6   | 25  |
 |  11 |  14 |    SCLK |   IN | 0 | 23 || 24 | 1 | IN   | CE0     | 10  | 8   |
 |     |     |      0v |      |   | 25 || 26 | 1 | IN   | CE1     | 11  | 7   |
 |   0 |  30 |   SDA.0 |   IN | 1 | 27 || 28 | 1 | IN   | SCL.0   | 31  | 1   |
 |   5 |  21 | GPIO.21 |   IN | 1 | 29 || 30 |   |      | 0v      |     |     |
 |   6 |  22 | GPIO.22 |   IN | 1 | 31 || 32 | 0 | IN   | GPIO.26 | 26  | 12  |
 |  13 |  23 | GPIO.23 |   IN | 0 | 33 || 34 |   |      | 0v      |     |     |
 |  19 |  24 | GPIO.24 |   IN | 0 | 35 || 36 | 0 | IN   | GPIO.27 | 27  | 16  |
 |  26 |  25 | GPIO.25 |   IN | 0 | 37 || 38 | 0 | IN   | GPIO.28 | 28  | 20  |
 |     |     |      0v |      |   | 39 || 40 | 0 | IN   | GPIO.29 | 29  | 21  |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+---Pi 4B--+---+------+---------+-----+-----+

use GPIO29 for example and short it to ground - right next to it-.

Hope this clarifies it for you.

Best,

P

1 Like

Thanks for all your help and suggestions, Pierre and Tim. It’s much appreciated!

I unfortunately ran into another issue. wiringPi doesn’t seem to have great support for newer Raspberry Pis. I’ve tried updating it with apt, compiling a newer version from source, and a couple of other stuff, but I can’t get the gpio readall command to work, which is bummer.
It somehow doesn’t manage to recognize the board type of the Zero 2 W model.

I then proceeded to test your script, Pierre, though not with openFrameworks, but in a separate, dedicated cpp file that I tried to compile with GCC.
However, even when I specify the directory, namely /usr/include, GCC somehow fails to #include <wiringPi.h> from there.
Here’s the command I used: g++ -I/usr/include main.cpp

right.
I’ll wip out my pi-zero-w2 this evening and will try to reproduce.
What’s your version of OS? Buster right?
it’s werid that it doesn’t work, maybe try to install it as dewscribed on the wiringPi website?
Follow the purge steps:

 sudo apt-get purge wiringpi
hash -r

Then:

sudo apt-get install git-core
sudo apt-get update
sudo apt-get upgrade

cd
git clone git://git.drogon.net/wiringPi 
cd ~/wiringPi
git pull origin
./build

Test the installation:

gpio -v
gpio readall

Let me know where you are having problems with those steps.

Best,

P

Yes, Debian Buster, since the driver of the display I use isn’t supported on Bullseye yet.

I already tried that.

The first issue with this is that the official git link is dead, since the developer abandoned the project a few years ago. I managed to find an alternate link and used that, however it doesn’t fix the issue:

git clone --branch final_official_2.50 https://github.com/WiringPi/WiringPi.git ~/wiringpi

I still get this after building it:

Raspberry Pi Details:
  Type: Unknown18, Revision: 00, Memory: 512MB, Maker: Sony
  * Device tree is enabled.
  *--> Raspberry Pi Zero 2 W Rev 1.0
  * This Raspberry Pi supports user-level GPIO access.

And:

Oops - unable to determine board type... model: 18

I now have these files in /usr/local/lib:

  • libwiringPi.so
  • libwiringPiDev.so

OK, I finally got wiringPi working, but only as a programming library. As a CLI tool, it still doesn’t comply.

There are a couple of things to note here!

First, after building wiringPi, it is necessary to add the path /usr/local/lib to /etc/ld.so.conf - to the same line as the already existing paths -, and reload the config with sudo ldconfig.

Then when attempting to compile with GCC, you don’t try to link the wiringPi.h file from /usr/include - like me - that ships with Raspian, but instead the newly installed wiringPi shared library files (*.so) from /usr/local/lib, for instance like this: g++ main.cpp -lwiringPi

With all of this, your example finally compiled fine, but did nothing when the pin was shorted to ground. I instead tried another example with a single blinking LED, and that worked fine.
Turns out, wiringPiSetup(); from your script, should be wiringPiSetupGpio(); instead.

Here’s a simplified version of your script:

#include <iostream>
#include <wiringPi.h>

const int pin = 17;

int main() {

  wiringPiSetupGpio();
  pinMode(pin, INPUT);
  pullUpDnControl(pin, PUD_UP);

  while (true) {
    if (digitalRead(pin) == LOW)
      std::cout << "Connection established\n";
    else
      std::cout << "No connection\n";
    delay(1000);
  }

  return 0;
}

It now compiles fine with the above GCC command.

This time I also cloned wiringPi from an other source:
git clone https://github.com/WiringPi/WiringPi.git

I’m not sure if that makes any difference though.

Sorry was a lit out of the loop lately.

Did you get it to work through with OF in the end?

I’m glad this has worked for you.

Best,

P

I was also quite busy today and yesterday, so I didn’t have time to try yet.
I’ll keep this thread updated with my findings.