MECCANICA e DINTORNI

Buongiorno,
riprendo da questo thread viewtopic.php?f=16&t=15729&start=1410
per aprire il "mio" filone sull'els e relativi problemi-chiarimenti-consigli.
In allegato metto il programma che, per ora, ha girato solo sul banco. Presto dovrei riuscire a provarlo sul tornio.
Se qualcuno vuole provarlo son disponibile a spiegare tutto quello che serve.
Premessa: il lavoro non e' tutta farina del mio sacco, ha preso spunto dal lavorone di McMax, dal lavorone di un russo e rubando l'interfaccia del programma di Mimoletti. Un doveroso ringraziamento a tutti per il lavoro che avete fatto.
Non volevo reinventare l'acqua calda ma c'erano cose che non mi piacevano nel programma di McMax, cose che non mi piacevano in quello del russo e cose che non mi piacevano in quello di Mimoletti.
Quindi mi sono creato il mio programma con qualche feature in piu' (che se funziona dovrebbe rendere il tutto piu' funzionale rispetto a quello di mimoletti e di McMax) e togliendo tante cose rispetto al programma di McMax e del russo che, per come lavoro io, non le avrei mai usate a vantaggio di una interfaccia utente piu' immediata.

Giusto due precisazioni, riprendendo il vecchio thread (chi partecipa si beva una tazza di camomilla altrimenti ci sbattono fuori tutti )
1. McMax, mentre stavo guidando ho avuto l'illuminazione su quello che cercavi di spiegarmi sulla routine di interrupt. Nel tuo programma, quando entri nelle varie funzioni (filettatura, avanzamento, ecc...) fai partire un ciclo while che diventa falso solo alla pressione di un pulsante. Adesso capisco perche' dicevi che mettendo tutto sotto interrupt il ciclo "normale" diventava sterile.
In realta' ho fatto anch'io cosi', prendendo spunto dal tuo programma (e, di nuovo, ti ringrazio perche' ho trovato tante nuove idee). Pero', preso dalla discussione (e dal fatto che il programma l'avevo scritto due mesi fa, poi accantonato per mancanza di tempo, e non mi ricordo neanche cos'ho fatto stamattina) non avevo considerato che avevo fatto anch'io come te e quindi non capivo a pieno il tuo discorso.
Nella discussione mi ero concentrato sulla routine di interrupt pensando di averla chiamata all'interno della funzione "filettatura" (quindi dove vado a gestire anche il display, ad esempio).
Solo stamattina ho avuto il flash che l'interrupt lo "accendo" giusto prima di entrare nel while quindi posso tranquillamente gestire li' il motore (nel mio ciclo while, alla fine, c'e' solo il controllo del pulsante per uscire e poco altro).
Per un programmatore navigato sara' una banalita' ma per un programmatore ignorante non e' cosi' banale (pur avendo capito il tuo programma e quello del russo, mi mancava l'ultimo passo per capire al 100%).

2. sempre domanda per McMax, perche' hai usato il timer1 per gestire la generazione del passo? Ok, capito, mi sono risposto da solo.
Tu devi generare anche un segnale pwm per l'avanzamento asincrono. Visto che e' una cosa che non avrei mai usato (trovo molto piu' comodo e diretto l'avanzamento a cent/giro) la relativa funzione l'avevo guardata ma non approfondita.

3. ultima domanda per esaurire quello che era rimasto in sospeso dal vecchio thread: si discuteva sul fatto di far fare piu' operazioni contemporaneamente al micro. Mi e' rimasto un dubbio: le periferiche (ad esempio i timer e l'interfaccia qei) sono indipendenti dalla cpu, giusto? Se imposto un timer che faccia cambiare di stato la relativa porta OC, questa cambiera' di stato senza occupare la cpu, corretto? Quindi il micro e' in grado di fare piu' operazioni contemporaneamente (inteso letteralmente, non che sembrano contemporanee).
Era giusto un dubbio, dalla discussione mi sembrava di aver capito il contrario ma potrei aver capito male io (o aver sbagliato quanto scritto sopra).

Matteo: "perche' hai usato il timer1 per gestire la generazione del passo?"
perché è l'unico a 16bit
il timer lo uso in due modi:
- single shot ==> durante la filettatura per generare il passo tramite FireStep(). con FireStep si forza il timer ad un valore vicino al TOP in modo che esaurisca l'impulso entro pochi microsecondi. In questo modo il tempo di on dell'impulso di step non è bloccante per il codice; l'alternativa sarebbe stata quella di muovere manualmente un pin mettendoci un delay in mezzo ma non sarebbe stato per niente efficiente visto che è bloccante (il delay, intendo)
- fast PWM mode ==> durante avanzamenti e movimento libero. In questo caso il timer continua a generare un impulso da pochi microsecondi alla frequenza che gli impostiamo.

Matteo:"le periferiche (ad esempio i timer e l'interfaccia qei) sono indipendenti dalla cpu, giusto? Se imposto un timer che faccia cambiare di stato la relativa porta OC, questa cambiera' di stato senza occupare la cpu, corretto? Quindi il micro e' in grado di fare piu' operazioni contemporaneamente (inteso letteralmente, non che sembrano contemporanee)."

le periferiche hardware sono svincolate dal flusso di esecuzione pertanto si, operano entro i loro limiti autonomamente. La QEI ad esempio per leggere l'encoder è una mano santa perché conta i passi esattamente come se fosse un timer ma con la differenza che legge entrambi i segnali in quadratura (A e B) quindi incrementa il contatore quando l'encoder gira in un verso e lo decrementa quando gira nell'altro, il tutto senza impegnare la CPU. Chiaramente queste periferiche prima o poi dovranno interagire con il programma tramite un interrupt che si può innescare, ad esempio, al raggiungimento di un certo valore del contatore piuttosto che in "polling" ad esempio con un ciclo while che controlla il raggiungimento di un valore voluto.
I timer funzionano più o meno nello stesso modo ma contano il singolo impulso e non decodificano direttamente il segnale in quadratura dell'encoder.
Lo stesso vale per l'output: il PWM che utilizzo per generare gli step per la vite funziona su questo principio, con la differenza che non usa un Clock in ingresso (tipo il segnale dell'encoder) ma utilizza il Clock interno del processore per cambiare lo stato di un pin di uscita ma, di fatto, anche lui lavora "autonomamente" senza impegnare la CPU.

McMax: "l timer lo uso in due modi:
- single shot ==> durante la filettatura per generare il passo tramite FireStep(). con FireStep si forza il timer ad un valore vicino al TOP in modo che esaurisca l'impulso entro pochi microsecondi. In questo modo il tempo di on dell'impulso di step non è bloccante per il codice; l'alternativa sarebbe stata quella di muovere manualmente un pin mettendoci un delay in mezzo ma non sarebbe stato per niente efficiente visto che è bloccante (il delay, intendo)"

Si, questo mi era chiaro. Ma appunto perche' deve contare solo 2 tick avevo intenzione di usare il timer2 a 8 bit. Ma vedo adesso che il pin oc2b e' lo stesso dell'interrupt1 (che volevo usare per leggere l'index dell'encoder).
Mbho, vedremo cosa riesco a inventarmi

Si con il single shot puoi usare anche il timer a 8 bit ma in fast PWM per far girare lo stepper è meglio il 16bit perché hai più risoluzione e riesci a farlo andare più piano. Ho scelto il 16bit perché il prescaler massimo del ATMega è 1024 e con timer a 8bit e stepper impostato a 400 passi/giro la velocità minima di rotazione è di 9 giri/min: per torni come il mio con la barra non è un grosso problema perché va già lenta di suo ma per chi usa la vite per fare gli avanzamenti 9 giri/min rischiano di essere troppi. Ho deciso quindi di usare il timer a 16bit per permettere di usare il sistema anche su torni che non hanno la barra e devono fare gli avanzamenti con la vite.

Hai preso l'encoder con l'index?

Si, il mio encoder ha anche l'index.
Volevo usarlo ma al momento non so come... devo ragionarci sopra.

lo puoi usare per leggere la velocità di rotazione del mandrino con precisione. Lo devi mettere sotto interrupt: e non è necessario che usi un ingresso INT, puoi anche mettere sotto interrupt qualsiasi altro pin (PCINT).
Usando l'index la velocità di rotazione letta è molto più reale perché l'interrupt, essendo che se ne genera solo uno a giro, non disturba troppo l'esecuzione di millis() e micros(), che in questo caso servono per calcolare il tempo di rivoluzione del mandrino.

La mia idea (che funziona ma non so se e' migliorabile usando l'index sotto interrupt) e' questa:
- ogni giro completo del mandrino (2000 impulsi) incremento la variabile tacho
- armo il timer1 modo 4 (CTC con top a OCR1A) in modo che faccia il match ogni secondo
- nella routine di interrupt (TIMER1_COMPA_vect) attivo un flag che andro' a leggere nel programma principale
- se il flag e' vero, vado a leggere tacho, moltiplico per 60, lo visualizzo sul display e azzero tacho e il flag.

Cosa dici? Per funzionare funziona ma non so se sia migliorabile.
A nasometro, andando a leggere l'index non credo si guadagni tanto (a meno di usare l'index come clock per il timer).
Lascerei la visualizzazione dei giri solo nel menu degli avanzamenti, in filettatura non lo userei (neanche in avanzamento ma fa figo )

