Tranne bestemmiare una settimana per fare il porting della libreria per gli oled!
Appunto! Quello che dicevo.
Quanto hai calcoli dei cicli, vale certamente quel che hai detto tu. Però precisione per precisione vorrei farti notare una cosina. Non che questo tolga nulla alla validità delle considerazioni da te fatte circa i micro più prestanti e le CIP, che sono certamente la scelta più appropriata.
Tu dici:
Togliendo tutto l'Assembler di mezzo, si passa da 109.5 KHz a 89.9KHz. A prima vista sono solo 19.6KHz di differenza, ma 19.6 su 89.9, sono più del 20% di differenza come impiego risorse (se leggo una frequenza minore, vuol dire che la ISR generata alla fine è più lunga). Come dire che se un singolo encoder nella mia ISR in assembler usa (61+22=83) cicli, quella generata dal compilatore ne usa 83+20%=99.6 ovvero 17 cicli in più. Se poi consideri che questo spreco può avvenire 90000 volte in un secondo, ecco che su 16000000 cicli a disposizione ne abbiamo buttati (si fa per dire) 1530000. Direi che usando il C invece dell'assembler ci giochiamo ad esempio tutti i cicli che ci servono per trasmettere le letture in seriale e forse anche altro. Solo per fare un esempio.... Se il limone è già piccolo, la prima, cosa direi che è evitare di far cadere una parte del succo fuori dal bicchiere quando lo spremi.
Questo per quanto riguarda la tua domanda iniziale.
Evitare l'assembler e lasciare che il compilatore faccia il suo lavoro?
Questo comunque sempre per accademico spirito di voler spaccare il capello in quattro, non perché tutti questi discorsi abbiano poi nella pratica giornaliera una qualche utilità effettiva.
In ogni caso a parte il motor-control che tu hai citato, gli encoder NPN o PNP, già per ragioni più legate all'imunità ai disturbi e quant'altro, difficilmente vengono impiegati sopra i 15-20KHz e molti PLC, quando offrono contatori integrati nella CPU (solitamente non più di quattro) dichiarano frequenze massime di 50KHz solo con elettronica line-driver ed usando al loro interno micro ben più prestanti di un Arduino. Producendo alla fine tempi di ciclo di scansione sempre dell'ordine dei mSec. Quindi in ogni caso con frequenze di elaborazione del ciclo 'Nobile' diciamo così, di almeno due ordini di grandezza rispetto la frequenza massima leggibile dall'encoder.
In definitiva, l'essere riusciti a leggere più encoder a frequenze così alte con un Arduino è già di per se un risultato di buon livello. Poi valutare la bontà di una singola libreria (la mia non è nemmeno quello dato che va riadattata ogni volta) senza valutare l'applicazione nel suo complesso lascia il tempo che trova. Ma ovviamente questo lo puoi fare solo di volta in volta su di un applicazione ben specifica.
In astratto puoi solo e soprattutto conviene, prescindere dall'HW impiegato e discutere della metodologia impiegata per la lettura, evidenziandone pregi e difetti. Non puoi fare altro. Se ti spingi oltre esci dal merito del tema proposto e si entra in un ginepraio, come stiamo facendo noi in queste due pagine di post. Anche se entrambi abbiamo il merito (prendiamocelo dai!) di aver sviscerato, ad uso di chi ha avuto la pazienza di leggerci, alcune delle problematiche e dei limiti del buon vecchio caro Arduino.
La finiamo qui senza tediare ulteriormente i nostri lettori?
O ti riferisci al sito?
