Проблема наистина е много странен и вече направо откачих а пак не мога да го отстраня почвам да се съмнявам за хардуерен бъг в SSP модула но като си мисля това е доста малко вероятно.
Да опиша нещата :
Програмата ми измерва едно аналогово напрежение няколко пъти чрез 10bit ADC на PIC намира средно аритметичното от измерванията. Изпраща резултата като два байта по I2C.
След което отново се стартира измерване и всичко си повтаря в цикъл.
PIC е slave устройство в моя случаи. Проблема се състои в това че установих че не винаги получаваните байтове по I2C са коректни.Набеждавах за това всичко аналоговата си част, програмата си дето изчислява, но след идалго блъскане чрез симулация с proteus видях че всичко си работи по същия начин както и на реалната схема и че грешката се появява при определени стойности на изпращаните байтове. Проследих нещата и установих че грешките които се появяват са винаги в първият(най-старшия) бит на байта които се изпраща но се проявяват само при някои стойности на байта а при други не. По конкретно:
при изпращане па 00 66 по магистралата реално се изпраша не това а 00 Е6
при 00 СС всичко е наред и се получава 00 СС
при 01 33 пак си е ОК и се получава 01 33
при 01 98 обаче пак изцепка 01 18
Веднага си казах дъни се когото първият бит които се изпраща от байта е 1 но не е така
при 01 FF всичко пак си е ОК получава се 01 FF
при 02 66 издънка 02 Е6
при 02 СС ОК 02 СС
при 03 30 ОК 03 30
при 03 98 пак грешка 03 18
при 03 FE ОК 03
Пробвах да разменя първо да изпращам младшия после старшия байт нищо не се промени просто се размениха.Грешки си останаха на същите стойности на байтовете.Като гледам на симулацията на proteus още щом се запише байта които ще се изпраща в SSPBUF , още преди да се разреши такта чрез CKP извода SDA се актуализира със стойността на най- старшия бит на байта от SSPBUF.Интересното и най-странното е че при стойностите на байтовите при които стават грешките състоянието на SDA не отговаря на 7 бит от SSPBUF.
Това не е от това че примерно магистралата не е свободна проверих.
Направо не знам какво става . Някой има ли идеи?

Я постни малко код най-добре, има нещо гнило с адресирането ти (Slave режима има два метода адресиране - със 7 или 10 бита), струва ми се, че тоя втория ти байт се приема като адрес на устройството, a не като <data>. Покажи последователността, в която подаваш start, address, data, ack/nack, stop. PIC-а който изпраща има ли хардуерен I2C и как ипзращаш там ?

PICa е настроен да използва 7 битов адрес SSPM3:SSPM0(SSPCON)=1110 защото в други участъци от програмата ми използвам прекъсвания при старт и стоп условие.
Последователността от I2C свалена чрез terminal-I2C на proteusa e:
S AB A 00 A E6 A 00 A E6 A 00 A E6 A ...............................00 A E6 N P
Master устройството ми не е PIC AT89C51 e I2c комуникацията при него е реализирана софтуерно. Всички времена са по-големи от минималните на PIC освен това тя си работи със сигурност тъй като към магистралата има свързани и други slave устройства освен PIC с които комуникацията е без никакви проблеми.Но проблема не се дължи и на конфликт с другите устройства пробвал съм и при изключени от магистралата всички slave устройства освен пика и проблема пак си остава. Още по странното е че в други участъци на програмата ми PIC работи и в режим на slave приемник и там абсолютно в всичко си е наред.
Колкото до кода ето участъка който изпраща байтовете:
newIzm bsf STATUS,RP0 ;банка 1
izStar btfss btGotPre ;SSP очаква ли да за почне предаване на данни? Този бит се управлявя от прекъсванията от SSP модула и се установява в единица след приемането адреса на PIC
goto izStar
bcf btPred2B ;не се предава байт2 а първи
btfsc SSPSTAT,P ;при открито стоп условие се прекратява комуникацията
return

.
.
. извършва се измерването
bcf STATUS,RP0 ;избор банка 0
bcf STATUS,RP1 ;избор банка 0
movf z2,w
bait2 call iz4Send ;изчакване завършване на вече започнало изпращане
call StSend ;стартиране изпращането на байта от W
btfsc STATUS,C
return
bsf STATUS,RP0 ;избор банка 1
btfsc btPred2B;
goto newIzm ;ако btPred2B=1 т.е. ако се е предавал втория байт
bsf btPred2B;предава се байт2
bcf STATUS,RP0 ;избор банка 0
movf z3,w
goto bait2
.
.
.
goto newIzm


