Итак, ситуевина. Есть шина i2c на ней висят два мастера и одна еепромка.

Мастеры одновременно (ресеты обьединены) начинают ломиться в еепромку на запись. Но в разные адреса.

М1 ломится в 0А по адресу страницы 00 0F и пишет туда байт 'B'
M2 ломится в 0А по адресу страницы 00 FF и пишет туда байт 'B'

Исходя из правил арбитража М2 арбитраж должна проиграть и свалить с поляны. Однако, что происходит на самом деле:

Итак, осциллограммка для привлечения внимания.


Красный квадратик отмечает место, где идет конфлик уровней. Как видим, запись прошла в ЕЕПРОМ по адресу 00 0F - Еепром подтверждает это.

Что же о процессе думают два контроллера? Я писал в буфер лог работы конечного автомата прерывания TWI (тупо TWSR) и выдавал потом в уарт. Получил такую картину:

М1: 08 18 28 28 28
M2: 08 18 28 28 28

Расшифровка если кто не помнит:
08 - передан СТАРТ
18 - Передан адрес девайса и получен АСК
28 - передан первый байт (00) и получен АСК
28 - передан второй байт (0F vs FF) и получен ACK
28 - передан последний байт 'B' и получен АСК
- дальше будет стоп.

Хотя по логике шины должно быть так

М1: 08 18 28 28 28
M2: 08 18 28 38 ...........08 18 28 28 28

38 - проигрыш арбитража и старт(опционально) после освобождения шины

Почему М2 продолжил передачу, хотя пролажал арбитраж на целой тетраде? Аппаратный глюк контроллера? И как с этим жить?

З.Ы.
Пример сугубо учебно демонстрационный и не стоит задавать вопросы "зачем нужно много мастеров, да еще в таком синхроне".

UPD ах да, по одиночке они спокойно пишут каждая в свой адрес. А вот когда вместе, то вот такое вот садомазо.

Выполнение арбитража может развиться 3 различными сценариями. Вы прямо точно попали в первый сценарий
1. Два или более ведущих осуществляют однотипный обмен с одним и тем же slave.
В этом случае никто из них не сможет распознать конфликт на шине.

Обана, т.е. после передачи адреса Slave может начаться любой бардак и никто это не отследит? Т.е. получается принимают такой вариант как маловероятный и забивают.

Повидимому считается, что в данном случае Вы должны учитывать такую возможность и программно "рулить" арбитражем

Стоп. Первый сценарий тут не катит. Он для того случая, когда мои оба мастера шлют абсолютно идентичные посылки. Да, они не поймут ,что пишут синхронно, но это и не важно - т.к. все пройдет корректно.

Там есть и второй сценарий, он как раз мой:

2.Два или более ведущих обращаются к одному и тому же ведомому с различными _данными_ или различными типами обмена (чтение/запись). В этом случае распределение приоритетов произойдет во время передачи битов _данных_ или бита направления. Ведущий, потерявший приоритет, может либо переключиться в режим неадресованного ведомого, либо дождаться освобождения шины и сформировать состояние СТАРТ для ее захвата.

Т.е. на этапе передачи данных и происходит косяк.

ДА, похоже. А что на осциллограмме данных второго ведущего?

Похоже тут прокладка виновата

У меня контроллеры стартуют с интервалом в 40мс оказывается. И вторая пачка тоже проходит ,сама по себе, независимо от первой. И на одном захвате осцила они не влезают. Решил поглядеть полную картину за 500мс и увидел это. Не то оптимизатор так изза одного байта шалит, не то SUT биты по разному стоят. Сейчас разбирусь.

Сообщите , плиз , пройдёт или нет арбитраж- интересно

Гы. Прикольно. Ресеты четко синхронно. Разница там видна, но на пределе чувствительности осциллографа.

Фуз биты в обоих контроллерах бит в бит. Код одинаковый, прям один и тот же хекс загрузил в оба. А второй стартует позже первого на 40мс. Это внутренний RC так долго раскачивается? О_о

А введите програмную задержку на 40 mc/ или фьюзами "поиграться"

Да я проще - сейчас засинхроню оба МК один от другого.

В общем, сейчас все более менее правдоподобно. ОДин МК продул сразу арбитраж еще на уровне адреса слейва. Видимо неудачно ткнулся в период. Второй МК спокойно записал байт в еепромку. Первый, сразу же по окончании работы второго тоже пытался в еепромку сунуться, дал старт и SLA, но получил NACK и отпал. Видать еепромка долго жует.

08 18 28 28 28 победитель
08 38 08 20 проигравший.

20 код отсутствия ответа на адрес слейва.

Он же должен тутже перейти в slave - почему он 08 получил т.е сформировал START

Так это без времён, только статусы.
С временами было бы

Так точно. Первый оттарабанил. Только он дал стоп, тут же второй влепил старт.

Вот он этот момент передачи управления от одного к другому

Ну так может , рестарт спасёт?

Ну я на рестарт и запрограммировал в случае адрес фейла. Думаю 20мс вполне хватит.

А на зацикливание, как только освободится - пройдёт

Можно еще число попыток сделать ограниченным. Хотя времени на попытку опроса уходит мизер.

А что за EEPROM и нет ли у неё флага типа ЗАНЯТО

Традиционно I2C EEPROM просто не отвечают ACK-ом на свой адрес пока пишут данные.
А там уже в свом софте нужно предусмотреть повторы через какой-то разумный период, скажем, 1/5..1/4 паспортного времени записи — чтобы и в шину зря не долбиться постоянно, и, если это важно, не слишком долго ждать готовности.