VB6.0 a 24C16

[Tom Mazouch]

Ing. Roman Kolb?bek wrote:
> 
> A ten ACK testovat 300x dokola, jak jsem pochopil o neco niz ;-).
> Ale za pokus to stoji.

Nooo...tady asi ne. To by se pak musel testovat kazdej bit :-). 
Tam to byla trosku jina situace.

> akorat ze ja jsem predpokladal, ze to goto 1) udelam maximalne 2x.
> Takze pokud nedostanu ACK trikrat po sobe, tak nad pameti zlomim hul a
> prohlasim ji za vadnou.

Zalezi na rychlosti komunikace. Spis nez max. pocet pokusu bych tam dal
nejakej timeout.

> Kdesi jsem cetl, ze nekdy maji zarizeni I2C problem zachytit start bit
> a ze pomuze tesne predtim udelat stop. Ale toto mne ted moc netrapi. V

To bude asi o necem trosku jinym, tipl bych, ze slo o SW emulaci I2C
slave, tam se doporucuje poslat start, 0x01 (tusim), restart a teprve
ted zacit.
S I2C si lze nabehnout jinak, zalezi na kvalite a vychytanosti tech
rutin. Napr. kdyz jsem si psal I2C master sam, taxem pred prijmem ACKu
zapomnel uvolnit SDA, takze pri vhodnych datech jsem si ACK generoval
sam :-).
Nebo dalsi priklad "blbosti programatorovy" - v rutine STOP mam ted na
zacatku "stazeni" SDA. Nez jsem to tam dal, tak STOP neSTOPoval, protoze
pokud jsem skoncil s SDA=1 (treba proto, ze jsem posilal zaverecny
nACK), tak nesel stop vygenerovat (nahodit neco uz nahozenyho nejde :-).

Jeste detail: nACK na konci cteni se posila proto, aby tc. vysilajici
I2C slave nezacal posilat dalsi data. Pokud by si pridrzel SDA=0, master
by nedokazal poslat stop.
Proste cteni musi koncit nACK, STOP, jinak muze slave zustat v neznamym
stavu a dalsi operace se nepodari. To by se pak mohlo projevovat tim, ze
funguji jen "liche" operace.

A hlavne je potreba se presvedcit, ze to tak je v programu a ne pouze v
mysli programatora :-).

  TomM