C library for GPIO

[spunj]

Hello all!
I'm interested in using the GPIO for various tasks, mostly just for fun now. Looking around a bit has revealed a library for use in Python, but nothing seems to be available in C. Has anything been provided yet...? If not I'm prepared to make my own, I would just appreciate a point in the right direction to know where to start (low level calls). I'm a hardware engineer really (VHDL), and could use the experience to get back into C, as it has been some time!

[higwoth1]

Hi,

There is quite a nice one, if you've used Arduino syntax before, at https://projects.drogon.net/raspberry-pi/wiringpi/

Haven't tried it yet (too busy), but checking the code over it looks good.

I don't think it's safe, yet, to use in a multi-tasking environment, by which I mean if you have two programs trying to access the ports it may conflict and not work as expected. I could be wrong though. I don't think the Python library is either. Or the Pi examples come to that (try running two hello_audio tasks to hear the noise it makes).

There is the usual confusion with pin numbering.

Hopefully I'll get to play around with it tomorrow.

[spunj]

That was quick, thanks! I will make a circuit and have a play this weekend.

[gordon@drogon.net]

Hi,

There is quite a nice one, if you've used Arduino syntax before, at https://projects.drogon.net/raspberry-pi/wiringpi/

Haven't tried it yet (too busy), but checking the code over it looks good.

I don't think it's safe, yet, to use in a multi-tasking environment, by which I mean if you have two programs trying to access the ports it may conflict and not work as expected. I could be wrong though. I don't think the Python library is either. Or the Pi examples come to that (try running two hello_audio tasks to hear the noise it makes).

There is the usual confusion with pin numbering.

Hopefully I'll get to play around with it tomorrow.

It's "safe" in that it will do what you tell it to do - ie. if one program sets a pin to output and another sets it to input, then the last program to run "wins". There is no locking though, so if your setting a pin to an output and changing the value, then it's possible that another program changing another pin can alter that first operation if it gets interrupted in the middle of its read/modify/write cycle.

So the solution is to not have 2 programs playing with the GPIO....

And the pin numbering - yes - I notice they've changed the picture on the Wiki now to represent the actual Broadcom Chip pins - the arguments being "this is how it's done on other GPIO enabled devices". My view is that this is a Pi, not any other device with GPIO, lets keep it simple - which is the same view the Arduino folks take, however I'm going to update my "pins" diagram shortly.

It is technically correct that we should be using the Chip GPIO pins, but at the same time, it's so non-intuitive... If there is another Pi released with differnt GPIO pin mappings then it's all change, however if it's just a matter of changing the mapping in a library, then it's just that library that changes, re-link your own code and it carries on. Each way has its merits - I just want to make life easy for myself and other Arduino people I know who are moving to the Pi.

The one down-side right now is that your program will need to be root to use the GPIO with this library.

Do email or leave a comment on the website if you need though. If I have time this weekend then my plan is to relase and update (more documentation!) and put up some examples and photos, etc.

-Gordon

[higwoth1]

I'm with you there on the pin numbering, what's easier to update, a thousand programs or one library. Keep it simple.

Personally, I liked the Python library way of using pin1 as pin1, pin2 as pin2. They can change the hardware all they want, but pin1 will always be pin1, just like the Arduino/Maple. All the library has to do is take note of the board revision and map accordingly. Of course you get problems with pwm being available on some pins and not others which might change in a board revision. The Maple (leaflabs) had a similar problem and gets round it by having a function that returns the device capabilities, but that's a future problem.

I still haven't found time to play around with your library yet

[cupcake]

How about for C++? Has anyone written a C++ library to communicate with GPIOs? Or even a wrapper for the C library mentioned above?

Looking at the sample codes here, I'm tempted to make a switch to Python for this part of my system.

http://elinux.org/RPi_Low-level_periphe ... le_.28C.29

[texy]

I get an error with gcc when I try and compile that code with the Debian distro - see this post :
http://www.raspberrypi.org/phpBB3/viewt ... 934#p91486

Note sure why ?

Also on the Low Level Periperal page mentioned above, I note that in the C++ code, the ports are made Inputs before making them Outputs, but this
is not done in the Python code. Again, why is that?

Texy

[gordon@drogon.net]

I get an error with gcc when I try and compile that code with the Debian distro - see this post :
http://www.raspberrypi.org/phpBB3/viewt ... 934#p91486

Note sure why ?

Also on the Low Level Periperal page mentioned above, I note that in the C++ code, the ports are made Inputs before making them Outputs, but this
is not done in the Python code. Again, why is that?

Texy

In Gerts code, they are made input before output due to a slight optimisation in his code - making them input clears the bits to zero, making them output sets bits to one. Examine the macros in detail to understand.

I'l be updating my wiringPi library to work under c++ shortly - I'll post something here when I do, however something else, more exciting has come up...

-Gordon

[texy]

Oooh you are a tease !
Texy

[cupcake]

I'l be updating my wiringPi library to work under c++ shortly - I'll post something here when I do, however something else, more exciting has come up.

Look forward to that. Keep us updated. Cheers.

[cupcake]

I'l be updating my wiringPi library to work under c++ shortly - I'll post something here when I do, however something else, more exciting has come up...

I've now reused your library in my C++ program. Appears to work well. All I really did was to wrap the include in extern "C".

I am hitting kernel panics after my program has been running for a while though. Has anyone here stumbled upon something similar? I know certain keyboards have been causing it, but I don't have any keyboard connected to my RPi (simply power, ethernet cable, and GPIO jumper wires).