Find error for DHT11 with BBB code .......

[Sumit Bhut]

Hello friends,

I'm compilited this code for interface BBB with DHT11(temperature-humidity sensor) this code is compiled and run successfully but OUTPUT
is 0'c temperature - 0% humidity ....
Plz , find error this code...


Code-

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <stdint.h>
#include <sys/time.h>
#include <unistd.h>

#define MAXTIMINGS    85
#define DHTPIN        48
int dht11_dat[5] = { 0, 0, 0, 0, 0 };


void inputdirection(int pin);

int readpin(int pinnum);

void outputdirection();
void writepin(int pinnum, int value);
void pauseSec(int sec);
void pauseNanoSec(long nano);

void outputdirection()
{
        char buf[10];
        char buf2[50] = "/sys/class/gpio/gpio";


            FILE *in,*indir;

                in = fopen("/sys/class/gpio/export", "w");
                    fseek(in,0,SEEK_SET);
                        fprintf(in,"%d",48);
                            fflush(in);
                               
                                sprintf(buf,"%i",48);
                                    strcat(buf2,strcat(buf,"/direction"));
                                        indir = fopen(buf2, "w");
                                            fseek(indir,0,SEEK_SET);
                                                fprintf(indir,"out");
                                                    fflush(indir);
                                                        fclose(in);
                                                            fclose(indir);

}

void inputdirection(int pin)
{
        char buf[10];
        char buf2[50] = "/sys/class/gpio/gpio";
        FILE *in,*indir;

            in = fopen("/sys/class/gpio/export", "w");
                fseek(in,0,SEEK_SET);
                    fprintf(in,"%d",48);
                        fflush(in);
                           
                            sprintf(buf,"%i",48);
                                strcat(buf2,strcat(buf,"/direction"));
                                    indir = fopen(buf2, "w");
                                        fseek(indir,0,SEEK_SET);
                                            fprintf(indir,"in");
                                                fflush(indir);
                                                    fclose(in);
                                                        fclose(indir);

}
int readpin(int pinnum)
{
    int value;
        FILE *inval;
                inval = fopen("/sys/class/gpio/gpio48/value", "r");
                        fseek(inval,0,SEEK_SET);
                                fscanf(inval,"%d",&value);
                                        fclose(inval);
                                        return value;
}

   
void writepin(int pinnum, int value)
{
        FILE *val;
            char buf[5];
                char buf2[50] = "/sys/class/gpio/gpio";

                    sprintf(buf,"%i",pinnum);
                        strcat(buf2,strcat(buf,"/value"));

                            val = fopen(buf2, "w");
                                fseek(val,0,SEEK_SET);
                                    fprintf(val,"%d",value);
                                        fflush(val);
                                            fclose(val);
}
void pauseSec(int sec)
{
        time_t now,later;

            now = time(NULL);
                later = time(NULL);

                    while((later - now) < (double)sec)
                                later = time(NULL);
}

void pauseNanoSec(long nano)
{
        struct timespec tmr1;

            tmr1.tv_sec = 0;
                tmr1.tv_nsec = nano;

                   
}

 

 
void read_dht11_dat()
{
    uint8_t laststate    = 1;
    uint8_t counter        = 0;
    uint8_t j        = 0, i;
    float    f; /* fahrenheit */
 
    dht11_dat[0] = dht11_dat[1] = dht11_dat[2] = dht11_dat[3] = dht11_dat[4] = 0;
 
    /* pull pin down for 18 milliseconds */
    outputdirection();
    writepin(48,0);
    usleep(18000);
    /* then pull it up for 40 microseconds */
    writepin(48,1);
        usleep(40);
    /* prepare to read the pin */
    inputdirection(48);
 
    /* detect change and read data */
    for ( i = 0; i < MAXTIMINGS; i++ )
    {
        counter = 0;
        while ( readpin(48) == laststate )
        {
            counter++;
            usleep( 1 );
            if ( counter == 255 )
            {
                break;
            }
        }
        laststate = readpin(48);
 
        if ( counter == 255 )
            break;
 
        /* ignore first 3 transitions */
        if ( (i >= 4) && (i % 2 == 0) )
        {
            /* shove each bit into the storage bytes */
            dht11_dat[j / 8] <<= 1;
            if ( counter > 16 )
                dht11_dat[j / 8] |= 1;
            j++;
        }
    }
 
    /*
     * check we read 40 bits (8bit x 5 ) + verify checksum in the last byte
     * print it out if data is good
     */
    /*if ( (j >= 40) &&
         (dht11_dat[4] == ( (dht11_dat[0] + dht11_dat[1] + dht11_dat[2] + dht11_dat[3]) & 0xFF) ) )
    {*/
        f = dht11_dat[2] * 9. / 5. + 32;
        printf( "Humidity = %d.%d %% Temperature = %d.%d *C (%.1f *F)\n",
            dht11_dat[0], dht11_dat[1], dht11_dat[2], dht11_dat[3], f );
    /*}else  {
        printf( "Data not good, skip\n" );
    }*/
}


