MECCANICA e DINTORNI

Caro Max,

Nonostante i nostri battibecchi, mi diverte tantissimo discutere con te e ti considero un'amico di tastiera.
Come te ho conseguito il diploma come perito, ma con la specializzazione in Elettroni e Telecomunicazioni.
Inoltre sono un Radioamatore e il mio nominativo è IU8NNS.
I primi programmi per i Pic, li ho scritti in assembler, utilizzando l'ambiente di sviluppo del Microchip, MPLAB, il programma era caricato su floppy disk.
Poi sono passato al Picbasic della ME Lab, e successivamente al MikroC della Mikroe.
Quando una materia mi appassiona cerco di approfondirla il più possibile, ho letto decine di libri sull'argomento scritti sia in Inglese che in Italiano.
Sperimentando le cose di cui scrivo.
Da come mi poni le domande, mi hai deluso, sono sempre più convinto che ti mancano le nozioni di base.
L'interrupt esiste per un solo motivo, per dare la possibilità ad un micro di poter eseguire più operazioni contemporaneamente.
Questo è l'unico motivo per cui esiste l'interrupt.
E' sbagliato pensare che sia errato utilizzare degli If all'interno della routine di Interrupt. In alcuni dei mie progetti ho dovuto abilitare più interruzioni, come avrei potuto fare se non avessi avuto la possibilità di discriminarli?
Quando parli di simmetria rispetto a cosa? Quello che conta è la sua durata nella peggiore delle ipotesi.
Normalmente quando si progetta qualcosa, si tiene conto sempre del condizioni più sfavorevoli.
Ripeti come un mantra le stesse cose senza argomentare. In elettronica un segnale e da ritenersi sempre causale a causa delle fluttuazioni microscopiche dei componenti della materia, come ad esempio il moto degli elettroni in un metallo. Ma non è questo il punto.
Non ho mai scritto che è possibile conoscere il valore assunto in un preciso istante nel tempo dal segnale prodotto dall'encoder, ma piuttosto che possiamo determinare con una buona precisione, l'intervallo di tempo nella peggiore delle ipotesi, tra un'interruzione e quella successiva.

Umbez: La durata della routine di interruzione deve essere il più breve possibile, in modo che sia completata prima della prossimo evento di interruzione.
Su questo punto non ci sono dubbi, mai scritto il contrario. Ti sfido a trovare una sola riga in cui ho scritto diversamente. Ma la domanda che bisogna porsi è: Breve, ma quanto? 5us? 10us? 20us? Nessuno potrà mai rispondere a questa domanda, perché dipende dal caso specifico.
Se la nostra routine di interruzione dura 10us, non sarà possibile seguire eventi che si ripetono con una un intervallo di tempo inferiore a questo valore.
Nel nostro caso, possiamo determinare la frequenza massima con cui si potranno verificare questi eventi? Certamente che si.
Assumendo che la velocità massima di rotazione, sia di 3000 giri/min, avremo una frequenza di 120Khz. Il periodo sarà di circa 8us.
Quindi gli eventi si potranno verificare con un intervallo di tempo compreso tra infinito e circa 8us.
Nel caso di Matteo la sua routine dovrà durare meno di 8us, punto.
Se invece consideriamo la mia routine in virtù del modo in cui eseguo la suddivisione degli impulsi, avrò intervallo di tempo nella peggiori delle ipotesi, dodici volte maggiore, in avanzamento e due volte maggiore in filettatura.

Matteo: Ho scritto esattamente quello che hai capito, nel nostro caso l'evento che genera l'interruzione è di tipo ricorrente. Nel caso dei fulmini e di tipo random.
Per me un evento è di tipo random quando tutti i fattori che incidono sul risultato non possono essere definiti.
Nel nostro caso invece avremo sempre la possibilità di determinare con buona precisione (ovviamente non sarà mai una precisione assoluta), il tempo minimo che intercorre tra un evento e quello successivo.
Ora se pensi che il segnale prodotto dall'encoder sia di tipo random, spiegamene il motivo sono pronto a ritrattare tutto quello che ho scritto.

