Не могу понять- если я в слейве хочу принимать данные на прерываниях, то эта ф-я сама будет вызываться что-ли? Или мне ее крутить самому надо в вечном цикле? Почему тогда она к прерываниям относится? Если это просто опрос ф-ии?
Просто логику не понять.

Как я понял Вам нужна колбэк функция. Которая вызовется после окончания приема. Если проэкт генерился в КубеМХ.
At reception end of transfer, HAL_I2C_SlaveRxCpltCallback() is executed and user can
add his own code by customization of function pointer HAL_I2C_SlaveRxCpltCallback()

HAL_I2C_Slave_Receive_IT должна вызываться сама, цикл не нужен.

Спасибо.
Итак,
HAL_I2C_Slave_Receive_IT
вызывается сама по окончании приема, без цикла опроса.

HAL_I2C_SlaveRxCpltCallback()
это откуда взялось? Её мне как-то надо использовать? Или достаточно первой?
Да, проект в кубе сгенерён.

Там есть затычка-пустышка с атрибутом __weak.
А Вам нужно написать нужное Вам без этого атрибута.

т.е. я переписываю у себя ф-ю
HAL_I2C_SlaveRxCpltCallback()
куда происходит вызов при получении данных в прерывании?

А HAL_I2C_Slave_Receive_IT
как-то использую?

Как то придется использовать
I2C_TwoBoards_ComIT

раньше была кнопка dowload zip, теперь нет её.
git-clone
выдает ошибку на ссылку. Только в браузере могу просмотреть.
Выкачать можно от туда? И как?

Надо перейти в корень хранилища и там всё есть.

а так ?
STM32Cube_FW_F4
Хотя все эти примеры есть локально в хранилище Куба (путь есть в настройках Куба)

Это не принципиально- как с гита скачать. Можно и просто текст скопировать было.
Тем не менее, вопрос остается.

Попробую еще раз переформулировать его.
есть ф-я weak, которая была переписана.

Я так понимаю, что если нам при приеме надо что-то делать, то это именно она. Тут она зажигает LED. Можно обойтись без нее? Думаю, да. Судя по коду.


Дальше, есть вызов ф-и в main() ,но до вечного цикла


Получается, надо единожды передать ей массив и размер и структуру?
Дальше само на прерываниях будут приниматься значения в массив?

дополню вопрос- чтобы еще раз получить сообщение в режиме слейва мне что надо сделать? Ждать, пока массив обновится или вызывать повторно эту ф-ю?
Вот что не ясно.

Конечно надо её вызывать. По коду видно что после приема нужного кол-ва байт прерывания запрещаются.

т.е. чтобы получить новую порцию байт- вызываю ф-ю
HAL_I2C_Slave_Receive_IT
я ее вызываю, она активна, как только там данные пришли, на их получила? Или вызвав ее, если нету данных, то ничего потом не будет принято? Если данные позже придут.

Подглядел на ютубе- вызывание делается в ф-ии
HAL_I2C_SlaveRxCpltCallback



Это оптимальное решение, наверное?

Вот честно, так и нет ясности- для приема в режиме мастера или слейва на прерываниях, надо как вызывать ф-ю?
Чтобы при приходе адреса данного I2C устройства, происходили прерывания и выполнялась ф-я?
Не крутить же ее все время? Что это за прерывания тогда такие?

Разобрался немного.
Чтобы принять данные на прерываниях в режиме слейва, надо делать так:
До входа в основную петлю вызываем ф-ю


и теперь проц будет ждать пока не придут данные. После этого, массив slave_rx_buff заполнится данными и на этом прием закончится. Ничего больше не будет приниматься.
Чтобы продолжить прием, надо написать ф-ю

где при каждом прерывании будет выполнятся код в теле. И запускаться вновь на ожидание прерываний. Причина- как писали выше- после приема данных, прерывания по i2c запрещаются. Мы т.о. снова их разрешаем.

еще вопрос- как при приеме в ф-ю
HAL_I2C_Slave_Receive_IT
данных из вне от мастера, узнать, сколько байт было передано и реально принято?
Не нашел в I2C счетчика принятых байт.

ерунда какая- то творится с I2C.
Принимает на прерываниях один пакет, дальше ничего не принимает и виснет.
Заметил, что

вторая строчка выдает


Кто-то сталкивался? Как корректно вообще работать с I2C на прерываниях и HAL?

при работе с другим МК STM32 в качестве мастера, все ок.
Как только подключаюсь к другой железке, она мастер, принимаю один пакет, а после второго пакета висну, в регистре ISR висит бит BUSY.
Из-за чего может быть?

Удалось побороть?

Проверяйте отработку слейва по ACK-NACK.
Возможно также, что в этом случае "залип" мастер, ожидающий готовности slave.
Посмотрите осцилографом, что твроится на шине. А лучше лог. анализатором.

Кроме того ожидание в стиле
while( GetState() ) { forever} не феншуй, по причине возможного зависания и постоянного дергания опрашиваемой периферии.
(если это не опрос флага-переменной, которая устанавливается в векторе прерывания)

Побороть не удалось. HAL на кубе, применительно к I2C глючный. Замечено, что тот же код работает на разных МК совершенно по разному.
Пришлось на регистрах писать.