int main()
    {
        while ( 1 )
    {
        read_dht11_dat();
    pauseSec( 1 ); /* wait 1sec to refresh */
    }
 
    return(0);
}

[Dennis Lee Bieber]

On Mon, 21 Mar 2016 22:17:44 -0700 (PDT), Sumit Bhut
<smb...@gmail.com> declaimed the following:

>
>*Code-#include <stdio.h>#include <stdlib.h>#include <string.h>#include

><time.h>#include <stdint.h>#include <sys/time.h>#include <unistd.h>#define

>MAXTIMINGS 85#define DHTPIN 48int dht11_dat[5] = { 0, 0, 0, 0, 0

>} return(0);}*

You really need to find a better posting agent... When reading the
message all your functions were on a diagonal (each line getting what
looked like an additional tab), but as you see above when quoted they came
over as if they had no new lines...

Let's see if cut&paste is any more legible...

-=-=-=-=-

-=-=-=-=-=-

Comment: These functions are essentially identical except for the "in"
or "out". In one you defined to pass the pin number -- but you never use
the pin number. Also, since you are doing a full open/close sequence on the
files, you probably do NOT need to do the fseek() -- opening a file for "w"
normally deletes all contents and writes from the beginning. fseek() might
be useful if you open the file at the start of the program with ("w+") and
never close it (but then you need to ensure that you overwrite all needed
characters -- writing
out
then coming back to write
in
would result in the file containing
int
as you didn't get rid of the longer string first. As I mentioned, opening
as "w" should wipe out the contents and put you at the beginning)

It is also disconcerting to see a file variable "in" being opened for
output... Hmmm, why %d in one spot and %i in the next?

I'd replace them with one function: (Untested!)

-=-=-=-=-=-
void setDirection(int pin, int dir)
{
FILE *fpin, *fpinDir;
char pinDir[50];

fpin = fopen("/sys/class/gpio/export", "w"):
fprintf(fpin, "%i", pin);
fflush(fpin);

sprintf(pinDir, "/sys/class/gpio/gpio/%i/direction", pin);

fpinDir = fopen(pinDir, "w");
fprintf(fpinDir, dir ? "in" : "out");
fflush(fpinDir);

fclose(fpinDir);
fclose(fpin);
}
-=-=-=-=-=-

Use it as:

/* To set pin for output */
setDirection(48, 0);

/* To set pin for input */
setDirection(48, 1);

Similar comment for your read function -- you pass in the pin number,
but never use it internally.


I've not checked the dht11 spec sheet, but this (blast -- whatever
format your text is in I can't seem to cut&paste a second block -- it seems
locked onto the stuff I copied above)... The loop where you "skip first 3"
looks like it also only takes every other transition (i%2) -- does the
DHT11 return to 0 between every data bit?

I'd have to study a bit (but first i need to go to work!) to make sense
of the data capture section. Those loops have me concerned.

--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

[Dennis Lee Bieber]

On Tue, 22 Mar 2016 08:47:59 -0400, Dennis Lee Bieber
<wlf...@ix.netcom.com> declaimed the following:

> I've not checked the dht11 spec sheet, but this (blast -- whatever
>format your text is in I can't seem to cut&paste a second block -- it seems
>locked onto the stuff I copied above)... The loop where you "skip first 3"
>looks like it also only takes every other transition (i%2) -- does the
>DHT11 return to 0 between every data bit?
>

