вопрос по протоколу обмена

[rubel]

... Достаточно в конце пакета передать "холостой" байт, и по подтверждению от слейва на него судить о том, прошла передача или нет. ACK - передаем следующий пакет, NACK - повтор предыдущего. Ошибки на I2C - редкость и вводить большой "оверхед" для борьбы с ними ИМХО не стоит.

можно и так,- но для приложения,где длина посылок фиксирована и вы точно знаете сколько времени займет подсчет КС слэйвом. а если длина переменная? и к тому же неизвестно каким алгоритмом пользуется автор при подсчете КС. может он полиномы склоняет...
А насчет коррекции ошибок типо "стоит -не стоит"-решать автору.ему виднее, сколько буит "стоить" эта "редкая ошибочка". Если малого время отклика на команду не требуется, Возвращать CRC - самое оно.

[kison]

Сообщение от kison

Просто ждать можно очень долго.

Это завист от установки таймера и количества попыток, а эти величины зависят от задачи. После превышения количества попыток мастер понимает, что связи нет.

В варианте мастер‹-›слейв ни от какого таймера ничего не зависит. Для чтения нужны условия - старт/адресация+R и т.д. Если мастер этого не сделает, то ничего и не получит. А если сделает, то и ждать не надо. Но на это уйдет время, причем довольно большое.

Используйте арбитраж.

А смысл сего действия? Создать себе лишние проблемы на ровном месте? Были бы при этом какие нибудь преимущества. А так одни минусы.

[kison]

можно и так,- но для приложения,где длина посылок фиксирована и вы точно знаете сколько времени займет подсчет КС слэйвом. а если длина переменная? и к тому же неизвестно каким алгоритмом пользуется автор при подсчете КС. может он полиномы склоняет...

Мне все равно сколько. В стандарте шины оговорено, что слейв может "попридержать" мастера удерживая SCL в низком уровне. И время этого не оговаривается. Мне вполне хватает времени посчитать CRC. Именно так релизована шина в интеллектуальных слейвах - микроконтроллерах. Ведь система может быть занята и отработает прерывание от модуля I2C с большим запозданием. Но данные потеряны не будут - мастер подождет

А насчет коррекции ошибок типо "стоит -не стоит"-решать автору.ему виднее, сколько буит "стоить" эта "редкая ошибочка". Если малого время отклика на команду не требуется, Возвращать CRC - самое оно.

Ну, от самой идеи ввести в протокол КС я автора не отговариваю. А вот в передаче ее назад смысла не вижу. Достаточно дать понять мастеру, что посылка вполне валидна. В принципе, если шина не загружена, то можно ( но нужно ли?) и назад передавать. Все от конкретики зависит.