DHT11 e MKS/RAMPS, collegamento e funzionalità

MK4Duo ver. 4.3.5

Volendo collegare una sonda tipo DHT11 alla scheda 8bit di tipo RAMPS / MKS, quali pin sono indicati perchè possa funzionare la lettura?

Ho verificato una connessione al pin D40, e al pin X_MAX ma in nessuno dei due casi ottengo dati validi

Edited 1 time(s). Last edit at 03/06/2018 05:25PM by Romulus76.

@Magokimbra nessuna info in merito??

O io uno sono, il DHT11 l'ho provato sul due, sul mega non ho avuto modo, devo vedere la libreria come si comporta e come lo usa. Se riesco fine settimana gli do un occhio..

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Quote
MagoKimbra
O io uno sono, il DHT11 l'ho provato sul due, sul mega non ho avuto modo, devo vedere la libreria come si comporta e come lo usa. Se riesco fine settimana gli do un occhio..

Guarda, se conoscessi un po di più il flusso del firmware, ed i meccanismi di timeout/timer/scheduler potrei darti una mano volentieri; il problema principale è che fino ad oggi non ho avuto molto tempo perchè appunto lo dedicavo alla mia nuova corexy.

Ora appena l'ho "rifinita" (e manca poco) posso dedicare un po all'analisi del firmware, ma senza aver nessun documento o diagrammi flusso è difficile capire tutto facilmente ed in modo veloce.

Ti avevo domandato perchè avevo visto questo video su YT, quindi ero convinto andasse già bene con mk4duo. Però forse lo avevi utilizzato solo come test, magari neppure nell'MK4duo

Stamattina stavo guardando appunto il modulo classe del dhtsensor, sembra fatto bene (a stati) e chiaro, chiamato ogni quanto tempo non so perchè poi il printer.idle ho visto è "spalmato" per vari punti del codice. Di certo utilizza gli interrupt, quindi necessariamente il pin deve avere l'interrupt intercettabile disponibile.... ma qualeee??

Adesso mi scarico il PDF del mega2560 e mi faccio un "sommario" dei pin disponibili con la RAMPS..

La funzionalità PINS_DEBUG non l'ho ancora provata... che da indietro ad HOST?

Edited 1 time(s). Last edit at 03/08/2018 04:10AM by Romulus76.

No no certo che ho usato MK4duo... Il fatto che la libreria usa gli interrupt e per il mega è un po un casino.. Ora vedo se riesco ad aggiustare la cosa...

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Quote
MagoKimbra
No no certo che ho usato MK4duo... Il fatto che la libreria usa gli interrupt e per il mega è un po un casino.. Ora vedo se riesco ad aggiustare la cosa...

Ma per libreria intendi il tuo modulo classe dhtsensor.cpp? Perchè non vedo altri riferimenti esterni.

Cmq, guardando il codice sorgente sembrerebbe tutto in ordine, ora dovrei capire dove connettere il DATA del sensore:

disponibili:
X_MAX = D2 (PE4, PWM T3B, INT4)
Y_MAX = D15 (PJ0, USART3 RX, Pin Int 9)
Z_MAX = D19 (PD2, USART1 RX, Ext Int 2)

non presenti: D10, D11, D12, D13 (non sono tirati sugli headers MKSGEN)

mentre tutti gli altri restanti DigitalPin con interrupt sono già occupati.

Oggi dopo la pausa pranzo faccio un test con una scheda MKS e sensore in ufficio con oscilloscopio, verifico se viene pilotato, lo start di protocollo da 20ms per la richiesta dati.
Idee su quale pin scegliere??

Edited 1 time(s). Last edit at 03/09/2018 04:50AM by Romulus76.

@MagoKimbra ho fatto il test posizionando il pin X_MAX e sembra che, dopo una corretta vaschetta da 20ms, la sonda risponde alla richiesta.

Ho allegato tre screenshot dell'oscilloscopio, la cosa strana è che il segnale della sonda non è "livellato" bene... mentre 1 logico è coerente (pullup interno abilitato probabilmente con INPUT_PULLUP) lo 0 logico è a quasi 3V e questo non credo sia molto buono.