Mi pare di sentire rumore di unghie sui vetri, mi sbaglierò...

Siamo qui in 4 a dirti che stai sbagliando sulla questione del random e, magicamente, torniamo a parlare di condizioni nelle routine di interrupt... vaaaaaaa beeeeneeee!

massimo:"L'interrupt esiste per un solo motivo, per dare la possibilità ad un micro di poter eseguire più operazioni contemporaneamente"
Mai detto il contrario. Nel caso specifico l'operazione in questione (oltre al normale flusso) è la lettura di un ingresso che cambia di stato in modo RANDOMICO. Senza l'interrupt dovrei stare continuamente a controllare il pin e non potrei fare nient'altro.
Quindi ? Che incredibile contenuto tecnico hai apportato a questa discussione che si, a questo punto, sta diventando un po' sterile ?

Massimo:"Quando parli di simmetria rispetto a cosa?"
Rispetto al tempo ... sai, se dobbiamo leggere una segnale a qualche kilohertz (o qualche decina) è un parametro importante....

Massimo:"Ripeti come un mantra le stesse cose senza argomentare"
azz.... e meno male, già mi fa male la mano così a furia di scrivere, pensa se argomentavo!

Massimo:"Non ho mai scritto che è possibile conoscere il valore assunto in un preciso istante nel tempo dal segnale prodotto dall'encoder, ma piuttosto che possiamo determinare con una buona precisione"
qui il rumore delle unghie aumenta.. sarò io?
Aspetta che ti cito ancora:
Massimo:"Ma nel caso dell'encoder lo puoi sapere con precisione assoluta, dipende dalla velocità di rotazione e dal numero di impulsi a giro"

Quindi siamo passati da una "precisione assoluta" a una "buona precisione" nel giro della stessa giornata. Record personale! L'altra volta ci avevi messo un paio di giorni! Se aspettiamo domani la precisione diventerà scarsa... che poi è quella giusta

Massimo:"Ora se pensi che il segnale prodotto dall'encoder sia di tipo random, spiegamene il motivo sono pronto a ritrattare tutto quello che ho scritto."
Questa era per Matteo ma facciamo rispondere il nostro amico Eugenio da Rovigo:
Eugenio:" l'impulso encoder deve essere reputato random perché per motivi diversi la velocitá del mandrino puó cambiare: sbalzi della tensione di rete, materiale da filettare non omogeneo che induce oscillazioni nella velocitá del mandrino, scheggiatura utensile, etc..."
Potrei aggiungere altro ma ho già detto quello che dovevo dire e sono stufo di ripetermi come un disco rotto. Leggi bene tutto il thread prima di rispondere, per favore.

Massimo:"Da come mi poni le domande, mi hai deluso, sono sempre più convinto che ti mancano le nozioni di base"
azz, mi hai beccato! E' da 6 anni e 95 pagine che sono su questo thread e non se n'era mai accorto nessuno
Vabè, è stato bello finchè è durato!

ah, un'ultima cosa, le domande qui sei tu che le fai a me, e poi mi contesti TUTTE le risposte. Io non ti ho mai chiesto niente... così per chiarire.

Scusate se mi intrometto brevemente nel discorso, spero di non alzare un vespaio...

mimoletti dice: <L'interrupt esiste per un solo motivo, per dare la possibilità ad un micro di poter eseguire più operazioni contemporaneamente.
Questo è l'unico motivo per cui esiste l'interrupt.>

questo è errato, l'interrupt ha la precisa e unica funzione di interrompere il corrente flusso di esecuzione e far saltare il program counter alla routine che in gergo tecnico si dice che serve l'interrupt (ISR). Terminata l'esecuzione l'esecuzione del programma riprende da dove era stata interrotta. Punto.

