Re: [beagleboard] Weird Problem using GPIOs on BBB

[William Hermans]

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

On Thu, Jul 14, 2016 at 9:11 PM, Raul Piper  wrote:

> 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
>
> On Friday, July 15, 2016 at 2:26:00 AM UTC+5:30, William Hermans wrote:
>>
>> By the way. I'm not familiar with the C++ fstream object. But this person
>> is not doing any error checking . . .
>>
>> On Thu, Jul 14, 2016 at 1:48 PM, William Hermans 
>> wrote:
>>
>>> 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 ?
>>>
>>> On Thu, Jul 14, 2016 at 11:20 AM, William Hermans 
>>> wrote:
>>>
 OK, I'm still a little busy, but I should have something example wise
 in a couple hours.

 On Thu, Jul 14, 2016 at 1:00 AM, William Hermans 
 wrote:

> 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*
>
> On Wed, Jul 13, 2016 at 10:02 PM, Raul Piper 
> wrote:
>
>> Attached.
>> One is the cpp code and other is the bash script.
>> cpp code uses the GPIO class from the attached GPIO.7z .
>>
>>
>> On Thursday, July 14, 2016 at 9:50:45 AM UTC+5:30, William Hermans
>> wrote:
>>>
>>> Let's put it this way. No code, no help . . .
>>>
>>> On Wed, Jul 13, 2016 at 9:19 PM, William Hermans 
>>> wrote:
>>>

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

 Output : Toggle doesnt happens

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


 On Wed, Jul 13, 2016 at 9:02 PM, Raulp 
 wrote:

> 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(10);
> //set value 0
>

Re: [beagleboard] Weird Problem using GPIOs on BBB

[Raul Piper]

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

On Friday, July 15, 2016 at 2:26:00 AM UTC+5:30, William Hermans wrote:
>
> By the way. I'm not familiar with the C++ fstream object. But this person 
> is not doing any error checking . . .
>
> On Thu, Jul 14, 2016 at 1:48 PM, William Hermans  > wrote:
>
>> 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 ?
>>
>> On Thu, Jul 14, 2016 at 11:20 AM, William Hermans > > wrote:
>>
>>> OK, I'm still a little busy, but I should have something example wise in 
>>> a couple hours.
>>>
>>> On Thu, Jul 14, 2016 at 1:00 AM, William Hermans >> > wrote:
>>>
 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*

 On Wed, Jul 13, 2016 at 10:02 PM, Raul Piper  wrote:

> Attached.
> One is the cpp code and other is the bash script.
> cpp code uses the GPIO class from the attached GPIO.7z .
>
>
> On Thursday, July 14, 2016 at 9:50:45 AM UTC+5:30, William Hermans 
> wrote:
>>
>> Let's put it this way. No code, no help . . .
>>
>> On Wed, Jul 13, 2016 at 9:19 PM, William Hermans  
>> wrote:
>>
>>>
>>> #code2
>>> //create an instance of gpio41
>>>  //set direction as OUT
>>> //set value as 1
>>> usleep(10);
>>> //set value 0
>>>
>>> Output : Toggle doesnt happens
>>>
>>> Whats this ? This is not code. At best it's comments, and usleep().
>>>
>>>
>>> On Wed, Jul 13, 2016 at 9:02 PM, Raulp  wrote:
>>>
 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(10);
 //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 

Re: [beagleboard] Weird Problem using GPIOs on BBB

[William Hermans]

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

On Thu, Jul 14, 2016 at 1:48 PM, William Hermans  wrote:

> 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 ?
>
> On Thu, Jul 14, 2016 at 11:20 AM, William Hermans 
> wrote:
>
>> OK, I'm still a little busy, but I should have something example wise in
>> a couple hours.
>>
>> On Thu, Jul 14, 2016 at 1:00 AM, William Hermans 
>> wrote:
>>
>>> 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*
>>>
>>> On Wed, Jul 13, 2016 at 10:02 PM, Raul Piper 
>>> wrote:
>>>
 Attached.
 One is the cpp code and other is the bash script.
 cpp code uses the GPIO class from the attached GPIO.7z .


 On Thursday, July 14, 2016 at 9:50:45 AM UTC+5:30, William Hermans
 wrote:
