Какъв език използваш за кода? Питам, защото за MikroC има такъв пример ТУК

Той писа по горе, асм

Когато мастъра изпрати байт, слейва трябва да потвърди приемането с ACK, което е сваляне на SDA в лог. 0. Ако линията не е свалена в определения момент, мастъра счита това за NACK, т.е. няма предаване на NACK от слейва към мастъра. Това означава още, че ако слейва не е запоен или поне една от двете линии е прекъсната, мастъра пак ще детектне NACK.

Това съм го пропуснал... Може да свали примера, да го преработи и да види ASM файла.

Какво значи вида но АСК? Ти не знаеш ли къде какво пращаш?
Имаш вариант, слейва автоматично да задържа линията след като получиш валиден адрес с бит AHEN и валидни данни с бит DHEN.Слагаш в буфера каквото ще слагаш там и софтуерно с CKP подаваш ACK

Вида на ACK означава неговото състояние ACK=0 или ACK=1.
Потвърждението ми е подчинено на хардуера на модула,тоест той го определя автоматично на база дали са спазени някои условия.
Нямам контрол над него и не искам ръчно да го определям.
Искам да знам след като е било генерирано от моя хардуер към главното у-во ,каква стойност е било 0 или 1.
По този начин ще си правя изводи в каква посока да поеме софтуера.
И специално подчертавам търся метод за откриване стойността на ACK веднага след приемането на байт със съвпадащ адрес , а не след байт с данни.(казано по просто получава се съвпадащ адрес,прекъсва и аджеба АСК=? ,което е изпратено от моя хардуер към мастер)
Благодаря.

Абе как 0 или 1? ACK винаги е 0! Ако си го пуснал автоматично значи на деветия такт отговаря с ACK, след като си е разпознал адреса. Проблемът ти не е как отговаря слейва, щото то е ясно как отговаря, а колко време(инструкции) ти е един такт и от там си сметни колко време имаш и за какво. А ръчното управление на ACK не ти бърка по никакъв начин мастера, това си е част от протокола и мастера ще неще е длъжен да го изпълни, а за софтуера на слейва това е една инструкция.

Ако буфера е пълен или бит sspov=1 след като се приеме(или по време на приемане) на слейв адреса какво става.Какво ще е потвърждението към мастер?

Няма да има потвърждение, но за да се стигне дотам значи софтуерът ти е пълна боза, защото след първото приемане на адрес вече си потвърдил веднъж автоматично, че си го приел, но не си прочел буфера, което е проблем в софтуера ти, щото ако нямаш време да прочетеш адреса то кога ще го четеш, кога ще го сравняваш и кога ще реагираш... никой не знае. Затова ти казах да си сметнеш времето за реакция и да реагираш според него. Може да сетнеш BOEN, с който избягваш препълване на буфера и дори да не си го прочел новите данни се приемат и изместват старите, но така замазваш проблема, ако го има, защото ако не си прочел адреса, а мастера вече ти праща данни кашата става пълна.

Всъщност има ли го тоя проблем или само си мислиш, че може да го има? Я дай малко информация на колко МHz ти работи слейва и скоростта на I2C !

Използвам контролер PIC16F1786 с вътрешен осцилатор 4MHZ (Tcy=1us).
SLAVE ми е изграден вътре в този контролер като готов модул (MSSP).
SLAVE работи на 100kbps.
Clock streching ми е разрешен и за приемане и за предаваме на данни,тоест ще задържа линията и в двата случая,след бита за потвърждение(9 импулс).
Бит BOEN съм го нулирал(BOEN=0) ,за да не се презаписват данните и по този начин да загубя някои от тях,ако например мастера е по-бърз от слейв (работи например в режим 400kbps) ,но в моя случай той е известен и работи на 100kbps също като слейва.А пък и колкото и да бърза мастера, слейв хардуера ще задържи линията веднага след 9 импулс за да имам време аз в софтуера да си свърша работата и след това ще я отпусна.
Мисля си ,че може да настъпи проблем или някакво объркване в слейва ,защото софтуера ми се занимава и с други дейности като измерване на напрежение ,чрез АЦП , измерване на температура ,като чете данните за нея от цифров датчик 18B20. Температурата се чете от датчика бит по бит и се пращат команди за това и за конвертиране ,като това са процеси, които докато траят не трябва да има прекъсвания.Именно тук преди да ги започна аз забранявам прекъсванията в контролера и след приключването на процесите разрешавам отново прекъсванията.
I2C модула забранявам и разрешавам успоредно с прекъсванията.
I2C комуникацията ми е базирана да работи в програмата за обслужване на прекъсванията,поради факта че следи флага SSPIF ,а той се установява след 9 импулс на всяко I2C съобщение при наличие на условие старт разбира се(няма да навлизам в подробности,който се занимава с този тип модули в контролерите са му известни тези неща).
Мисълта ми е следната аз незнам кога мастера ще поиска данни от мен(слейв) ,нямам и отправна точка която да следя .
Той може да ги поиска във всеки един момент ,ако в този момент слейва е забранен заедно с прекъсванията ,мастера ще установи че няма никой вкъщи и ще си предприеме действията които са му зададени понататък.
Нещата стоят по-различно ,ако слейва ми е разрешен заедно с прекъсванията ,има активна комуникация между мастера и слева ,но идва момента след като съм излязъл от програмата за обслужване на прекъсването от SSPIF ,когато трябва да се забрани и слейва и прекъсванията за да се чете датчика за температурата.
После като приключи този процес и разреша слейва и прекъсванията ,тогава комуникацията ще бъде вече нарушена ,компрометирана.
Какво да направа аз тогава?

