Jump to content

    
Sign in to follow this  
DI HALT

Mega16+Twi+Multimaster = не работает арбитраж

Recommended Posts

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

 

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

 

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

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

 

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

 

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

ii2cgluk.gif

 

Красный квадратик отмечает место, где идет конфлик уровней. Как видим, запись прошла в ЕЕПРОМ по адресу 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 ах да, по одиночке они спокойно пишут каждая в свой адрес. А вот когда вместе, то вот такое вот садомазо.

Edited by DI HALT

Share this post


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

 

З.Ы.

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

 

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

Выполнение арбитража может развиться 3 различными сценариями. Вы прямо точно попали в первый сценарий

1. Два или более ведущих осуществляют однотипный обмен с одним и тем же slave.

В этом случае никто из них не сможет распознать конфликт на шине.

Share this post


Link to post
Share on other sites

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

Share this post


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

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Edited by DI HALT

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

08 18 28 28 28 победитель

08 38 08 20 проигравший.

 

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

Edited by DI HALT

Share this post


Link to post
Share on other sites
08 18 28 28 28 победитель

08 38 08 20 проигравший.

 

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

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

Share this post


Link to post
Share on other sites

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

С временами было бы

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

Share this post


Link to post
Share on other sites

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

 

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

stst.gif

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this