in realtà ci hai capito abbastanza, è proprio quello il problema nello scegliere i breakpoint giri e carico motore.
Scusa se non sono stato troppo chiaro, è difficile descrivere in poche parole i concetti dietro quello che dovrebbe fare una gestione motore (io da profano in elettronica e programmazione, sto facendo una specie di reverse engineering, dal funzionamento lato utente finale sto risalendo a ritroso su "come" lavora una ECU in firmware... non sono bruscoline...)
Comunque alla base di ciò che affermavo, vi è che sarebbe opportuno poter spaziare i breakpoint RPM in base alla curva di coppia del motore perchè, dove esso si comporta linearmente, io aumento il divario di giri a cui fa il controllo mappa, mentre nelle zone dove il motore è più imprevedibile, per facilitare le cose, spesso sono costretto ad aumentare il numero di breakpoint in quella zona ravvicinando i giri di controllo (ovvero i breakpoint) ti faccio un'esempio:
ho un motore che deve funzionare liscio a filo di gas in citta, poi il motore sale con una progressione abbastanza lineare fino a 5000 rpm, da li al massimo numero di giri utili (diciamo 6000) del motore diventa poco lineare. Quindi se la mia mappa ha 16 breakpoint RPM, affinchè vengano inglobati tutto il range di funzionamento, quindi i miei breakpoint potrebbero essere:
0 , 1 , 2 , 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
0, 500, 1000, 1500, 2000, 2500, 3000, 3500, 4000, 4500, 5000, 5500, 6000, 6500, 7000, 7500
Questo qui sopra sarebbe uno spreco di breakpoint tutti spaziati ogni 500 giri e partendo da 0 e superando i giri utili.
noi Tuner del settore Racing, dove queste cose sono all'ordine del giorno, in base a questo ipotetico motore faremmo:
0 , 1 , 2 , 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
1000, 1250, 1500, 1750, 2000, 2500, 3000, 3500, 4000, 4500, 5000, 5250, 5500, 5750, 6000, 6250,
come vedi, ho evitato lo 0, quando il motore è fermo la ECU resta in "ascolto" del segnale giri quindi in stand by, appena vede "girare" il motore, attua altre strategie specifiche della partenza (cranking) superato una certa soglia giri, passa allo stato "running" e qui, entra in funzione la nostra bella mappa. quindi i nostri giri iniziano intorno alla zona di minimo che magari sarà intorno ai 900-1000 giri, per una buona erogazione, si predispongono breakpoint ogni 250 giri poi si passa a 500 giri alla volta (nella zona dove il motore è linare, ed infine, nella zona dove il motore è un po più irregolare e vicino alla potenza massima, si ritorna di nuovo a spaziare ogni 250 giri. Ovviamente, questo dipende molto dal tipo di centralina che ho per mani e dal motore, ho centraline che hanno solo 16 breakpoint giri disponibili e con motori che fanno tantissimi giri diventa un problema trovare la spaziatura giusta, altre ECu invece, gestiscono fino a 32 breakpoint giri x 24 carico motore a mappa (e consentono i 250 giri dappertutto).
Visto che la mia idea è per un motore specifico e conosco le mappe originali, mi bastano i 16 breakpont giri ed anzi, forse userò anche la spaziatura originale, questo lo deciderò al momento delle fasi finali, se ci arriverò, della messa in moto di un motore cavia, ma per ora, quel momento è lontanuccio, meglio concentrarsi sui problemi uno ad uno separatamente e poi andare ad inglobarli uno alla volta fino ad ottenere il firmware completo e funzionante.
Quindi da qui, la mia preoccupazione per rendere fin da subito, più ottimizzato il codice, magari anche con queste lacune, sarebbe funzionante, ma essendo io profano, preferisco pensare al massimo risparmio di risorse per garantire velocità di riserva in caso di guai non previsti, quindi per esempio, per le funzioni di ricerca breakpoint sensori temperatura vari e relativo calcolo valori ingegneristici (sensore NTC non lineari, richiedono la linearizzazione mediante array, rieccoci !! capite?) l'ho ottimizzato inglobando le ricerche in una unica funzione Universale, che viene invocata da ogni funzione sensore da calcolare invece di fare una funzione per ogni sensore (sono 3 al momento i sensori). così ho risparmiato diversi byte di flash, codice più breve, e qualcosina a livello di uso SRAM (forse il compilatore gia di per se ottimizzava tantissimo prima), adesso sto facendo la stessa cosa con queste altre mappe, se non le ho inglobate in quella "universale" è per la differenza di numero breakpoints, e per quieto vivere, ho preferito farne una specifica per le mappe di gestione, ma una volta capito bene come fare, l'idea è inglobare anche queste ricerche in quella unica funzione "universale" come se fosse una libreria. Le librerie, per ora, non ne uso nessuna, ma l'idea sarebbe anche verificare se conviene o meno, trasferire queste funzioni universali in librerie in modo da rendere il codice più trasportabile e corto (nello sketch ovviamente). La strada è lunga....
PS. sai che la tecnica che descrivi di dividere/moltiplicare per 128 l'ho vista tantissime volte sulle ECU di vecchia generazione? anche loro a corto di risorse e senza FPU.