Okay -- spent lunch with a data sheet.

Take-aways: Each bit is started with a low state, and then 0/1 is
determined by the length of the high state that follows. Given that, I'd
skip the modulo and "last state" stuff, and explicitly look for the
inter-bit "low", then look for the bit-data high.

In pseudo-code (based off of Python)

-=-=-=-=-
setDir(IN)
while not readPin():
usleep(5) #5usec busy wait if some device hasn’t
released bus

inData = [0, 0, 0, 0, 0] #initialize read data array

# signal read request
setDir(OUT)
writePin(LOW)
msleep(20) #msec (spec min 18msec)
writePin(HIGH)
usleep(20) #minimum of 20-40 usec to response
setDir(IN)
usleep(25) #spec 20+25 => 45, must be into device low state
now

# handle device response (the above sleep should put us in the LOW
while not readPin(): #low signal state, start of response
usleep(5) #busy loop, 13 cycles for worst case
(80usec)

while readPin(): #high signal, ignore until a low (start
first bit)
usleep(5) #busy loop, 13 cycles for worst case
(80usec)

for bit in range(40):
cnt = 0
while not readPin(): #inter-bit low
usleep(5) #busy loop, 10 cycles for 50usec

while readPin(): #high
cnt += 1
usleep(5) #should be enough to ensure
difference
#between 0/short and 1/long
#0/short is 5-6 cycles
#1/long is 14 cycles

#next stuff has to run fast as it occurs during the start of the
#inter-bit low of the next bit (needs to finish in <50usec,
preferably
#done in <25usec
#cnt > 10 splits difference between 25-30usec (26-28) 0 and 70usec
1

byte = bit / 8
if cnt > 10: #data bit is 1
inData[byte] = inData[byte] << 1 + 1
else: #data bit is 0
inData[byte] = inData[byte] << 1 + 0

if (inData[0] + inData[1] + inData[2] + inData[3]) % 256 == inData[4]:
#good data
else:
#bad read, checksum did not match
-=-=-=-=-

Or find an Arduino DHT11 library and port it into BB C (the one I
looked at included TimeOut error conditioning if the bus doesn't change)

[Sumit Bhut]

Hi, Dennis Lee Bieber

Thanks for the valuable effort but i am unaware of the python language and hence it would be really appreciable if you could provide me your help in C/C++ language only.

[Dennis Lee Bieber]

On Thu, 31 Mar 2016 00:16:28 -0700 (PDT), Sumit Bhut
<smb...@gmail.com> declaimed the following:

>Hi, Dennis Lee Bieber
>
>Thanks for the valuable effort but i am unaware of the python language and
>hence it would be really appreciable if you could provide me your help in
>C/C++ language only.
>

The best I could provide then (since I've not learned the build tool
chain on the BBB, and don't know if I even have a DHT11 in my box of
assorted cheap sensors) is to point you to a working implementation for the
Arduino.

http://playground.arduino.cc/Main/DHTLib IS C++, and includes timeout
errors if it doesn't get a response

Obviously you'd have to replace all the I/O (digitalWrite(),
digitalRead() [though the latest library looks to be doing direct I/O port
reads and masking to get the pin], and delay() stuff) with BBB equivalent
functions.

The main function is at the bottom of the page: _readSensor()

And, as I suggested in the "Python" pseudo-code, there is no fiddly
game using a modulo function to follow changes in the pin state. You know
the protocol always uses a LOW state to start any stage (wake-up, response,
start of bit) followed by some duration of HIGH state (pretty much
irrelevant for the wake-up/response; only the 0/1 duration is significant).
Therefore, reading the sensor should explicitly look for LOW and HIGH
conditions. Your modulo doesn't know which state it is in -- if you started
testing when the sensor had the line in the wrong state, you could be
counting the length of the start of bit LOW, rather than the bit HIGH
period.

[Dennis Lee Bieber]

This is a follow up to my prior response...

On Thu, 31 Mar 2016 00:16:28 -0700 (PDT), Sumit Bhut
<smb...@gmail.com> declaimed the following:

>Hi, Dennis Lee Bieber
>
>Thanks for the valuable effort but i am unaware of the python language and
>hence it would be really appreciable if you could provide me your help in
>C/C++ language only.