>
> Let's put it this way. No code, no help . . .
>
> On Wed, Jul 13, 2016 at 9:19 PM, William Hermans 
> wrote:
>
>>
>> #code2
>> //create an instance of gpio41
>>  //set direction as OUT
>> //set value as 1
>> usleep(10);
>> //set value 0
>>
>> Output : Toggle doesnt happens
>>
>> Whats this ? This is not code. At best it's comments, and usleep().
>>
>>
>> On Wed, Jul 13, 2016 at 9:02 PM, Raulp  wrote:
>>
>>> 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(10);
>>> //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
>>>
>>>
>>> On Wednesday, July 13, 2016 at 8:52:30 PM UTC+5:30, William Hermans
>>> wrote:

 When I try to do the same using a user 

Re: [beagleboard] Weird Problem using GPIOs on BBB

[William Hermans]

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 ?

On Thu, Jul 14, 2016 at 11:20 AM, William Hermans  wrote:

> OK, I'm still a little busy, but I should have something example wise in a
> couple hours.
>
> On Thu, Jul 14, 2016 at 1:00 AM, William Hermans 
> wrote:
>
>> 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*
>>
>> On Wed, Jul 13, 2016 at 10:02 PM, Raul Piper 
>> wrote:
>>
>>> Attached.
>>> One is the cpp code and other is the bash script.
>>> cpp code uses the GPIO class from the attached GPIO.7z .
>>>
>>>
>>> On Thursday, July 14, 2016 at 9:50:45 AM UTC+5:30, William Hermans wrote:

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

 On Wed, Jul 13, 2016 at 9:19 PM, William Hermans 
 wrote:

>
> #code2
> //create an instance of gpio41
>  //set direction as OUT
> //set value as 1
> usleep(10);
> //set value 0
>
> Output : Toggle doesnt happens
>
> Whats this ? This is not code. At best it's comments, and usleep().
>
>
> On Wed, Jul 13, 2016 at 9:02 PM, Raulp  wrote:
>
>> 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(10);
>> //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
>>
>>
>> On Wednesday, July 13, 2016 at 8:52:30 PM UTC+5:30, William Hermans
>> wrote:
>>>
>>> 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%)

>>>
>>> 

Re: [beagleboard] Weird Problem using GPIOs on BBB

[William Hermans]

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

On Thu, Jul 14, 2016 at 1:00 AM, William Hermans  wrote:

> 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*
>
> On Wed, Jul 13, 2016 at 10:02 PM, Raul Piper 
> wrote:
>
>> Attached.
>> One is the cpp code and other is the bash script.
>> cpp code uses the GPIO class from the attached GPIO.7z .
>>
>>
>> On Thursday, July 14, 2016 at 9:50:45 AM UTC+5:30, William Hermans wrote:
>>>
>>> Let's put it this way. No code, no help . . .
>>>
>>> On Wed, Jul 13, 2016 at 9:19 PM, William Hermans 
>>> wrote:
>>>

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

 Output : Toggle doesnt happens

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


 On Wed, Jul 13, 2016 at 9:02 PM, Raulp  wrote:

> 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(10);
> //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
>
>
> On Wednesday, July 13, 2016 at 8:52:30 PM UTC+5:30, William Hermans
> wrote:
>>
>> 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.
>>
>> On Wed, Jul 13, 2016 at 2:41 AM, Raulp  wrote:
>>
>>> 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
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to beagleboard...@googlegroups.com.
>>> To view this discussion on the web visit
>>> 

Re: [beagleboard] Weird Problem using GPIOs on BBB

[William Hermans]

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*

On Wed, Jul 13, 2016 at 10:02 PM, Raul Piper  wrote:

> Attached.
> One is the cpp code and other is the bash script.
> cpp code uses the GPIO class from the attached GPIO.7z .
>
>
> On Thursday, July 14, 2016 at 9:50:45 AM UTC+5:30, William Hermans wrote:
>>
>> Let's put it this way. No code, no help . . .
>>
>> On Wed, Jul 13, 2016 at 9:19 PM, William Hermans 
>> wrote:
>>
>>>
>>> #code2
>>> //create an instance of gpio41
>>>  //set direction as OUT
>>> //set value as 1
>>> usleep(10);
>>> //set value 0
>>>
>>> Output : Toggle doesnt happens
>>>
>>> Whats this ? This is not code. At best it's comments, and usleep().
>>>
>>>
>>> On Wed, Jul 13, 2016 at 9:02 PM, Raulp  wrote:
>>>
 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(10);
 //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


 On Wednesday, July 13, 2016 at 8:52:30 PM UTC+5:30, William Hermans
 wrote:
