Pytanie o I2C

Ja my¶lê, ¿e jak clock nie bêdzie pracowa³ w trakcie tego przerwania to jakby siê dla tej pamiêci czas zatrzyma³ i powinno byæ oki. U mnie na mniejszej prêdko¶ci dziala idealnie z przerwaniami w tle.

PC

U¿ytkownik "szlovak" snipped-for-privacy@o2.pl napisa³ w wiadomo¶ci news:dcd51o$p9p$ snipped-for-privacy@nemesis.news.tpi.pl

Uk³ad I2C-slave nie ma w³asnego zegara a zmiany stanu automatu interfejsowego zachodz± jedynie na zboczach sygna³ów SCL i SDA. Je¿eli nic siê nie bêdzie dzia³o na magistrali to i automat pozostanie przez ten czas w niezmienionym stanie. Ograniczenie na minimaln± czêstotliwo¶æ SCL i maksymalny czas trwania transakcji wprowadzono dopiero w SMBus.

Marek Dzwonnik napisał(a):

dzięki, czyli SMbus ma 10khz a i2c 0 czyli nawet o wiele mniej niż mi potrzeba

To ograniczenie jest prawdopodobnie nominalne - dasz 1Hz i tez bedzie dzialalo ..

J.

"J.F." news: snipped-for-privacy@4ax.com

Potwierdzam. Swego czasu programowa³em rêcznie (uk³ad sk³adaj±cy siê z zespo³u dwóch isostatów, switch-a i inwerterów z wej¶ciem Schmitta do eliminacji drgañ styków) uk³ad syntezy TSA5511 i bez problemu czas trwania jednego s³owa (taktowanie rêcznie switchem :) ) móg³ trwaæ nawet i pó³ godziny. Nie mia³o to znaczenia. W czasie testów wygenerowa³em kilka pierwszych bitów s³owa, zostawi³em tak± "rozgrzeban±" transmisjê i po 20 minutach wróci³em i j± dokoñczy³em i kostka wszystko ³yknê³a bezb³êdnie. Tak wiêc maksymalne d³ugo¶ci czasów trwania impulsów zegarowych, ich wspó³czynniki wype³nienia przy standardowym I2c nie maj± znaczenia - tak wynika z moich testów.

Mi siê tu kojarzy pierwsze kontakty z AT89C2051 Kiedy to w³a¶nie rêcznie na dipswitchach wpisywa³em program skompilowany do wersji binarnej przezemnie na kartce papieru. Heh... To by³y czasy... Ale powiem wam, wychodzi³o mi to nawet, a najd³u¿szy program mia³ 80 instrukcji

Nie mia³em wtedy komputera, a mikproprocesory szalenie mnie interesowa³y No i do dzi¶ mi to pozosta³o