Come risolviamo il problema ora? Idee?

EDIT (15:23): analizzato il codice HAL:pinMode(....)

static inline void pinMode(const pin_t pin, const uint8_t mode) {
      switch (mode) {
        case INPUT:
          ::pinMode(pin, INPUT); break;
        case OUTPUT:
          ::pinMode(pin, OUTPUT); break;
        case OUTPUT_LOW:
          ::pinMode(pin, OUTPUT);
          ::digitalWrite(pin, LOW);
          break;
        case OUTPUT_HIGH:
          ::pinMode(pin, OUTPUT);
          ::digitalWrite(pin, HIGH);
          break;
        default: break;
      }
    }

manca il case nello switch INPUT_PULLUP , nel file HAL_AVR.H.
Sto anche osservandone il funzionamento, ma perchè richiami la stessa funzione "pinMode" in ogni case?? sembra una cosa ricorsiva... non capisco...

Edited 2 time(s). Last edit at 03/09/2018 09:34AM by Romulus76.

[www.arduino.cc]

Bisognerebbe cominciare con questi:
Mega, Mega2560, MegaADK 2, 3, 18, 19, 20, 21

Appena posso provo..

Edit: non avevo letto che hai provato con il pin 3. va bene... Non è livellato perché su quel pin poi transita al comunicazione quindi c'è il treno di bit con cui comunica al processore i valori di temperatura e umidità.

Edited 1 time(s). Last edit at 03/09/2018 09:09AM by MagoKimbra.

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Quote
MagoKimbra
[www.arduino.cc]

Bisognerebbe cominciare con questi:
Mega, Mega2560, MegaADK 2, 3, 18, 19, 20, 21

Appena posso provo..

Edit: non avevo letto che hai provato con il pin 3. va bene... Non è livellato perché su quel pin poi transita al comunicazione quindi c'è il treno di bit con cui comunica al processore i valori di temperatura e umidità.

Si capisco il treno di bit che arrivano in risposta, ma anche se per usec dovrebbe comunque andare a 0 il bit, anche perchè i livelli logici TTL sono:
"L" = 0 V to 0.8 V
"H" = 2 V to 5V

Tu hai visto gli screenshot? Siamo a 3V per lo "L" logico... quindi vede tutto come logico H.

Ho appena editato il post, nel file HAL_AVR la pinMode non mi sembra corretta o funzionante... INPUT_PULLUP ???

Edited 3 time(s). Last edit at 03/09/2018 10:30AM by Romulus76.

Perché? Così deve funzionare...

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Quote
MagoKimbra
Perché? Così deve funzionare...

Punto1: nel codice dove sta il case "INPUT_PULLUP"?
Punto2: i livelli logici non sono corretti, o meglio "L" non è visto (0v to 0,8v)... siamo a 3V!!

Sicuro sia tutto a posto con il pinMode?

Si sicuro!!

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Quote
MagoKimbra
Si sicuro!!

Piccolo aggiornamento

1. Il mio sensore non era provvisto di resistenza di Pull-up da 10k sulla linea DATA, ho provveduto a saldarci una resistenza.

2. Ho rieseguito i test a casa (senza oscilloscopio) ma con MK4duo continua a non comunicare (ne su piedino 2 ne su 3)

3. Ho provato a scaricare un semplice esempio arduino (utilizzando metodo non interrupt), e la sonda funziona correttamente... quindi escludo problemi elettrici.

Ci sono novità a riguardo da parte tua?

