McMax, se vuoi modificare il tuo programma, alla luce di questa "analisi", io spegnerei il timer0, sostituirei attachinterrupt con la manipolazione dei registri e cambierei delay (che non funziona piu') con _delay_ms(). Veloce e facile e guadagni un bel po'. Anche a bassi giri (3-400rpm) ti eviti gli errori dovuti all'intervento dell'isr del timer0.
Il resto delle ottimizzazioni non so se valga la pena farle, dovresti rivedere un po' tutto il programma e, comunque, se non parti accelerando e finisci decelerando dubito che lo stepper riesca a partire in bomba (forse un nema17 che ha poca inerzia... il mio nema34 non ce la fa. Parte senza rampa fino a 150rpm. Oltre stalla).
Resterebbe il problema dell'int e del long modificato nell'isr e letto fuori, dovresti sistemare disabilitando l'interrupt quando vai a leggerle.
Una domanda: quando ho una variabile che viene modificata da una isr devo dichiararla volatile (cosi' il compilatore sa che deve ricaricarla ogni volta perche' potrebbe essere cambiata dall'isr a sua insaputa).
Ma se ho il contrario? Cioe' ho una variabile che viene modificata nel main e controllata nell'isr. Non penso serva dichiararla volatile (quando entra nell'isr il compilatore carica e scarica i registri che gli servono e, comunque, all'interno dell'isr va a leggere dalla memoria o dal registro, se una variabile e' fissata in quel registro). Io ho fatto cosi' e funziona ma non so se funziona per caso o perche' il mio ragionamento e' corretto. Anche qua, in ottica di ottimizzare piu' possibile il codice.
Altra curiosita': attivando l'ottimizzazione -O3 (massima velocita'), la mia isr ci mette circa 0.5uS in meno ad essere eseguita. Poca cosa ma quello che e' interessante e' che certe variabili restano fisse nei registri (probabilmente il compilatore vede quelle caricate e scaricate piu' spesso e dedica un paio di registri a quelle variabili) risparmiando tempo (non deve caricare e scaricare dalla memoria. Se l'indirizzo di memoria e' a 16bit, il comando lds occupa 2 cicli e il comando str altri 2. E questo per una variabile byte. Se fosse una int sarebbero 4+4 cicli. Una long 8+8 cicli).
Quindi anche nel resto del programma si ha un incremento di velocita' che, pero', si paga con un raddoppio della lunghezza del codice (se con l'ottimizzazione standard di arduino -Os il mio codice occupa il 35% dello spazio, con l'ottimizzazione -O3 occupa il 77%).
E infine un'altra cosa che sapevo ma non avevo realizzato di sapere. L'alu puo' fare operazioni solo sui registri. Se i registri sono a 8bit, devo caricare i dati dalla memoria un byte alla volta, fare l'operazione, salvare in un registro e scaricarlo in memoria, byte per byte.
A questo punto immagino che un processore a 32bit abbia registri da 32bit con tutti i vantaggi che si porta dietro.
Poi c'e' il discorso dei bus di memoria ma li' devo ancora interiorizzare il discorso.
Ultimissima curiosita': in C scrivo a++; (la variabile "a" e' un byte). Il codice compilato non fa una addizione ma sottrae ad "a" il valore 255 (0xff). Immagino sia per evitare l'overflow (se a=255 e facesse a+1=256, il bit in eccesso non saprebbe dove metterlo... sottraendo 255, invece, la variabile va in overflow ma restando sempre nel suo spazio di memoria di 8 bit. Intelligente!).
|