;============================================================================================
;подпрограма за изчакване завършване изпращането по I2C
iz4Send
bcf STATUS,RP1 ;избор банка 1
bsf STATUS,RP0 ;банка 1
btfsc SSPSTAT,P ;открито ли е условие stop
return ;да изход от подпрограмата
btfss SSPSTAT,R_W ;ще се 4ете ли от PIC
goto iz4Send ; не проверките се правят докато се мине към четене
btfss btZavPr ;Завършило ли е предаването този бит се установява в порограмата за обслужване на прекъсването от SSP при изпратен байт
goto iz4Send ; не е
bcf btZavPr ;завършело е
bcf STATUS,RP0 ;банка 0
return
;=======================================================================================
;подпрограма за стартиране на изпращането на байт по I2C
StSend bsf STATUS,RP0 ;избор на банка 1 RP0=1
bsf STATUS,C
btfsc SSPSTAT,P ;открито ли е условие stop
return ;открито е условие stop
bcf STATUS,RP0 ;избор на банка 0 RP0=0
bcf SSPCON,WCOL; Clear the WCOL
movwf SSPBUF ;стартиране на изпращането
btfsc SSPCON,WCOL; Was there a write!!!!!!!!!!!!!!!!!!111
goto StSend
bsf SSPCON,CKP ;разрешаване на такта
bcf STATUS,C
return
;=======================================================================================

Установих някаква периодичност в грешката която се получава. Като пробвах за всяка стойност от 00 до FF получих следното:

стойност която действителна стойност
записвам в SSPBUF която се изпраща по I2C
0X 0X
1X 1X
2X 2X
3X 3X
4X CX
5X DX
6X EX
7X FX
8X 0X
9X 1X
AX 2X
BX 3X
CX CX
DX DX
EF EX
FX FX

т.е. грешката се появява само при изпращане на числа от 64(40) до 175(BF)
Някои имали някакво обяснение за тази странна работа на мен ми се вижда че няма освен се повече се замислям за хардуерен бъг на процесора но не ми се вярва.Не мога и не мога да намеря обяснение за това дето се получава.
Ако някой е използвал SSP модула на PIC16F88 в режим на slave предавател моля да драсне някой ред по въпроса

Ти по какво съдиш за това "действителна стойност която се изпраща" - ако съдиш по това което приемаш тогава би трябвало да кажеш "действителна стойност която се приема" - с един най-обикновен калкулатор можеш да видиш че 7-ми бит ти се приема и като 8-ми - с други думи осмия не се приема а за 7 и 8 приемаш седмия - нещо не ти е добре тайминга в приемника. Ако ползваш хардуерния модул на пика - едва ли той окашорва работата.

Използвам точно SSP модула на PIC в режим на I2C slave предавател.Това че 7 и 6 бит са еднакви ясно не мога да разбера защо се получава така.Значи по принцип съгласно PDF за SSP при работа ката slave предавател след приемането на адресният байт и генерирането на потвърждението хардуерно се задържа такта CKP=0 което принуждава master да изчака и се генерира прекъсване. В отговор на това прекъсване софтуерно трябва SSPBUF да се зареди с байта който ще се изпраща.Това зареждане предизвиква и прехвърляне на байта от SSBUF в изместващият регистър на SSP при което на SDA трябва да се установи стойността на седмият бит от байта. След това трябва да се разреши такта чрез поставяне на CKP в 1.
Когато симулирам схемата постъпково всичко си става точно така с изключение на случаите когато записаният байт в SSPBUF е от 64 до 175.В тези случаи при записването на байта В SSPBUF на SDA извода не се установява стойността на 7 бит, а тази която наистина отговаря на 6 бит.След един тактов импулс съответно на SDA се извежда стойностна на 6 байт след още един тази на 5 и т.н всички с изключение на седмият които се извежда първи са си ок. При положение че записвам в SSPBUF един байт и на изхода SDA не се извежда седмият бит на записаният байт това не намирисвали на някакъв бъг в SSP модула?