I guess mmio would be sufficient enough for our application where we would be able to access the gpio pins in mhz frequency as compared to khz frequency through sys/class.
On Monday, April 4, 2016 at 5:49:01 PM UTC+5:30, Dennis Lee Bieber wrote: > > On Mon, 4 Apr 2016 03:40:22 -0700 (PDT), Sumit Bhut > <[email protected] <javascript:>> declaimed the following: > > >> > >> Here also the problem remains the same as in my code, we are not able > to > >initialize the DHT11 sensor somehow... but yeah on a surprising note this > >link proved to be quite handy in fetching the data from the sensor though > >as i am not acquainted with python, whatever is happening inside the code > >is mysterious to me. > > > > > https://learn.adafruit.com/dht-humidity-sensing-on-raspberry-pi-with-gdocs-logging/software-install-updated > > > Well, based on my C++ code results, the native BBB will not be > able to > successfully read the DHT11. I could signal it to start okay, but wasn't > capturing the return bits fast enough to get them all, leading to a > timeout > when the device had sent everything and I was still waiting for part of > the > first byte. > > The /sys file system access has too much overhead for the timing > required. Even the "loadable kernel module" guide that had been referenced > indicated those had 20usec response latency, and that's basically the size > of a 0-bit; by the time the kernal module could act on the start of a > 0-bit, it would be time to detect the end of the bit. > > The Adafruit code is doing one thing I'd have to study -- the > memory-mapped I/O, which bypasses the OS access scheme. That should be > fast > enough (if an Arduino @ 16MHz with direct pin access can handle it, surely > a BBB @ 1GHz with direct I/O access should keep up). {Now, do I spend next > week-end converting to MMIO, using the Adafruit core, or just code an > Arduino -- to make sure my DHT11 is working correctly} Actually -- it does > two things: besides memory mapping, it changes process priority to help > keep the OS out of the way. > > Interesting -- they aren't bothering with clock timings at all; > they > are just counting loop cycles while testing for both the low and high > states, and then using the bit-start low count (at 50usec average) as the > split point between 0 and 1 bits. Makes it somewhat clock-independent as > long as the loop runs fast enough to get more than a few counts for the > shortest duration. > > If the MMIO mode didn't work, the next step would be PRU. > > NOTE: the only thing the file Beaglebone_Black_Driver.c does is > turn > the library into something that can be imported into Python. > -- > Wulfraed Dennis Lee Bieber AF6VN > [email protected] <javascript:> HTTP://wlfraed.home.netcom.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 [email protected]. For more options, visit https://groups.google.com/d/optout.
