Max io in questi casi per deteminare quanto tempo impiega una routine ciclica e di conseguenza quanto ne rimane per il resto del programma (a priorità più bassa)
uso semplicemente un I/O (out) di servizio e l'oscilloscopio, alzando l'uscita all'inizio del ciclo critico e abbassandola alla fine, così vedo bene i tempi al netto di eventuali timer sw e printf varie; specialmente in ambiente RTOS dove ci sono processi concorrenti.
In questo modo mi rendo conto anche dell' eventuale jitter temporale e della sua entità.
Visto che esiste una libreria PID (tre versioni) della Keil (ARM) non vedo perché andare ad usare un porting di una cosa proveniente da Arduino... (che tra l'altro ha un discreto numero di fork il che mi fa sospettare che tanto perfetta non sia)
Un micro a 8 bit che gestisce numeri reali è estremamente lento per cui i tempi di di ciclo del PID sono espressi in secondi o al massimo decimi di sec.
Io ne feci uno qualche anno fa su un ATMega48 che aveva un ciclo di 1mS ma per essere veloce (così da lasciare sufficiente spazio al resto del programma) utilizzava interi scalati
Comunque la modalità auto, se ho capito bene, serve a fare in modo che quando cambi i coefficienti PID al volo, l'errore corrente venga opportunamente scalato, in automatico, per evitare perturbazioni nel segnale d'uscita.
Prova a dare un'occhiata qui per le librerie kail
https://stm32f4-discovery.net/2014/11/project-03-stm32f4xx-pid-controller/ Il ciclo computazionale del pid lo devi agganciare a un interrupt periodico (periferica timer) ad alta priorità.
Per tracciare dei grafici sul PC, dalle grandezze in gioco, per vederne l'andamento nel tempo (ovviamente segnali relativamente lenti), in modo pratico e veloce uso il programma StampPlot che si interfaccia con la seriale del micro.
Ne esiste una versione Lite free che è più che sufficiente
https://www.parallax.com/downloads/stampplot-lite-software Credo che potrà tornarti utile.