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 <yyrk...@gmail.com> 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 <yyrk...@gmail.com> > 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 <yyrk...@gmail.com> >> 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 <raulpbloo...@gmail.com> >>> 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 <yyr...@gmail.com> >>>>> wrote: >>>>> >>>>>> >>>>>> #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(). >>>>>> >>>>>> >>>>>> On Wed, Jul 13, 2016 at 9:02 PM, Raulp <imsaura...@gmail.com> 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(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 >>>>>>> >>>>>>> >>>>>>> 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 <imsaura...@gmail.com> >>>>>>>> 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 >>>>>>>>> <https://groups.google.com/d/msgid/beagleboard/cb65b710-203e-4579-8c08-e2b817dc7a03%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> 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 >>>>>>> <https://groups.google.com/d/msgid/beagleboard/521956ed-983d-49b9-85f2-62e269dcf7fa%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>>> 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/68d794b1-fdd4-49de-acd0-30923269f437%40googlegroups.com >>>> <https://groups.google.com/d/msgid/beagleboard/68d794b1-fdd4-49de-acd0-30923269f437%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> 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/CALHSORpo7cvqW49gUCsS7-g-Sm-j2Zy_k8RqkdscPVj4Do6bzw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