Python may not have been fast enough for the toggling -- combined with
the fact that time.clock() seemed to have a granularity of 0.01 seconds (or
10 milliseconds) which would make it difficult to tell how long the time
was between transitions.

I attempted to generate something in C++ which took hours. For some
reason I can't seem to find a GPIO pin that was actually toggling when
under an oscilloscope. Even when manually setting the pin value using the
echo 1 > /sys/class/gpio/gpio#/value
from a command line. I could read back the 1 (or 0) value, but never found
a level change on the 'scope -- the pin was either tied high, or tied to
ground.

My last version is showing some activity, but is still failing, as
shown (I'm wondering if usleep() has some obscenely large granularity on
the BBB, because it took 53 seconds to go from "beginning measurement" to
the first timeout error on the first byte, sixth bit):

debian@beaglebone:~$ sudo ./DHT11
Beginning measurement pass

Timeout counting bit length 0 5

***** Error while reading sensor

Beginning measurement pass

Timeout counting bit length 0 6

***** Error while reading sensor

Beginning measurement pass

Timeout counting bit length 0 5

***** Error while reading sensor

Beginning measurement pass

Even worst case (all 1 bits) the entire data read (40 bits @ 120 uSec
each) is less than 5 msec, and the 20 msec wake up brings the total to
around <30 msec... So where did the other 53000 msec delay come from?

debian@beaglebone:~$ date && sudo ./DHT11
Sat Apr 2 21:25:45 EDT 2016
Beginning measurement pass

Timeout counting bit length 0 3

***** Error while reading sensor

Beginning measurement pass

Timeout counting bit length 0 4

***** Error while reading sensor

Beginning measurement pass
^Cdebian@beaglebone:~$ date
Sat Apr 2 21:27:37 EDT 2016
debian@beaglebone:~$


Based upon where it is timing out, the code must be seeing some
toggling of the signal coming in, or it is reading atmospheric noise; as it
gets past the bus available, wake up response, and a couple of data bits --
all actions that require seeing a LOW then HIGH sequence.

Maybe next weekend I'll have time to convert the deprecated usleep()
into current POSIX nano_sleep(). In the meantime, my code follows. Compile
with

g++ -o DHT11 DHT11.cpp -std=c++0x

-=-=-=-=-=-
/*
* DHT11.cpp Simple Humidity and Temperature Sensor
* April 2, 2016 Dennis L Bieber
*
* This file defines (and uses) a class to read DHT11 sensors
* on the BeagleBone Black
*
* Minimal error checking is performed, timeout testing is done
* using cpu-hog polling loops
*
* As I've not done C++ in 15 years, there will be some construct
* that may not be "proper"
*
*/

#include <iostream>
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <ctime>
#include <unistd.h>

using namespace std;

enum /*class*/ Direction { OUT, IN };
enum /*class*/ PinState { LOW, HIGH };

struct TimeOutError {};
struct CheckSumError {};
struct DHTError {};

class DHT11
{
int pinNum;
long timeOutuSec;
char pinDirPath[200];
char pinDataPath[200];
public:
DHT11(int pin, int timeOut);
~DHT11();
void readDegC(float &humidity, float &temperature);
void readDegF(float &humidity, float &temperature);
private:
void read(float &humidity, float &temperature);
void setDir(Direction dir);
void writePin(PinState value);
PinState readPin();
};

DHT11::DHT11(int pin, int timeOut)
{
FILE *exportCtl;

// save pin number and timeout values
// (though pin number may only be used here)
pinNum = pin;
timeOutuSec = timeOut * 1000; // msec -> microsec

// export the pin for later access
exportCtl = fopen("/sys/class/gpio/export", "w");
fprintf(exportCtl, "%d", pinNum);
fclose(exportCtl);

// set up the pinData and pinDirCtl paths
sprintf(pinDataPath, "/sys/class/gpio/gpio%d/value", pinNum);
sprintf(pinDirPath, "/sys/class/gpio/gpio%d/direction", pinNum);
}

DHT11::~DHT11()
{
FILE *exportCtl;

// unexport the pin for cleanup
exportCtl = fopen("/sys/class/gpio/unexport", "w");
fprintf(exportCtl, "%d", pinNum);
fclose(exportCtl);
}

