Heater
Posts: 13357
Joined: Tue Jul 17, 2012 3:02 pm

Re: ScriptBasic

Fri May 31, 2019 5:23 pm

RichardRussell,
In the 'real world' of digital communication (over the airwaves, or copper wire or fibre etc.) errors and corrupted data are a fact of life.
Yep. Been there, done that, many times. From simple serial links to distributed, fault tolerant, control systems. In the "real world" of digital systems they are all analog!
One rarely experiences the luxury of guaranteed perfect data, every time, outside of the realm of a self-contained computer,...
Ah, there is a point. Looks like I'm thinking about the DHT11 sensor in the wrong light.

I would generally expect a SPI or I2C device, or a peripheral chip like a RAM connected to a processor to communicate flawlessly so much that one does not worry about the failure rate.

Apparently the DHT11 is not to be treated as such.

The odd thing about this case is that the unreliability seems to be caused by the receiving end of the system, even if the DHT11 is working well and the communication link is noise free. All down to the non-deterministic timing of application code in the OS.

Where then should one do all this error checking and retrying?

Potentially if it's done at a low level, in C under BASIC say, then the read function may never return. Or at least the time taken to get a correct result is unbounded!

That is scary in itself.
Memory in C++ is a leaky abstraction .

User avatar
John_Spikowski
Posts: 1392
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: ScriptBasic

Fri May 31, 2019 5:32 pm

I was able to get the C version of the DHT11 example working that uses the wiringPi library. I stumbled on a thread on this forum about someone with the same issue with the Python version working and the C version not. Seems there was an error in the code. See commented out line going from 16 to 50.

I wonder if I'm wasting my time using the Phython C code and use Gordon's wiringPi library?

I took a peek at the WiringPi API and it looks a lot easier to use than the rpi.gpio library I'm using. It shouldn't take too long to create a WPI extension module.

Code: Select all

/*
 *  dht11.c:
 *  Simple test program to test the wiringPi functions
 *  DHT11 test
 */

#include <wiringPi.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#define MAXTIMINGS  85
#define DHTPIN    7
int dht11_dat[5] = { 0, 0, 0, 0, 0 };