Не знам с какъв акъл ще прекъснеш активна връзка, за да четеш датчици. Температурата толкова бързо ли се променя, та е важно да я прочетеш баш по време на комуникацията с мастера? Ако забраняваш I2C на всяко излизане от прекъсване, ти съсипваш всеки опит на мастера нещо да получи. И цялото I2C в прекъсването... подходът ти е тотално сбъркан

Измислил съм го по следния начин: инициализира се контролера,прекъсванията и комуникационния модул са забранени,измервам си необходимите параметри(напрежения,температура,ток и т. н.),за което е необходимо около 150ms време ,след това задавам ново време от порядъка на 520ms (TIMER1) ,като след изтичането му ще се премине към изпълнение на главната програма отначало (тоест това е време до следващото опресняване на данните).
Веднага след като съм стартирал това време да тече (520ms) ,разрешавам модула за комуникация и прекъсванията,като
по този начин се получава един прозорец от време ,в който SLAVE ще може да отговори на евентуална заявка от страна на мастера и да комуникира с него(преди това не е било възможно да се случи това ,защото е бил забранен.Мастера колкото и пъти да го търси ,няма кой да му отговори.)След като изтече времето от 520ms ,времевият прозорец се затваря и комуницацията става невъзможна (забранява се комуникационния модул и прекъсванията).
Докато тече времето от 520ms или иначе казано времето до UPDATE DATA ,процесорът не се занимава с нищо друго освен да проверява за изтичането на времето и при евентуална комуникация да прекъсне и да я обслужи съответно.
Засега горе долу това ми се върти из главата.

Имам и друга идея ,но засега нещо и се чудя:
Тъй като мастера не знае кога точно да попита слева за данните ,си мислех например да ползвам пин SDA като цифров пин настроен като изход ,като докато тече процес по замервания на данните ,да нулирам SDA=0 и едва когато данните са готови (приключил е процеса на измерване) SDA да се настрой като вход и тя съответно ще се издърпа от резистора към 5 волта ,ще стане лог.1.Всичко това гореспоменатото се прави при изключен комуникационен модул за да не му влияе.Модула се включва заедно с промяната на SDA от изход към вход.
Мастера пък от своя страна ще следи пин SDA и така ще разбира кога има данни за него и съответно да се включи и да ги вземе,и кога данните не са готови ,съответно да не прави излишни и безсмислени заявки към слейва.
В общи линии е това.
Какво мислите по въпроса?

Това което си направил не изглежда никак ОК. Спокойно можеш да си правиш всичко едновременно. Изпозлвай прекъсванията по предназначение. каквото и да мериш, си го мери, няма нужда да спираш каквито и да са прекъсвания по това време. В прекъсвнаията не прави нищо друго освен да обработваш източника на прекъсването и да си вдигаш съответните флагове.
В майна имаш един безкраен цикъл, в който си проверяваш съответните флагове които ти вдогаш и вършиш съответната работа, ако е по сложно и разклонено си слагаш стейт машина. В момента това кеото си направил е едно губене на време във въртене на безмсислени цикли, но в същото време се лимитираш какво можеш да свърши в тези цикли.
Няма нужда да си спираш прексъването и комуникацията, особенно на I2C-то. Нека мастера те полира на необходимото време, не знам какво рпавиш, може да е 100 ms, може да е 500 ms а може и да е 1 ms, няма значение. Каквото и да е, ти ще му отговаряш при всяко полиране без това да ти бърка измерванията, и без да с еправи слейва на умряла риба докато мери.
Изобщо забрави за подхода с чакания нещо да се случи, това може да се прилага като изключение в някакви много редки случаи.

Обръщам се специално към ToHu ,ако прочетете в по-преднире ми постове ще забележите че съм обяснил ,защо неможе да работи всичко едновременно,Има цифров датчик за температура ,който използва 1WIRE протокол за обмен и ако в същото време мастера поиска данни от слейва (от мен ) ,а при мен се изпълнява в този момент някакви операции с датчика 1WIRE протокола ще бъде нарушен и данните ще са компрометирани,защото аз ще трябва да прекъсна ,за да обслужа прекъсването за и2ц комуникацията и 1wire отива по дяволите.

Не е точно така, зависи как си реализирал one wire комуникациията, там скороста не е висока, има достатъчно време за да обслужваш и i2c, като между другото двата процеса ще са реално паралелни.
P.s. Предполагам използваш библиотека която пък ме използва никакъв хардуер дори и таймер.