MECCANICA e DINTORNI

In un ambiente di esecuzione uniprocesso, ovvero dove non ci sono processi concorrenti, come è quello di arduino
basta usare le classiche pseudofunzioni sei() e cli().



Per "non atomic code" si intende un operazione che richiede per la sua esecuzione più di un ciclo macchina, com'è la lettura o la scrittura di una long.

Personalmente non ho mai usato arduino, però col compilatore IAR, mi ricordo che funzionavano senza problemi.
Casomai c'è da approfondire un'attimo la questione di cosa succede dopo l'esecuzione della sei(); se non ricordo male
l'istruzione successiva alla sei() viene sempre eseguita anche se c'è un interrupt in attesa (pending interrupt)

edit:
forse la cosa migliore per evitare problemi è far seguire la sei() da un'istruzione NOP, che però mi sa che non è presente come pseudo funzione e va scritta in asm
__asm__ __volatile__ ("nop\n\t"); oppure meglio creare una macro:

Guardando in giro ho visto che è stat creata una libreria per arduino che implementa delle macro
per l'esecuzione di blocchi di codice in modo atomico
https://www.arduino.cc/reference/en/libraries/simplyatomic/
all'attro pratico dovrebbe essere la stessa cosa della critical section vista prima ma arrangiata in forma di
macro

uhm, interessante. Quindi se disabilito gli interrupt ma l'evento che causerebbe l'interrupt avviene, questo non viene perso ma viene accodato.
Devo approfondire (la prima domanda e': quanti interrupt possono venire accodati nell'atmega328?), adesso cerco info.
Ok, trovato. Un solo interrupt per tipo che verra' eseguito in ordine di importanza (ad esempio un interrupt esterno ha precedenza rispetto a un interrupt generato dal match di un timer).

Per quanto riguarda la macro sei() viene eseguita l'istruzione successiva anche se ci sono interrupt in coda.
Ed e' vero che, nell'ambiente avr, non c'e' un'istruzione nop (ma come dice albi basta creare una macro).

La macro ATOMIC_BLOCK() e' gia' inclusa nell'ambiente avr ma, appunto, funziona solo sulla famiglia avr. Visto che l'ambiente arduino si e' ampliato (ad esempio coi sam di arduinoDue) qualcuno ha creato la libreria simplyatomic per rendere la macro valida anche per altre famiglie di processori.
Qua spiega cosa fa in piu' la macro rispetto a cli()....sei()
https://blog.oddbit.com/post/2019-02-01 ... n-avrlibc/

Si ma a meno che non ti metti ad usare i goto, cli() sei() ti basta e avanza.

<<Ok, trovato. Un solo interrupt per tipo che verra' eseguito in ordine di importanza>>

Esatto, ogni interrupt ha il suo (e unico) flag, quindi quando risulta pending ed è impossibile determinare se l'evento è occorso più volte,
e la sua ISR verrà eseguita una sola volta.
I micro AVR non hanno la possibilità di variare la priorità degli interrupt, come per esempio e possibile fare con gli arm.

Da notare che ATOMIC_BLOCK() usa come costrutto base un ciclo for() eseguito per una sola volta ma che richiede l'uso di una variabile addizionale
nascosta nella macro.
@matteou poi provare ad usarla, anche solo per curiosità, ma per quello che era il tuo scopo, concordo con umbez sul fatto che sei() e cli() siano sufficienti,
e secondo i miei gusti anche più leggibile come codice.

Ho ricordi di quand'ero ragazzino e cercavo di imparare il basic che usare il goto e' un po' la sconfitta del programmatore.
Da quello che leggo anche adesso, il goto sarebbe meglio non usarlo.

Comunque son d'accordo anch'io che cli() e sei() siano piu' eleganti e immediati.
Nel mio programma non ho piu' necessita' di usare sezioni critiche. Ho riscritto parte del programma in modo che le variabili incriminate non venissero modificate dall'interrupt.
Devo finire di sistemarlo (commentarlo) e poi lo pubblico.

Una domanda, avevo gia' provato a cercare ma senza successo. Il _ a cosa serve?
Ad esempio _BV() e' la macro (o comando) che e' fatto cosi' oppure il simbolo _ ha uno scopo?
E il doppio __ ? Ad esempio __asm__ __volatile__ ("nop\n\t");
L'ho sempre associato ai comandi assembly inseriti nel programma c ma non sono granche' convinto.

Provengono dallo standard c++ ad esempio nell'11 la regola di nomenclatura per le macro su scope globale è underscore+all capital letter.. doppio _ non ricordo a che regola fa riferimento. Prima che lo chiedi _t su determinati tipi proviene dallo standard POSIX.
...ma davvero ti interessano ste robe?

