Sensori hall e Serial.read()

International Italiano Generale
21

Aggiungo: nel codice di esempio perché quando devi leggere fai sempre il "detachInterrupt();" e poi "attachInterrupt()" invece di usare semplicemente "noInterrupts()" e "interrupts();" per sospendere gli interrupt (che tra l'altro vanno lasciati disabilitati per il minor tempo possibile quindi eviterei anche di usare la seriale)?
Una cosa del tipo:

  if(millis()-prev_time[0] >= intervals[0]){
    prev_time[0] = millis();
    noInterrupts();
    rpm = 60*counter;
    counter = 0;
    interrupts();
    Serial.print("RPM value: ");
    Serial.println(rpm);
  }

Ma ovviamente resta in piedi quanto detto nel mio precedente post...

22

Assolutamente da NON usare così ... vengono disabilitati TUTTI gli interrupts ... quello che gestisce la seriale, quelli che gestiscono i timers, ecc. ecc.

Questa cosa si fa solo in programmi veramente particolari che hanno la VERA necessità, in certi momenti, di NON essere interrotti neanche per pochi µsec, ma in tutti gli altri i casi NO!

Va bene invece la tecnica del detach() e attach() per evitare alcuni interrupt specifici.

Guglielmo

23

Ah, dimenticavo... Non ho ancora mai avuto necessità di usare i "pin change interrupt", per cui ho provato cercare: se non ho capito male, sulla UNO sono solo tre le porte utilizzabili per i pin change interrupt e quindi al massimo 3 ISR, il che mi fa tornare alla mia domanda originaria (che si risolverebbe potendo vedere il suo codice reale...): su quali pin ha definito gli interrupt e come ha fatto a definirne quattro separati e concorrenti?

24

Ovvero 24 pins :grin: ... tranquillo ne può definire quanti ne vuole ...

In pratica la porta su cui è il pin genera l'interrupt, poi, da software, la funzione cerca "quale" è il pin specifico che ha generato l'interruzione :wink:

Guglielmo

25

Si, immaginavo una cosa del genere ma potendo vedere il suo vero codice avrei potuto capire meglio (anche imparare, che è una delle cose che mi interessano quando frequento il forum :wink: ), mentre l'unico codice di esempio postato qui è fuorviante perché usa un modo completamente diverso.

Ma comunque a me sembra che gestire 200 interrupt al secondo e contemporaneamente anche la seriale sia alla portata anche della UNO, per cui continuo a chiedermi se dipenda da come è stato implementato il tutto (ad esempio la ISR viene chiamata su CHANGE, e verificare quindi il cambio di stato unitamente al rilevare quale pin abbia generato l'interrupt non è propriamente semplcie come fare "++counter;"), e se per caso non possa essere questo ad influire negativamente sulla comunicazione seriale ossia sul relativo interrupt. Tu sai qualcosa in merito?

26

Il meccanismo a livello MCU è molto veloce, 3 cicli di clock (≈187 nsec.) ...

... poi, se ha usato la giusta libreria, anche la successiva elaborazione è molto veloce, però considera che, a quel punto, l'interrupt vero e proprio è già finito :wink:

Guglielmo

27

Ecco un bel documento in cui si analizzava la "pin change interrupt" e tutte le tempistiche collegate (salvataggio dei registri, ecc. ecc.): Interrupt Timing.pdf (1.2 MB).

Ricordo che la migliore libreria era la EnableInterrupt che gestiva correttamente tutti i vari tipi di interrupt :slight_smile:

Guglielmo

28

Grazie, lo immaginavo. Però resta comunque il fatto che fino a che non si vede il "vero" codice possiamo farci tutte le pipp.. elucubrazioni teoriche possibili ed immaginabili... :wink:

Ottimo spunto, grazie mille, me la segno (no, non lo dico sarcasticamente come Troisi in "non ci resta che piangere" :slight_smile: )