void DHT11::setDir(Direction dir)
{
FILE *pinDirCtl;

pinDirCtl = fopen(pinDirPath, "w");
fprintf(pinDirCtl, (IN == dir) ? "in" : "out");
fclose(pinDirCtl);
}

void DHT11::writePin(PinState value)
{
FILE *pinData;

pinData = fopen(pinDataPath, "w");
fprintf(pinData, "%d", (HIGH == value) ? 1 : 0);
fclose(pinData);
}

PinState DHT11::readPin()
{
int pinValue;
FILE *pinData;

pinData = fopen(pinDataPath, "r");
fscanf(pinData, "%d", &pinValue);
fclose(pinData);

return (1 == pinValue) ? HIGH : LOW;
}

void DHT11::read(float &humidity, float &temperature)
{
char data[5] = {0, 0, 0, 0, 0};
int toCnt;

cout << "Beginning measurement pass" << endl;

// ensure bus is high (no device is pulling it down)
setDir(IN);
toCnt = 0;
try
{
while (LOW == readPin())
{
toCnt++;
if (toCnt > timeOutuSec)
throw TimeOutError {};
usleep(1);
}
}
catch (TimeOutError)
{
cout << endl << "Timeout waiting for bus available" << endl;
throw DHTError {};
}

// send wake up signal; spec gives minimum of 18msec
setDir(OUT);
writePin(LOW);
usleep(20 * 1000); // deprecated, should use nano_sleep
writePin(HIGH);
setDir(IN);

// wait for response start
toCnt = 0;
try
{
while (HIGH == readPin())
{
toCnt++;
if (toCnt > timeOutuSec)
throw TimeOutError {};
usleep(1);
}
}
catch (TimeOutError)
{
cout << endl << "Timeout waiting for response start" << endl;
throw DHTError {};
}

// wait for response indicator end
toCnt = 0;
try
{
while (LOW == readPin())
{
toCnt++;
if (toCnt > timeOutuSec)
throw TimeOutError {};
usleep(1);
}
}
catch (TimeOutError)
{
cout << endl << "Timeout waiting for response indicator end" <<
endl;
throw DHTError {};
}

// wait for first data bit start
toCnt = 0;
try
{
while (HIGH == readPin())
{
toCnt++;
if (toCnt > timeOutuSec)
throw TimeOutError {};
usleep(1);
}
}
catch (TimeOutError)
{
cout << endl << "Timeout waiting for first bit start" << endl;
throw DHTError {};
}

// loop over 5 data bytes
for (int i = 0; i < 5; i++)
{
// loop over 8 bits per byte
for (int b = 0; b < 8; b++)
{
// wait for actual bit start
toCnt = 0;
try
{
while (LOW == readPin())
{
toCnt++;
if (toCnt > timeOutuSec)
throw TimeOutError {};
usleep(1);
}
}
catch (TimeOutError)
{
cout << endl << "Timeout waiting for actual data bit " << i
<< " " << b << endl;
throw DHTError {};
}

// accumulate microseconds for duration of bit
// until start of next bit signal
toCnt = 0;
try
{
while (HIGH == readPin())
{
toCnt++;
if (toCnt > timeOutuSec)
throw TimeOutError {};
usleep(1);
}
}
catch (TimeOutError)
{
cout << endl << "Timeout counting bit length " << i << " "
<< b << endl;
throw DHTError {};
}

// determine short or long (0 or 1)
if (toCnt > 45)
data[i] = (data[i] << 1) + 1;
else
data[i] = (data[i] << 1) + 0;

}
}

// checksum computation
if ((data[0] + data[1] + data[2] + data[3]) % 256 != data[4])
throw CheckSumError {};

humidity = (float) data[0] + ((float) data[1] / 10.0);
temperature = (float) data[2] + ((float) data[3] / 10.0);
}

void DHT11::readDegC(float &humidity, float &temperature)
{
// reports are that one should read twice as the first
// read contains stale data
read(humidity, temperature);
read(humidity, temperature);
}

void DHT11::readDegF(float &humidity, float &temperature)
{
readDegC(humidity, temperature);
// convert degC to degF
temperature = (temperature * 9.0) / 5.0 + 32.0;
}

