Far eseguire due funzioni indipendenti

[lelerelele]

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.

Certamente. Sono perfettamente d'accordo, ma per me sarebbe una valutazione da fare, in base alla quale definire come va a lavorare l'interrupt, (si stava parlando di fare eseguire entro l'interrupt grandi elaborazioni).
no?

[SandroCalligaro]

Scusate il post lungo, ma vista la piega che ha preso il thread, mi sembrava bello condividere qualche esperienza.
Anche io consiglio a Macelettronic di imparare a programmare bene, anche perché al giorno d'oggi è difficile fare elettronica senza.

Il fatto è che, come dice xyz, se il micro non ce la fa a svolgere il "lavoro" in tempo, sei comunque fregato.
Se si può, dovrai rilassare i tempi, cioè aumentare il periodo con cui esegui le operazioni ripetitive...

Se pensiamo ad applicazioni di controllo, avere una temporizzazione certa è come avere delle buone fondamenta. Se inizi a fare sul serio ti accorgi che non puoi accettare di non sapere che tempo di campionamento hai (con precisione alta), se il tuo timer dura esattamente 1 secondo, ecc ecc.
Questa cosa (come tante altre), poi, diventa un modo di fare, una di quelle cose che fai senza pensarci, come un artigiano serio e di esperienza ha le sue "procedure". E' un limite? Non credo... (*)

Per contro, la cosa peggiore è non sapere cosa stia succedendo dentro il micro, nel senso di perdere di vista la sequenza e la temporizzazione. Considerando che a volte (per limiti del sistema di debugging o per altri motivi) non è possibile mettere breakpoint durante il funzionamento, bisogna fare il possibile per evitare situazioni dubbie (**).

Ribadisco quello che dicevo qualche giorno fa, cioè che per me è meglio imparare a fare le cose per bene (e quindi ad imparare da chi è "del mestiere", almeno all'inizio) anche quando apparentemente non fa differenza rispetto ad una soluzione raffazzonata.

Attenzione che abbiamo considerato il caso in cui ci sia un solo interrupt legato ad un timer, mentre se ci sono altri interrupt la cosa si complica non poco. Andrebbero gestiti, tra l'altro, in base a delle priorità.
Nelle applicazioni che ho visto, eventuali altri interrupt erano principalmente "one-shot", come ad esempio il superamento di qualche soglia, che va ad interrompere il normale funzionamento. In ogni caso, ci potrà essere un solo interrupt che occupa la maggior parte del tempo, mentre le altre routine di servizio dovranno essere abbastanza brevi.
Alcuni microcontrollori hanno una gestione molto fine e flessibile (ma anche complicata) delle priorità, un esempio che conosco (anche se non ho mai dovuto mettere le mani più di tanto nella configurazione degli interrupt) è il TI C2000.



(*) Mio padre era un artigiano molto appassionato del suo lavoro. Nonostante cercasse sempre soluzioni creative, aveva delle "abitudini" o "procedure", piccoli dettagli che seguiva senza nemmeno pensarci (ad esempio, disponeva i pezzi da lavorare in un certo verso). A cosa serviva? A non fare errori banali.
Visto che stiamo parlando, in fin dei conti, di "buone pratiche" nella programmazione di microcontrollori in C/C++...
Siccome sono rimasto "scottato" una volta, quando definisco una costante numerica uso sempre le parentesi, e spesso metto ".0" dietro l'intero:

Codice: Seleziona tutto

#define NUM (1.0/10.0)
#define DEN (2.0)
#define QUOTIENT (NUM/DEN)

Meglio mettere le parentesi dove non serve, che rischiare di farne a meno dove serve...

(**) Nel dubbio, ad esempio se si pensa che la routine di interrupt duri troppo, si può sempre fare una verifica con l'oscilloscopio, alzando ed abbassando un pin del micro...

[WALTERmwp]

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

Significa che hai sbagliato a scegliere il micro-controllore o hai scritto del codice molto inefficiente o (...)

Saluti

[IlGuru]

Al limite le interrupt si possono anche mascherare

[lemure64]

Siccome sono rimasto "scottato" una volta, quando definisco una costante numerica uso sempre le parentesi, e spesso metto ".0" dietro l'intero:

Codice: Seleziona tutto

#define NUM (1.0/10.0)
#define DEN (2.0)
#define QUOTIENT (NUM/DEN)

Meglio mettere le parentesi dove non serve, che rischiare di farne a meno dove serve...

Le macro sono atroci... pure io metto parentesi ovunque, tipo:

Codice: Seleziona tutto

val = (((ptr->x).y).z) ;


Non so su due piedi se l'esempio è sintatticamente corretto, tanto quando il compilatore protesta provo "->" al posto di "." con le varie combinazioni, però spero renda l'idea: nonostante le regole di precedenza mi risparmierebbero tante parentesi, se trovo

Codice: Seleziona tutto

val = ptr->x.y.z ;


Semplicemente l'occhio mi si confonde totalmente; uno dei motivi del perché non posso mettere le mani sul codice scritto non da me. Meno male che non è lavoro...

[xyz]

n base alla quale definire come va a lavorare l'interrupt, (si stava parlando di fare eseguire entro l'interrupt grandi elaborazioni).
no?

Dipende cosa stai scrivendo, se hai un programma principale il quale esegue la maggior parte dei calcoli, gli interrupt devono fare il minimo indispensabile, devono sottrarre meno cicli macchina possibili. Se stai scrivendo un sistema operativo runtime tutti i tuoi thread sono interrupt e il ciclo principale è equivalente a un loop infinito con un salto a se stesso.

[marioursino]

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

Premesso che non ho ben capito questa domanda, nella scrittura di un firmware si dovrebbeto fare le cose in modo deterministico.

In altre parole devi sempre conoscere il tempo di elaborazione massimo di ogni routine, e il tuo eventuale ciclo di controllo deve essere più lento della loro somma.

Riguardo l'esecuzione degli interrupt condivido tutto ciò che ha detto Sandro: nei fw che scrivo, di solito il 90% è dedicato all'esecuzione di ISR che sono scanditi da timer (ad esempio, in ordine, ADC - DMA - calcolo dell'errore - DAC). Un piccolo margine rimane per il "main" che gestisce l'interfaccia.

[EcoTan]

Parlando da autocostruttore domestico, molto dipende dal sistema di sviluppo.
Fino al compilatore XC16 per i dsPic, per dichiarare una ISR basta una istruzione del tipo seguente:
void __attribute__((no_auto_psv)) _ISRFAST _MI2C1Interrupt(void) { //ISR I2C master
Mi è capitato di dichiararne a bizzeffe nello stesso programma, anche lunghe, e non ho avuto alcun problema, senza essermi mai curato di priority, level, nesting, masking o altre cose difficili, ovviamente evitando che il tempo di esecuzione complessivo si avvicini troppo a quello reale.
Passando al compilatore XC32, tanto per restare nell'esempio, è cambiato tutto fino al punto che ho dovuto rinunziare all'uso delle ISR (e anche questo, in un caso, ha funzionato bene).