Това е осцилограмата, когато се вика функцията I2C_MasterReadTRBBuild(1,10,1,statusReadSlave1):

I2C_MasterReadTRBBuild(1,10,1,statusReadSlave1)
Вместо тази червената единица , процедурата очаква адрес и пише в структурата, сочена от него;
Та най вероятно омазваш някакъв регистър и данни , и предизвикваш прекъсвания;
Осцилограмата показва, че И2Ц регистрите са в някакво читаво състояние, нищо повече;
Адресът който излиза на буса е (0x67 << 1 )+1 (read) и няма нищо общо със твоя адрес 1;


Не е това начинът;
Със същия успех можеш да буташ колата си и да твърдиш, че моторът мърка;

В чаршава на пика пише:

25.5.1 SLAVE MODE ADDRESSES
The SSP1ADD register (Register 25-6) contains the
Slave mode address. The first byte received after a
Start or Restart condition is compared against the
value stored in this register. If the byte matches, the
value is loaded into the SSP1BUF register and an
interrupt is generated. If the value does not match, the
module goes idle and no indication is given to the
software that anything happened.

От това си правя извода (вероятно погрешно), че прекъсване в slave възниква само ако адресът съвпада. Дори пробвах да променям въпросната "червена единица" и установих, че само при стойност 1, прекъсването възниква.

От друга страна, не разбирам, как няколко slave ще слушат шината, ако прекъсване възникваше само при съвпадение на адрес.

Хех, много ясно, че адреса трябва да съвпадне, нали може да имаш N устройства на същата шина
И да, всички слейвове слушат едновременно. А прекъсването възниква само в отделен слейв/устройство.

Т.е - ако правилно съм разбрал:

1 - Всички slave устройства непрекъснато (какъвто и потребителски код да изпълняват), слухтят шината.

2 - Прекъсване възниква само в този slave, който е намерил съвпадение на предавания адрес със своя.


Т.е - ако горното е вярно, експериментите ми показват, че при изпълнение на I2C1_MasterReadTRBBuild(A,B,C,D)
аргументът "A" указва адреса на slave, защото само, ако той е верният (в случая A=1), възниква прекъсване.

С осцилоскопа гледаш шината, там предава мастера - вижда се че не отговаря никой слейв -
какво ги намеси слейвовете?
С тая червена единица омазваш паметта/регистрите на мастера - и какво се случва - само можеш да гадаеш;
Разгледай тази любима твоя функция - само пише няколко адреса, не задейства никакъв хардуер - на теория;
На практика червената единица предизвиква обозяване на хардуера, и ти губи времето;

Понеже вече съвсем се обърках, ще попитам по друг начин:

Може ли да възникне прекъсване от MSSP в slave, ако няма съвпадение на адреса му?

Нали преди малко го цитира от менюала, защо питаш пак?

Питам, защото искам да се захвана за поне едно ясно нещо. В случая в Slave наблюдавам прекъсване а реално, както каза Стефан, не му предавам коректен адрес.

Наблюдаваш, щото пишеш там, където не трябва. Стефан вече ти каза, че бърникаш в грешната функция.

OK. Ще продължавам да се боря с I2C_MasterRead (). До момента - греда.

Ако опитваш със същите сбъркани аргументи на I2C_MasterRead(...), няма да прогресираш много...
Като начало следното трябва да го има след SYSTEM_Initialize(), а в генерираните сорсове не виждам някой да го прави:
Едит: всъщност има ги във вид на функции като INTERRUPT_GlobalInterruptHighEnable(), но са закоментирани.

Това "INTERRUPT_GlobalInterruptHighEnable()" не го намирам, къде е.

Иначе, както писах по-напред, INTERRUPT_GlobalInterruptEnable(); и INTERRUPT_PeripheralInterruptEnable(); съм ги пуснал.

При тебе нямаш 'high', щото си с ПИК16. Гледам, че I2C1_Initialize() си сетва PIE1bits.SSP1IE, така че остава да извикаш правилно I2C API-то и си в бизнеса

Мда. Добре звучи. На този етап си оставам само с викането