13.01.2017, 14:04
|
|
Прописка
Регистрация: 11.04.2006
Сообщений: 197
Сказал спасибо: 80
Сказали Спасибо 31 раз(а) в 30 сообщении(ях)
|
Мультимастер через UART
Озадачился созданием устройств с управлением по однопроводной шине подобной K-Line. Есть желание прикрутить мультимастер для "общений" между собой.
Собственно вопрос...может есть уже у кого наработки по этому вопросу в виде исходников(С, Pascal) дабы не изобретать велосипед? Имею затык в виде разруливания коллизий на шине.
|
|
|
|
13.01.2017, 17:35
|
|
Гуру портала
Регистрация: 17.07.2010
Адрес: мурмурляндия
Сообщений: 10,712
Сказал спасибо: 189
Сказали Спасибо 3,194 раз(а) в 2,071 сообщении(ях)
|
Re: Мультимастер через UART
Плохая затея.
Ну я бы мониторил бит idle line.
Хотя будет ли оно успевать хз.
Запили на каншине. Там аппаратно делается и приспособлено для мульти изначально
__________________
кагмаподэ магмаподэ
|
|
|
|
14.01.2017, 01:56
|
|
Прописка
Регистрация: 11.04.2006
Сообщений: 197
Сказал спасибо: 80
Сказали Спасибо 31 раз(а) в 30 сообщении(ях)
|
Re: Мультимастер через UART
С кан шиной не вижу смысла затевать...мк с ним на борту дороже копеечных с UART. Подобный мультимастер реализован на BMW прошлых лет и зовут вроде IBUS. Но там юзают трансивер с контролем коллизий...ценник высоковат (проще тогда уже CAN заюзать). В общем надо разбираться...
|
|
|
|
14.01.2017, 02:19
|
|
Гуру портала
Регистрация: 17.07.2010
Адрес: мурмурляндия
Сообщений: 10,712
Сказал спасибо: 189
Сказали Спасибо 3,194 раз(а) в 2,071 сообщении(ях)
|
Re: Мультимастер через UART
смотря для чего тебе эта шина
от коллизий ты не избавишься просто так.
тут или смириться с ними и слушать свое же эхо и если эхо не то то еще раз отсылать либо отказаться от мультимастера и просто одним мастером постоянно опрашивать ведомых. есть инфа - скачал, нету, следующего опрашиваешь. именно я так и делаю везде.
можно например линию занимать постоянным уровнем несколько десятков миллисек. при этом все остальные прочухают что передавать нельзя. хотя это тоже не полное решение проблемы.
да и к лайн сама по себе - гавно
__________________
кагмаподэ магмаподэ
Последний раз редактировалось индюк; 14.01.2017 в 02:21.
|
|
|
|
14.01.2017, 02:33
|
|
Супер-модератор
Регистрация: 13.03.2004
Адрес: Minsk
Сообщений: 2,381
Сказал спасибо: 1,962
Сказали Спасибо 1,328 раз(а) в 578 сообщении(ях)
|
Re: Мультимастер через UART
Когда-то давно, еще работали с x51 процессорами - назревала тема с несколькими МК в "типа микросетке", обмен между всеми но не очень напряженный - с паузами. И я начал было прорабатывать тему. Но тема не родившись умерла - и бросил.
Мысли по ней были такие:
1) Не на "шине" а по кольцу. Плюс - полная свобода, надо - передал пакет с адресом, далее его принимает следующий - не мой - передать далее, мой - принять и замолчать. Но - разрыв цепи - и все встало.
2) Вариант - шина, протокол типа - у всех есть номера, и по окончании передачи кого-либо (первого мастера) идут таймслоты, в которых определенный номер может начать передачу, а как она пошла - остальные "замолкли" и сбросили таймер. Но тут - получилось - приоритет - а хотелось бы равноправия. Можно было конечно замутить изменение приоритета по кольцу - но на тех (x51) процессорах это вышло бы, наверное, напряжно для них.
3) Один - основной "мастер" он же пульт, что более подходило к нашей конфигурации системы. Но у него есть пауза - тут он выдает пакет типа "я все, передаю мастера номеру 1". Тот - если нет чего сказать - выдает пакет "передаю мастера номеру 2". Но что-то не понравилось мне в этом.
Возможно, есть и еще варианты - но - как получилось, тема умерла, и "протоколы" остались "на бумаге".
__________________
[ жизнь приятна и красива, если выпить литр пива ]
|
|
|
|
14.01.2017, 02:53
|
|
Почётный гражданин KAZUS.RU
Регистрация: 20.08.2010
Адрес: Днепр
Сообщений: 8,565
Сказал спасибо: 5,041
Сказали Спасибо 10,615 раз(а) в 3,604 сообщении(ях)
|
Re: Мультимастер через UART
лучше организовать общение между мастерами так, чтобы коллизии просто исключались. Кстати, трудно представить, что это за устройство, состоящее из нескольких мастеров, которым только дай волю - такой галдеж могут устроить, что парализуют всю работу. Например, каждый будет упорно пытаться отправить какой-то байт, который он считает суперважным. И так - все одновременно. Ну, и до бесконечности.
В первую очередь надо присвоить мастерам приоритеты. Никаких равноправий. Хотя бы у одного должен быть приоритет более высокий, чем у остальных. А лучше, если у всех разные. Тогда, даже если коллизия возникнет, произойдет быстрый выход из нее, победит однозначно тот, у кого прав больше. В принципе, во многих протоколах это уже заложено, приоритет определяется адресом устройства. У кого адрес младше - тот на коне.
Как вариант, можно жестко задать очередность передачи права голоса, от одного мастера к другому. То есть, сначала права мастера получает первый в очереди. И делает все, что хочет. Но ограниченное время. Или просто, выполняет определенную конкретную последовательность действий. Например, может опрашивать конкретных слейвов (в том числе и тех, которые могут быть мастерами). А может просто выдавать некие данные, на всеобщее пользование. Ну, как в том же CANе, в котором куча инфы крутится, и пользуются ею все, кому она нужна.
Так вот, выдал он все, что хотел. Или опросил всех, кого хотел. После этого выдает пакет, в котором содержится адрес очередного устройства, которому передается право мастера. Ну, и так по кругу.
Но тут надо предусмотреть ситуацию, когда один из мастеров выкинет фортель. Может он завис, или вообще умер. И тогда вся цепочка остановится. Чтобы выйти из такой ситуации, нужен арбитр, который знает правила игры, и следит за их соблюдением. И если он видит, что очередному передали право мастера, а он долго сопли жует, и не использует это право - то надо быстренько взять его на заметочку. поставить на счетчик, а тем временем право мастера передать следующему.
Кому быть таким арбитром? Как вариант, такую функцию можно доверить всем участникам. Каждый должен знать адрес не только следующего, но и адрес того, кому он передает право голоса. И тогда, после передачи права следующему, он некоторое время должен проследить, как этот следующий себя ведет. Если не пользуется, значит умер, и тогда его вычеркиваем, а передаем право дальше по кругу.
Ну, для затравки достаточно.
|
|
|
Сказали "Спасибо" Alex9797
|
|
|
14.01.2017, 03:13
|
|
Гуру портала
Регистрация: 17.07.2010
Адрес: мурмурляндия
Сообщений: 10,712
Сказал спасибо: 189
Сказали Спасибо 3,194 раз(а) в 2,071 сообщении(ях)
|
Re: Мультимастер через UART
Ахренеешь все это прописывать. Оно того стоит?
__________________
кагмаподэ магмаподэ
|
|
|
|
14.01.2017, 05:15
|
|
Модератор
Регистрация: 04.08.2010
Адрес: Москва СЗАО
Сообщений: 11,257
Сказал спасибо: 11,170
Сказали Спасибо 3,858 раз(а) в 2,928 сообщении(ях)
|
Re: Мультимастер через UART
Для полного отказа от попытки реализации своего варианта стоит посмотреть на реализации промышленных протоколов.
Читаем CSMA/CD и желание писать все с 0 сразу пропадает.
Тут таки стоит оценить затраты на разработку и стоимость готовых решений (тот же CAN).
Расчёты явно в пользу готовых решений.
Кстати в ценнике на МК учитывается и память на все нужные библиотеки для реализации.
С простым и дешевым вся дорогая программа в итоге может просто не поместиться в память.
__________________
rtfm forever должно быть основой для каждого. Альтернатива грустна, поскольку метод слепого щенка успешно работает при весьма малом числе вариантов…
|
|
|
|
14.01.2017, 16:27
|
|
Прописка
Регистрация: 11.04.2006
Сообщений: 197
Сказал спасибо: 80
Сказали Спасибо 31 раз(а) в 30 сообщении(ях)
|
Re: Мультимастер через UART
Нашел инфу о предшественнике CAN, а именно SAE J1708...в общем ничего сложного с арбитражом в теории.
Собственно ждем простоя линии равное 10 длительностям одного бита...передаем один байт и сами себя слушаем что приняли...если совпадает, значит фигачем оставшуюся последовательность с проверкой каждого байта. Если не совпали отправленный и принятый, то опять ждем простоя линии, но увеличиваем интервал ожидания на случайную величину...это на случай, если одновременно несколько устройств захотят поговорить и повторяем отправку.
Остается красиво это все реализовать на прерываниях, без блокировки в основном цикле...это в идеале, а так можно и самоблокирующиеся функции пока не передаст/примет с некоторым таймаутом, дабы не было вечного залипания. В общем как-то так.
Жаль, что придется пилить самому ))) Или плюнуть и реализовать по простому один мастер и куча слейвов. В любом случае отказ одного слейва должен приводить к остановке всего агрегата в целом и не допускаться дальнейшая эксплуатация.
|
|
|
|
15.01.2017, 16:19
|
|
Прописка
Регистрация: 04.09.2009
Сообщений: 167
Сказал спасибо: 1
Сказали Спасибо 35 раз(а) в 25 сообщении(ях)
|
Re: Мультимастер через UART
Сообщение от awtoap
|
Озадачился созданием устройств с управлением по однопроводной шине подобной K-Line. Есть желание прикрутить мультимастер для "общений" между собой...
|
А мультимастер действительно необходим? На USART легко ложится LIN. Вы опишите задачу более детально, тогда глядишь и советы будут, исходя из Ваших "хотелок".
|
|
|
|
Ваши права в разделе
|
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения
HTML код Выкл.
|
|
|
Тема |
Автор |
Раздел |
Ответов |
Последнее сообщение |
Тормоза при передаче данных через UART в Bluetooth модуль
|
rus_12345 |
Микроконтроллеры, АЦП, память и т.д |
8 |
05.01.2015 19:39 |
Парапсихология, гомеопатия и паранаука
|
Marc2005 |
Отвлекитесь, эмбеддеры! |
2616 |
05.09.2014 23:07 |
Передача 8-битных данных через мобильник
|
begun |
Микроконтроллеры, АЦП, память и т.д |
9 |
12.07.2010 13:36 |
Нужна консультация по связи МК AVR через uart в кабине трансп.с-ва
|
code-by |
Микроконтроллеры, АЦП, память и т.д |
2 |
05.04.2010 18:19 |
Как быстро читать через FT232R?
|
Chudilo |
Микроконтроллеры, АЦП, память и т.д |
9 |
13.02.2010 00:57 |
Часовой пояс GMT +4, время: 05:29.
|
|