Dire che dia la possibilità al micro di eseguire più operazioni contemporaneamente è falso ed impossibile da realizzare, qualunque sistema si usi per gestire più task contemporaneamente, sia che lo si faccia attraverso un loop nel flusso di codice principale (round robin) che con un'interruzione gestita da un interrupt periodico magari anche tenendo conto del livello di priorità dei task come nei RTOS, l'esecuzione dei diversi task non sarà mai realmente contempranea.
Solo da un punto di vista a lungo termine si potrà avere sensazione che lo sia, ed è realmente ciò che serve avere nella pratica, ma attenzione ad avere sempre ben chiaro il concetto che non sono realmente operazioni contemporanee.

L'utilizzo che si fa dei vari interrupt è solamente una questione di architettura del programma, relegarli a ruoli precisi e schematizzati è riduttivo e controproducente
Ogni programmatore ha il libero arbitrio di usarli al meglio e con fantasia, e anche il concetto che le ISR devono essere concise e brevi, pur essendo una raccomandazione che si fa spesso ai principianti, è un cocetto che dipende molto dal contesto applicativo e dall'architettura del programma.
Quello che puo essere critico per un progamma che lavora in real time, può essere accettabilissimo in un contesto diverso come in un data logger, dove i tempi sono enormemente più dilatati rispetto al ciclo di esecuzione delle istruzioni del micro.
E' respnsabilità del programmatore adeguare il prorio codice al contesto nel migliore dei modi, e per farlo bene serve una cosa che si chiama "esperienza" più che di regoline generali.

Anche sul discorso che faceva Max sugli eventi interrupt da lui chiamati random, devo dire che non ha torto, anche se la parola random, forse non è la più azzeccata.

Dal punto di vista dell'esecuzione di un programma, tutto quello che viene eseguito e gestito all'interno del main program va considerato avente carattere periodico, mentre quello che viene gestito attraverso gli interrupt e ISR, ha carattere aperiodico.

Il fatto che una sorgente di eventi, come è in questo caso l'encoder, abbia una cadenza periodica non significa nulla dal punto di vista del meccanismo di gestione dell'interrupt e dell esecuzione del codice della ISR associata, sarà sempre da considerare un evento aperiodico.
Questa cadenza periodica potrà invece avere benissimo una logica dal punto di vista dell'architettura del programma stesso, ma questo però è un aspetto che non riguarda direttamente l'interrupt in quanto tale.

Bisogna stare attenti ad avere ben chiari questi aspetti per evitare di fare confusione altrimenti vien fuori una discussione tra sordi che si protrae all'infinito

Spero di essere stato utile e scusate la forse eccessiva pignoleria, ma un pochina a volte serve.

Grazie Alberto per essere intervenuto ci aiuterai a chiarire le idee.

Ha perfettamente ragione, con l'interrupt abbiamo la sensazione che stia compiendo più operazioni in contemporanea ma in realtà, lui sospende la routine principale, di fatto. Peccato hai smontato l'unica cosa su cui io e Max eravamo d'accordo.
Ho solo un dubbio: nel mio caso quando utilizzo il Timer per contare gli impulsi non sospendo la routine principale, neanche in quel caso possiamo asserire che il micro stia compiendo due operazioni contemporaneamente?

Durante i mie messaggi ho sostenuto le seguenti affermazioni:

1) Che non possiamo conoscere il valore del segnale in uscita all'encoder in un'istante di tempo ben preciso, ma invece è possibile calcolare con precisone il tempo minimo che intercorrerà tra un fronte di salita e quello successivo, a patto di conoscere la velocita di rotazione e il numero di impulsi a giro dell'encoder.

2) La routine di interrupt deve essere il più breve possibile, ma non esiste una durata ottimale, dipende dalla frequenza degli eventi che vogliamo seguire.

3) Non è corretto dire che non si devono usare gli IF all'interno della routine. L'importante e rispettare la regola precedente.

4) La durata della routine non influisce sulla stabilità del codice, ma solo sulla frequenza massima che potranno avere gli eventi che vogliamo seguire.

Sono corrette le mie affermazioni?

Grazie mille.

