[elektro] PIC I2C lib

[Andras Huszti]

Hali!

> Aztan inkabb elvetettem, mivel nem ismerek minden eszközt, és elvben 
> előfordulhat olyan eset, hogy pl. egy read által visszajött értéktől 
> függ, hogy kell-e még olvasni vagy írni, mit, mennyit.
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
Az iras es olvasas vegyesen nem tunik nagyon ertelmesnek, lehetne, de
eleg kacifantos lenne szerintem.

(Viszont! A modszer amit emlitettem akkor is mukodne, hiszen az
adatokban meg lehet adni, hogy mikor legyen start meg stop. Tehat egy
read utan feldolgozva, adhatsz olyan adatot neki amiben nincs start.
Akar meg mukodhetne is, de eleg bonyolult lenne. Minden esetre
univerzalis.)

> 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
eseten. Nem tudom pontosan az IIC mit ir erre, ugy remlik, hogy a hibas
eseteket a Microchipes doksik nem nagyon taglaljak, de a Philips-es
doksi sem igazan. Vegulis mind1, mert START kondicio utan ugyis
alaphelyzetbe kerul a busz.

> Minél előbb, annál jobb. Ez egyelőre nem multimaster lib, de ebben a 
> szemléletben gondolkodos
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.

> 
> Tényleg, ha bus collision van, a START feltételt vagy a cím küldését az 
> ISR újrapróbálhatná párszor a főprogram nélkül is.
> Kérdés, hogy van-e ennek értelme?
Szerintem nem. Tul sok logika kerul az ISR-be. Erdemes azt karcsun
tartani. Adatot minel elobb normal kontextusba kellene atvinni es ott
feldolgozni.

> Ha multi-master környezet van, akkor a főprogramot úgyis fel kell 
> készíteni az újraküldésre, ekkor meg tökmindegy.
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
ujrakuldheti. Tipikusan az IIC drivert kezelo applikacio egy allapotgep.
Ebben meg konnyu megoldani az ujrakoldest. Viszont ovatosan mert konnyen
elszalhatnak az allapotatmenetek szamai.

> Most epp eleg preciziosra vettem a format :-) eleg sok hibalehetoseg 
> van, ahogy nezem.
Abbol mindig tobb van mint a jo mukodesbol.

> 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.

Miert is fordulhat elo, hogy nincs kuldendo adat(lehet irtad de
kiesett)? Ha belegondolok, akkor ez inkabb tervezesi hiba. Ha
elofordulhat ilyen eset akkor egyszerubb attervezni a programot, ugy
hogy kisebb darabokban lehessen elkuldeni az adatot. Akkora meretet kell
valasztani ami a kuldes kezdetetekor mar rendelkezesre all biztosan.
Masik lehetoseg, hogy meg kell varni hogy osszegyuljun kello mennyisegu
adat. Ha kuldes kozben kifogy es ezt tamogatni kell programbol akkor
marha bonyolult lesz.

> Percek kérdése és eljutok oda hogy kipróbáljam. :-)