<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=CS link=blue vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Nevím jak to řeší Arduino knihovny, ale HW to má takto:</p><p class=MsoNormal> Po každém přenosu byte přijímající strana odpoví bitem <b>ACK</b>=0 a to už včetně adresy. Tzn. první na čem to může zhavarovat je, že slave neodpoví na adresu. Pak když master zapisuje do slave, zase slave může říct dost tím ACK. Při čtení ze slavu, musí naopak master potvrzovat ACK. U nekonečných věcí typu ADC se takto obvykle má čtení zarazit. Nakonec se posílá <b>stop</b> bit, ale to je mimo běžnou komunikaci, stejně jako <b>start</b>.</p><p class=MsoNormal> No a pak je ještě <b>clock stretching</b>: Když slave nestíhá, může SCL podržet v 0 a master by měl na základě toho čekat (libovolně dlouho). A tady je to zajímavý, protože některý (nebo všechny, nevím) ATmegy mají v implementaci chybu, která většinou nevadí, ale RPI zero (a možná i nějaký další, nevím) mají taky chybu a to zrovna takovou, že jejich setkání vede k zátuhům:-)</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>PH</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='border:none;padding:0cm'><b>Od: </b><a href="mailto:zapik@email.cz">Petr Zapadlo</a><o:p></o:p></p></div><p class=MsoNormal>Však já tam tuhle funkci používám, ale byl jsem svědkem toho, že I2C </p><p class=MsoNormal>slave byl nějaký zaseklý a Atmegu mi resetoval WDT, protože se čekalo na </p><p class=MsoNormal>nějakou operaci na I2C sběrnici.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Snažím se tomu nějak předejít a když nad tím tak přemýšlím, tak podle </p><p class=MsoNormal>mě už Wire.requestFrom(I2C_SLAVE_ADDRESS, 10); musí zajistit ten přenos </p><p class=MsoNormal>dat do bufrů, které jsou pak testovány pomocí Wire.available()</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Jelikož nikde nejsou nějaké pauzy na přenos, a funkce RequestFrom a </p><p class=MsoNormal>available jdou hned za sebou, tak podle RequestFrom končí až v okamžiku, </p><p class=MsoNormal>kdy je v bufru 10 byte a pokud zahapruje Slave, tak se to pozná už v </p><p class=MsoNormal>rámci RequestFrom.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>A tem jsem možnost nějakého timeout nenašel.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Myslím si to správně?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Dne 12. 12. 20 v 21:33 Petr Labaj napsal(a):</p><p class=MsoNormal>> Já o Arduinu vím pendrek. Ale podle dokumentace je tam funkce </p><p class=MsoNormal>> available(),</p><p class=MsoNormal>> která je určitě neblokující a říká, kolik dat je k dispozici.</p><p class=MsoNormal>> Takže si timeout a ošetření kolapsu partnera snadno uděláte podle </p><p class=MsoNormal>> libosti sám.</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> ***********************</p><p class=MsoNormal>> Dne 12.12.2020 v 21:04 Petr Zapadlo napsal(a):</p><p class=MsoNormal>>> Zdravím,</p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>>> měl bych dotaz k použití I2C sběrnice, resp k její obsluze.</p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>>> Je to na ATmega328. Příkladový kousek kodu:</p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>>> Wire.requestFrom(I2C_SLAVE_ADDRESS, 10);</p><p class=MsoNormal>>> while (Wire.available()) {</p><p class=MsoNormal>>> pole[i] = Wire.read();</p><p class=MsoNormal>>> i++;</p><p class=MsoNormal>>> if (i>=10){break;}</p><p class=MsoNormal>>> }</p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>>> A můj dotaz, jak se to bude chovat když Slave nějak zahapruje.</p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>>> Funkce Wire.requestFrom(I2C_SLAVE_ADDRESS, 10); má vrátit počet byte, </p><p class=MsoNormal>>> tj v mém případně bych měl dostat číslo 10. Už tato funkce načte </p><p class=MsoNormal>>> těch 10 byte do bufru? A nebo jen dá pokyn "otroku posílej data" a na </p><p class=MsoNormal>>> vlastní přenos nečeká?</p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>>> Má smysl testovat návratovou hodnotu z této funkce?</p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>>> Když Slave neodpoví, kde se to zasekne, bude se někde na něco čekat? </p><p class=MsoNormal>>> Je tam nějaký timeout?</p><p class=MsoNormal><o:p> </o:p></p></div></body></html>