secondo me il debug migliore sarebbe anazlizzare con un oscilloscopio o un analizzatore di livelli abbastanza veloce (magari anche un altro arduino ce la fa, bisogna fare un paio di conti in base al clock che stai usando) la differenza tra la libreria attuale e la stessa implementazione fatta con la libreria SPI di arduino (che sono quasi certo che non si bloccherà)
terrei anche d'occhio i valori di LS_reg e MS_reg, poi variando il valore di inizio della i non ho capito se ci si blocca sempre dopo X step o se il numero di cicli varia
Ragazzi, ma avete perlomeno visto il codice? La libreria che ho copiato sono poche funzioni che usano direttamente l'SPI hw tramite i registri del micro, sto cercando di capire il bug in una di quelle funzioni che non usa a sua volta altre librerie
ho ben visto, e hai provato a confrontare il codice con la "vera" SPI? in particolare la begin differisce assai dalla tua init. In particolare dice di assegnare le porte come OUTPUT -DOPO- aver attivato la SPI, altrimenti MISO in autometico ritorna ad essere INPUT (commento riga 32 da https://github.com/arduino/Arduino/blob/master/libraries/SPI/SPI.cpp leggiti anche il link sul tracker dei bug che ha un sacco di chiarimenti sulla cosa e anche sul fatto di usare CPOL ad 1, ovvero il tuo caso, che sembra far saltare per qualche istante il clock. Tutto dipende dal fatto che il valore di default sui pin è low)
In oltre ci sono delle inizializzazioni differenti, per esempio il bit CPOL non viene modificato, a meno che non chiami "setDataModule" che cambia anche il valore del bit CPHA, ma queste sono impostazioni che credo non debbano dare fastidio.
fammi sapere se copiare
DDRB = _BV(PB0) | _BV(PB3) | _BV(PB5); // set SCK,MOSI,PB0 as Fsync
anche come uiltima istruzione della init funziona