Последовательное соединение нескольких МК по uart, Соединить МК tx-rx Опции

[rtl_user]

Возможно ли соединить несколько МК по uart(4-5штук)?
Т.е. каждый контроллер является и мастером и ведомым( относительно следующих МК)
Передаем например 1 байт следующий МК принимает добавляет свой байт и передает дальше и т.д.

[iosifk]

Возможно ли соединить несколько МК по uart(4-5штук)?
Т.е. каждый контроллер является и мастером и ведомым( относительно следующих МК)
Передаем например 1 байт следующий МК принимает добавляет свой байт и передает дальше и т.д.

Посмотрите, как реализован интерфейс LIN.

[@Ark]

Возможно ли соединить несколько МК по uart(4-5штук)?
Т.е. каждый контроллер является и мастером и ведомым( относительно следующих МК)
Передаем например 1 байт следующий МК принимает добавляет свой байт и передает дальше и т.д.

Возможно.

[rtl_user]

Возможно.

Не получается больше трех(

[aaarrr]

Не получается больше трех(

Для каждого МК это соединение точка-точка, так что дело не в UART. Проверяйте логику работы ПО. Что именно не получается?

[kolobok0]

Возможно ли соединить несколько МК по uart(4-5штук)?....

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

ответ прост.
подумайте над тем, как аппаратно сделать передачу на всех кроме себя дальше дело техники.

удачи вам
(круглый)

[LII]

Не получается больше трех(

Так не получается?




Сообщение отредактировал LII - Dec 5 2017, 22:01

[Alex A. Mihaylov]

Так не получается?

Получится. Добавьте еще одну линию от последнего TX к первому RX и получите классическую топологию кольцо. Дальше вопрос только назначить всем уникальные адреса (административно) и договориться о формате пакетов. Опробовано неоднократно.

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

[rtl_user]

Получится. Добавьте еще одну линию от последнего TX к первому RX и получите классическую топологию кольцо. Дальше вопрос только назначить всем уникальные адреса (административно) и договориться о формате пакетов. Опробовано неоднократно.

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

[Эдди]

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

[OKF]

Не получается больше трех(

Эт если соображать на троих.)))

[rtl_user]

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

МК соединяются последовательно. Как на рисунке только без третьего провода. Т.е. есть мастер и он передает байт данных, принимает ведомый плюсует к полученным и передает уже два байта дальше и т.д. Скорость не важна.
На бумаге все красиво, не знаю как в железе и наверно придется ставить генератор вместо кварца

[aaarrr]

На бумаге все красиво, не знаю как в железе и наверно придется ставить генератор вместо кварца

В железе решается внятным протоколом. Генератор точно не поможет.

[Эдди]

МК соединяются последовательно.

И в чем проблема? Это ж как адресуемые светодиоды получается. По USART1 данные принимаем, по USART2 передаем дальше, откусив первые N байт.
Только с большими длинами линий могут возникнуть косяки.

[LII]

МК соединяются последовательно. Как на рисунке только без третьего провода.

Третий провод на рисунке - это общий, он нужен обязательно!

[rtl_user]

Третий провод на рисунке - это общий, он нужен обязательно!

Я подумал что это стробирующий.

В железе решается внятным протоколом. Генератор точно не поможет.

Если частота будет плавать боюсь что будут пропуски.

[aaarrr]

Если частота будет плавать боюсь что будут пропуски.

А по какой причине она будет плавать при работе от кварца?

[rtl_user]

А по какой причине она будет плавать при работе от кварца?

Всегда считал что генератор более стабильный. Плюс разброс по частоте меньше.
Ну думаю на железе все выйдет, начнем с кварца.

[aaarrr]

Всегда считал что генератор более стабильный. Плюс разброс по частоте меньше.

Надо очень сильно постараться, чтобы не вписаться с кварцем в потребности UART'а.

[Эдди]

Кварц для UART? Там что, частота в несколько мегагерц что ли?
До 115200 всегда хватало внутреннего RC-генератора, выше просто не проверял (но, судя по тому, что на 115200 ошибок вообще не было на линиях до полуметра, оно и на мегагерце должно на коротких линиях работать).

[mantech]

Кварц для UART? Там что, частота в несколько мегагерц что ли?
До 115200 всегда хватало внутреннего RC-генератора, выше просто не проверял (но, судя по тому, что на 115200 ошибок вообще не было на линиях до полуметра, оно и на мегагерце должно на коротких линиях работать).

Это только в "тепличных" условиях, на самом деле, при разбросе температур, больше 19200 от RC делать не следует.

Всегда считал что генератор более стабильный. Плюс разброс по частоте меньше.
Ну думаю на железе все выйдет, начнем с кварца.

Стабильный генератор с термокомпенсацией, но стоит он так, что разницу почувствуете. Для УАРТа подойдет кварц с любым ppm.

[rtl_user]

Попадалась информация что по uart минимальное число ошибок с кварцем 3.6864. Кто то работал?

[Сергей Борщ]

Попадалась информация что по uart минимальное число ошибок с кварцем 3.6864. Кто то работал?

"Слышал звон, да не знаю, где он". Число ошибок зависит исключительно от помеховой обстановки и разности скоростей приемника и передатчика. Если разница больше какого-то определенного числа (зависит от реализации приемника, обычно - если за время передачи одного слова набегает ошибка более половины длительности бита) - будет ошибка. Частота 3686400 делится нацело на стандартные скорости обмена, т.е. ошибка скорости определяется только нестабильностью и погрешностью кварца. Точно также нацело делится и 7.3728 МГц и 11.0592 МГц. Но это все было актуально для микроконтроллеров 20-летней давности, имевших целочисленный делитель частоты УАПП (UART). Современные же контроллеры практически поголовно имеют дробные делители и в них можно получить приемлемую ошибку для стабильной работы при любой частоте кварца.

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

[rtl_user]

В каком то ДШ была табличка. МК атмега 8 старый или нет?

[Сергей Борщ]

В каком то ДШ была табличка.

Ну да, самим поделить частоту кварца на скорость и найти ошибку нам уже лень, нам надо чтобы дядя посчитал и в табличку свел. Сочувствую.

МК атмега 8 старый или нет?

Первое техописание на него было выпущено в 2001 году (см. раздел Datasheet Revision History в конце описания). 16 лет - это старый или нет?

[rtl_user]

спасибо

[mantech]

Попадалась информация что по uart минимальное число ошибок с кварцем 3.6864. Кто то работал?

В МК есть делитель входной частоты, которую он делит на скорость передачи данных. Так вот, если число получается дробное - могут возникнуть ошибки приема, поэтому стараются делать целое число и, если нужна одна из стандартных скоростей передачи (1200, 9600, 115200бит\сек) выбирают соотв. кварцы. Я в своих устройствах стараюсь использовать кварц 11059200 Гц, т.к. в АВРках позволяет работать на 3.3В и быстродействие МК получается очень хорошее.

[Эдди]

16 лет - это старый или нет?

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

[Obam]

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

Пока производитель сам не предупредит (по опыту, атмел не замечен в скоропалительности) - "NRND", нечего раньше времени паниковать.

[rtl_user]

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

[ArtemKAD]

В МК есть делитель входной частоты, которую он делит на скорость передачи данных. Так вот, если число получается дробное - могут возникнуть ошибки приема, поэтому стараются делать целое число и, если нужна одна из стандартных скоростей передачи (1200, 9600, 115200бит\сек) выбирают соотв. кварцы.

Че за глупость вы несете, описание USART-а наконец не желаете прочитать?!
НИКАКИХ ошибок не будет пока взаимная скорость приемника и передатчика не разойдутся на пол бита за ОДИН передаваемый байт т.е. пол бита на 10 передаваемых бит(8 бит данных плюс старт- и стоп-бит). Или иначе говоря для отсутствия ошибок взаимные скорости не должны отличаться больше чем на 1/20 т.е. на 5%.

У вас, из-за неудачного кварца, может быть и 3% ошибка установки скорости, но пока в диапазоне температур и напряжений скорость не уйдет еще на 2% ошибок не будет от слова СОВСЕМ.

[Сергей Борщ]

У вас, из-за неудачного кварца, может быть и 3% ошибка установки скорости, но пока в диапазоне температур и напряжений скорость не уйдет еще на 2% ошибок не будет от слова СОВСЕМ.

На второй стороне тоже может быть 3%, но в другую сторону. Так что урезаем осетра вдвое (до 2.5%) и можем спать спокойно.

[@Ark]

На второй стороне тоже может быть 3%, но в другую сторону. Так что урезаем осетра вдвое (до 2.5%) и можем спать спокойно.

Чтобы совсем спокойно спать, лучше осетра еще урезать - до 1% (с обеих сторон).

Любой кварц подойдет по стабильности и точности для использования в тактовом генераторе МК. Из тактовой, путем деления, будет получена скорость для UART. Если есть ограничения на выбор делителя, что часто имеет место в мелких МК, то лучше использовать кварцы с частотами, кратными 115200.

Без кварца, на внутреннем генераторе (зачастую, недостаточно точном и стабильном), также, можно организовать надежную работу UART. Но для этого потребуются специальные процедуры калибровки генератора, перед каждым сеансом связи. Или после сбоев, соответственно. Это имеет смысл, только если хотите сэкономить на кварце. То есть для простых, но (крупно)серийных изделий. В остальных случаях это не актуально...

[ArtemKAD]

Может быть и больше. Главное, что в тех таблицах из даташитов в которых написано "Error" это не процент битых пакетов при передаче, а ошибка установки конкретной скорости.

[LII]

Если есть ограничения на выбор делителя, что часто имеет место в мелких МК, то лучше использовать кварцы с частотами, кратными 115200.

Товарищи, за теоретизированием вы забыли суть решаемой задачи. Связываются два одинаковых микроконтроллера с одинаковыми кварцами. Зачем подгонять скорость обмена к стандартным величинам? Для надежной работы достаточно чтобы частоты приемника и передатчика были одинаковыми, никакой кратности не нужно добиваться. Об этом уже говорили выше:

Че за глупость вы несете, описание USART-а наконец не желаете прочитать?!
НИКАКИХ ошибок не будет пока взаимная скорость приемника и передатчика не разойдутся на пол бита за ОДИН передаваемый байт

[@Ark]

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

Для порядка.
На первый взгляд, полностью изолированные, локальные устройства, нередко, потом становятся частями более сложных систем. Что изначально, возможно, и не планировалось. И сразу встают вопросы совместимости... Даже если не становятся, то в процессе отладки может возникнуть, например, потребность подключить их к порту ПК, для проверки...
P.S. Лучше придерживаться стандартов и "канонов", гласных и негласных. Тем более, когда это ничего не стоит, а необходимость их нарушения ни чем не обоснована. Меньше будет проблем в будущем...

[mantech]

Для порядка.
На первый взгляд, полностью изолированные, локальные устройства, нередко, потом становятся частями более сложных систем. Что изначально, возможно, и не планировалось. И сразу встают вопросы совместимости... Даже если не становятся, то в процессе отладки может возникнуть, например, потребность подключить их к порту ПК, для проверки...
P.S. Лучше придерживаться стандартов и "канонов", гласных и негласных. Тем более, когда это ничего не стоит, а необходимость их нарушения ни чем не обоснована. Меньше будет проблем в будущем...

Полностью согласен!