Ciao Bob, si quello che leggi nelle flash è l'esegubile più i dati per farli eseguire dalla CPU che lavora/elabora (attraverso cicli vari di idle, interrupt, polling, read/write, ecc...) i dati scritti in linguaggio macchina nella sua ROM, ora se io modifico un singolo BP potrei avere delle incongruenze che il Processore non potrebbe interpretare nel modo corretto (per esempio con valori "out-range") oppure BP a multiplo collegamento (attinenti a più tabelle contemporaneamente) che potrebbero interrompere il ciclo stesso della ECU. Ora sapiamo che la stessa ECU può equipaggiare diversi motori con differenti potenze e se noi osserviamo come i BP interagiscono nelle varie tabelle possiamo sfruttare queste "differenze" per le nostre elaborazioni, ma andare ad elaborare l'eseguibile stesso è molto oltre le esigenze del normale preparatore. Se guardiamo una lettura estesa di una ECU ci troviamo, come in un programma per PC, delle "zone" abbastanza distinte dove troviamo: l'eseguibile, le tabelle e la parte che presiede alla verifica dell'insieme (qui troviamo anche checksum, codifiche e simili). Nel dettaglio notiamo che mediamente i BP sono allocati in maniera equidistante, inteso come indirizzi di memoria e di conseguenza pure le mappe sono così distanziate, sapendo che per esempio una ECU a 16bit possa assumere 65535 valori per unità e che il range come il carico "load" o una qualunque altra grandezza in gioco come i volt di un sensore, il numero dei giri, varia da un minimo ed un massimo, possiamo sapere i valori in scala dei BP. Esempio concreto: il debimetro fornisce un valore di tensione di circa 5V (4.95V ±0.05) che diviso per 65535 da circa il valore 0.00007629 che è il minimo valore che può discriminare, ora se moltiplichiamo questo valore per i valori iscritti in ordinata ed ascisse di un BP sapremo quale valore "reale" esso rappresenta. Scusate la lunghezza ma spero di essere stato chiaro nell'esposizione sull'argomento.