mimoletti: "con l'interrupt abbiamo la sensazione che stia compiendo più operazioni in contemporanea ma in realtà, lui sospende la routine principale, di fatto. Peccato hai smontato l'unica cosa su cui io e Max eravamo d'accordo"
La sensazione forse ce l'avevi tu. Per quanto mi riguarda non ha smontato proprio niente! Il concetto di task e di priorità a me è sempre stato molto chiaro... non so come potessi pensare che fossimo d'accordo su una roba del genere.
Mi ri-cito da solo, giusto per chiarire (eh si perché adesso di passare anche per il coglione di turno non ne ho nessuna voglia):
McMax 22/11/2021 00:51: "Con l'interrupt sono sicuro che qualsiasi cosa io stia facendo in quel momento, il programma darà precedenza (o priorità) all'evento di interrupt fermando temporaneamente l'esecuzione del resto del codice"

25/11/2021
mimoletti ore 09:50: "Ma nel caso dell'encoder lo puoi sapere con precisione assoluta, dipende dalla velocità di rotazione e dal numero di impulsi a giro"
mimoletti ora 17:06: "ma piuttosto che possiamo determinare con una buona precisione, l'intervallo di tempo nella peggiore delle ipotesi, tra un'interruzione e quella successiva"
mimoletti ore 20:52: "1) Che non saremo mai in grado di conoscere il valore del segnale in uscita all'encoder in un'istante di tempo ben preciso."

Ho fatto un'errore, avevo detto che saremmo arrivati a domani.... non ce l'abbiamo fatta.

Sinceramente mi sento un po' preso per il cubo, ed onestamente a sto punto fatico a capire dove stai andando a parare. Il topic è stato riacceso da Matteo che sta studiando il mio codice per imparare e per cercare di migliorarlo, e ben venga! Non ho capito cosa c'entri tu in tutto questo ? Perché ti devi sempre infilare ogni volta nei discorsi per poi finire a parlare del tuo codice, della tua routine, di come fai tu questo, di come fai tu quello ?
Anche la questione dell'evento random, che a sto punto mi pare veramente di lana caprina ma molto molto fine, perché diavolo l'hai tirata fuori ? Stai dicendo tutto e il contrario di tutto, nell'arco della stessa giornata, e il bello è che continui imperterrito a farlo anche dopo che ti viene fatto notare.
E io sono certo che anche ora troverai il modo di rigirare la frittata... e io sempre più stronzo che continuo ancora a darti retta!

Molto volentieri cercherò di darti il mio punto di vista, in un ottica generale, con la speranza che sia utile a tutti.

<quando utilizzo il Timer per contare gli impulsi non sospendo la routine principale, neanche in quel caso possiamo asserire che il micro stia compiendo due operazioni contemporaneamente?>

La risposta è ovvia, se consideriamo il microcontrollore nel suo insieme, tutte le periferiche, che sono puramente hardware, sono concepite per lavorare in modo indipendente dal flusso del programma; conseguentemente la lettura dei registri di qualsiasi periferica può avvenire in polling ma anche allo scatenarsi di un determinato evento, come per esempio un comparatore di un timer, che lancia il suo interrupt.
Quando in polling vai a leggere un contatore non possiamo dire che il programma esegue due task contemporaneamente ma il micro nel suo insieme ha molte periferiche hardware che lavorano in parallelo all'esecuzione del programma.
E' la differenza che passa tra una MCU e una MPU come per esempio il processore dei PC.

<1) Che non saremo mai in grado di conoscere il valore del segnale in uscita all'encoder in un'istante di tempo ben preciso>
Non vedo perché no, gli impulsi di un encoder hanno un durata finita, se sul fronte viene generato lun interrupt e con quello andassimo a leggere i pin dell'encoder avremmo la fotografia dello stato delle sue uscite in quel momento.
Ma in realtà penso che tu volessi alludere al valore dell'encoder inteso come valore di conteggio accumulato nel contatore di una periferica.
In quel caso dipende come lo vai a leggere, se lo leggessi in polling, mancando una sincronizzazione tra gli eventi di scrittura del contatore e la lettura da parte del programma, la certezza matematica di leggere il conteggio attuale viene a mancare anche se poi in pratica potrebbe essere anche una cosa trascurabile, perche con le letture successive non si ha mai un errore cumulativo. La criticità di questo approccio come sempre dipende dalla situazione.
Se invece leggessi l'accumulatore tutte le volte che l'uscita dell'encoder cambia di stato attraverso l'interrupt da essa generato, saresti sicuro di leggere esattamente il valore attuale del conteggio.