void read_dht11_dat()
{
  uint8_t laststate = HIGH;
  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 */
  pinMode( DHTPIN, OUTPUT );
  digitalWrite( DHTPIN, LOW );
  delay( 18 );
  /* then pull it up for 40 microseconds */
  digitalWrite( DHTPIN, HIGH );
  delayMicroseconds( 40 );
  /* prepare to read the pin */
  pinMode( DHTPIN, INPUT );

  /* detect change and read data */
  for ( i = 0; i < MAXTIMINGS; i++ )
  {
    counter = 0;
    while ( digitalRead( DHTPIN ) == laststate )
    {
      counter++;
      delayMicroseconds( 1 );
      if ( counter == 255 )
      {
        break;
      }
    }
    laststate = digitalRead( DHTPIN );

    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 )    OLD LINE  */
      if ( counter > 50 )
        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( void )
{
  printf( "Raspberry Pi wiringPi DHT11 Temperature test program\n" );

  if ( wiringPiSetup() == -1 )
    exit( 1 );

  while ( 1 )
  {
    read_dht11_dat();
    delay( 1000 ); /* wait 1sec to refresh */
  }

  return(0);
}


[email protected]:~/sensors $ ./dht11-test
Raspberry Pi wiringPi DHT11 Temperature test program
Data not good, skip
Data not good, skip
Humidity = 61.0 % Temperature = 21.1 *C (69.8 *F)
Data not good, skip
Humidity = 61.0 % Temperature = 21.1 *C (69.8 *F)
Data not good, skip
Data not good, skip
Data not good, skip
Humidity = 61.0 % Temperature = 21.1 *C (69.8 *F)
Data not good, skip
Humidity = 61.0 % Temperature = 21.1 *C (69.8 *F)
Data not good, skip
Humidity = 61.0 % Temperature = 21.1 *C (69.8 *F)
Data not good, skip
Humidity = 61.0 % Temperature = 21.2 *C (69.8 *F)
Data not good, skip
Data not good, skip
Data not good, skip
Humidity = 61.0 % Temperature = 21.1 *C (69.8 *F)
Data not good, skip

hippy
Posts: 5964
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: ScriptBasic

Fri May 31, 2019 6:45 pm

Heater wrote:
Fri May 31, 2019 3:08 pm
Personally I think having to use the Video Core to do this simple GPIO thing sounds kind of nuts.
It may be nuts, but that's what comes from using a SoC and an OS which isn't easily capable of directly handling peripherals which require determinism. And that's what we we have.

Using the VC4 as a deterministic core seems an easy way round the problem, assuming it does work. There's a spare VPU core available, it's usually not otherwise being used, so one might as well put it to some good use.

It shouldn't be any harder than using a deterministic core if one were provided. Except it's not officially documented and there's no official support for using it.
RichardRussell wrote:
Fri May 31, 2019 3:44 pm
My advice, for what it's worth, is to ignore the existing Python (and C etc.) code and start from scratch coding the required functionality in ScriptBASIC.
I agree. Those libraries are best used for gaining and clarifying understanding, providing guidance and verifying one's own code against.

Which leads me to ...
ScriptBasic wrote:
Fri May 31, 2019 2:24 pm
It would be helpful if you could compare my SB code with the Python code I'm trying to emulate and tell me if I missed a step. The C code is the rpi.gpio library you pointed me to.
I don't have any great knowledge of the RPi.GPIO code. I used it ( and other libraries ) as above, got the gist of what was going on alongside my understanding of the ARM peripheral PDF, then set about coding the routines how I felt they should be.

RPi.GPIO is probably the most used library and has all the low-level stuff in it, and it's documented. It therefore makes a good starting point for anyone wanting to implement similar; hence why I recommended that. But there are things about it which I personally don't like; particularly function naming. But there's nothing wrong with it, beyond not being how I'd do it.

However, if you just take the low-level C code, put that in a ScriptBasic wrapper, it should just work, 'as is'.

User avatar
RichardRussell
Posts: 579
Joined: Thu Jun 21, 2012 10:48 am

Re: ScriptBasic

Fri May 31, 2019 6:50 pm

Heater wrote:
Fri May 31, 2019 5:23 pm
Potentially if it's done at a low level, in C under BASIC say, then the read function may never return. Or at least the time taken to get a correct result is unbounded!
My intention is for the read function (coded entirely in BBC BASIC - I see no need for C or any other 'helper' language) to return either with valid humidity and temperature data or an error code indicating that the read wasn't successful. Then it's up to the 'calling program' whether to retry or to do some other work first. This is no different in principle from a low-level 'sector read' function in a disk driver: typically there will be a limit on the number of retries to avoid 'unbounded' delays.

User avatar
John_Spikowski
Posts: 1392
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: ScriptBasic

Fri May 31, 2019 6:55 pm

Just changing the retry delay from 1 to 1.5 seconds improved responses.

Code: Select all

[email protected]:~/sensors $ ./dht11-test
Raspberry Pi wiringPi DHT11 Temperature test program
Data not good, skip
Humidity = 61.0 % Temperature = 21.1 *C (69.8 *F)
Humidity = 61.0 % Temperature = 21.1 *C (69.8 *F)
Data not good, skip
Humidity = 61.0 % Temperature = 21.1 *C (69.8 *F)
Humidity = 61.0 % Temperature = 21.1 *C (69.8 *F)
Humidity = 61.0 % Temperature = 21.2 *C (69.8 *F)
Humidity = 61.0 % Temperature = 21.2 *C (69.8 *F)
Humidity = 61.0 % Temperature = 21.2 *C (69.8 *F)
Humidity = 61.0 % Temperature = 21.2 *C (69.8 *F)
Data not good, skip
Data not good, skip
Humidity = 61.0 % Temperature = 21.3 *C (69.8 *F)
Humidity = 61.0 % Temperature = 21.3 *C (69.8 *F)
Humidity = 61.0 % Temperature = 21.2 *C (69.8 *F)
Data not good, skip
I'm really glad Python is no longer my point of reference. The little time I did spend with Python reasured my reasoning not to use it was justified.
Last edited by John_Spikowski on Sat Jun 01, 2019 12:26 am, edited 1 time in total.

hippy
Posts: 5964
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: ScriptBasic

Fri May 31, 2019 7:01 pm

Heater wrote:
Fri May 31, 2019 5:23 pm
Where then should one do all this error checking and retrying?

Potentially if it's done at a low level, in C under BASIC say, then the read function may never return. Or at least the time taken to get a correct result is unbounded!
I would attempt a number of retries at the low level on the grounds that, if one stall screwed things, things will hopefully work if done quickly enough before another stall comes along. And then bail out with a negative humidity if not, leave the user code to decide what to do.
RichardRussell wrote:
Fri May 31, 2019 6:50 pm
My intention is for the read function (coded entirely in BBC BASIC - I see no need for C or any other 'helper' language) to return either with valid humidity and temperature data or an error code indicating that the read wasn't successful. Then it's up to the 'calling program' whether to retry or to do some other work first. This is no different in principle from a low-level 'sector read' function in a disk driver: typically there will be a limit on the number of retries to avoid 'unbounded' delays.
The problem with returning a fail immediately to the higher code is that the higher code doesn't get that 'try again immediately option', every time it calls it may get another stall which screws things, never gets a valid result unless it gets lucky.

A number of retries, and/or a timeout, in the lowest level code would give the best chance of success IMO.

It has to be accepted that the Pi isn't intended nor designed to work with all possible peripherals, and there will be some which don't or won't work with pi-based bit-banging, need an external peripheral interface adding to use them, or a lot of hoop-jumping to make them usable.

Heater
Posts: 13357
Joined: Tue Jul 17, 2012 3:02 pm

Re: ScriptBasic

Fri May 31, 2019 7:07 pm

@hippy,
It may be nuts, but that's what comes from using a SoC and an OS which isn't easily capable of directly handling peripherals which require determinism. And that's what we we have.

Using the VC4 as a deterministic core seems an easy way round the problem, assuming it does work.
OK. It's nuts but one has to appreciate a good hack that gets the job done. Harken's back to the Demo Scene days of getting C64's and such to do things that were not really intended or documented.

@RichardRussell,
My intention is for the read function ... to return either with valid humidity and temperature data or an error code indicating that the read wasn't successful. Then it's up to the 'calling program' whether to retry or to do some other work first.
I like it.
Memory in C++ is a leaky abstraction .

User avatar
RichardRussell
Posts: 579
Joined: Thu Jun 21, 2012 10:48 am

Re: ScriptBasic

Fri May 31, 2019 8:44 pm

hippy wrote:
Fri May 31, 2019 7:01 pm
The problem with returning a fail immediately to the higher code is that the higher code doesn't get that 'try again immediately option'
But you can't "try again immediately" since, as I understand it, the DHT11 can be polled only about once per second. So an 'immediate retry' would imply blocking for something like that period of time, which I doubt would be acceptable in many applications.

User avatar
John_Spikowski
Posts: 1392
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: ScriptBasic

Fri May 31, 2019 8:51 pm

My approach is to return the first valid result and let the user determine the frequency they need to call the function. I'm going to keep anything timing critical at the C level in the extension module.

I may design this WiringPi extension module to call the API and make high level calls to device functions which does the WiringPi stuff under the covers. For example the DHT11 function might look like ...

WPI::DHT11(pin, temperature, humidity)

The temperature and humidity arguments would contain the DHT11's returned values for the call.

hippy
Posts: 5964
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: ScriptBasic

Sat Jun 01, 2019 12:12 am

RichardRussell wrote:
Fri May 31, 2019 8:44 pm
hippy wrote:
Fri May 31, 2019 7:01 pm
The problem with returning a fail immediately to the higher code is that the higher code doesn't get that 'try again immediately option'
But you can't "try again immediately" since, as I understand it, the DHT11 can be polled only about once per second.
I couldn't see any limit on read rates in the datasheet I have.

There is a required one second wait after initial power-up and "Each read out the temperature and humidity values are the results of the last measurement For real-time data, sequential read twice, but is not recommended to repeatedly read the sensors, each read sensor interval is greater than 5 seconds can be obtained accurate data".

That suggests it's not worth reading more than once every 5 seconds, but does to me suggest the sensor can be read again immediately to get a reading if the first was corrupted.

The proof of the pudding would be in trying it, but I don't have a DHT11 myself.

User avatar
RichardRussell
Posts: 579
Joined: Thu Jun 21, 2012 10:48 am

Re: ScriptBasic

Sat Jun 01, 2019 2:03 am

hippy wrote:
Sat Jun 01, 2019 12:12 am
I couldn't see any limit on read rates in the datasheet I have.
It states here that for the DHT11 "No more than 1 Hz sampling rate (once every second)" and for the DHT22 "No more than 0.5 Hz sampling rate (once every 2 seconds)".

User avatar
John_Spikowski
Posts: 1392
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: ScriptBasic

Sat Jun 01, 2019 3:46 am

The WPI extension module works.

Code: Select all

DECLARE SUB DHT11 ALIAS "DHT11" LIB "wpi"

DHT11(7, humidity, temperature)

PRINT "Humidity: ",humidity, " %\n"
PRINT "Temperature: ",temperature, " C\n"
Output

Code: Select all

[email protected]:~/sbrpi/examples $ scriba testwpi.sb
Humidity: 58 %
Temperature: 23 C
[email protected]:~/sbrpi/examples $ 
WPI Extension Module

Code: Select all

/*
WiringPi Extension Module
UXLIBS: -lc -lwiringPi
*/


#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include "../../basext.h"
#include <wiringPi.h>

#define MAXTIMINGS  85

/**************************
 Extension Module Functions
**************************/

typedef struct _ModuleObject {
  void *HandleArray;
}ModuleObject,*pModuleObject;


besVERSION_NEGOTIATE
  return (int)INTERFACE_VERSION;
besEND


besSUB_START
  pModuleObject p;

  besMODULEPOINTER = besALLOC(sizeof(ModuleObject));
  if( besMODULEPOINTER == NULL )return 0;

  p = (pModuleObject)besMODULEPOINTER;
  return 0;
besEND


besSUB_FINISH
  pModuleObject p;

  p = (pModuleObject)besMODULEPOINTER;
  if( p == NULL )return 0;
  return 0;
besEND


/****************
 Device Functions
****************/

besFUNCTION(DHT11)
  int pin;
  VARIABLE Argument1;

  besARGUMENTS("i")
    &pin
  besARGEND


  VARIABLE Argument2;
  VARIABLE Argument3;
  unsigned long __refcount_;
  LEFTVALUE Lval2;
  LEFTVALUE Lval3;

  Argument2 = besARGUMENT(2);
  besLEFTVALUE(Argument2,Lval2);
  besRELEASE(*Lval2);
  *Lval2 = NULL;

  Argument3 = besARGUMENT(3);
  besLEFTVALUE(Argument3,Lval3);
  besRELEASE(*Lval3);
  *Lval3 = NULL;

  *Lval2 = besNEWLONG;
  *Lval3 = besNEWLONG;

  wiringPiSetup();

  int valid = 0;

while(valid == 0)
 {
  int dht11_dat[5] = { 0, 0, 0, 0, 0 };
  uint8_t laststate = HIGH;
  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 */
  pinMode( pin, OUTPUT );
  digitalWrite( pin, LOW );
  delay( 18 );
  /* then pull it up for 40 microseconds */
  digitalWrite( pin, HIGH );
  delayMicroseconds( 40 );
  /* prepare to read the pin */
  pinMode( pin, INPUT );

  /* detect change and read data */
  for ( i = 0; i < MAXTIMINGS; i++ )
  {
    counter = 0;
    while ( digitalRead( pin ) == laststate )
    {
      counter++;
      delayMicroseconds( 1 );
      if ( counter == 255 )
      {
        break;
      }
    }
    laststate = digitalRead( pin );

    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 > 50 )
        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;
    LONGVALUE(*Lval2) = dht11_dat[0];
    LONGVALUE(*Lval3) = dht11_dat[2];
    valid = 1;
  }
  delay( 1500 );
 }
  besRETURNVALUE = NULL;