>
> 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.
>
> On Wed, Jul 13, 2016 at 2:41 AM, Raulp  wrote:
>
>> 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
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to beagleboard...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/cb65b710-203e-4579-8c08-e2b817dc7a03%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
 For more options, 

Re: [beagleboard] Weird Problem using GPIOs on BBB

[Raul Piper]

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


On Thursday, July 14, 2016 at 9:50:45 AM UTC+5:30, William Hermans wrote:
>
> Let's put it this way. No code, no help . . .
>
> On Wed, Jul 13, 2016 at 9:19 PM, William Hermans  > wrote:
>
>>
>> #code2
>> //create an instance of gpio41
>>  //set direction as OUT
>> //set value as 1
>> usleep(10);
>> //set value 0
>>
>> Output : Toggle doesnt happens
>>
>> Whats this ? This is not code. At best it's comments, and usleep().
>>
>>
>> On Wed, Jul 13, 2016 at 9:02 PM, Raulp > > wrote:
>>
>>> 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(10);
>>> //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
>>>
>>>
>>> On Wednesday, July 13, 2016 at 8:52:30 PM UTC+5:30, William Hermans 
>>> wrote:

 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.

 On Wed, Jul 13, 2016 at 2:41 AM, Raulp  wrote:

> 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
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google 
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to beagleboard...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/cb65b710-203e-4579-8c08-e2b817dc7a03%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

 -- 
>>> For more options, visit http://beagleboard.org/discuss
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to beagleboard...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/521956ed-983d-49b9-85f2-62e269dcf7fa%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: [beagleboard] Weird Problem using GPIOs on BBB

[William Hermans]

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

On Wed, Jul 13, 2016 at 9:19 PM, William Hermans  wrote:

>
> #code2
> //create an instance of gpio41
>  //set direction as OUT
> //set value as 1
> usleep(10);
> //set value 0
>
> Output : Toggle doesnt happens
>
> Whats this ? This is not code. At best it's comments, and usleep().
>
>
> On Wed, Jul 13, 2016 at 9:02 PM, Raulp  wrote:
>
>> 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(10);
>> //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
>>
>>
>> On Wednesday, July 13, 2016 at 8:52:30 PM UTC+5:30, William Hermans wrote:
>>>
>>> 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.
>>>
>>> On Wed, Jul 13, 2016 at 2:41 AM, Raulp  wrote:
>>>
 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

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to the Google
 Groups "BeagleBoard" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to beagleboard...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/beagleboard/cb65b710-203e-4579-8c08-e2b817dc7a03%40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/521956ed-983d-49b9-85f2-62e269dcf7fa%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORp14_KYQAcMPQyWkpn17LxZSA9V4D2tmqhR1XyXxA5UkA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Weird Problem using GPIOs on BBB

[William Hermans]

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

Output : Toggle doesnt happens

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


On Wed, Jul 13, 2016 at 9:02 PM, Raulp  wrote:

> 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(10);
> //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
>
>
> On Wednesday, July 13, 2016 at 8:52:30 PM UTC+5:30, William Hermans wrote:
>>
>> 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.
>>
>> On Wed, Jul 13, 2016 at 2:41 AM, Raulp  wrote:
>>
>>> 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
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/cb65b710-203e-4579-8c08-e2b817dc7a03%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/521956ed-983d-49b9-85f2-62e269dcf7fa%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORpGnC6YmgO9-y9Z-W%2Bsd%3DysiYRiaNm5mRe-KLR6XBYJ%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Weird Problem using GPIOs on BBB

[Raulp]

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(10);
//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


On Wednesday, July 13, 2016 at 8:52:30 PM UTC+5:30, William Hermans wrote:
>
> 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.
>
> On Wed, Jul 13, 2016 at 2:41 AM, Raulp  > wrote:
>
>> 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
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/cb65b710-203e-4579-8c08-e2b817dc7a03%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/521956ed-983d-49b9-85f2-62e269dcf7fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Weird Problem using GPIOs on BBB

[William Hermans]

>
> 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.

On Wed, Jul 13, 2016 at 2:41 AM, Raulp  wrote:

> 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
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/cb65b710-203e-4579-8c08-e2b817dc7a03%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORq-cz1hxjWQCy-VNiZheN6HP8EL2J7wF9bAVP1HNoVDEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Weird Problem using GPIOs on BBB

[Raulp]

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

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cb65b710-203e-4579-8c08-e2b817dc7a03%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.