I did the fseek because it didn't work without the fseek, and I agree that it doesn't make sense to fseek a psuedo device. You might be right in that the fseek was just adding delays or doing an fflush of the buffers. (The other reason was that I found examples on the Internet using fseek)
When I converted over to unix io, I no longer needed the seeks. I just wanted to get this working quickly and will probably convert over to using the PRU later. Thanks for the input. On 2013-10-18 9:00 PM, "Juanjo" <[email protected]> wrote: > I might be wrong but I think doing fseek() on a GPIO "device" isn't quite > correct. > > A GPIO device is more like a char device not a block device were you can > actually seek it. So you are only limited to write 1 or 0, the delay in > between is set by you plus all the variance that a common not-RT OS adds to > it. We know that these are exposed on /sys fs and not on /dev where you can > actually see if you are dealing with a char or block device. > > For a more precise bit banging PRUSS is the way to do it IMHO. > > On Friday, October 18, 2013 7:22:17 PM UTC-3, Paul Tan wrote: >> >> Thanks, I'll try to see if there is a difference with libsoc or not. >> However, I did manage to get it working with low level unix i/o (open, >> write) instead of the buffered stream i/o (fopen, fwrite). It works >> correctly, I didn't need a seek operation, and I was able to get pulse >> widths down to 10uS reliably. Interesting difference though: fwrite >> to "/sys/class/gpio/export" succeeds even if GPIO30 was already exported, >> but write to "/sys/class/gpio/export" fails if GPIO30 was already exported. >> >> In case anyone's wondering why I'm trying to get really short pulses, I'm >> trying to connect an iGaging DRO slides to a BeagleBone Black (yeah, I'm >> trying to CNC my lathe using a DRO closed loop servo with my Dual Motor >> Controller Capes). Scoping out my iGaging DRO, I found that the builtin >> controller uses 24uS pulses with a 128uS duty cycle. I'm working off of >> Yuriy's work on the Arduino (http://www.yuriystoys.com/p/** >> android-dro.html <http://www.yuriystoys.com/p/android-dro.html>), but >> trying it on the BeagleBone. >> >> Paul Tan. >> http://exadler.com >> http://exadler.blogspot.com >> >> >> >> On Friday, October 18, 2013 1:26:31 PM UTC-4, Jack Mitchell wrote: >>> >>> On 18/10/2013 18:14, Paul Tan wrote: >>> > I'm having some weirdness that I don't quite understand. I'm trying >>> to >>> > just toggle a GPIO pin (GPIO30) on and off using C and just the file >>> > subsystem. Everything seems to work if there is a delay between the >>> > fseek and the fwrite. See this pastebin for the relevant code >>> > http://pastebin.com/Ftvv0nvE. As it is, it works. If you uncomment >>> the >>> > code, instead of creating a square wave on the oscilloscope, it just >>> > creates pulse spikes (i.e. short on times). Can someone explain what >>> is >>> > happening? I'm working off a stock BeagleBone Black, no updates (I >>> > wanted to make sure the code worked on all versions, as people would >>> be >>> > getting their BBB and trying it directly). >>> > >>> > Paul Tan. >>> > http://exadler.blogspot.com >>> > http://exadler.com >>> > >>> > -- >>> > 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. >>> > For more options, visit >>> > https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>. >>> >>> >>> Hi Paul >>> >>> If you don't object to using a library there is libsoc[1] which is made >>> for this exact purpose. If nothing else, you could see if the same >>> behavior is observed using it? >>> >>> https://github.com/jackmitch/**libsoc<https://github.com/jackmitch/libsoc> >>> >>> Cheers, >>> Jack. >>> >>> -- >>> >>> Jack Mitchell ([email protected]) >>> Embedded Systems Engineer >>> http://www.embed.me.uk >>> >>> -- >>> >> -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to a topic in the > Google Groups "BeagleBoard" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/beagleboard/SLaa4HiC99A/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
