Purtroppo il rischio che l'intervallo tra una commutazione è l'altra sia dell'ordine dei secondi c'è, io penso che sotto il secondo non si può scendere. Per ridurre ancora almeno in teoria il tempo totale richiesto per trovare la migliore configurazione ci sono le solite strade da seguire. Per come si è partizionato il range da 0 63 in 2 partizioni lo si può partizionare in 4, ma per scegliere la giustra strategia occorrono i dati reali di ROS, cioè occorre un database di ROS da studiare al fine di verificare come cambia nel tempo il ROS durante la ricerca in modalità sequenziale, cioè a step di 1uH o quello che sarà il minimo step scelto.
Ciò che occorre è un algoritmo di predizione ROS, e come tutte le predizioni può fallire, ma del fallimento l'algoritmo si può accorgere e provedere a fare una nuova predizioni basata sui stessi dati rilevati oppure con una correzione.
Ci possono essere alcuni dati costanti e alcuni dinamici che contribuiscono a calcolare la predizione. I dati statici vengono dedotti analizzando i dati reali di ROS e se possibile si ricavano queste costanti. Quelli dinamici vengono ricavati dal funzionamento dell'algoritmo. Insieme dati costanti e dinamici vengono usati da un algoritmo al fine di attuare una appropriata strategia.
64 / 4 = 16
range
0-15
15-31
31-47
47-63
commutazione a 15
misuraROS
commutazione a 31
misuraROS
continua fino a 4 misurazioni
Es valori campionati nelle quattro lettura di sopra 3.0 2.9 2.0 2.2
E chiaro che il miglior valore di ROS dovrebbe trovarsi nei dintorni della 32 configurazione, cioè si parte da 31 si incrementa o si decrementa fino a trovare il miglior ROS.
Bene o male che vada ci sono 4 + 16 commutazioni, ma è possibile fare un calcolo (2.9 - 2.0) e (2.0 - 2.2) per capire che prima devo decidere di commutare a salire da 2.0 verso 2.2, perche 0.9 > 0.2.
Tutta teoria di supposizioni senza studiare i dati reali tipici, qui @campa dovrebbe poter fare qualcosa no o chi per lui deve fornire un'insieme di dati su cui fare elucubrazioni mentali.
Andrea: leggi sopra... tutto ciò che affermi è probabilmente vero e realistico, ma qui stiamo partendo da 0 con un software che dovrà pilotare un apparecchio che non c'è (lo capisco ora, visto che parli di potenziometri e resistenze);
Rimane sempre il punto fermo fissato prima da Michele, cioè il codice al momento deve fare la commutazione sequenziale il logica binaria partendo da 0 o da 64/2, e non occore sia scritto alla perfezione permettendo ad esempio la modifica del solo algoritmo decisionale, va bene una accrocco limitato a fare da muletto, sarebbe però opporturno pensare di creare una collezioni di dati durante il funzionamento, o interna al micro oppure spedita via seriale senza prima collezionarla nel micro.
Soluzione che uso spesso:
myFunc(int8_t direction)
{
static uint8_t counter = 0; // mantiene il valore dell'indice o della configurazione
if (direction)
++counter;
else
--counter;
// meglio direction ? ++counter : -- counter;
// meglio ancora se messo in una define
// nota che posso modificare direction in corsa, se devo condividere la direction con il chiamante direction deve essere
// globale o un puntatore.
}
Ciao.