Перейти к содержанию
    

I2C несколько мастеров

у нас несколько плат соединены между собой и на каждой плате стоит по несколько датчиков I2C

в общей сложности около 50 штук

каждая плата для "своих" датчиков является мастером и к тому же чужая плата

может читать данные с других плат по этой шине.

возник вопрос, как их разделить, чтобы они друг друга не мешали

я рассматриваю такие решения:

1) разделить по времени, например одна плата запрашивает датчики каждую 5-ю секунду, другая каждую 10-ю

2) перед чтением каждая плата проверяет клоковую шину, что по крайней мере в течении 1 секунды она не меняет состояние и находится в единице

 

может есть еще какие методы, кто знает?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

7 minutes ago, inventor said:

разделить по времени, например одна плата запрашивает датчики каждую 5-ю секунду, другая каждую 10-ю

В зависимости от того, как долго платы находятся во включенном состоянии и погрешности тактовых генераторов таймслоты со временем не наползут на друг друга?

8 minutes ago, inventor said:

перед чтением каждая плата проверяет клоковую шину, что по крайней мере в течении 1 секунды она не меняет состояние и находится в единице

Занятие может произойти на времени 1,001 с. Т.е. проверили, начали занимать, и кто-то тоже занял.

9 minutes ago, inventor said:

может есть еще какие методы, кто знает?

I2C же аппаратно поддерживает мультимастер. Используйте ошибку арбитража доступа к шине, и если таковая возникла, то занимайте шину через случайный промежуток времени.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если плата может услышать чужого мастера можно перекидывать горячую картошку. Т.е. читает плата 1. Когда она закончила передаёт управление плате 2 отправив какое то сообщение. Вплоть до того что выставляет какой нибудь бит на расширителе портов. Соответственно плата 2 когда видит сообщение или поднятую ножку понимает что её время общаться и дальше цикл продолжается.

Работа по времени возможна только если время общее. Нужно раздавать всем время. Или уметь его синхронизировать. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 minutes ago, Arlleex said:

В итоге не понятно, на одной физической шине все висят, или нет. Отсюда и плясать.

да, на одной

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Тогда если у всех разные адреса, то никто никому мешать не будет (при правильно организованных драйверах I2C с мониторингом состояний BUSY на шине и контролем потери арбитража (прямо как в CAN-е, да)).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 час назад, rkit сказал:

"Несколько плат" с общей i2c это рецепт для нестабильного фарша.

Несколько голословное утверждение. У меня были устройства, где платы между собой соединялись по I2C, и ничего - годами работают, причем каждая плата - и мастер и слейв одновременно. А ТС-у, если не требуется детерминированное время получения ответа от датчиков, вполне можно обойтись и одной шиной (раз уж так уже сделали), главное не запороть ее возросшей емкостью (читай как "если что, буферы поставь").

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

i2c.thumb.png.75386cf8b79c54fdadab89b94e2f897f.png

мы разделяем вот так. о чем ни разу не пожалели. особенно если board-to-board.

Изменено пользователем jenya7

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я понял так, что данные со всех 50 датчиков должны быть у всех Мастеров. Предположим для определённости что Мастеров 5шт. Варианты:

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

 

2. Более быстрый и предсказуемый вариант. Один Мастер вычитывает все 50 датчиков, собирает данные в единый блок, и рассылает остальным Мастерам - каждому персонально. Остальные в это время находятся в режиме подчинённого, и у каждого есть свой Slave-адрес. 

Поведение системы становится более предсказуемым. У остальных Мастеров появляется экономия времени на служебных сигналах, адресах датчиков на шине, адресах регистров, и т.д. Точно подсчитать экономию времени, в данном случае нельзя, т.к. неизвестно, что за датчики, и какой объём данных из них считывается за раз. Но в общем это и быстрее и надёжнее.

 

3. Ещё быстрее. Один Мастер вычитывает все 50 датчиков, собирает данные в единый блок, и отправляет его массовой рассылкой остальным Мастерам - всем сразу. Остальные в это время находятся в режиме Подчинённого, с одинаковым для всех Slave-адресом (например GeneralCall = 0). Время на такую рассылку информации занимает менее 100 опросов.

 

4. И ещё более скоростной вариант. Один Мастер вычитывает 50 датчиков, а остальные "слушают" шину, читая с неё данные, но не пытаясь ею управлять (никаких ACK, HOLD и прочее). Чтение производится по прерыванию от линий SDA и SCL, согласно с логикой работы шины I2C. Здесь все 5 Мастеров получают весь объём данных одновременно, и всего лишь за 50 опросов

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 часа назад, controller_m30 сказал:

4. И ещё более скоростной вариант. Один Мастер вычитывает 50 датчиков, а остальные "слушают" шину, читая с неё данные, но не пытаясь ею управлять (никаких ACK, HOLD и прочее). Чтение производится по прерыванию от линий SDA и SCL, согласно с логикой работы шины I2C. Здесь все 5 Мастеров получают весь объём данных одновременно, и всего лишь за 50 опросов

Решение так себе. Так как код будет очень критичен к задержкам входа в ISR: придётся давать максимальный приоритет прерываниям от этих ног (а может и от всех ног), а весь остальной код нужно будет полностью перетрясти на предмет отсутствия запретов прерываний на времена >=1мкс (примерно, при SCLK=400кГц), а может даже и меньше.

Да и не нужно это имхо: Думаю что многие МК позволят запрограммировать свою I2C-периферию и пины в таком режиме, чтобы ACK-и HOLD-ы не формировались, но при этом сама I2C-периферия работала. Естественно этот вариант не для кубокодеров - нужно уметь читать мануалы.  :unknw:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

06.07.2021 в 18:11, inventor сказал:

у нас несколько плат соединены между собой и на каждой плате стоит по несколько датчиков I2C

в общей сложности около 50 штук

каждая плата для "своих" датчиков является мастером и к тому же чужая плата

может читать данные с других плат по этой шине.

Ой какая жуть, эта i2c сама по себе жуть, а в таком использовании....  Сколь приходилось так делать, всегда делал 1го мастера, к которому подключена гирлянда слейвов, у этого мастера был выход на "нормальный" мультиконтрольный порт (rs485) по которому все контроллеры забирали и отдавали данные. А иначе получается что-то вроде эзернета, но без аппаратного детектора коллизий и паддинга - удовольствие еще то, ИМХО..

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, mantech said:

Ой какая жуть, эта i2c сама по себе жуть, а в таком использовании....  Сколь приходилось так делать, всегда делал 1го мастера, к которому подключена гирлянда слейвов, у этого мастера был выход на "нормальный" мультиконтрольный порт (rs485) по которому все контроллеры забирали и отдавали данные. А иначе получается что-то вроде эзернета, но без аппаратного детектора коллизий и паддинга - удовольствие еще то, ИМХО..

в rs485 два слейва могу одновременно передавать данные?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

51 минуту назад, mantech сказал:

...эзернета, но без аппаратного детектора коллизий...

Ага и часто ли Вы в современном полнодуплексном эзернете коллизии видите?:wink:
 

41 минуту назад, jenya7 сказал:

в rs485 два слейва могу одновременно передавать данные?

А в I2C? А в CAN? Могут, только везде по-разному устроены механизмы доступа к среде и разрешения коллизий, и что с ними делать в каждом случае определяется либо самим интерфейсом (аппаратно), либо в связке с протоколом, реализованным в ПО, например, для организации ретрансмитов и т.д. Причем в RS, CAN, I2C домен коллизий ограничивается самой физической шиной, в эзернете же все несколько сложнее (есть вариации).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...