Student.se

Jag gör ett exjobb som inkluderar ett USB till I2C-gränssnitt från Allt om Elektronik och en PIC16F877:a. Detta har dock, tyvärr, inte visat sig vara någon vidare bra kombination! Orsaken är att konstruktörerna hos Texas Instruments inte har följt I2C-specifikationen fullt ut och "glömt" att lägga till stöd för "clock stretching", dvs en funktion som gör det möjligt för I2C-slaven att hålla tillbaka mastern genom att hålla klock-ledningen (SCL) låg. Jag upptäckte detta när jag försökte läsa från PIC:en via I2C-gränssnittet och mikrokontrollern hanterade avbrottet som genereras av I2C-hårdvaran. Under denna tid drar PIC:en SCL-ledningen låg för att hålla tillbaka mastern till dess att den är redo att skicka data. Mastern upptäcker dock inte detta (pga att detektering av "clock stretching" inte är implementerad i TUSB3410) utan fortsätter glatt att försöka läsa från I2C-slaven innan den har data att skicka. Resultatet blir att den missar ett par bitar av första byten. Vid mätning på I2C-bussen med ett oscilloskop gick det att se "rester" av pulser från mastern på klockledningen strax efter att R/W och ACK-bitarna skickats. Problemet uppstår endast när en mikrokontroller som t ex PIC används som I2C-slav. Hårdvarubaserade I2C-chip är tillräckligt snabba för att reagera direkt när I2C-mastern vill läsa eller skicka data.