ELS (Electronic Lead Screw) - progetto con ARDUINO

[matteou]

Tutto quello che c'e' nel ciclo for fa parte della routine di interrupt.
NON e' il codice della vite elettronica ma solo dell'interrupt, messo dentro un ciclo for per misurarne la velocita' (salvo micros() in una variabile, faccio girare 100 mila volte il codice che voglio testare, alla fine sottraggo micros() a quello che avevo letto e ottengo il tempo che ci ha messo ad eseguire il ciclo for. Divido per 100.000 e ottengo il tempo che ci mette a fare il pezzo di codice che mi interessa testare).

A scanso di equivoci, ti allego il codice completo.
Si, in effetti leggo un canale dell'encoder in pooling all'interno dell'interrupt. Ma tramite la lettura diretta dei registri (vedi il define di DREAD) e' abbastanza veloce.

Per quanto riguarda la funzione firestep() diventata un #define, non sapevo si chiamassero macro.
L'ho messa cosi' perche' analizzando il codice con Mecha mi aveva fatto notare che chiamavo una funzione all'interno di un interrupt (e si pensava potesse rallentare l'esecuzione dell'interrupt).
In realta' non cambia nulla, la velocita' e' praticamente la stessa (evidentemente il compilatore fa gia' una buona ottimizzazione).
Ho lasciato lo stesso nome firestep() solo per comodita' di non cambiare il nome all'interno del codice, avrei potuto chiamarla SPARAunCOLPO che il concetto non sarebbe cambiato (o, meglio, sostituire firestep() con TCNT1=65533; ma visto che lo fa gia' il compilatore al posto mio ho risparmiato fatica)

[umbez]

Ti do i miei 2 cent professionali, ma poi il codice è tuo e fai come preferisci. Ciò che hai fatto con la macro non si fa semplicemente perché non è parlante. Soprattutto con arduino che splitta il codice in più file. Se hai in 10 file diversi quella chiamata, un altro programmatore che leggerà il tuo sorgente non capirà mai che stai facendo al primo sguardo, e lo costringi ogni volta a cercarla per capire. In generale, non nel tuo caso perché non ho visto il tuo codice, funzioni e soprattutto variabili devono essere parlanti, non k j x o kmix() scrivi() leggi() ecc..sono regole di buonsenso, come il camelCase o gli _ prefix nelle variabili private delle classi, che velocizzano la manutenzione del codice...

[matteou]

Chiaro. Sapevo già di questa regola ma sul momento il nome della variabile/funzione/macro/ecc... mi sembra sensato e chiaro. Poi mi accorgo che neanche io capisco cosa ho scritto.
Nel caso specifico la funzione (poi diventata macro per provare) è abbastanza chiara. La sua funzione è sparare un impulso di step e McMax, giustamente, l'ha chiamata firestep.
Comunque io sono autodidatta e pasticcione, il mio codice è scritto male e commentato peggio. Me ne rendo conto quando, a distanza di tempo, devo rimettere mano al codice. A volte ho preferito ricominciare da capo piuttosto che cercare di capire cosa ho fatto...

[PierluigiP]

Mimoletti hai recuperato il programma per Mega? Se non puoi allegarlo non fa niente... Quale sarebbe il programma del russo? È gratis?
Grazie

[mimoletti]

Non ancora, non ci siamo incontrati. Prova con quello del russo.

[PierluigiP]

Link al russo? Grazie

[McMax]

Matteou, mi piacerebbe capire come mai vuoi eseguire tutto quel codice sotto interrupt ma senza commenti, scusami, non riesco a seguirlo.
Una prima considerazione che faccio è che io non farei mai una routine di interrupt così complicata e soprattutto così lunga. L'nterrupt per definizione deve essere una singola azione che non può essere ritardata dal resto del codice. Nell'applicaizone specifica del ELS l'interrupt deve essere la lettura dell'encoder che, come output, deve avere un incremento o un decremento di passo. Tutto il resto non è prioritario e deve essere eseguito al di fuori della routine di interrupt.

Altra cosa che non capisco è perché vuoi tenere sotto interrupt un solo canale dell'encoder e leggere l'altro in polling (anche se questo non è un polling ma un semplice controllo) solo per determinare la direzione. Tra l'altro, così facendo, sfrutti solo la risoluzione nominale dei passi e non x4. Cioè in pratica stai facendo fare al micro quello che normalmente si fa fare esternamente ad un flip-flop, ovvero una logica a stati hardware che costa niente ed è molto più veloce di un codice.... non mi pare molto efficiente.
Ragiona sul fatto che la routine di interruppt ti serve solo per intercettare il passo dell'encoder istantaneamente, tutto il resto è conseguenza di quel passo ma non dovrebbe essere fatto nella routine di interrupt.

Questa è la mia, con i tempi di esecuzione stimati (il calcolo fatto usando il clock di arduino micros() o millis() non è molto affidabile)

Codice: Seleziona tutto

void InterruptEncoderFilettatura() 
{
static byte prev_encoder; //definizione di variabile byte (1 ciclo di clock: 62,5 nanosecondi) 
byte port; //definizione di variabile byte (1 ciclo di clock: 62,5 nanosecondi) 

port = PIND & B00001100; //and logico tra due byte e trasferimento indiretto (3 cicli di clock: 187,5 nanosecondi)
port |= prev_encoder; //or logico tra due byte e trasferimento indiretto (3 cicli di clock: 187,5 nanosecondi)
steps += encoder[port]; //addizione tra due valori e trasferimento indiretto (3 cicli di clock: 187,5 nanosecondi)
absolute_encoder_steps += encoder[port]; //addizione tra due valori e trasferimento indiretto (3 cicli di clock: 187,5 nanosecondi)

port >>= 2; //shift a destra di due posizioni (2 cicli di clock: 125 nanosecondi)
prev_encoder = port; // load indiretto di 1 byte (2 cicli di clock: 125 nanosecondi)
step_flag = true; // cambio di stato logico di variabile boolean (1 ciclo di clock: 62,5 nanosecondi)
} //END of the Interrupt Service Routine

I calcoli sono stimati tenendo conto del clock di Arduino UNO a 16Mhz (62,5ns a ciclo)
In totale sono 1187,5 ns. Ovvero 1,1875 us.
Stiamo larghi e consideriamo anche il tempo di chiamata e push/pop dallo stack, direi che in 2us facciamo tutto comodamente.
Mi pare strano che la tua impieghi solo 4us, anche considerando che se fai operazioni tra variabili a 16 bit impieghi molti più cicli.

[matteou]

Adesso sono sul telefono e mi fa fastidio scrivere troppo, quindi rispondo velocemente.
McMax, non sono d'accordo. La lettura dell'encoder e la generazione degli step devono avere la stessa priorità. Se la mia routine riesce a leggere tutti i passi di encoder ma il resto del programma non riesce a generarmi tutti gli step sono fregato al pari di perdermi un impulso di encoder (carro e mandrino non saranno più in Sincro in entrambi i casi).
Quindi tanto vale mettere tutto nella routine di interrupt o sbaglio ragionamento?
Al banco sembra funzionare ma la prova è da fare sul tornio (spero prossimi giorni).
Al resto rispondo dal PC, molto più comodo

[McMax]

No Matteou non sbagli ragionamento, il tuo è un errore di concetto.
Ricordati sempre che stai programmando un microcontrollore, non un codice che gira su un PC con dietro un sistema operativo col suo livello di astrazione dell'hardware. Qui è l'hardware che devi controllare, e sono i tempi di reazione dell'hardware quelli a cui ti devi adattare.
Iniziamo col capire come mai ti serve un interrupt: essenzialmente per intercettare un input (encoder) a prescindere da cosa il codice stia facendo in quel momento. Senza l'interrupt la lettura dell'encoder andrebbe fatta in polling, ovvero restando ad "ascoltare" i pin di ingresso encoder in attesa del momento in cui cambiano di stato. Ma questa operazione è assolutamente inefficiente visto che:
- ci costringe a stare in un loop dove a cadenza regolare devo controllare lo stato degli ingressi
- non è detto che ci faccia intercettare l'evento nel momento stesso in cui avviene: se ad esempio sto facendo altro e l'encoder cambia di stato potrei accorgermene in ritardo fino al caso in cui mi perdo addirittura l'evento perché mentre avveniva i codice stava facendo altro.
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. Ma attenzione, l'evento di interrupt NON evita la normale esecuzione del programma, semplicemente la ritarda.
Ma cosa succede se stai eseguendo la routine di interrupt e si genera un altro evento che dovrebbe generare un interrupt? semplice: te lo perdi! La chiamata all'interrupt attiva un flag che si resetta solo quando la chiamata termina, quel flag evita che un altro interrupt possa interrompere l'esecuzione dell'interrupt corrente quindi, mentre sto gestendo un interrupt, non ne posso gestire un altro. In realtà non è del tutto vero perché esistono anche interrrupt a diversa priorità che si possono chiamare uno sull'altro (si chiama "nesting") ma direi che siamo fuori scopo con un microcontrollore così modesto.

Tutto questo per dire che l'interrupt deve essere un'eccezione, un evento prioritario non mascherabile che si genera e si deve esaurire nel più breve tempo possibile.
Non so che lavoro tu faccia ma immagina che il tuo capo ti dia 10 lavori da fare: di questi ce ne saranno alcuni più urgenti rispetto ad altri, e magari uno o due più urgenti di tutti. Normalmente assegni le priorità corrette ed esegui subito i più urgenti per poi passare a quelli meno urgenti e poi ai meno urgenti ancora. Ma se a certo punto diventassero tutti urgenti sarebbe uguale ad averli tutti non urgenti visto che avrebbero tutti lo stesso livello di priorità! Ed a quel punto a cosa ti servirebbe la priorità.. e quindi l'interrupt ?
Tu praticamente stai facendo fare tutto il lavoro alla routine di interrupt ma, ricordi a cosa ci serviva? A leggere l'encoder, e solo a quello! Ma perché serve solo a quello? Semplice, perché quello è l'evento che accade (il cambio di stato del pin encoder) che non è controllato dal codice, avviene da solo, randomicamente (non esattamente ma per il codice è come se lo fosse), quindi il codice deve essere in grado di intercettarlo a prescindere da quello che sta facendo.
La generazione del passo per lo stepper invece è controllata dal tuo codice, sei tu che decidi quando farlo, non avviene randomicamente.

[umbez]

Max, potrei farti un'osservazione, ovvero quando entro nell'handler dell'interrupt riattivo il flag globale cosi va in catch su un altro interrupt ;-)
Ma sappiamo TUTTI che è una FOLLIA farlo poichè potrebbe generare un loop infinito...

[Davide Resca]

OT - On
Visto che in questo thread si usano pochi termini in inglese, potreste coinvolgere anche Carlo1974 che voglio vedere cosa salta fuori ?
OT- Off

[McMax]

Davide, Carlo è il benvenuto se vuole partecipare alla discussione
Non sono un fan degli inglesismi ma purtroppo quando si tratta di elettronica e informatica a volte i termini in italiano nemmeno esistono

[PierluigiP]

Ho provato con soddisfazione la versione originale ora stavo cercando di vedere come funzionava la versione di sbinf sia per il cablaggio più semplice che per vedere il menù avanzamento, perchè nella versione che ho provato, forse a causa mia (ma non sono così esperto per capirlo), non riesco a utilizzarla per fare un avanzamento vincolato...
provando la versione I2C l'arduino IDE mi da continuamente errori di compilazione a causa della libreria LCD, volevo chiedere a sbinf se può ricaricare la sua versione aggiornata come aveva detto per poter vedere se così riesco a utilizzarla, grazie.
Ho messo il sistema su un myford Super 7, se qualcuno ne avesse bisogno ho disegnato e rendo disponibili anche qui (basta chiedere e li carico, non lo faccio subito per evitare di sporcare il thread) gli stl delle pulegge MXL da 10,12, 26 e 36 denti con scasso adatto alla barra filettata da 16mm del tornio e trascinamento a chiavetta e compatibili (le piccole) con un asse stepper da 6,35mm.

[sbinf74]

Eccola ho usato la libreria proposta dal libray manager di arduino

libreria_usata.GIF

Per quanto riguarda l'avanzamento vincolato effettivamente ho fatto delle modifiche proprio perchè anche io avevo incontrato delle difficoltà nell'interazione con questo menù.

[PierluigiP]

Grazie mille!! Molto gentile