DI HALT 0 19 ноября, 2010 Опубликовано 19 ноября, 2010 (изменено) · Жалоба Итак, ситуевина. Есть шина 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 ах да, по одиночке они спокойно пишут каждая в свой адрес. А вот когда вместе, то вот такое вот садомазо. Изменено 19 ноября, 2010 пользователем DI HALT Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ILYAUL 0 19 ноября, 2010 Опубликовано 19 ноября, 2010 · Жалоба Почему М2 продолжил передачу, хотя пролажал арбитраж на целой тетраде? Аппаратный глюк контроллера? И как с этим жить? З.Ы. Пример сугубо учебно демонстрационный и не стоит задавать вопросы "зачем нужно много мастеров, да еще в таком синхроне". UPD ах да, по одиночке они спокойно пишут каждая в свой адрес. А вот когда вместе, то вот такое вот садомазо. Выполнение арбитража может развиться 3 различными сценариями. Вы прямо точно попали в первый сценарий 1. Два или более ведущих осуществляют однотипный обмен с одним и тем же slave. В этом случае никто из них не сможет распознать конфликт на шине. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DI HALT 0 19 ноября, 2010 Опубликовано 19 ноября, 2010 · Жалоба Обана, т.е. после передачи адреса Slave может начаться любой бардак и никто это не отследит? Т.е. получается принимают такой вариант как маловероятный и забивают. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ILYAUL 0 19 ноября, 2010 Опубликовано 19 ноября, 2010 · Жалоба Обана, т.е. после передачи адреса Slave может начаться любой бардак и никто это не отследит? Т.е. получается принимают такой вариант как маловероятный и забивают. :laughing: Повидимому считается, что в данном случае Вы должны учитывать такую возможность и программно "рулить" арбитражем Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DI HALT 0 19 ноября, 2010 Опубликовано 19 ноября, 2010 · Жалоба Стоп. Первый сценарий тут не катит. Он для того случая, когда мои оба мастера шлют абсолютно идентичные посылки. Да, они не поймут ,что пишут синхронно, но это и не важно - т.к. все пройдет корректно. Там есть и второй сценарий, он как раз мой: 2.Два или более ведущих обращаются к одному и тому же ведомому с различными _данными_ или различными типами обмена (чтение/запись). В этом случае распределение приоритетов произойдет во время передачи битов _данных_ или бита направления. Ведущий, потерявший приоритет, может либо переключиться в режим неадресованного ведомого, либо дождаться освобождения шины и сформировать состояние СТАРТ для ее захвата. Т.е. на этапе передачи данных и происходит косяк. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ILYAUL 0 19 ноября, 2010 Опубликовано 19 ноября, 2010 · Жалоба ДА, похоже. А что на осциллограмме данных второго ведущего? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DI HALT 0 19 ноября, 2010 Опубликовано 19 ноября, 2010 (изменено) · Жалоба Похоже тут прокладка виновата :) У меня контроллеры стартуют с интервалом в 40мс оказывается. И вторая пачка тоже проходит ,сама по себе, независимо от первой. И на одном захвате осцила они не влезают. Решил поглядеть полную картину за 500мс и увидел это. Не то оптимизатор так изза одного байта шалит, не то SUT биты по разному стоят. Сейчас разбирусь. Изменено 19 ноября, 2010 пользователем DI HALT Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ILYAUL 0 19 ноября, 2010 Опубликовано 19 ноября, 2010 · Жалоба Сейчас разбирусь Сообщите , плиз , пройдёт или нет арбитраж- интересно Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DI HALT 0 19 ноября, 2010 Опубликовано 19 ноября, 2010 · Жалоба Гы. Прикольно. Ресеты четко синхронно. Разница там видна, но на пределе чувствительности осциллографа. Фуз биты в обоих контроллерах бит в бит. Код одинаковый, прям один и тот же хекс загрузил в оба. А второй стартует позже первого на 40мс. Это внутренний RC так долго раскачивается? О_о Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ILYAUL 0 19 ноября, 2010 Опубликовано 19 ноября, 2010 · Жалоба А введите програмную задержку на 40 mc/ или фьюзами "поиграться" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DI HALT 0 19 ноября, 2010 Опубликовано 19 ноября, 2010 (изменено) · Жалоба Да я проще - сейчас засинхроню оба МК один от другого. В общем, сейчас все более менее правдоподобно. ОДин МК продул сразу арбитраж еще на уровне адреса слейва. Видимо неудачно ткнулся в период. Второй МК спокойно записал байт в еепромку. Первый, сразу же по окончании работы второго тоже пытался в еепромку сунуться, дал старт и SLA, но получил NACK и отпал. Видать еепромка долго жует. 08 18 28 28 28 победитель 08 38 08 20 проигравший. 20 код отсутствия ответа на адрес слейва. Изменено 19 ноября, 2010 пользователем DI HALT Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ILYAUL 0 19 ноября, 2010 Опубликовано 19 ноября, 2010 · Жалоба 08 18 28 28 28 победитель 08 38 08 20 проигравший. 20 код отсутствия ответа на адрес слейва. Он же должен тутже перейти в slave - почему он 08 получил т.е сформировал START Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 19 ноября, 2010 Опубликовано 19 ноября, 2010 · Жалоба Так это без времён, только статусы. С временами было бы 08 18 28 28 28 победитель 08 38 08 20 проигравший. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DI HALT 0 19 ноября, 2010 Опубликовано 19 ноября, 2010 · Жалоба Так точно. Первый оттарабанил. Только он дал стоп, тут же второй влепил старт. Вот он этот момент передачи управления от одного к другому Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ILYAUL 0 19 ноября, 2010 Опубликовано 19 ноября, 2010 · Жалоба Ну так может , рестарт спасёт? :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться