Една кратка лекция за кафето.
Процесорът може да прави само три неща - чете от адрес , пише на адрес и прекъсва. За пълнота ще спомена и 4-то : може да променя данните.
Всичко останало е следствие.
Като напишеш
INT BUFFER [11]
караш компилатора да задели памет за 11 обекта int.
BUFFER [ z]= x;
Това кара компилатора да
генерира код, който сумира адреса на първия елемент от буфера с променливата z, после резултатът се ползва за адрес , на който да се запише числото , прочетено от адреса x.
Компилаторът се опитва да помага, където може.
Ако напишеш buffer [123]= x;
ще забележи, че 123 е повече от 11 и ще свирне. В случая buffer [x] няма как да помогне и оставя това на твоя отговорност.

Какво става, когато декларираш
Int buffer []
?
......
Това е за домашно

Какво става, когато декларираш
Int buffer []
?
......
Това е за домашно

Благодаря за обяснението!

Когато напиша Int buffer [] не ме плюе.

В частност - за декларацията "uint8_t RXbuffer_forslave_1[];" по метода проба-грешка стигнах до извода, че с [] се подразбира [52].
До този извод стигнах, като пробвах да чета RXbuffer_forslave_1[1]; RXbuffer_forslave_1[2]................
До RXbuffer_forslave_1[52] минава и от там нагоре започва да реве.
Ако декларацията съм я направил, както трябва (примерно uint8_t RXbuffer_forslave_1[87];) респективно реве над RXbuffer_forslave_1[87].

По въпроса за:



сложих порт да цъка и той не цъка.

За INTCONbits.PEIE никъде не видях нещо, което да го сетва. Изобщо никъде не видях нещо да има бизнес с INTCON регистъра.

Ако mcu-то имаше memory protection, щеше да питаш "що гърми" ?
Виж в документацията на компилатора какво пише за този тип дефиниране на масив.
gcc-то пише нещо от сорта warning: 'array 'blabla' assumed to have one element'.

Просто успокой малко топката и се върни малко назад. Направи прекъсване по таймер, неговия хандлер да съка порт-лед. Разучи го , както и прекъсванията.

много ме съмнява gcc да пише такива неща... все пак gcc следва стандартите

А стандартно подобно нещо се нарича "отворен масив" (търси в гугъл "open array"). И по принцип може да се ползва за тип или за член на структура, но не и да изпляскаш глобална променлива от такъв тип. Не че е нещо лошо, просто отворения масив в дефиниция е де-факто масив с НУЛА елемента. Но както казах по-добре да се ползва за тип (примерно функция, която може да получава масиви с различни дължини) или като последно поле в структура (виж flexible array member).

Това пише.

Дефиницията е int blabla[]; глобална променлива.
warning: main.c|20|warning: array 'blabla' assumed to have one element|
Компилатор: gcc version 6.3.1 20170215 (release) [ARM/embedded-6-branch revision 245512] (GNU Tools for ARM Embedded Processors 6-2017-q1-update)

Изненада - XC8 компилира и линква int blabla[]



Първия аргумент трябва да е от тип 'указател към uint8_t'. Ако ще се подава не-начален елемент от масив, трябва да има & преди елемента, т.е.

и то при условие, че my_buffer е масив от uint8_t; ако е от тип int - трябва да има каст:

Ако myBuffer има нулева дължина, вероятно ще има намазани други променливи.
Накратко, трябва да имаш нещо подобно:

хм... прав си! Чак се изненадох... според С99 (clause 6.9.2) трябвало да се заделя един елемент и да се инициализира с 0. Тъпо! Отворените масиви се ползват много във всякакви комуникациионни протоколи и тем подонни библиотечки. Навсякъде се разчита че sizeof на структура не се променя с добавянето на поле с отворен масив. Демек в структура не заема място, а извън заема... Тъпо, тъпо...

@tolstolob:

Така въведено:

uint8_t myBuffer[10];
uint16_t address;
I2C2_MESSAGE_STATUS msgStatus;

I2C2_MasterRead(&myBuffer[0],
2,
address,
&msgStatus);


ми дава грешка.


Все си мислех, че MCC е създаден за такива, като мен за да могат хора, които не са много навътре в бизнеса да си свършат работа. В случая се получава обратното. Губя маса време, занимавам и вас за да вникна в нещо неработещо и неразбираемо.

На този етап възнамерявам да изоставя това начинание (i2c) и да си реша задачата с други, по ясни за мен средства - примерно SPI. Осигуряването на достатъчен брой пинове за целта ще ми отнеме несравнимо по-малко време.

Благодаря ви, за помощта. Бъдете живи и здрави!

Луд умора няма. Само се поти

Мислех да я изоставя тая пущина, но сега мира не ми дава. Не че нямам вариант да мина и без I2C....

Накратко - продължавам с копането

И така - това което открих до момента е:

1 - То си го пише, че в потребителския софтуер на slave и на master трябва изрично да се разрешат прекъсванията (global и peripherial) ама някой трябва и да го прочете....

2 - След като ги разреших и за да видя, дали реално ISR функцията в slave се изпълнява, сложих тя да пали led но той се пали само при положение, че в потребителския софтуер на master се извика функцията I2C1_MasterReadTRBBuild ().
При викане на I2C1_MasterRead () - комуникация не се наблюдава и прекъсване в Slave няма.

3 - Впредвид вида на функцията I2C1_MasterRead ():



и описаното в т. 2, си мисля, че не се изпълнява условието (i2c1_object.trStatus.s.full != true), което към настоящия момент не ми е много ясно, какво означава, респективно, какво трябва да направя за да се изпълни.

Според мене не се изпълнява
в Insert

Led - чето се пали при викане на I2C1_MasterRead в потребителския цикъл, но комуникация не се наблюдава и не стартира ISR в slave.



Добавих въпросния ред, но нищо не се променя.

Не ми се четат всички страници.

Моите 5 стотинки. Преди време и аз като учех нещата И2Ц ми беше напълно неясно.
Улеснението е ако имаш осцилоскоп, правиш безкраен цикъл да предава един/два байта и картинката да залепне статично на екрана. ясно ще се види какво (не)върви и има ли акнолиджи.