quindi non intendi usare l'index ma i passi encoder... ok. L'idea è buona.
Perché vuoi gestire solo un flag nella ISR del Timer e non direttamente la moltiplicazione e il reset di tacho ?

I passi encoder come li leggi ?

McMax:"Perché vuoi gestire solo un flag nella ISR del Timer e non direttamente la moltiplicazione e il reset di tacho ?"
Perche' cosi' ho tutto insieme nel codice principale (calcolo, reset delle variabili, aggiornamento del display) senza avere un pezzo nella routine di interrupt e un pezzo nel programma principale.
Forse, pero', mi conviene andare a leggere direttamente la voce nel registro appropriato (OCF1A nel registro TIFR1), mi risparmio la chiamata all'interrupt e una variabile (poca cosa ma, ogni tanto, ci permettiamo di fare i raffinati).
Quindi verrebbe:
- ogni 2000 impulsi incremento tacho
- armo il timer1, modo 4, match ogni secondo
- nel main, verifico se OCF1A in TIFR1 e' a 0, se vero, metto OCF1A a 1, moltiplico tacho per 60, aggiorno il display e resetto tacho.

McMax: I passi encoder come li leggi ?
Semplicemente incrementando una variabile (Enc) ogni volta che viene chiamato l'interrupt.

Mi sono sempre chiesto perchè insistete a lavorare su quell'arduino UNO che ha un solo timer decente (intendo a 16 bit )
Visto che nelle intenzioni di questo 3d dovrebbe nascere una nuova versione del fw, perché non cogliete anche l'occasione per passare un scheda arduino con qualche timer in più come la versione Mega 2650, tra l'altro mi sembra che anche come prezzo sia più che abbordabile, al limite un clone.
Sarebbe senz'altro adatta anche gestire anche un secondo asse e diventare una piattaformina per svilupparci sopra anche qualche altro gingillo.
Per quello che ricordo degli Atmel, (non ci lavoro più ormai da una 15na d'anni), come architettura sono abbastanza scalabili, lo sforzo per migrare l'attuale fw, dovrebbe essere realmente modesto.

Sono d'accordo Albi, io dovendo rifare tutto andrei però su 32bit: ormai non ha senso stare su micro a 8bit.

Matteo, la cosa può funzionare, ma sarebbe meglio mantenere l'interrupt allo scadere del timer per evitare di leggere il valore del timer in polling. Io nella ISR del timer andrei a bloccare tacho (magari salvandone il valore in una variabile diversa) in modo da avere la misura più precisa possibile.
Alternativamente puoi anche evitare di usare la variabile tacho: visto che già incrementi i passi nella ISR dell'encoder, quando interviene l'interrupt del timer vai a leggere i passi e li salvi in una variabile: in questo modo sei sicuro di avere una lettura precisa e puntuale e non una varibaile incrementata ad ogni giro che, soprattutto alle basse velocità, può essere fuorviante.

Quindi:
- parti con la lettura dei passi encoder e contemporaneamente accendi il timer per contare 1sec
- nella ISR del timer copi i passi encoder letti in un'altra varibaile
- nel ciclo principale calcoli la velocità e aggironi il display
- Fai ripartire resettando i passi encoder e il timer nello stesso istante

Non sono d'accordo, almeno per il mio scopo (che e' anche quello di imparare).
A suo tempo avevo fatto un cruscotto digitale per la motoretta (un'aprilia rs125 per tornare sedicenni), era venuto simpatico. Avevo usato un arduino due e un display 800*480 pixel.
Per leggere i giri motore e la velocita' (giri ruota) l'intenzione era armare un timer come input capture unit.
Non sono stato in grado di impostare due timer come volevo, mi son perso nel datasheet del sam3x (il micro dell'arduino due) e ho dovuto ripiegare su una libreria fatta da altri di cui non ho capito il funzionamento (limiti miei, sto ancora imparando).
In piu', con la potenza di calcolo del sam3x l'ottimizzazione del codice era optional (a parte giri motore e giri ruota, il resto - folle, sensore cavalletto, temperatura motore, temperatura gas di scarico, frecce, luci di posizione, anabbaglianti, abbaglianti, benzina, olio, e forse altro che dimentico - era letto in polling senza problemi).
Con l'atmega328, le risorse sono limitate e il codice deve essere scritto bene altrimenti non funziona.

Per quanto riguarda il mio programma, ok, chiaro. Adesso provo ad implementare quello che mi dice McMax.

< io dovendo rifare tutto andrei però su 32bit: ormai non ha senso stare su micro a 8bit.>

Come recita un noto proverbio: "Il meglio è nemico del bene"

E' Inutile pensare a un 32 bit quando la maggior parte degli utenti che programmano se la cavano a malapena con un 8 bit,
sarebbe una cosa disincentivante al massimo.

Un ATMega 2650, è semplicemente lo stesso processore di prima solo con più timer e più memoria, per il resto
cambia poco, e chi programma sull' UNO programma anche su quello senza problemi.
Passare a un 32 bit è un salto troppo complicato, un progetto fatto su quello rischia di non vedere mai la luce.

beh alla fine se stai sull'architettura Arduino non cambia molto, l'ambiente di sviluppo è lo stesso e il linguaggio anche.
Considera che ormai il micro a 8 bit non ha più molto senso: a livello di costo siamo li e con gli IDE che ci sono oggi non fa una grande differenza sviluppare con un 8 o con un 32.
Se guardi ad esempio STM32, le schede di sviluppo della serie NUCLEO sono addirittura meno costose di arduino e come ambiante di sviluppo hai la possibilità di scegliere quello che vuoi, a partire dai più famosi KEIL e IAR passando per ARM mbed e STM32 cube fornito direttamente da ST che è gratuito, ben supportato e potentissimo... oltre a ciò alcune schede NUCLEO sono anche supportate da arduino IDE che, per quanto limitato, è comunque molto popolare.
Last but not least: ST è un'azienda Italiana (in parte) e produce parecchi semiconduttori in Italia.... Arduino pure è italiana ma i micro sono Microchip (ex ATMEL) quindi di produzione americana (si fa per dire...).

Su STM32 ci lavoro fin dal 2006 quando uscì la serie F103, per cui posso dire di conoscerlo abbastanza,
perciò anche ti dico che stai facendo un errore di valutazione.
faccio alcune osservazioni (in ordine sparso) per farvi capire che le cose non sono così semplici come potrebbero sembrare.

1) l'architettura è molto più complessa di un 8 bit, le periferiche pure lo sono, i timer per esempio possono essre più complessi di quelli dell' AVR anche di un fattore 10 (tanto per dare l'idea) Vedo che c'è difficoltà (o poca voglia..) a capire a fondo quelli dell'AVR figuriamoci quelli dell' STM32.

2) Uno dei vantaggi principali se non il più grande è quello di avere risorse per ospitare agevolmente un RT/OS (fin'ora ho usato ChibiOS)
ma usarlo non è semplice e richiede esperienza. In passato ho anche usato uC/OsII su AVR, ma occupa troppe risorse ed alla fine non rimane molto per i vari task.
La nota negativa è che ChibiOs non è supportato da STM32Cube, a differenze dell'omnipresente FreeRTOS.

3)Dubito che in ambiente arduino l'STM32 sia supportato efficacemente, e comunque l'utilizzare alcune libererie per le periferiche non ti esenta dal conoscerle a fondo.
Posso sbagliarmi perché non l'ho mai usato in vita mia, ho solo dato un'occhiata a quello che si trova su internet per capire di che si trattava, ma credo che un ambiente di sviluppo semplificato come l'Ide di arduino non sia adatto ai micro di questo tipo.

4)E' vero che esistono sistemi di sviluppo free per STM32, ma essi non ti danno certo la pappa scodellata. Personalmente uso ChibiStudio che è una customizzazione di Eclipse con toolchain GNU e con qualche facility per il supporto di ChibiOS.

5)STM32Cube è un tool che ti permette fondamentalmente generare lo scheletro del codice della struttuta di configurazione, partendo da una serie di strumenti grafici. Molto ben fatto e molto utile per l'impostazione preliminare del progetto. lo uso sempre.

6)Nulla da eccepire sull' italianità, di ST, anche se mi pare che la quota italiana sia scesa alle briciole, comunque segnalo che anche ChibiOs è italiano.

Quando nel 2006 ho iniziato il passaggio da AVR a STM32, non è stato affatto veloce e indolore, la cosa ha richiesto almeno 2-3 anni, un micro a 32bit e mooooolto più complesso dell'AVR e a volerlo conoscere a fondo richiede un impegno notevole, anche di studio.
A volte, per esempio, anche un differenza tra una versione e l'altra della toolchain può creare situazioni difficili da risolvere per un principiante.

Ultimamente ho lavorato su Atmel SAM4S8 e AtmelStudio 7, ho constatato che l'architettura di questo micro è abbastanza meno complessa dell'STM32. Mi pare ci sia un scheda arduino basata su un cortex M0 Atmel, forse quella è più semplice per approcciare (sempre relativamente) il 32bit