<2) Invece è possibile calcolare con precisone il tempo minimo che intercorrerà tra un fronte di salita e quello successivo, a patto di conoscere la velocita di rotazione e il numero di impulsi a giro dell'encoder.>
Se hai una periferica timer con sufficiente risoluzione e un clock di periferica di almeno 3-4 ordini di grandezza più veloce della frequenza che devi misurare puoi senz'altro fare questo tipo di misura con una buona precisione usando l'input capture del timer. Non ti serve sapere la velocità di rotazione dell'encoder, anzi è proprio attraverso la misura del periodo tra i due fronti che determineresti con precisione la velocità di rotazione.

3) La routine di interrupt deve essere il più breve possibile, ma non esiste una durata ottimale, dipende dalla frequenza degli eventi che vogliamo seguire.
4) Non è corretto dire che non si devono usare gli IF all'interno della routine. L'importante e rispettare la regola precedente.
Anche in questo caso vale il buon senso, non esistono regoline da applicare senza capire bene il contesto e quello che potrebbe accadere.
Sicuramente se hai molti interrupt che si succedono a frequenza sostenuta bisogna rendersi conto che di tempo per l'esecuzione del main program ne rimarrà poco e questo potrebbe per esempio rallentare l'interfaccia utente fino a renderla inutilizzabile.
In genere si cerca di mettere nelle ISR lo stretto indispensabile, ma non si deve diventar matti a togliere per forza le strutture di controllo di flusso di programma come gli if o i while... Se nella ISR c'è bisogno un loop bisogna considerare quante volte si ripete pensando che il tempo di esecuzione del corpo viene moltiplicato. In genere le iterazioni si cerca di evitarle ma a volte un loop per esempio per inizializzare un piccolo array, porebbe essere accettabile.
Comunque il discorso potrebbe essere lungo e convolge altri aspetti che nel vostro caso possiamo sicuramente sorvolare.

5) La durata della routine non influisce sulla stabilità del codice, ma solo sulla frequenza massima che potranno avere gli eventi che vogliamo seguire.
In senso stretto è vero però bisogna capire che cosa si vuol intendere per stabilità del codice... Quando si parla di frequenza massima degli eventi da seguire, bisogna tener conto di lasciare un po' di tempo anche alle altre parti di del programma che comunque devono girare. Non può essere eseguito soltanto il codice delle iSR.
Se una ISR è lunga sicuramete non succede nulla all'integrità del codice del main program, nel senso che non crasherà però potrebbero verificarsi effetti collaterali spiacevoli nell'applicazione, come lentezze varie o una reattività scarsa o discontinua nell'interfaccia utente che porterebbero ad un funzionamento insoddisfacente dell'applicazione.

Ragazzi datevi una calmata, questi battibecchi non fanno bene a nessuno e il forum così non va da nessuna parte...

Alby, io è da 6 anni che sopporto questi attacchi e onestamente ne ho anche un po' le palle piene. A me va bene tutto ma quando mi si prende per il cubo non ci sto. Se dici una cosa e te la rimangi due messaggi dopo a me girano e io non ci posso fare nulla.
Se sbaglio, e lo faccio tante volte, lo ammetto. Non cerco di girare la frittata pensando di avere a che fare con degli idioti funzionali che si bevono tutte le cagate che sparo.

La calmata me la darò, ma non adesso.

Non Max non ti sto prendendo per il cubo. Ma come succede anche a te, quando leggo delle castronerie, non riesco a tenere le dita ferme. E grazie ad Alberto ho capito cosa intendevi quando mi scrivevi:

Dal punto di vista del micro, su questo hai ragione, gli eventi vanno considerati "Random".

Se sbaglio non ho nessun problema ad ammetterlo.

Durante tutta la discussione abbiamo avuto due tesi contrapposte:

Max@: La tua sostiene che la routine di interrupt debba necessariamente essere il più breve possibile pena l'instabilità del sistema come l'uso degli IF all'interno di essa. E che debba essere simmetrica, ossia avere sempre la stessa durata pena anche in questo caso l'instabilità del sistema.

Massimo@: La mia invece sostiene che la routine è bene che sia il più breve possibile, ma non esiste una durata ideale, dipende dalla frequenza degli eventi che vogliamo seguire e che non c'è nessuna contro indicazione nell'usare degli IF all'interno di essa. E che non deve necessariamente avere una durata costante e quindi detto alla tua maniera può essere anche asimmetrica.

Quindi ricapitolando:

1) Una durata più o meno lunga della routine non influisce sulla sua instabilità.
2) L'uso degli IF non influisce sulla stabilita del sistema.
3) La routine non deve essere necessariamente "simmetrica", pena l'instabilità del sistema.

Volendo condensare quanto ha scritto da Albi la tua tesi è errata.

PS.

25/11/2021
mimoletti ore 09:50: "Ma nel caso dell'encoder lo puoi sapere con precisione assoluta, dipende dalla velocità di rotazione e dal numero di impulsi a giro"
mimoletti ora 17:06: "ma piuttosto che possiamo determinare con una buona precisione, l'intervallo di tempo nella peggiore delle ipotesi, tra un'interruzione e quella successiva"
mimoletti ore 20:52: "1) Che non saremo mai in grado di conoscere il valore del segnale in uscita all'encoder in un'istante di tempo ben preciso."

E' chiaro che se prendi delle parti a caso possa sembrare che mi contraddico ma non è cosi:

Ho sempre sostenuto che vista la fonte possiamo conoscendo la frequenza massima di rotazione, del nostro mandrino, calcolare con assoluta precisione l'intervallo minimo che avremo tra un fronte di salita e quello successivo, lo detto e ripetuto svariate volte. Ma non potremo mai conoscere il valore del segnale in uscita in un'istante di tempo ben preciso.
Sono due concetti diversi che assolutamente non si contradicono, forse nel modo in cui li ho esposti sono un pò difficili da comprendere.
Un conto è capire le cose un' altro è spiegarle. Nel fare la seconda sono un pò meno bravo. Per questo chiedo venia.

Fare un confronto diretto delle soluzione utilizzate, come state facendo, non ha molto senso perché sono due micro diversi
con periferiche diverse e il firmware è stato pensato da persone diverse ognuna con le proprie esperienze alle spalle.
Non c'è mai una sola strada per raggiungere un determinato risultato, e anche l' asserire che ce n'è sicuramente una migliore di tutte
mi sembra una sciocchezza.

I due sistemi funzionano bene entrambi e questo è comprovato da decine di realizzazioni e utilizzatori soddisfatti, di conseguenza il firmware
è da ritenersi maturo da ambedue le parti.
Che poi ci possano essere ulteriori margini di miglioramento è probabile, ma vale per ogni realizzazione a questo mondo.

Alla prova dei fatti non ritengo che si possa asserire che uno dei due approcci all' architettura del firmware sia inferiore all'altro e viceversa, altrimenti
bene o male, si sarebbero verificati bug e/o limiti di funzionamento che a quest'ora sarebbero sicuramente noti.
Un vecchio detto recita che il software buono è quello che funziona...

Al limite ci si potrebbe dilungare nel confrontare i due sistemi a livello di funzionamento nelle condizioni limite
ma sinceramente non credo sia un tema che appassionerebbe qualcuno.

A me non interessa stabilire quale dei due programmi funziona meglio. La cosa che mi ha appassionato è stato il confronto intellettivo. Solo che tutte le volte che gli proponevo una soluzione differente dalla sua, mi rispondeva: Non si fa perché rende il codice instabile, fino ad arrivare al matematicamente impossibile.

Blocco il thread perche' si sta uscendo dal seminato.

Se qualcuno ha qualcosa da aggiungere puo' sempre contattarmi in privato.

Concordo !