Dus mijn hypothese is dat er tussen de slaves en de master een verschil van mening ontstaat over hoeveel clockpulsen er geweest zijn.
Dat zie ik niet zomaar, rew. Als we aannemen dat de slaves geen clock stretching doen, dan wordt de clock dus alleen door de master laag getrokken. Als die dus laag blijft, dan zit het probleem hoe dan ook in de master. Als een slave out-of-sync is om welke reden dan ook, dan klopt er wellicht iets niet in de response, maar het kan mi. niet verklaren waarom een SCL laag blijft.
Als ik TS zo lees, dan is het ergens een brak stuk implementatie (hardware of software) wat zo nu en dan de mist in gaat. Dat kan veroorzaakt worden door een bepaalde state waar net een interrupt in optreedt. Of nou juist niet.
Het kan ook een hardware bug zijn. Of zoals Arco al opmerkte: een brakke implementatie in hardware waardoor de boel op z'n b*k gaat als je er niet heel lief in software mee om gaat (bijvoorbeeld een shift-out register zonder shadow register zodat wanneer je daar te vroeg in schrijft je shift-out stuk gemaakt wordt).
Wat je ermee moet? Nou ja, de source van de software implementatie eens goed bekijken (is die beschikbaar?), eens heel goed kijken dat de datasheet zegt over hardware I[sup2][/sup]C. En dan eens kijken of dat matched.
De delays waar Arco het over heeft... Het is natuurlijk wel een 'pic-ding-waardige oplossing'. Maar ja, je moet wel eens wat...
In die context zou het verhogen van de bussnelheid ook wel eens een oplossing kunnen zijn: als je wat plat schrijft tijdens een shift-out en dat is hardware, dan is die mogelijk al voorbij als je de bus snelheid wat op schroeft... Aangenomen dat dat gewoon de setting in een divider is en de software daar verder geen weet van heeft.