No sto provando.. Allora la sonda per come è fatta manda dati a un certo punto dopo la richiesta. Il programmino senza interrupt certo che funziona sta li aspetta la risposta e quando la riceve ti segnala il dato, ma questo non è possibile sulla stampante, perché significherebbe, anche se per alcuni millisecondi il firmware si ferma in attesa di risposta per non perdere i dati, capisci bene che questo non è possibile. Unna cosa se con arduino ti fai un piccolo termometro d'ambiente e va bene, ma nella stampante dove deve gestire temperature, gli stepper il parsing dei dati, la lettura usb gestire il display, fermarsi ad aspettare una risposta non va per niente bene... Quindi sul due si fa con gli interrupt, quando è pronto e manda i dati il cambio di stato del pin interrompe il processore , che va subito a leggere e dopo aver letto ritorna a fare quello che stava facendo..
Non so se mi sono spiegato... Senza interrupt, bisogna creare un timer, visto che il tempo della risposta è quello dato dal datasheet, quindi mandare il segnale di richiesta di lettura, far partire il timer pre programmato con il tempo dato, tornare a fare quello che si stava facendo, e quando il timer finisce il conteggio richiama la routine ISR per leggere i dati...E Visto che i timer sono già belli che usati, volevo evitare questo, quindi sto studiando come fare... Altrimenti bisogna usare pin con gli interrupt, in teoria dovrebbe già funzionare, ma tu mi dici di no..
Attenzione pin 2 e 3 digitali non analogici..

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Questa è la routine di lettura del DHT11 della libreria ufficiale adafruit..

Ora se guardi in blu blocca tutti gli interrupt per non essere bloccato mentre legge e già sta cosa non mi piace, se arriva la chiamata dei timer degli stepper o della temperatura la salta, quindi si potrebbero avere dei tentennamenti durante la stampa.
Poi in rosso i delay troppi, fermo non fare nulla in attesa di risposte...

