Мультимастер через UART

[awtoap]

Озадачился созданием устройств с управлением по однопроводной шине подобной K-Line. Есть желание прикрутить мультимастер для "общений" между собой.

Собственно вопрос...может есть уже у кого наработки по этому вопросу в виде исходников(С, Pascal) дабы не изобретать велосипед? Имею затык в виде разруливания коллизий на шине.

[индюк]

Плохая затея.
Ну я бы мониторил бит idle line.
Хотя будет ли оно успевать хз.
Запили на каншине. Там аппаратно делается и приспособлено для мульти изначально

[awtoap]

С кан шиной не вижу смысла затевать...мк с ним на борту дороже копеечных с UART. Подобный мультимастер реализован на BMW прошлых лет и зовут вроде IBUS. Но там юзают трансивер с контролем коллизий...ценник высоковат (проще тогда уже CAN заюзать). В общем надо разбираться...

[индюк]

смотря для чего тебе эта шина
от коллизий ты не избавишься просто так.
тут или смириться с ними и слушать свое же эхо и если эхо не то то еще раз отсылать либо отказаться от мультимастера и просто одним мастером постоянно опрашивать ведомых. есть инфа - скачал, нету, следующего опрашиваешь. именно я так и делаю везде.

можно например линию занимать постоянным уровнем несколько десятков миллисек. при этом все остальные прочухают что передавать нельзя. хотя это тоже не полное решение проблемы.

да и к лайн сама по себе - гавно

[nml]

Когда-то давно, еще работали с x51 процессорами - назревала тема с несколькими МК в "типа микросетке", обмен между всеми но не очень напряженный - с паузами. И я начал было прорабатывать тему. Но тема не родившись умерла - и бросил.

Мысли по ней были такие:

1) Не на "шине" а по кольцу. Плюс - полная свобода, надо - передал пакет с адресом, далее его принимает следующий - не мой - передать далее, мой - принять и замолчать. Но - разрыв цепи - и все встало.

2) Вариант - шина, протокол типа - у всех есть номера, и по окончании передачи кого-либо (первого мастера) идут таймслоты, в которых определенный номер может начать передачу, а как она пошла - остальные "замолкли" и сбросили таймер. Но тут - получилось - приоритет - а хотелось бы равноправия. Можно было конечно замутить изменение приоритета по кольцу - но на тех (x51) процессорах это вышло бы, наверное, напряжно для них.

3) Один - основной "мастер" он же пульт, что более подходило к нашей конфигурации системы. Но у него есть пауза - тут он выдает пакет типа "я все, передаю мастера номеру 1". Тот - если нет чего сказать - выдает пакет "передаю мастера номеру 2". Но что-то не понравилось мне в этом.

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

[Alex9797]

лучше организовать общение между мастерами так, чтобы коллизии просто исключались. Кстати, трудно представить, что это за устройство, состоящее из нескольких мастеров, которым только дай волю - такой галдеж могут устроить, что парализуют всю работу. Например, каждый будет упорно пытаться отправить какой-то байт, который он считает суперважным. И так - все одновременно. Ну, и до бесконечности.

В первую очередь надо присвоить мастерам приоритеты. Никаких равноправий. Хотя бы у одного должен быть приоритет более высокий, чем у остальных. А лучше, если у всех разные. Тогда, даже если коллизия возникнет, произойдет быстрый выход из нее, победит однозначно тот, у кого прав больше. В принципе, во многих протоколах это уже заложено, приоритет определяется адресом устройства. У кого адрес младше - тот на коне.

Как вариант, можно жестко задать очередность передачи права голоса, от одного мастера к другому. То есть, сначала права мастера получает первый в очереди. И делает все, что хочет. Но ограниченное время. Или просто, выполняет определенную конкретную последовательность действий. Например, может опрашивать конкретных слейвов (в том числе и тех, которые могут быть мастерами). А может просто выдавать некие данные, на всеобщее пользование. Ну, как в том же CANе, в котором куча инфы крутится, и пользуются ею все, кому она нужна.

Так вот, выдал он все, что хотел. Или опросил всех, кого хотел. После этого выдает пакет, в котором содержится адрес очередного устройства, которому передается право мастера. Ну, и так по кругу.

Но тут надо предусмотреть ситуацию, когда один из мастеров выкинет фортель. Может он завис, или вообще умер. И тогда вся цепочка остановится. Чтобы выйти из такой ситуации, нужен арбитр, который знает правила игры, и следит за их соблюдением. И если он видит, что очередному передали право мастера, а он долго сопли жует, и не использует это право - то надо быстренько взять его на заметочку. поставить на счетчик, а тем временем право мастера передать следующему.

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

Ну, для затравки достаточно.

[индюк]

Ахренеешь все это прописывать. Оно того стоит?

[mike-y-k]

Для полного отказа от попытки реализации своего варианта стоит посмотреть на реализации промышленных протоколов.
Читаем CSMA/CD и желание писать все с 0 сразу пропадает.
Тут таки стоит оценить затраты на разработку и стоимость готовых решений (тот же CAN).
Расчёты явно в пользу готовых решений.
Кстати в ценнике на МК учитывается и память на все нужные библиотеки для реализации.
С простым и дешевым вся дорогая программа в итоге может просто не поместиться в память.

[awtoap]

Нашел инфу о предшественнике CAN, а именно SAE J1708...в общем ничего сложного с арбитражом в теории.
Собственно ждем простоя линии равное 10 длительностям одного бита...передаем один байт и сами себя слушаем что приняли...если совпадает, значит фигачем оставшуюся последовательность с проверкой каждого байта. Если не совпали отправленный и принятый, то опять ждем простоя линии, но увеличиваем интервал ожидания на случайную величину...это на случай, если одновременно несколько устройств захотят поговорить и повторяем отправку.
Остается красиво это все реализовать на прерываниях, без блокировки в основном цикле...это в идеале, а так можно и самоблокирующиеся функции пока не передаст/примет с некоторым таймаутом, дабы не было вечного залипания. В общем как-то так.
Жаль, что придется пилить самому ))) Или плюнуть и реализовать по простому один мастер и куча слейвов. В любом случае отказ одного слейва должен приводить к остановке всего агрегата в целом и не допускаться дальнейшая эксплуатация.

[shindax]

Озадачился созданием устройств с управлением по однопроводной шине подобной K-Line. Есть желание прикрутить мультимастер для "общений" между собой...

А мультимастер действительно необходим? На USART легко ложится LIN. Вы опишите задачу более детально, тогда глядишь и советы будут, исходя из Ваших "хотелок".