Far eseguire due funzioni indipendenti

[drGremi]

Il discorso è che in ingegneria non esiste "una strada", ognuna ha pro e contro. Dipende dalle esigenze.
Per esempio se può essere una buona idea usare un timer e un interrupt per un progetto può essere una pessima idea per un altro (magari sui il PWM e quel timer è occupato).
Usare la funzione millis può essere comodo, ma il micro deve riavviarsi entro un mese circa (un po' di più di un mese), oppure bisogna tenere in conto di alcune questioni (overflow della variabile e conseguente reset del conteggio). Te ne accorgi solo se il sistema rimane acceso per molto tempo.
Fare il discorso in generale ha poco senso, si dovrebbe parlare di suggerimenti di casi specifici.

Altri casi bisogna decidere se premiare la facilità di programmazione o l'efficienza (esempio, usare float in microcontrollori invece degli interi che non supportano il calcolo interi immediatamente).
Oppure usare una sprintf invece di formattare con altri metodi. Più veloce da programmare, meno prono agli errori e molto esoso a livello di lunghezza di codice.
Non c'è spesso una strada giusta.

[WALTERmwp]

Sarò breve ...
In rete si recuperano informazioni facilmente, quasi chiunque può mettere insieme un Arduino e due modulini, e questo credo sia positivo.
Poi, qualche difficoltà insorge nel far funzionare l'accrocchio, non si capisce perché le cose non girano come su quel sito o quell'altro invece raccontano.
E così, sempre in rete, si cerca altrove, a volte risolvendo(spesso senza capire perché) a volte rabberciando, toccando i limiti d'un approccio superficiale: questo, sia chiaro, non è una colpa, ci mancherebbe, ma ad esempio la carente padronanza d'un linguaggio di programmazione, se non la totale ignoranza, rendono veramente complicato portare un aiuto perché l'assenza dei fondamentali non consente di comprendere il suggerimento ricevuto.
Si può tentare ovviamente, ma l'investimento in termini di tempo e di energia è tale che molti desistono.
Comunque capita che un utente riceva la soluzione take-away(ciapa sü e porta via) e se ne va contento ma dipende da molte circostanze: il sito tende a valorizzare lo scambio della conoscenza e la reciproca disponibilità è un punto di partenza.
Un invito a studiare deprime e allontana chi vorrebbe la soluzione semplicemente staccando un ticket, qualcun altro invece prova a metterci del proprio e allora si va avanti.
Ma una regola che schematizza in modo rigido ruoli e comportamenti non esiste.
Al forum partecipano utenti estremamente competenti e preparati, non è un modo per scrivere a vanvara (leggesi alla Balasso), ma non si denigra l'impreparazione, certamente si biasima la pigrizia.
Questo è quanto, poi, aiutate se volete(e potete); fine del pippone.

Saluti

[nicsergio]

Bella la soluzione di edgar!

Visto che questo thread ha assunto un carattere generale di condivisione di approcci ed esperienze, porto anche la mia. Non sono assolutamente un programmatore esperto di C/C++, vengo dal mondo dei PLC e dei controlli numerici e sono per la praticità ed il riutilizzo.

Il mio approccio con Arduino, visto che in genere al micro farò fare parecchie cose, è tenere la sezione "main" il più possibile ordinata e pulita, per cui tendo ad organizzare il codice in classi, privilegiando il comfort di programmazione rispetto alla pura efficienza, almeno in quelle applicazioni dove non serve essere tirati.
Per questo esempio userei la mia classe timer, che emula un temporizzatore configurabile all'eccitazione, alla diseccitazione o astabile (ciclico, intermittente). In questo modo posso concentrarmi su quello che voglio ottenere e non sui dettagli implementativi ad esempio della funzione millis o di gestirne il caso dell'overflow.

Il codice per gestire due led lampeggianti connessi ai pin 7 ed 8, uno ogni secondo e l'altro ogni due secondi e mezzo, sarebbe:

Codice: Seleziona tutto

#include <Timer.h>

bool enbLed1;
bool enbLed2;
Timer timLed1(Cycle, 1000, &enbLed1, blink1);
Timer timLed2(Cycle, 2500, &enbLed2, blink2);


void setup() { }

void loop()
{
    enbLed1 = true;      //--> da gestire: abilitazione led 1
    enbLed2 = true;      //--> da gestire: abilitazione led 2

    timLed1.update();
    timLed2.update();
}

void blink1(bool state)
{
    digitalWrite(7, state);
}
void blink2(bool state)
{
    digitalWrite(8, state);
}


Allego, se può interessare, la libreria in questione.
Spero di non aver fatto inorridire troppo qualcuno, ma fa lo stesso

[SandroCalligaro]

Non me ne vogliano i puristi, nella routine di gestione dell'interrupt bisognerebbe eseguire il minimo possibile

Questa secondo me è un'affermazione che non vale in generale, anzi. Dal mio punto di vista (ovviamente ognuno vede meglio le cose con cui ha avuto a che fare) la maggior parte del tempo viene spesa eseguendo la routine di interrupt.

Ho in mente applicazioni di controllo veloce (tempi di aggiornamento <1 ms, come ordine di grandezza) o processamento di segnale, o comunque dei casi in cui la precisione della temporizzazione è essenziale.
In questi casi, alcune cose si devono fare il più possibile velocemente e all'inizio dell'interrupt (tipicamente leggere gli ingressi analogici), per avere più tempo possibile per i calcoli che ne conseguono e per ridurre il jitter (se la conversione A/D viene avviata via software), ma poi tutto il processamento real-time va fatto nell'interrupt, per essere certi di non perdere campioni e di avere una sequenza ben precisa delle operazioni (che non deve poter essere interrotta, a sua volta).

Nei "ritagli di tempo" rimanenti, il microcontrollore potrà eseguire i task asincroni (ad esempio quelli relativi alla comunicazione o all'interfaccia utente) e quelli a frequenza inferiore (quelli per i quali non occorre una temporizzazione così precisa).

[SandroCalligaro]

Comunque, per generalizzare un po', mi sembra di poter dire che, per ottenere apparentemente l'esecuzione di due o più funzioni in modo indipendente, come chiedeva l'OP, il primo passo sia avere un "timer", che fissi il "quanto" di tempo, sul quale fare conteggi ecc.
Per "timer" intendo qualcosa che permetta di sapere quando è passato un certo periodo di tempo, sia esso un oggetto software o hardware.

La versione per me fatta "male" (che considero poco seria) è quella che, per vedere se è passato un certo tempo, usa una funzione di ritardo.
Quella "fatta bene" (quanto bene... è da vedere) usa un interrupt, più o meno direttamente.
Usando un ritardo, infatti, si hanno almeno due svantaggi:

• la precisione del tempo è scarsa, perché il codice che viene eseguito alla fine del ritardo causa anch'esso un ritardo, che si accumula;
• il tempo in cui si "aspetta" è tempo perso, mentre con l'interrupt quel tempo può essere sfruttato per fare altro.

PS: forse per gli informatici si tratta di problemi "classici". Non appartenendo a quella categoria, però, non so se e come siano stati codificati, teorizzati e risolti.

[IlGuru]

La differenza è che il ritardo fatto con interrupt sfrutta un contatore ed un comparatore hardware che lavorano indipendentemente da quello che fa la mcu, altrimenti, il conteggio ed il test devono essere fatti dalla mcu che nel frattempo non può fare altro.

[Macelettronic]

Ragazzi vi chiedo scusa se non ho più risposto, ma le email di notifica del forum mi arrivano tra le spam, anche se le ho contrassegnate come email "buone", quindi non ho più controllato il forum
Per farla breve, ho continuato ad usare gli NE555 che per adesso insieme a qualche altro componente soddisfano le necessità che ho per i diorami.

[WALTERmwp]

(...) ho continuato ad usare gli NE555 che per adesso insieme a qualche altro componente soddisfano le necessità che ho per i diorami.

bravo, ma se hai la possibilità non rinunciare allo studio, anche usando Arduino.
La programmazione ti consente una flessibilità difficilmente raggiungibile con lo hardware cablato.

Saluti

[lelerelele]

parere personale, SandroCalligaro e IlGuru, tutto giusto, in entrambi i casi, dipende da cosa devo fare.
Se uso il polling, certo che perdo tempo del processore per verificare se presente il segnale, (od il timer), se però il tempo tra un segnale letto ed il successivo è lungo, rispetto al tempo in cui svolgo il mio compito di elaborazione, allora vale la pena usarlo, anche perché l'uso dell'interrupt implicherebbe che ciclassi nel main continuamente aspettando l'interrupt. Non cambierebbe niente.
Se invece ho svariate elaborazioni da fare, ed il tempo intercorso tra due segnali è basso, sono costretto ad usare interrupt, per avere il tempo di elaborare ed aggiornare altre funzioni in coda.
In merito alle routine di interrupt ed al carico che devono ricoprire, mi è capitato di avere un ciclo che non veniva mai svolto, perché l'interrupt era troppo veloce, in questo caso, anche se svolgessi tutti gli interrupt, non avrei abbastanza tempo elaborarli, perdendo pezzi di programmi, per me la soluzione (dipende sempre dal caso specifico), sarebbe l'interrupt che legge il dato, più velocemente possibile, poi l'elaborazione avrebbe in coda il dato corretto da elaborare.
Se il micro non ci arriva, è meglio saltare l'interrupt o saltare la sua elaborazione?
saluti.

[xyz]

Se il micro non ci arriva, è meglio saltare l'interrupt o saltare la sua elaborazione?

Significa che hai sbagliato a scegliere il micro-controllore o hai scritto del codice molto inefficiente o stati usando una API (come quella di Arduino) non molto adatta nel gestire gli interrupt.