besEND
This is calling the DHT11 function 10 times in a FOR/NEXT loop.

Code: Select all

[email protected]:~/sbrpi/examples $ time scriba testwpi.sb
Humidity: 56 %
Temperature: 23 C
Humidity: 56 %
Temperature: 23 C
Humidity: 56 %
Temperature: 23 C
Humidity: 56 %
Temperature: 23 C
Humidity: 56 %
Temperature: 23 C
Humidity: 56 %
Temperature: 23 C
Humidity: 56 %
Temperature: 23 C
Humidity: 56 %
Temperature: 23 C
Humidity: 56 %
Temperature: 23 C
Humidity: 56 %
Temperature: 23 C

real	0m24.375s
user	0m0.083s
sys	0m0.001s
[email protected]:~/sbrpi/examples $ 
Last edited by John_Spikowski on Sat Jun 01, 2019 7:17 am, edited 4 times in total.

Heater
Posts: 13357
Joined: Tue Jul 17, 2012 3:02 pm

Re: ScriptBasic

Sat Jun 01, 2019 5:04 am

ScriptBasic,
I've demonstrated a one function fibo and a one function DHT11. This is really what ScriptBasic is about.
You might have to elaborate on that statement a bit. I don't get it.

What's different about "one function" in ScriptBasic compared to doing the same in any other language that supports functions?
Memory in C++ is a leaky abstraction .

