[elektro] PIC I2C lib

[Moczik Gabor]

Andras Huszti wrote:
> Jogos. En sem ismerek minden iic eszkozt, de volt olyan ahol read utan a
> write mar kulon frameben ment. Raadasul stop nelkul, siman startal
> kellet kezdeni. Igy nem kellet talalgatni, hogy lesz-e olvasas vagy sem.
> En a kovetkezo konstelaciokat tudom elkepzelni:
>  - csak iras
>  - csak olvasas
>  - irast koveto olvasas
>  - irast koveto olvasas start kondicioval

STOP nélküli START, az a terminológia szerint is érvényes, ez a RESTART 
feltétel.

írást követő olvasás _csak_ restart-tal lehetséges, mert át kell vinni 
egy új címet (főképp a benne lévő R/W bitet). Elvileg lehet hogy a 
masterben be lehet állítani az RCEN bitet R/W=0 esetén is, de a slave 
tuti nem fog küldeni semmit, mert adatot vár. Mindketten beolvassák majd 
az 1-eseket az SDA-ról.

> Az iras es olvasas vegyesen nem tunik nagyon ertelmesnek, lehetne, de
> eleg kacifantos lenne szerintem.

Nem annyira. Ha minden műveletnél meg lehet adni, hogy mi lesz a 
következő, akkor elég logikusan tud kinézni. Nem akarom most itt ezer 
szóval leírni, még nincs 100%-ban átgondolva, de ha kész van, felrakom 
aztán lehet zsűrizni. :-)

>> A slave NAK válasza végzetes hiba? (mármint nem a címre)
>> El tudok képzelni olyan eszközt, ami elfogad további adatot függetlenül 
>> attól hogy az előző adatot nem fogadta el.
 >
> Nem is tudom. Masik leveledbol nekem is felremlet valami az ACK/NACK ra.
> Elso NACK utan en a tobbi adatra is NACK-ot varnek olvasaskor master

Most így elolvasva az I2C dokumentációt, egyértelművé vált:
Az adat fogadója nyugtáz. NAK=transzfer vége.
A master ezután STOP-ot küld.

Master-transmitter esetén ha a Slave NAK-et válaszol, akkor nem tud több 
adatot fogadni, a master köteles befejezni az átvitelt.
Befejezhető előbb is egy STOP-pal.

Master-receiver esetén ha nem akarunk a Slave-től tovább olvasni, akkor 
NAK-et kell válaszolni neki.
Ha akarunk, a slave itt úgy érzem bajban lehet, ha neki nincs mit 
küldeni. Nincs módja közölni, vagy megszakítani az átvitelt.

Erre fel kell készíteni az alkalmazást. Valamit muszáj küldeni.

> Gondolom a tobbi master a buszon(ha lenne) akkor varna egy stop eventre,
> hogy tudja, hogy szabad-e a busz. Vegulis jo strategia lehetne, hogy
> stop ot kuldeni hiba utan mindenkeppen.

Igazság szeint az atvitelt azzal kötelező zarni, végülis a NAK válasz az 
nem hiba, a kommunikáció része. :-)

Hogy mi legyen akkor, ha elkeveredik a rendszer, és egy timeout-nak kell 
kihoznia, az jó kérdés. Én ezesetben kikapcsolnám az SSP modult, majd 
vissza és újra felkonfigurálnám.

Azt át kéne gondolni, hogy kerülhet-e a busz ettől zárolt állapotba.
Elvileg nem:
- Master timeout-ol, elengedi a buszt. A slave-nek soha nincs oka fogni 
a buszt a masterre várva, legfeljebb belül vár az SCL-re. Remélhetőleg 
egy START majd kihozza onnan.

- Slave timeout-ol, elengedi a buszt. A master végigjátssza az átvitelt, 
a byte végén kap egy NAK-et mert az SDA magas.

> Szerintem nem. Tul sok logika kerul az ISR-be. Erdemes azt karcsun
> tartani. Adatot minel elobb normal kontextusba kellene atvinni es ott
> feldolgozni.

Ennyi logika már igazán nem oszt-nem szoroz. :-)
Elég hosszú ám az ISR már most!
(igaz hogy a fele komment, hogy később is értsem)

Mindenesetre nem USB ez, lassú pár byte-os transzferek vannak, ez a 
legritkább esetben időkritikus. Alkalmazásfüggő, de az adatfeldolgozást 
el lehet intézni az ISR-ben is (mármint nem a driverében, hanem az 
alkalmazáséban)

if (SSPIF) {
     i2c_isr(); // driver hívás
     ...        // adatfeldolgozás
     i2c_write...
}

> Es szerintem aplikacio fuggo. Az IIC driver tamogathat ilyet de nem
> feltetlenul kell. Pl IIC_write fugveny parametere lehet a resend. De en
> nem tennem. Tul bonyolult lenne a driver. Masreszrol a foprogram is

Az a baj, hogy univerzálisan biztosan nem lehet megoldani.
Az I2C driver csak a buszt ismerheti, az eszközt amivel kommunikász, azt 
nem. Ha ütközés van, a START-tól újra kell kezdeni, de mivel mint fent 
már vitattuk, függhet az adatoktól hogy mi a következő lépés. Ezt a 
driverben nem tudhatjuk.

A címet újra tudhatná küldeni, esetleg ha a cím után csak írás van, azt 
is, de ennyiért meg felesleges görcsölni.

>> Most azt tettem, hogy ha netan nincs adat, akkor addig letiltja a 
>> megszakitast. Lesz timeout is...

> Nehez dolog ha ISR-bol nem tudod ujratolteni a buffert mert akkor
> jelezni kell a foprogramnak, hogy majd gondoskodjon efelol.

Nem akkora kunszt, I2C_MASTER_TX_WAIT státusz. :-)
De a főprogramban nem kell vizsgálni, egy elkövetkező i2c_write() 
elintézi hogy átkerüljön küldési státuszba és engedélyezi a megszakíást is.

Ha nincs i2c_write, az valóban tervezési hiba, de jobb ha a driver nem 
akad ki mindjárt, majd a timeout elintézi, de legalább lehet debugolni.

> Miert is fordulhat elo, hogy nincs kuldendo adat(lehet irtad de
> kiesett)? Ha belegondolok, akkor ez inkabb tervezesi hiba.

Mivel 1 bytenyi write buffer van, a főprogramban egymás után vannak az 
i2c_write függvényhívások.
Ha mondjuk nem while(..); ciklusban várod hogy végre elmenjen az adat, 
hanem teszel mást, esetleg beüt egy-két másik ISR is, elképzelhető hogy 
nem áll rendelkezésre időben az adat.

> adat. Ha kuldes kozben kifogy es ezt tamogatni kell programbol akkor
> marha bonyolult lesz.

Ugyan...
Át kell lépni egy WAIT státuszba és tartani kell a buszt.

-- 
((( Móczik Gábor  )))--((( e|mail: pm-01 |@| progzmaster |.| hu )))
((( S.k.y.p.e.: moczik )))