Вот стоит задача - один управляющий блок и произвольное число подчиненных. И в управляющем и в подчиненных блоках стоят атмеги. Для упрощения межблочных соединеий и удешевления модулей решили делать связь между управляющим и подчиненными блоками на основе встроенного в меги UART. Кто-нибудь пробовал решать подобную задачу таким путем? Если да, то на какие результаты можно расчитывать (скорость и расстояние)? В идеале достаточно 320 kbps на расстояния до двух метров. Соединения расчитывается сделать плоским кабелем с землей через одну жилу.

Хм 2м и больше - ставьте rs485.
А вообще пробовал соединять так как вы говорите, TX от Master'a к RX всех slave'ов. TX'ы slave'ов по шине "монтажное И" к RX Master'a. Работает в пределах одного устройства (3 платы) расстояние около 30 см, на скорости 9600.

(обшибся с шиной, конечно там монтажное И)

Сообщение отредактировал defunct - Mar 18 2006, 20:46

Имеется ввиду просто голые порты сразу в магистраль? Тогда не знаю, просто не знаю,
что за порты у Atmela. Если отбуферизировать через какие-нибудь не быстрые шинники
(фронты наносекунд по 10) и триггера шимита на приемной сторне, то без проблем будет и на большие расстояния и на большие скорости. В давние времена бегала мультиплексированная восимибитная
шина на 2 MHz в пределах статива.
UART тоже разные бывают, те которые классические чипы 8250 от WD хороши были - по двум
отсчетам на импульс решение принимали и из такого мусора инфу выискивали..., ну а 8251 - уже подубовее и для более тепличных условий.

Это сильно удорожит конструкцию исполняющих блоков, не хотелось бы... .
Да, здесь тоже примерно так... А бОльшую скорость просто не пробовали? Или пробовали, но не пошло?

Ну... Схематика предполагается такая: от управляющего модуля TX идет сразу с порта в магистраль, в исполняющем модуле пришедший TX демпфирован 68 омами и подтянут к питанию, заходит в RX контроллера и через буфер (логический элемент 2-И) уходит на следующий модуль. Обратный TX на плате исполнительного модуля объединяется по И с TX от предыдущего модуля (вход от предыдущего модуля так же демпфирован и подтянут к питанию) и уходит в магистраль. Хотя обратная связь практически нужна только на уровне "есть сигнал/нет сигнала", так что в основном волнует именно прямая связь, от управляющего к исполнителям.
Повторюсь - девайс весьма дешевый, стоимость комплектухи исполняющего модуля буквально 70-80 рублей, поэтому не хотелось бы ставить драйвера.

Конкретно в этом устройстве повышать скорость не пробовал, т.к. 1 устройство (1 плата) была изготовлена ранее на C51 с осциллятором который просто не позволяет выставить скорость УАРТа больше 9600...

А просто связывать меги между собой без преобразователей с делителем UBRR=0 на скорости ~1 MBPS без проблем получалось, но правда расстояние было всего около 10см.

Так что пробуйте, высока вероятность того, что у Вас получится то, что Вы хотите.

Спасибо за информацию!

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

Когда-то пробовал. Ещё на 51. До 30 см допускается без буферов. При расстоянии 2м думаю будет работать, но за помехи на линии тебе никто гарантию не даст. Зависит от условий применения. Применение внешних интерфейсных микросхем решит проблему. На двух метрах будет работать как 232 так и 485 интерфейс. Теперь о "дополнительных затратах". Применение двух интерфеёсных микросхем - это 0.5$. Помоему это не высокая плата за стабильную работу.
И ещё один момент. Как правило, при такой работе возникает необходимость передачи данных/комманд. Или что-нибудь типа того. В этом смысле использование интерфейса UART более чем выгодно, так как позволяет передавать 9бит. Один из них использовать как управляющий. В новых MEGAх есть и режим "Мультипроцессорный". Правда самому мне его использовать не приходилось.

Тут меня шальная мысль посетила.
А не попробовать ли токовую петельку?

Спасибо за совет, попробую поиграться и так и эдак.

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

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


А поподробнее?

Эрзац 485, полагаю? Если интересуют бородатая (конца 80x) история _успешного_ построения гальванически развязанной сети на UART работающей на 115kbit в условиях машинного зала ДЕКАДНО ШАГОВОЙ АТС (помехи абсолютно неописуемые) на расстояниях в сотни метров. Причем все строилось
буквально "из ничего". Могу изложить, но полагаю, что это не этот случай.

485 интерфейс это в принципе и есть токовая петля. Я когда-то делал даже опторазвязку, но это для малых скоростей.
С точки зрения программиста rs485 - это полудуплекс, а rs232 полнодуплексный интерфейс. Сами микрухи не требуют дополнительных питаний (как было раньше) и 8 ножек соик корпус. Нафига тебе огород городить? Ты эту микруху на плате не заметишь.

Передавать уровни не потенциалом, а наличием отстствием/тока.
В соседней ветке даже схемка проскочила.
http://electronix.ru/forum/index.php?showt...=30&#entry96500
Я полагаю пара скоросных оптронов сравнима по цене с 232/485 микросхемой, но нечто подобное без гальваноразвязки можно изобразить и на паре транзисторов или там на 2-4 канальном опере.
В 80 годы такие схемы применялись очень широко, можно копнуть в литературе тех времен.
Помехоустойчивость у таких схем намного лучше потенциальных, что немаловажно учитывая высокую скорость.

485 это в принципе своем совершенно не токовая петля, сходство с токовой петлей заканчивается количеством проводов для передачи.


Это смотря что для опторазвязки использовать. Можно и до нескольких мегабит гальванику сделать.

И автору вопроса:
А вы уверены, что от 320 кБит/с вашему контроллеру не будет плохо, это где то 30 мкс на байт, а если по доброму делать протокол, так еще бы не плохо битые фреймы отслеживать по паузам между байтами.

Неплохо, но совершенно необязательно: в прерывании обслуживать - байт стаффинг протокол, вне прерывания - сверять CRC. 30 mks - с головой хватит.