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

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

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

Имеется ввиду просто голые порты сразу в магистраль? Тогда не знаю, просто не знаю,
что за порты у 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 - с головой хватит.

оф топ:
Вопрос по поводу uart : если связывать два контроллера по UART и взять тактовую одинаковую для обоих контроллеров (к примеру 16 МГц) и скорость по максимуму 115кбод, то ошибка будет равна нулю? так нет? Поправте меня знающие люди! Спасибо.

Ошибка будет равна 0% если 2 МК тактировать одним и тем же внешним генератором.
Если тактировать от разных кварцев одинакового номинала, то ошибка будет близкой к 0%.
По поводу максимума, для AVR на 16Mhz это 2Мбод.

Оба контроллера будут пахать на 16 мегагерцах, так что, думаю, вполне будут успевать . Ошибки будут отслеживаться по CRC в конце каждого пакета, при необходимости пакет будет повторен.

Читайте про интерфейс LIN.
В той задаче, о которой Вы пишете - самое трудное это выделение начала кадра данных. Либо делать избыточное кодирование. Либо делать аппаратные сигналы, по которым определяется начало кадра к абоненту.
А иначе - либо множество линий "точка-точка", либо обработка КАЖДОГО принятого байта данных с программной проверкой на начало кадра.
А все остальное - тривиально.
Если хотите на русском - у меня на сайте статья о микроконтроллерах NEC-2, там намного описан ЛИН.
Физический уровень можно выполнить по-другому, а вот логику и обработку ошибок при работе сети и синхронизацию UART'ов я бы взял оттуда.
Да и потом все устройства со стандартным LIN - будут Ваши: купил, прицепил, запрограммировал.
Удачи!

В теории оно конечно получится. Но UART это асинхронный интерфейс, в нормальной промышленной системе на такой скорости я думаю замучаетесь с помехами. Для этого подойдет синхронный I2C встроенный в атмеги аппаратно. Он позволяет развить скорость до 400 кбод. Но опять длина кабеля у него по спецификации помоему сантиметров 90. Точно не помню

Собственно никаких проблем, буквально десяток команд и "избыточное кодирование" по типу
SLIP протокола готово, что действительно решит проблемы с фреймами радикально.

Ну а уж если LIN.....CAN, то Atmel-ы с CAN имеют место быть, но тут вроде рачь идет об абсолютном минимализме в железе.





Это Вы не подумав :-(