Aiuto progetto flussometri + RFduino

Salve, sperando di non infrangere alcuna regola del forum, scrivo per chiedere aiuto in un progetto basato su RFduino.
Avendo notato prima, che nella versione inglese esistono svariati post su questo argomento.
Il progetto ha l' obbiettivo di leggere due o più sensori di flusso allo stesso momento.
Premetto che la lettura di un solo sensore avviene in modo corretto, ma implementando il codice ed inserendo il secondo pin la lettura avviene in modo anormale.
Se non si attivano i due sensori allo stesso momento la lettura non avviene... alcune volte capita che i segnali arrivino anche singolarmente ma la maggior parte delle volte ciò non avviene.
Da quello che ho capito sembra che RFduino non accetti il valore "CHANGE" durante la dichiarazione della callback, di conseguenza quando il magnete del sensore si ferma sotto il sensore di hall il segnale rimane in HIGH e ciò fa saltare tutto.... muovendo tale magnete sembra che l' altro sensore riprenda il funzionamento.

Questo è il mio codice

#include <RFduinoBLE.h>
volatile int wCnt = 0;
volatile int cCnt = 0;

int wISR (uint32_t ulPin) {
  wCnt++;
  return 0;
}

int cISR(uint32_t ulPin) {
  cCnt++;
  return 0;
}

void setup() {
  Serial.begin(9600);
  pinMode(2, INPUT_PULLUP);  // attivo la resistenza di pullup interna
  pinMode(3, INPUT_PULLUP);

  RFduino_pinWakeCallback(2, HIGH, wISR);
  RFduino_pinWakeCallback(3,  HIGH, cISR);
}

void loop() {

  RFduino_ULPDelay (1000); //loop 1 second interval
  {
    Serial.print(wCnt);
    Serial.print(' ');
    Serial.println(cCnt);
    wCnt = 0;
    cCnt = 0;
  }
}

Anche usando la funzione attachPinInterrupt di arduino e sostituendo HIGH con CHANGE naturalmente non funziona.
La schema elettronico è semplicissimo i sensori prendono 5v in entrata ed i segnali vanno direttamente sui pin 2 & 3 della scheda.
I flussometri sono open collector con input da 5v a 32V
Rimango a disposizione per ulteriori informazioni.

Ringrazio anticipatamente.

Saluti

Essendo le uscite dei flussometri open collector, giustamente hai attivato il resistore interno di pull up.

Quindi, il segnale sarà normalmente HIGH, diventando LOW quando viene fornito l'impulso

Tuttavia, nel setup hai inserito la condizione opposta:

RFduino_pinWakeCallback(2, HIGH, wISR);
RFduino_pinWakeCallback(3, HIGH, cISR);

mentre dovrebbe essere

RFduino_pinWakeCallback(2, LOW, wISR);
RFduino_pinWakeCallback(3, LOW, cISR);

Grazie per la risposta, il problema e' che se li setto tutti e due in LOW... i sensori danno i stessi impulsi su tutti e due i pin se soffio nel flussometro 1 il dato si ripete per il flussometro 2.
Non so' se e' un bug di rfduino, ma e' assurdo.
Il circuito e' stato testato e non ha corti.

Qualche idea tipo reset dei pin, o qualcosa del genere?

Grazie

mi spieghi che significa?

int wISR (uint32_t ulPin) {
wCnt++;
return 0;
}

Ho letto che devi inserire l'istruzione

RFduino_resetPinWake(ulPin);

in ciascuna ISR per resettare lo stato del pin che ha causato il wakeup :

int wISR (uint32_t ulPin) {
  wCnt++;
  RFduino_resetPinWake(ulPin);
  return 0;
}

int cISR(uint32_t ulPin) {
  cCnt++;
  RFduino_resetPinWake(ulPin);
  return 0;
}

elpapais:
mi spieghi che significa?

int wISR (uint32_t ulPin) {
wCnt++;
return 0;
}

E' la sintassi della callback in RFduino, ogni qual volta che c è un evento su quel pin wCnt viene incrementato.

E' l equivalente di arduino:

int wISR () {
wCnt++ ;
}

Se non sbaglio... :slight_smile:

cyberhs:
Ho letto che devi inserire l'istruzione

RFduino_resetPinWake(ulPin);

in ciascuna ISR per resettare lo stato del pin che ha causato il wakeup :

int wISR (uint32_t ulPin) {

wCnt++;
  RFduino_resetPinWake(ulPin);
  return 0;
}

int cISR(uint32_t ulPin) {
  cCnt++;
  RFduino_resetPinWake(ulPin);
  return 0;
}

Già provato... anche :

int wISR (uint32_t ulPin) {
  wCnt++;
  RFduino_resetPinWake(2);
  return 0;
}

int cISR(uint32_t ulPin) {
  cCnt++;
  RFduino_resetPinWake(3);
  return 0;
}

Ho idea che sarebbe meglio se ti rivelogessi al supporto di RFduino ... sicuramente loro conoscono meglio la problematica di noi ... ::slight_smile:

Guglielmo

