gpb01:
... che poi, se capisco bene quello che stai facendo, in pratica tu stai simulando in bit banging il funzionamento di una porta SPIAl quel punto potresti demandare il tutto alla libreria SPI e leggere il tuo blocco di 3 bytes direttamente tramite l'HW dedicato a fare ciò ... magari su una sola lettura non si velocizza molto, ma se le letture sono tante, probabilmente l'HW dedicato viaggia più veloce della sua simulazione in bit banging
Guglielmo
Da questo post mi sono reso conto che Arduino, per come è ora, risulta essere molto più potente di un MECT TPAC1007 con ARM969 32 bit che viene programmato in QT (parte HMI) e in ST.
Succede che da Arduino gli invio un HIGH, aspettare 21 ms (si , 21 millisecondi), fargli leggere il bit, inviare LOW e aspettare ancora 21 ms... Totale della lettura 24bit x 48 millisecondi (più di un secondo !!!). Se provo ad inviare a 20 msec. dal lato TPAC mi perdo dei bit...
Questo per dire che non è, appunto, la MCU (che tutti i produttori di PLC pubblicizzano come ultra-mega-veloce) la cosa importante, bensì il tempo di ciclo che fa si che gli ingressi e le uscite vengano aggiornati nel minor tempo possibile. Ma il tempo di ciclo dipende anche da "quante cose devo interpretare in un ciclo" e Guglielmo, appunto, ha gia scritto che meglio shiftare i bit che usare le moltiplicazioni (caro buon vecchio ASSEMBLER)...
Che dire, più vado avanti e più sono convinto che la strada dei compilatori sempre più enormi e mangiamemoria ("ma che te frega, tanto la memoria non costa nulla" dicono i programmatori della new generation) non sia la strada migliore da seguire...
Ricordo sempre che il primo Mac si chiamava 128 (erano Kbytes) e poi usci il modello Macintosh 512 (erano sempre Kbytes). E non faceva molte meno cose di ciò che fanno i computers odierni con un consumo i più di 2.000 volte la memoria di allora (Windows è almeno 1 Gbytes)...