User avatar
John_Spikowski
Posts: 1392
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: ScriptBasic

Sat Jun 01, 2019 5:15 am

What language do you prefer creating seamless C extensions in?

I would like to see a Python DHT11 function and the interface code required.

User avatar
RichardRussell
Posts: 579
Joined: Thu Jun 21, 2012 10:48 am

Re: ScriptBasic

Sat Jun 01, 2019 12:44 pm

For anybody who, like me, is writing their own DHT11 interface here are a couple of things to be aware of:

1. Seemingly some DHT11s are in fact DHT12s (possibly ones that have failed factory calibration). Although their accuracy may not be up to spec, it would be a shame to throw away the extra resolution (0.1° rather than 1°) which some - but not all - of the Python implementations I've seen do.

2. The Raspberry Pi dynamically switches the CPU clock between 600 MHz and 1200 MHz depending on demand! If your code relies on execution speed as its source of timing, you may well need to take this into account.

User avatar
John_Spikowski
Posts: 1392
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: ScriptBasic

Sat Jun 01, 2019 3:09 pm

Richard,

Did your DHT11 arrive yet?

Heater
Posts: 13357
Joined: Tue Jul 17, 2012 3:02 pm

Re: ScriptBasic

Sat Jun 01, 2019 3:39 pm

ScriptBasic,
What language do you prefer creating seamless C extensions in?
OK, now I'm with you now.