Si che mi interessano.
Capito la spiegazione (cercando un po' con i termini che hai usato), grazie.
Alla fine sono regole per evitare che i nomi (macro-variabili-ecc...) si ripetano.

@ McMax: nel tuo programma incrementi il conteggio degli impulsi encoder in una variabile long che poi vai a verificare nel main.
E' come avevo fatto io (io incrementavo la posizione del carro), non rischi di incorrere nello stesso problema?
Poi perche' hai usato questo: absolute_encoder_steps = one_turn_mandrel_steps/2; se ho capito giusto, tu aspetti mezzo giro di mandrino prima di prendere il sincronismo e partire per la prima volta.
Non riesco a capirne lo scopo.

non ricordo bene perché avevo previsto questa attesa.... probabilmente pensavo fosse meglio intercettare l'index piuttosto che farlo partire direttamente da li. Chiaramente il mezzo giro non è vincolante, può essere anche meno o di più, l'idea era quella di avere nella condizione di partenza già il controllo sull'index piuttosto che darglielo pronto.

E per la variabile long absolute_encoder_steps che incrementi nell'isr e controlli nel main, non rischi di avere letture falsate?
Vero che fai una una divisione con resto (meno probabilita' che dia risultato sbagliato anche se la variabile viene modificata) pero' il rischio c'e'

No Matteo attenzione, io non controllo una variabile long mentre filetto ma una int (steps). Effettivamente c'è una variabile long (absoute_steps, riferita ai passi motore stepper), ma il suo incremento o decremento non avviene ad ogni lettura encoder bensì ogni tot in funzione del passo. Nel caso peggiore (1 passo stepper per ogni passo encoder) verrebbe gestita ad ogni passo ma è una condizione più unica che rara e comunque potrebbe dare problemi solo a velocità elevata. Ma un filetto che richiede un passo stepper ad ogni passo encoder è un passo lunghissimo quindi non si potrebbe filettare veloce in ogni caso.

La divisione a modulo a cui ti riferisci viene fatta su absolute_encoder_steps per attendere l'index del mandrino quindi in quel momento specifico non sto filettando: il codice attende che quel while diventi vero, ovvero quando il resto è uguale a 0 ho intercettato l'index, quindi esco dal while ed inizio la filettatura iniziando a decrementare i passi comparati con le celle dell'array (lookup table).

Si, avevo capito il funzionamento.
Pero' controlli due variabili (mi ero dimenticato di steps) che vengono modificate all'interno di un isr.

Se ho capito giusto, il micro carica nei registri 8bit alla volta. Carica i primi 8 bit, arriva un interrupt che modifica quella variabile, il micro non lo sa e continua a caricare i byte mancanti.
Ti ritrovi un byte vecchio e il resto dei byte nuovi, quindi un valore casuale.
Sbaglio ragionamento?

no non sbagli.

"non ricordo bene perché avevo previsto questa attesa.... probabilmente pensavo fosse meglio intercettare l'index piuttosto che farlo partire direttamente da li. Chiaramente il mezzo giro non è vincolante, può essere anche meno o di più, l'idea era quella di avere nella condizione di partenza già il controllo sull'index piuttosto che darglielo pronto."

Sincronismo ?!
Un po' come ha fatto il tipo per sincronizzare lo stepper con l'albero fresa nella creazione degli ingranaggi ?
Se parti di botto potrebbe essere che lo stepper non riesca a seguire il mandrino istantaneamente...
Il tipo ha fatto fare una accelerazione rapida allo stepper per poi scendere alla velocità giusta della fresa , ma secondo me , il tuo sistema (pausa iniziale ) è altrettanto valido

Uhm no, non c'entra niente. McMax aspetta mezzo giro per essere sicuro di intercettare l'index. Una volta intercettato l'index, lo stepper parte a piena velocita'.

Correggetemi se sbaglio ma mi sembra che la criticita' nel codice di McMax possa essere "subdola" (nel senso che, in caso di problemi, e' difficile da trovare il colpevole).
Nel mio programma, ho avuto gioco facile perche' l'unico modo per uscire dal ciclo while di filettatura era che il conteggio dei passi fatti fosse maggiore o uguale al limite imposto.
Stabilito che l'if fosse scritto giusto e che la variabile non venisse modificata accidentalmente in altre parti del programma, l'unica opzione rimasta era che l'interrupt accadesse mentre controllavo la variabile che l'interrupt stesso stava riscrivendo (ipotesi confermata dal simulatore).
In piu', stabilendo che deve essere >= l'errore si presentava abbastanza spesso. Probabilmente se avessi messo solo la condizione == il problema sarebbe stato piu' raro ma piu' disastroso (lo scopo di usare il >= era proprio voler evitare di perdere, per qualsiasi ragione, il finecorsa. Usando solo l'uguaglianza, sarebbe stato piu' difficile che la variabile "corrotta" fosse proprio uguale al valore di finecorsa. Pero', nel malaugurato caso in cui l'interrupt modifica la variabile giusto quando l'uguaglianza sarebbe stata vera, avrei saltato il finecorsa e il carro avrebbe continuato a correre, schiantandosi contro il pezzo o il mandrino).

Per come e' strutturato il programma di McMax le probabilita' che ci siano risultati imprevisti e' abbastanza bassa.
Nel caso della variabile absolute_encoder_steps, dovrebbe assumere un valore che nella divisione dia riporto 0 (abbastanza improbabile).
Nel caso della variabile steps, potrebbe succedere che salti un'uguaglianza ma si traduce in un errore di un passo, poca cosa.