[elektro] PIC I2C lib

[Moczik Gabor]

Hali!

Teljes egészében megszakításos I2C kommunikációt írok. A slave már eleve 
megszakításos volt, a master-ral görcsölök.

Ha kész lesz, publikussá teszem az egészet. :-)

Az elképzelés, hogy a főprogram eldönti hogy írni vagy olvasni akar, 
kiadja a start_read vagy start_write utasítást, az ehhez szükséges 
címet, adatot lepakolja egy bufferbe, és jelzi hogy mehet. Innentől az 
ISR elintézi ami kell.

A write buffer csak 1 byte, mivel I2C-n tetszőlegesen bonyolult 
kombinációban lehet write/read utasításokat küldeni, a buffer írásakor 
az user mondja meg, hogy amint elment az adat vége-e a tranzakciónak 
vagy nem, az előbbi esetben az ISR automatikusan generál egy STOP 
feltételt is, az utóbbiban veszi a következő adatot és küldi.

Azt nem tudom eldönteni, hogy mi legyen akkor, ha nem kértek STOP-ot, 
tehát nincs vége, viszont az adat elment, megérkezett a megszakíás, de 
még a buffer nincs feltöltve az új adattal (késik a főprogram).

A CPU nagyságrenddel gyorsabb mint az I2C busz, ez elvileg nem 
következhet be ha a főprogramban egymás után vannak az utasítások, de jó 
lenne most már atomstabilra írni ezt a kócerájt.

Bújom az adatlapot egy ideje, de nem látom át, hogy master-ként hogyan 
tarthatnám a buszt. Ha az ISR-ben nem töltöm fel új adattal az SSPBUF 
regisztert, akkor nincs kiszolgálva a megszakítás.
Ha itt letiltom a megszakítást az megengedhető? (SSPIE=0)

A másik, hogy mit volna érdemes tenni ha a slave nem fogadja az adatot 
vagy a kiküldött címet (NAK)?
Most úgy írtam meg, hogy a cím küldésnél generál egy STOP-ot, a 
főprogramnak jelzi hogy nincs válasz.
Ha adat küldésnél kapok vissza NAK-et, akkor mi legyen?
Automatikusan lezárjam a kommunikációt az ISR-ben, vagy bízzam a 
főprogramra? Van gyakorlati példa, hogy NAK-ra nem kell megállni?

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