I'm not sure I have a preference. Calling language A from language B is not something I get a kick out of.

It all depends on the implementations of course. It goes pretty easily from Free Pascal to C, or Lua, or some Javascript engines.

I'm told it is truly "seamless" to mix and match languages under MS .Net but that is not something I ever want to have to do.
Memory in C++ is a leaky abstraction .

User avatar
John_Spikowski
Posts: 1392
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: ScriptBasic

Sat Jun 01, 2019 4:20 pm

Heater wrote: I'm not sure I have a preference. Calling language A from language B is not something I get a kick out of.
Avoiding C as a method to extend a scripting language seems counter productive. Most common libraries are written in C and the basis of the scripting language design. I'm unaware of any language that uses no external libraries. (other than C)

Heater
Posts: 13357
Joined: Tue Jul 17, 2012 3:02 pm

Re: ScriptBasic

Sat Jun 01, 2019 4:32 pm

Avoiding unnecessary work is not counter productive.

As you might have guessed from my response I have added C widgets to all kind of languages when need be.

Funny you should mention it, have been called on to create an interface to a protocol driver in C from Free Pascal just last week.

On my home turf I generally find that by the time I want to do something in C from node.js there has already been a dozen of what I need created by others!
Memory in C++ is a leaky abstraction .

User avatar
John_Spikowski
Posts: 1392
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: ScriptBasic