boolean DHT::read(bool force) {
  // Check if sensor was read less than two seconds ago and return early
  // to use last reading.
  uint32_t currenttime = millis();
  if (!force && ((currenttime - _lastreadtime) < 2000)) {
    return _lastresult; // return last correct measurement
  }
  _lastreadtime = currenttime;

  // Reset 40 bits of received data to zero.
  data[0] = data[1] = data[2] = data[3] = data[4] = 0;

  // Send start signal.  See DHT datasheet for full signal diagram:
  //   [www.adafruit.com]

  // Go into high impedence state to let pull-up raise data line level and
  // start the reading process.
  digitalWrite(_pin, HIGH);
  delay(250);

  // First set data line low for 20 milliseconds.
  pinMode(_pin, OUTPUT);
  digitalWrite(_pin, LOW);
  delay(20);

  uint32_t cycles[80];
  {
    // Turn off interrupts temporarily because the next sections are timing critical
    // and we don't want any interruptions.
    InterruptLock lock;

    // End the start signal by setting data line high for 40 microseconds.
    digitalWrite(_pin, HIGH);
    delayMicroseconds(40);

    // Now start reading the data line to get the value from the DHT sensor.
    pinMode(_pin, INPUT_PULLUP);
    delayMicroseconds(10);  // Delay a bit to let sensor pull data line low.

    // First expect a low signal for ~80 microseconds followed by a high signal
    // for ~80 microseconds again.
    if (expectPulse(LOW) == 0) {
      DEBUG_PRINTLN(F("Timeout waiting for start signal low pulse."));
      _lastresult = false;
      return _lastresult;
    }
    if (expectPulse(HIGH) == 0) {
      DEBUG_PRINTLN(F("Timeout waiting for start signal high pulse."));
      _lastresult = false;
      return _lastresult;
    }

    // Now read the 40 bits sent by the sensor.  Each bit is sent as a 50
    // microsecond low pulse followed by a variable length high pulse.  If the
    // high pulse is ~28 microseconds then it's a 0 and if it's ~70 microseconds
    // then it's a 1.  We measure the cycle count of the initial 50us low pulse
    // and use that to compare to the cycle count of the high pulse to determine
    // if the bit is a 0 (high state cycle count < low state cycle count), or a
    // 1 (high state cycle count > low state cycle count). Note that for speed all
    // the pulses are read into a array and then examined in a later step.
    for (int i=0; i<80; i+=2) {
      cycles   = expectPulse(LOW);
      cycles[i+1] = expectPulse(HIGH);
    }
  } // Timing critical code is now complete.

  // Inspect pulses and determine which ones are 0 (high state cycle count < low
  // state cycle count), or 1 (high state cycle count > low state cycle count).
  for (int i=0; i<40; ++i) {
    uint32_t lowCycles  = cycles[2*i];
    uint32_t highCycles = cycles[2*i+1];
    if ((lowCycles == 0) || (highCycles == 0)) {
      DEBUG_PRINTLN(F("Timeout waiting for pulse."));
      _lastresult = false;
      return _lastresult;
    }
    data[i/8] <<= 1;
    // Now compare the low and high cycle times to see if the bit is a 0 or 1.
    if (highCycles > lowCycles) {
      // High cycles are greater than 50us low cycle count, must be a 1.
      data[i/8] |= 1;
    }
    // Else high cycles are less than (or equal to, a weird case) the 50us low
    // cycle count so this must be a zero.  Nothing needs to be changed in the
    // stored data.
  }

  DEBUG_PRINTLN(F("Received:"));
  DEBUG_PRINT(data[0], HEX); DEBUG_PRINT(F(", "));
  DEBUG_PRINT(data[1], HEX); DEBUG_PRINT(F(", "));
  DEBUG_PRINT(data[2], HEX); DEBUG_PRINT(F(", "));
  DEBUG_PRINT(data[3], HEX); DEBUG_PRINT(F(", "));
  DEBUG_PRINT(data[4], HEX); DEBUG_PRINT(F(" =? "));
  DEBUG_PRINTLN((data[0] + data[1] + data[2] + data[3]) & 0xFF, HEX);

  // Check we read 40 bits and that the checksum matches.
  if (data[4] == ((data[0] + data[1] + data[2] + data[3]) & 0xFF)) {
    _lastresult = true;
    return _lastresult;
  }
  else {
    DEBUG_PRINTLN(F("Checksum failure!"));
    _lastresult = false;
    return _lastresult;
  }
}

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Quote
MagoKimbra
No sto provando.. Allora la sonda per come è fatta manda dati a un certo punto dopo la richiesta. Il programmino senza interrupt certo che funziona sta li aspetta la risposta e quando la riceve ti segnala il dato, ma questo non è possibile sulla stampante, perché significherebbe, anche se per alcuni millisecondi il firmware si ferma in attesa di risposta per non perdere i dati, capisci bene che questo non è possibile. Unna cosa se con arduino ti fai un piccolo termometro d'ambiente e va bene, ma nella stampante dove deve gestire temperature, gli stepper il parsing dei dati, la lettura usb gestire il display, fermarsi ad aspettare una risposta non va per niente bene... Quindi sul due si fa con gli interrupt, quando è pronto e manda i dati il cambio di stato del pin interrompe il processore , che va subito a leggere e dopo aver letto ritorna a fare quello che stava facendo..
Non so se mi sono spiegato... Senza interrupt, bisogna creare un timer, visto che il tempo della risposta è quello dato dal datasheet, quindi mandare il segnale di richiesta di lettura, far partire il timer pre programmato con il tempo dato, tornare a fare quello che si stava facendo, e quando il timer finisce il conteggio richiama la routine ISR per leggere i dati...E Visto che i timer sono già belli che usati, volevo evitare questo, quindi sto studiando come fare... Altrimenti bisogna usare pin con gli interrupt, in teoria dovrebbe già funzionare, ma tu mi dici di no..
Attenzione pin 2 e 3 digitali non analogici..

Sul tuo discorso nulla da eccepire, anzi sarebbe un problema se fosse implementata con cicli di wait o loop in FOR.
Ovviamente nulla deve essere sospensivo altrimenti il firmware non fa quel che deve, ovvero stampare!

Io ho utilizzato una libreria già bella e pronta per testarne il funzionamento (del sensore HW), volevo escludere problemi elettrici.
E' da capire se l'intercettamento dell'interrupt nel MEGA funziona bene con quel segnale, ora faccio qualche test...

Con mk4duo, come posso utilizzare una seriale? Cioè so come usarla, ma posso usare anche quella USB o devo usarne una aggiuntiva?
Tu come esegui il debug (a prescidere che in interrupt la libreria seriale non trasmette)??

Quote
MagoKimbra
Attenzione pin 2 e 3 digitali non analogici..

Che vuol dire? certo devono esser digitali, con interrupt esterno programmabile..

Ho trovato il problema della lettura legato all'interrupt del MEGA.
Ti posto in privato la soluzione