Stránka 1 z 2

I2C clock stretching

Napsal: 20 čer 2019, 15:46
od ZdenekHQ
Dneska jsme se v debatě poněkud zacyklili, jak vlastně řešit clock stretching u čipu. On po adresaci potřebuje 10-150ms na to, aby se probudil, pak pošle ACK. Jenže já tu dobu neznám a nevím, jestli mu můžu posílat hodiny, dokud nepošle ACK? A bez hodin snad ACK nepošle?

Na obrázku je to ten první byte, pak je pauza a následná další komunikace.

Jak to vlastně je? Tvrdá pauza je taky řešení, ale škoda 150ms, když je to výjimka jednou denně.

Napsal: 20 čer 2019, 17:27
od PotPalo
Však pozastav hodiny po dobu, pokiaľ nepríde ACK. V datasheete je čo? CLOCK má ostať L alebo H? Na ňom čakáme na ACK, potom pustíme hodiny ďalej. Samozrejme dať timeout, napríklad 200ms, keby sa dačo pošahalo, aby to neostalo zamrznuté.

Napsal: 20 čer 2019, 17:49
od ZdenekHQ
To tak jednoduchý nebude. Podívej se na ten průběh signálů.

Napsal: 20 čer 2019, 19:08
od PotPalo
No veď vidím. Žlté je CLOCK, zelené DATA? A to padnutie DATA na L za cca polovicou obrazovky je ACK? Potom by sa hneď mohol spustiť CLOCK, nečakať zbytočne. Skrátka nemať pevne definovaný čas CLOCK, ale mať detekciu ACK.

Keď som robil čítanie a zápis do 24LC16, riadil som zvlášť CLOCK aj DATA. Keď sa čakalo na ACK, tak sa čakalo. Nezáležalo ako dlho. Stačí urobiť nejakú krátku slučku, kedy stojí CLOCK a kontroluje sa DATA kedy príde ACK, potom sa pokračuje. Ak sa slučka skončí a ACK nepríde, nasleduje skok na ERROR.

Napsal: 20 čer 2019, 21:42
od Crifodo
Když jsme se tu tak dojímali ve vedlejším vlákně nad ****ním češtiny, jmenuje se to nějak česky?

Napsal: 21 čer 2019, 11:12
od ZdenekHQ
To asi těžko.

Navíc onen zákazník i hezký český pojmy překládá do vlastní angličtiny, takže mu občas vůbec nerozumím. I tady se rozčiloval, že je to "ACK stretching" a ne "clock stretching" a pak z něj vypadlo, že už na to narazili, I2C se kousala a oni nevěděli proč, protože to prostě ignorovali.

P.S. Bavíme se třeba o měniči a on řekne, že tam bude nějaká disipace. Chvilku se mně kouří z hlavy, než mně dojde, že mluví o účinnosti. A tak je to pořád.

PotPalo má zřejmě pravdu, podíval jsem se v klidu do dokumentace I2C a ten ACK skutečně spadne do nuly i bez hodin. Pak je to jasný.

Napsal: 21 čer 2019, 17:55
od PeteBurns
Takze nie je az taky looser ako o sebe tvrdi, je tak? ;)

Napsal: 21 čer 2019, 17:59
od ZdenekHQ
Není. Jen potřebuje zvednout sebevědomí, což sám doma před zrcadlem nedá.

Napsal: 26 čer 2019, 13:36
od ZdenekHQ
Už jsme se dobrali korektního řešení, jak by to mělo být, i když autor té součástky použil daleko elegantnější řešení (nemusí se hlídat SCL).

Psát na tohle SW driver je tedy docela pakárna. Pokud bych přidal z definice I2C, že to může být multimaster komunikace s detekcí kolizí, pojmenoval bych to skoro jako horor.

Napsal: 26 čer 2019, 14:16
od PotPalo
Tak podľa tohoto obrázku je to inak ako som písal. Zvyčajne je SCL iba vstup do riadeného zariadenia (do SLAVE), ale v tomto prípade je to aj vstup, aj výstup (podobne ako SDA). Ako výstup sa používa práve na ten clock stretching, zariadenie drží SCL na LOW.
Softvérovo to ošetriť nieje ťažké (a dalo by sa aj čisto hardvérovo, pokiaľ má master signál WAIT), treba mať v MASTER vstupno-výstupný port SCL (prípadne dorobiť vstupný, stačí akýkoľvek vstup, oddeliť odporom od SCL OUT). Potom už len podmienka: pokiaľ SCL OUT (=high) <> SCL IN (=low), je aktivované clock stretching slave zariadením, a treba čakať (až pokiaľ SCL IN nebude tiež high). Ak som to teda správne pochopil. Pokiaľ to pri tom zároveň používa aj ACK na SDA, tak stačí sledovať ten.

Ľudovo povedané, SLAVE kecá MASTERovi do CLOCKu.

ZdenekHQ píše:...Jen potřebuje zvednout sebevědomí...
Skôr potrebujem nájsť zmysel života (alebo spriaznenú dušu opačného pohlavia). Sebavedomie som nikdy nemal, tu nieje čo zdvíhať. :|

Napsal: 26 čer 2019, 15:30
od ZdenekHQ
V podstatě ano, jenže některý procesory mají přepínání direction(směru) portu IN/OUT(vstupní/výstupní) a je to pak pakárna, pokud se to emuluje softwarově. Prostě i dva obsazené piny (SDA,SCL) jsou někdy "moc".

Napsal: 26 čer 2019, 15:40
od PotPalo
Tak potom v mieste "Clock Stretching" prepnúť SCL na IN, načítavať stav a čakať až bude HIGH (mal by tam byť pull-up rezistor). To je celé. Následne sa môže SCL prepnúť zasa na OUT a pokračovať.

V tomto prípade by to hardvérovo išlo spraviť tak, že medzi CLK na master a CLK na slave dať rezistor, a operačným zosilňovačom podľa stavu [Vmaster>Vslave] aktivovať WAIT.

Napsal: 26 čer 2019, 15:44
od ZdenekHQ
Ano. Na papíru to vypadá jednoduše. Horší je to v praxi, když se třeba mění piny.

Každopádně pak si ten slave ten clock vygeneruje vlastně sám tím, že uvolní SCL.

Napsal: 26 čer 2019, 15:46
od ZdenekHQ
PotPalo píše:V tomto prípade by to hardvérovo išlo spraviť tak, že medzi CLK na master a CLK na slave dám rezistor, a operačným zosilňovačom podľa stavu [Vmaster>Vslave] aktivovať WAIT.


Tak tady jsi se skutečně zbláznil. Už si dej STOP bit.

Napsal: 26 čer 2019, 15:50
od PotPalo
Zvláštny systém pauzy pri zaneprázdnení. Nechápem, prečo nemohlo ostať klasické [ne]oznámenie odpoveďou ACK po poslaní ŠTART, ako je to pri zápise na serial eeprom rady 24xx.


edit:
ZdenekHQ píše:...Tak tady jsi se skutečně zbláznil. Už si dej STOP bit.
Prečo? Ono by to aj fungovalo, skrátka pokiaľ slave drží clock dolu, master má čakať. Len aby slave nezamrzol, to by to zamrzlo komplet. Inak uznávam, že je to blbosť, je to iba krajné riešenie pokiaľ by to už softvérovo nešlo inak.