Sat Jun 01, 2019 4:58 pm

Do you think Node is able to interface with the DHT11 device reliably?

I think it's important when selecting a scripting language for a task that it be extensible. From what I've seen out there it can be rather difficult / time consuming for one off projects.

I would guess I spent less than an hour writing both the GMP (fibo) and WPI (DHT11) example extension modules. Time is my most valuable asset at my age. I try to invest it wisely.

hippy
Posts: 5964
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: ScriptBasic

Sat Jun 01, 2019 6:07 pm

RichardRussell wrote:
Sat Jun 01, 2019 2:03 am
hippy wrote:
Sat Jun 01, 2019 12:12 am
I couldn't see any limit on read rates in the datasheet I have.
It states here that for the DHT11 "No more than 1 Hz sampling rate (once every second)" and for the DHT22 "No more than 0.5 Hz sampling rate (once every 2 seconds)".
I have to agree it says that, but there's no indication I could find of what the basis for such a claim is.

My suspicion is that needing to limit read rates comes down to self-heating effects. Read too frequently and it heats up and it starts screwing up the readings returned. It wouldn't be the first device to suffer such effects.

But, "readings will be inaccurate if you continually read more often than once every second" is very different to "you must wait a whole second before reading again" or "it won't report the last reading if you don't wait a whole second".

So, my take on things is, one shouldn't read too often, but it wouldn't be the end of the world if one read again immediately after getting a corrupted reading.

I would cite this in respect of my view, though acknowledging it refers to the DHT22 rather than DHT11 -

https://www.kandrsmith.org/RJS/Misc/Hyg ... _fast.html

"The datasheets for all the Aosong AM23xx and DHT devices are explicit that the quickest they should be polled is once every 2 seconds. What is not made clear is that you can get numbers out of the device much quicker than that, but they are likely wrong".

Wrong because, as the investigations there show, continually reading at a high rate causes self-heating. But double-reading at the recommended rate read should have far less, hopefully minimal or zero, effect.

If I had a DHT11 I'd try it; have the higher-level code read with a 1 second interval between readings. Have the low-level code take two immediately consecutive readings and see what happens.

Heater
Posts: 13357
Joined: Tue Jul 17, 2012 3:02 pm

Re: ScriptBasic

Sat Jun 01, 2019 6:14 pm

ScriptBasic,
Do you think Node is able to interface with the DHT11 device reliably?
As reliably as anything else I would guess. I have no DHT to test against. Tempted to get some mind.

A quick google turns up three different DHT modules for node.
I think it's important when selecting a scripting language for a task that it be extensible.
Node certainly is.

Like I say, anything I ever think of already has a node module. So it's just:

Code: Select all

$npm install whateverModule
and away I go. Time is of the essence as you say.
Memory in C++ is a leaky abstraction .

User avatar
John_Spikowski
Posts: 1392
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: ScriptBasic

Sat Jun 01, 2019 6:15 pm

hippy wrote: If I had a DHT11 I'd try it; have the higher-level code read with a 1 second interval between readings. Have the low-level code take two immediately consecutive readings and see what happens.
That high level loop of 10 iterations was done specifically to answer you curiosity. The DHT11 function only returns valid responses and reties are done internally. Each call does a full interface reset.

User avatar
John_Spikowski
Posts: 1392
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: ScriptBasic

Sat Jun 01, 2019 6:25 pm

Heater wrote: Like I say, anything I ever think of already has a node module.
This one looks easy to use.

DHT11 Node.js
Last edited by John_Spikowski on Sat Jun 01, 2019 7:48 pm, edited 3 times in total.

User avatar
RichardRussell
Posts: 579
Joined: Thu Jun 21, 2012 10:48 am

Re: ScriptBasic

Sat Jun 01, 2019 6:52 pm

ScriptBasic wrote:
Sat Jun 01, 2019 4:20 pm
I'm unaware of any language that uses no external libraries. (other than C)
As you know, BBC BASIC's libraries are written in BBC BASIC.

Return to “Other programming languages”