Credo di aver trovato il bandolo. Si tratta di una sfortunata coincidenza di
asserzione di IORQ+RD da parte dello Z80, con i fronti di commutazione del
clock da 14MHz che governa la cpld di I/O.
Dato che lo Z80 non puo` attendere che la SPI legga un byte, quest'ultima
deve prepararselo in anticipo. Per questo motivo ho fatto in modo che ad
ogni ciclo di lettura Z80 segua l'innesco di una nuova ricezione da parte
della SPI, che preparera` cosi` un nuovo dato entro 16T-states (del clock a
14MHz). Ricordo anche che il valore di questo clock e` imposto dal fatto di
dover gestire anche l'uart ad una frequenza ben precisa (115K2) e con
frequenze piu` alte avevo problemi nel numero di macrocelle per la
divisione.
Dato che durante il permanere dell'asserzione di IORQ+RD+CS puo` capitare
piu` di un clock da 14MHz, avevo vincolato lo "start" del processo di
ricezione al contenuto del contatore di bit: veniva innescato solo se zero,
in modo che cio` accadesse una sola volta.
Evidentemente (e tra l'altro mi erano gia` capitate stranezze di questo tipo
in altri progetti, dimentico sempre che non ho a che fare con software) il
modo in cui il compilatore ha tradotto questa cosa lasciava adito ad
incertezze, probabilmente perche` il contatore poteva essere ritenuto a zero
durante una sfortunata fase di commutazione di piu` bit. Per lo meno, non
trovo altra spiegazione.
Gia` l'aver vincolato lo start ad un singolo bit di flag aveva drasticamente
ridotto l'error-rate. Adesso ho proprio rivisto in modo piu` radicale tutta
la logica della SPI con in mente questa problematica e sembrerebbe
funzionare anche a 21. Faccio altre prove e se tutto ok aggiornero` il
sorgente sul sito.
Ciao!