Già fatto, il moderatore del forum ha testato lo sketch con lo shield RGB che ha due pulsanti e dice che gli funziona, nel frattempo ha scoperto un BUG... sul mode delle callback ma non centra nulla con il mio problema.

Il problema secondo me che i sensori di HALL a palette funziona a livello meccanico in modo differente dagli switch.

Ed è possibile che un pin rimanga in LOW o HIGH ... e quando ciò avviene l altro pin (non sò per quale motivo) smette di funzionare.

Non vedo luce.

Grazie

Anche io sono rimasto perplesso dalla ISR, in particolare da ulPin:

int wISR (uint32_t ulPin)

int cISR (uint32_t ulPin)

A cosa corrisponde ulPin?

Non è che bisogna inserire semplicemente il valore del pin corrispondente?

tmsio:
Il problema secondo me che i sensori di HALL a palette funziona a livello meccanico in modo differente dagli switch.

Ed è possibile che un pin rimanga in LOW o HIGH ... e quando ciò avviene l altro pin (non sò per quale motivo) smette di funzionare.

La butto li ... tutta da studiare ...
... se il problema è che possono rimanere HIGH o LOW ... perché non aggiungere sulla loro uscita un monostabile che comunque genera solo un impulso di durata prefissata al cambiamneto di stato e poi, indipendentemente da tutto, ritorna nelle condizioni iniziali ?

Guglielmo

cyberhs:
Anche io sono rimasto perplesso dalla ISR, in particolare da ulPin:

int wISR (uint32_t ulPin)

int cISR (uint32_t ulPin)

A cosa corrisponde ulPin?

Non è che bisogna inserire semplicemente il valore del pin corrispondente?

infatti quella era la mia domanda...
secondo me quella ISR e' fatta con la pala.....
non riesco a capire il nesso logico....ne tantomeno scopo e funzionamento...

poi altra cosa...
Azzarderei dicendo che dubito basti chiamare una routine "QualcosaISR" perchè il sistema sappia che si fa riferimento a una routine IRQ.

La soluzione?
S
T
U
D
I
A
R
E

elpapais:
Azzarderei dicendo che dubito basti chiamare una routine "QualcosaISR" perchè il sistema sappia che si fa riferimento a una routine IRQ.

Attento, se leggi bene il codice troverai:

RFduino_pinWakeCallback(2, HIGH, wISR);
RFduino_pinWakeCallback(3, HIGH, cISR);

... che credo indichino a RFduino che quelle sono le ISR ::slight_smile:

Guglielmo

Si Guglielmo ma che è ulp?
poi:
questo non mi quadra...
nt wISR (uint32_t ulPin)

Anche io l'ho capito che dovrebbe essere una irq a parte che non vedo logica nel sostituire attachinterrupt in wakeCallback

RFduino ha il SUO core, la SUA libreria e la SUA sintassi ... quindi non mi meraviglia usi delle call diverse ...
... tccherebbe scaricarsi tutta la documentazione e studiarsela ... ::slight_smile:

Guglielmo

gpb01:
RFduino ha il SUO core, la SUA libreria e la SUA sintassi ... quindi non mi meraviglia usi delle call diverse ...
... tccherebbe scaricarsi tutta la documentazione e studiarsela ... ::slight_smile:

Guglielmo

Ma concordi con me che è strana?

anzi assurda...

... ripeto, non conosco l'oggetto e quindi non mi pronuncio ::slight_smile:

Guglielmo

Da RFduino/variants/RFduino/libRFduino.h

/**
 * \brief Configures the pin to wake the device from system off and execute a callback.
 *
 * \param ulPin The number of the digital pin you want to read (int)
 * \param dwWake Either DISABLED, HIGH or LOW
 * \param callback The callback function to execute when the pin is detected.
 *                 Here is an example pin callback function:
 *                 int my_pin_callback(uint32_t pin)
 *                 {
 *                   // do something
 *                   // return 0 to reset wake_detect, return 1 to exit RFduino_ULPDelay
 *                   return 0;
 *                 }
 *                 To call this function on the when pin 5 goes high:
 *                 RFduino_pinWake(5, HIGH, my_pin_callback);
 */
extern void RFduino_pinWakeCallback( uint32_t ulPin, uint32_t dwWake, pin_callback_t callback ) ;

... leggi bene il commento e l'esempio ::slight_smile:

Il sorgente di RFduino_pinWakeCallback non c'è perché viene data in forma di precompilato (libRFduino.a)

Guglielmo

ottimo grazie.

Grazie ancora per il supporto, ho pensato al monostabile... in tal caso le letture risulterebbero corrette? Hai un codice articolo (tipo RS) che potrei testare...? Lo vado a comprare subito :slight_smile:

Altri test che farò questa sera.. far si che il sistema non vado in Ulp mode.... poichè potrebbe anche essere che l' evento non riesca (per non sò quale motivo) a fare il wakeup di rfduino... e che lui rimanga sempre in Ulp mode.... e esce da questo stato solo quando tutti e due i pin mandano segnale....
Può essere una teoria...

Grazie Ancora.

Emiliano