int main(int argc, char *argv[])
{
DHT11 mySensor = DHT11{48, 200}; // P9_15, 200mSec time-out

float humidity;
float temperature;

try
{
while (1)
{
try
{
mySensor.readDegF(humidity, temperature);
cout << "Humidity: " << humidity << "%\t"
<< "Temperature: " << temperature << " degF" << endl;
sleep(5);
}
catch (CheckSumError)
{
cout << endl << "***** Checksum mismatch" << endl << endl;
}
catch (DHTError)
{
cout << endl << "***** Error while reading sensor" << endl
<< endl;
}
}
}
catch (...)
{
// Any exception should take this route
cout << endl << "***** Something failed, I won't tell you what" <<
endl << endl;
}

return (0);
}
-=-=-=-=-=-

[Dennis Lee Bieber]

o/~ I'm Talking to Myself in Public o/~

On Sat, 02 Apr 2016 21:37:26 -0400, Dennis Lee Bieber
<wlf...@ix.netcom.com> declaimed the following:

> I attempted to generate something in C++ which took hours. For some
>reason I can't seem to find a GPIO pin that was actually toggling when
>under an oscilloscope. Even when manually setting the pin value using the
> echo 1 > /sys/class/gpio/gpio#/value
>from a command line. I could read back the 1 (or 0) value, but never found
>a level change on the 'scope -- the pin was either tied high, or tied to
>ground.
>
> My last version is showing some activity, but is still failing, as
>shown (I'm wondering if usleep() has some obscenely large granularity on
>the BBB, because it took 53 seconds to go from "beginning measurement" to
>the first timeout error on the first byte, sixth bit):
>

Actually, I suspect it's the overhead of all the I/O calls needed to
access GPIOs via a pseudo file system.

After all, to detect a 0 bit, requires being able to do three at least
six I/O function calls in 27usec (the HIGH period of the bit --
open/read/close to detect the transition to HIGH, and open/read/close to
detect the end transition back to LOW -- and preferably multiple cycles to
get some idea of the length)

Might need to try the mmap route... Hopefully won't need the PRU.

[John Syne]

Why not write this with a Kernel Module:

http://derekmolloy.ie/kernel-gpio-programming-buttons-and-leds/

This is much faster and will do what you want.

Regards,
John

> --
> 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/d/optout.

[Dennis Lee Bieber]

On Sat, 2 Apr 2016 21:35:18 -0700, John Syne
<john...@gmail.com> declaimed the following:

>Why not write this with a Kernel Module:
>
>http://derekmolloy.ie/kernel-gpio-programming-buttons-and-leds/
>
>This is much faster and will do what you want.
>

Well, actually -- I'm only doing it as an exercise in response to some
(IMO, atrocious) code from the OP. One reason it took most of the day is I
hadn't done any C++ in 15 years so had to flip pages in Stroustrup to even
find the syntax for classes... (I was also using M$ VS 2010 as the editor
and it objects to some features not implemented by M$; sftp to get the
source over for compilation).

I'm not a Linux programmer -- especially not when it comes to the guts
of the OS... The whole "everything is a file" grates on me. Device Tree
Overlays? I used to think setting up pins on a TIVA was onerous.

