Weird Problem using GPIOs on BBB

GoogleGroups
1

I have interfaced a hardware using the 5 Gpios on BBB.I can talk to this device using GPIOs by manually (echoing 0 and 1 to the GPIOS) writing to it in the sys/class/gpio directory by first exporting the Gpios and configuring their directions and value.It works perfectly fine.
But,
When I try to do the same using a user space C application I dont get the expected response.I am running this app as sudo’er and I have oscilloscope’d the timings of HIGH/LOW levels of the GPIOs and compared it with that of the manually writing procedure of GPIOS. The waveform and the timing diagrams almost matches (95%)
So,
What could mysteriously be missing here.?I can go deep into analyzing the wave-forms and timing diagrams as well if there is an issue in the timings of the Signals.
Please advice.Thanks in advance !
-Rp

2

When I try to do the same using a user space C application I dont get the expected response.I am running this app as sudo’er and I have oscilloscope’d the timings of HIGH/LOW levels of the GPIOs and compared it with that of the manually writing procedure of GPIOS. The waveform and the timing diagrams almost matches (95%)

I’m not exactly sure what you saying here . . . However, in code are you actually checking for errors, and error codes. Or does your code simply open, and use the file descriptors without any error checking what so ever ?

Seeing the code would probably help a lot.

3

OK let em explain a bit more :
#code 1
sudo echo 41 > export
cd gpio41
sudo chmod 666 direction
sudo chmod 666 value
sudo echo out > direction
sudo echo 1 > value
sleep 1
sudo echo 0 > value

Output : Toggle on the GPIO 41

#code2
//create an instance of gpio41
//set direction as OUT
//set value as 1
usleep(100000);
//set value 0

Output : Toggle doesnt happens

Now the output I am referring to is the functioning of the hardware I have used.(ignore toggling , it happens anyway using the code#2)

Or does your code simply open, and use the file descriptors without any error checking what so ever ?

I dont use error codes to check , but I have seen in the oscilloscope that the signal transition is happening according to my code.

-Rp

4

#code2
//create an instance of gpio41
//set direction as OUT
//set value as 1
usleep(100000);
//set value 0

Output : Toggle doesnt happens

Whats this ? This is not code. At best it’s comments, and usleep().

5

Let’s put it this way. No code, no help . . .

6

Attached.
One is the cpp code and other is the bash script.
cpp code uses the GPIO class from the attached GPIO.7z .

code.cpp (3.43 KB)

code.bash (3.3 KB)

GPIO.7z (20.6 KB)

7

You only need to toggle gpio ? How fast do you need it to be ? That code is far to complex, and uses threading, as well as callbacks for some odd reason. Threaded code can have performance overhead, and callbacks can cause problems on the stack if you’re not careful.

You would be better off writing your own wrapper code. You could either wrap the sysfs gpio files directly. Or if you wished you could wrap config-pin from universal io.

Anyway, it’s getting late here so perhaps tomorrow I’ll write up a quick example, that is far less code than D.R. Molloy’s . . . uh . …library ? The thing is, the sysfs directory / file structure is already there and functional. Why would anyone need to write so much code to encapsulate it ? shrug

8

OK, I’m still a little busy, but I should have something example wise in a couple hours.

9

Ok turns out I do not have to write an example. After a quick google search I found a very good simple example on stackoverflow: http://stackoverflow.com/questions/21198933/how-to-control-beaglebone-gpio-pins

So. . . this is a very good example that shows how one would, or could wrap the gpio sysfs files. This:

fs.open("/sys/kernel/debug/omap_mux/gpmc_ad4");
   fs << "7";

May be incorrect for current kernel / file system structure, but I can tell you what this bit of code is going. It’s simply muxing the pin he / she want to control in code. 0x7 == pin mux for GPIO mode. So you( we ) can either figure how do do this with modern debian images, or “we” could simply mu our pins with config-pin( universal IO ) or device tree overlay.

Personally, since I’ve been experimenting with Charles’ universal-io overlays and config-pin recently, and in my spare time. I’m favoring that lately. Also, that script is very easily wrapped in code as well. Anyway, once the pin it muxed for the correct mode, the rest of that code would( should ) simply work.

fs.open(“/sys/class/gpio/export”);
fs << “32”;
fs.close();

This is exactly as if you echo “32” into /sys/class/gpio/export. Which exports the pin.

fs.open(“/sys/class/gpio/gpio32/direction”);
fs << “out”;
fs.close();

Exactly like echoing “out” into /sys/class/gpio/gpio32/direction. Which configures the pin as output.

   fs.open("/sys/class/gpio/gpio32/value");
   fs << "1"; 
   fs.close();

Exactly the same as echoing “1” into /sys/class/gpio/gpio32/value. Which makes the pin output, and high.

Any further questions ?

10

By the way. I’m not familiar with the C++ fstream object. But this person is not doing any error checking . . .

11

Hello William,
Thankyou very much for jotting down all the relevant example amidst your busy schedule.I am really grateful to you.I will check this.This example looks far simpler to me.
Rgds,
Rp

12

You’re welcome. If you have more questions just ask.