usart в мультимастерном режиме? - Страница 2

mikeras · 29.11.2007, 18:14

С одним старшим проц - все просто: TxD старшего соеденино с младшими RxD, младшие TxD - к старшему RxD. Обмен как в классе - кого учитель вызвал, тому и краснеть.
А как с одноранговой. Физически на каждый проц поставть к примеру 232/485, а потом 485 в кучу.
Где бороться с коллизиями, точнее их обнаруживать.

nml · 29.11.2007, 19:42

Сообщение от mikeras

С одним старшим проц - все просто: TxD старшего соеденино с младшими RxD, младшие TxD - к старшему RxD.

Подерутся TxD младших. Они же не с открытым коллектором.

jelsay · 29.11.2007, 21:35

Цитата:

Так все-таки 1-й проц слышат 2-й и 3-й и 1-й?

Э.. мужики куда вас занесло

Такие задачи уж сто лет как решены - с помощью противоместных схем - примерно также как в телефонии

nokazus · 30.11.2007, 08:12

Сообщение от mikeras

Где бороться с коллизиями, точнее их обнаруживать.

На уровне протокола обмена.
Удачи.

makakus · 30.11.2007, 14:08

Когда UART работает с объединением Rx и Tx это похоже на RS485. Коллизии устраняются протоколом. Там и ищите примеры. Если хотите отслеживать биты, используйте вход с прерыванием по фронту, и - ручками.

Don_Ambrosio · 28.02.2008, 01:46

Сообщение от jelsay

арбитраж по таймам.. и т.п.
- несомненно медленно - но зато дешево..

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

А поподробней можно? Сам сейчас ваяю что-то подобное

Don_Ambrosio · 28.02.2008, 01:54

Сообщение от rear

Не совсем уверен, но кажется, что USART поддерживает Multi-processor а не Multi-master режим работы т.е. в системе есть один ведущий, все остальные - ведомые

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

jelsay · 13.04.2008, 07:10

Don_Ambrosio - извините, сразу не увидел, отвечаю с опозданием.

основой узла приоритета являлся некий аналог динистора (неоновой лампочки) с управляемым порогом включения - известно что если куча динисторов подключена к одной точке то сработывать будет только один - с наименьшим порогом срабатывания. Порог срабатывания же задавался ЦАП динамически для данного узла. Значение ЦАП задавала специальная группа перепрограммируемых счётчиков-регистров отвечающих за диапазон приоритета данного узла, скорость его роста, время захвата и т.п.
поскольку шина питалась источником тока - то захват шины данным узлом определялся простым токовым сенсором с гестирезисом. отпускание шины было принудительным.

удачи

Popeye · 14.04.2008, 23:07

Рекомендую на будущее иметь ввиду CAN шину. Делаю такую сеть, правда только первые шаги. Связал 4 узла на прием и передачу + 1 только на прием. В дальнейшем могут дойти до 200. Предельно просто, заряжаю буферы данных и даю команду послать. Все, и никакого арбитража (пока). Пусть CAN контроллер ломает голову когда втиснуть сообщение в поток. В начале очень пугался, ужасно много регистров надо заполнять, да хвала аллаху

не таким страшным оказался.
Удачи !

Don_Ambrosio · 14.04.2008, 23:48

Сообщение от Popeye

Предельно просто, заряжаю буферы данных и даю команду послать. Все, и никакого арбитража (пока). Пусть CAN контроллер ломает голову когда втиснуть сообщение в поток.

А я не люблю когда "голову ломать" не надо и кто-то уже решил проблему за меня. Я люблю всё сам делать, "ручками", с полным пониманием того зачем и для чего я это делаю