Hmmm, and part one of that article doesn't give me much hope -- if he's
reporting 15-25 microsecond response time (part 1: 20usec +/- 5), and we're
looking at a device that uses a 26-28usec high state to indicate a 0-bit
(the 1 bit is an 80usec high state.

{PS: I also abhor web sites with floating frames that obscure things when
printed, and no explicit print icon -- as the frame appears on every page
of the print-out overlaying the content}

[John Syne]

In that case, then you have no choice; PRU is your only solution on the BBB.

Regards,
John

[Dennis Lee Bieber]

On Sun, 3 Apr 2016 08:43:10 -0700, John Syne
<john...@gmail.com> declaimed the following:

>In that case, then you have no choice; PRU is your only solution on the BBB.
>

Which I'll have to leave to the OP -- I'm more likely to dig up an
Arduino with DHT library to confirm my DHT11 is working (it was one of some
37 or so little boards with headers for breadboarding -
http://www.amazon.com/SunFounder-modules-Arduino-Mega2560-controller/dp/B00CBDUD60
[though that has been updated, keypad and color manual it looks like, I
just had the sensors and poorly translated guide book] before trying to
figure out the build environment for the PRUs [After the Arduino I may try
the TIVA -- time I do something more than half the TI-RTOS training guide])

[William Hermans]

I'd probably go for something like an NXP LPC1114 if interfacing an external MCU to do offload / offboard type stuff. The reasoning is pretty simple. These MCU's IIRC only need a resistor, and a capacitor to get up and running. Based on other preferences, I'd actually prefer something like an MSP430G2552* because they're easy to use, and I'm fairly familiar with them already. the NXP MCU's I've actually not touched yet, but have done a lot of reading on them( in the past ).

[William Hermans]

Oh, and the other reason why the LPC1114's are "good" for makers. They come in a DIP28 package . . .

[Dennis Lee Bieber]

On Sun, 3 Apr 2016 10:58:43 -0700, William Hermans
<yyr...@gmail.com> declaimed the following:

>I'd probably go for something like an NXP LPC1114 if interfacing an
>external MCU to do offload / offboard type stuff. The reasoning is pretty
>simple. These MCU's IIRC only need a resistor, and a capacitor to get up
>and running. Based on other preferences, I'd actually prefer something like
>an MSP430G2552* because they're easy to use, and I'm fairly familiar with
>them already. the NXP MCU's I've actually not touched yet, but have done a
>lot of reading on them( in the past ).
>

Remember -- I was only doing this as a learning experiment in the
attempt to help the OP (who has posted the same illegible message two or
three times, only acknowledging one of my responses... I suspect they may
also have problems with accessing the forum)

If I really needed to use a full-up BBB with a DHT11 I'd have to figure
out the PRUs first; if they didn't support it I'd probably try a small
(relatively speaking) PIC chip using one GPIO to the DHT11 and likely
create some simple serial port/UART command protocol to get to the BBB.
However, TIVAs are rather cheap (TI should really push them as a "Maker"
product rather than "evaluation boards"). Ethernet capable for ~$20/$25
[latter has the hardware crypto], and the smaller one for ~$13.

[William Hermans]

I know all about the TivaC boards. Which actually used LM4F120* processors prior, and I believe now use the TM4C processors. They are not however cheap. I think I got my "connected" crypto board for $12 on sale a while back.

But wait a minute is the dht-11 UART ? I was thinking it was one wire( which linux has a generic one wire driver ). Any way, no idea what the problem could be, it should be dead simple easy to write an application to use these if UART. And I'm not going to write someone's term paper for them . . .

[Sumit Bhut]

I tried it with my nanosleep() code as follow:

  void pauseNanoSec(long nano)

 {

struct timespec tmr1;

tmr1.tv_sec = 0;

tmr1.tv_nsec = nano;

 }

Here I guess we only need the low and high pulses while you have taken three pulses as high, low and high which I didn't get. 

on what basis did you took this value 44 here? 

 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

[Dennis Lee Bieber]

On Sun, 3 Apr 2016 19:23:11 -0700, William Hermans
<yyr...@gmail.com> declaimed the following:

>But wait a minute is the dht-11 UART ? I was thinking it was one wire(
>which linux has a generic one wire driver ). Any way, no idea what the
>problem could be, it should be dead simple easy to write an application to
>use these if UART. And I'm not going to write someone's term paper for them
>. . .
>

No -- the DHT11 is a one-wire using varying-duration "high" to indicate
difference between 0 and 1.

I only mentioned the UART as something rather ridiculous:

BBB <uart> TIVA(Arduino/PIC) <1-wire> DHT11

Essentially using the external microcontroller board (or just chip for the
PIC) in place of figuring out the PRU instruction set and communication
modes <G>

But I think my side of the effort is really done -- I'd just do the
other board to verify my DHT11 is functional. The trick now will be to get
the OP to realize what I seem to have confirmed... Native BBB has too much
overhead to read the DHT11.

[Dennis Lee Bieber]

On Mon, 4 Apr 2016 03:40:22 -0700 (PDT), Sumit Bhut
<smb...@gmail.com> 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.

[Sumit Bhut]

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.