Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Последовательное соединение нескольких МК по uart
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > AVR
rtl_user
Возможно ли соединить несколько МК по uart(4-5штук)?
Т.е. каждый контроллер является и мастером и ведомым( относительно следующих МК)
Передаем например 1 байт следующий МК принимает добавляет свой байт и передает дальше и т.д.
iosifk
Цитата(rtl_user @ Dec 5 2017, 21:07) *
Возможно ли соединить несколько МК по uart(4-5штук)?
Т.е. каждый контроллер является и мастером и ведомым( относительно следующих МК)
Передаем например 1 байт следующий МК принимает добавляет свой байт и передает дальше и т.д.

Посмотрите, как реализован интерфейс LIN.
@Ark
Цитата(rtl_user @ Dec 5 2017, 21:07) *
Возможно ли соединить несколько МК по uart(4-5штук)?
Т.е. каждый контроллер является и мастером и ведомым( относительно следующих МК)
Передаем например 1 байт следующий МК принимает добавляет свой байт и передает дальше и т.д.

Возможно.

rtl_user
Цитата(@Ark @ Dec 5 2017, 20:09) *
Возможно.

Не получается больше трех(
aaarrr
Цитата(rtl_user @ Dec 5 2017, 23:12) *
Не получается больше трех(

Для каждого МК это соединение точка-точка, так что дело не в UART. Проверяйте логику работы ПО. Что именно не получается?
kolobok0
Цитата(rtl_user @ Dec 5 2017, 21:07) *
Возможно ли соединить несколько МК по uart(4-5штук)?....


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

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

удачи вам
(круглый)
LII
Цитата(rtl_user @ Dec 5 2017, 22:12) *
Не получается больше трех(

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


Alex A. Mihaylov
Цитата(LII @ Dec 6 2017, 00:59) *
Так не получается?



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

Но, если честно, лучше не городить огород а взять RS485 и поверх него какой-нить ModBus. При любом раскладе реализация будет в том или ином виде ущербной. Но так хоть сколько-нить стандартной.
rtl_user
Цитата(Alex A. Mihaylov @ Dec 6 2017, 04:55) *
Получится. Добавьте еще одну линию от последнего TX к первому RX и получите классическую топологию кольцо. Дальше вопрос только назначить всем уникальные адреса (административно) и договориться о формате пакетов. Опробовано неоднократно.

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


Эдди
Да элементарно они вешаются на параллельный интерфейс (эдакий псевдо-485). Просто ногу Tx нужно настроить не в пушпульный режим, а в открытый сток. И повесить резистор подтягивающий на всю линию (потому как внутренняя подтяжка при большом количестве девайсов на линии будет жрать ток).
OKF
Цитата(rtl_user @ Dec 5 2017, 23:12) *
Не получается больше трех(

Эт если соображать на троих.)))
rtl_user
Цитата(Эдди @ Dec 6 2017, 06:26) *
Да элементарно они вешаются на параллельный интерфейс (эдакий псевдо-485). Просто ногу Tx нужно настроить не в пушпульный режим, а в открытый сток. И повесить резистор подтягивающий на всю линию (потому как внутренняя подтяжка при большом количестве девайсов на линии будет жрать ток).

МК соединяются последовательно. Как на рисунке только без третьего провода. Т.е. есть мастер и он передает байт данных, принимает ведомый плюсует к полученным и передает уже два байта дальше и т.д. Скорость не важна.
На бумаге все красиво, не знаю как в железе и наверно придется ставить генератор вместо кварца
aaarrr
Цитата(rtl_user @ Dec 6 2017, 08:45) *
На бумаге все красиво, не знаю как в железе и наверно придется ставить генератор вместо кварца

В железе решается внятным протоколом. Генератор точно не поможет.
Эдди
Цитата(rtl_user @ Dec 6 2017, 08:45) *
МК соединяются последовательно.

И в чем проблема? Это ж как адресуемые светодиоды получается. По USART1 данные принимаем, по USART2 передаем дальше, откусив первые N байт.
Только с большими длинами линий могут возникнуть косяки.
LII
Цитата(rtl_user @ Dec 6 2017, 07:45) *
МК соединяются последовательно. Как на рисунке только без третьего провода.

Третий провод на рисунке - это общий, он нужен обязательно!
rtl_user
Цитата(LII @ Dec 6 2017, 10:52) *
Третий провод на рисунке - это общий, он нужен обязательно!

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

Цитата(aaarrr @ Dec 6 2017, 07:46) *
В железе решается внятным протоколом. Генератор точно не поможет.

Если частота будет плавать боюсь что будут пропуски.
aaarrr
Цитата(rtl_user @ Dec 6 2017, 13:49) *
Если частота будет плавать боюсь что будут пропуски.

А по какой причине она будет плавать при работе от кварца?
rtl_user
Цитата(aaarrr @ Dec 6 2017, 11:54) *
А по какой причине она будет плавать при работе от кварца?

Всегда считал что генератор более стабильный. Плюс разброс по частоте меньше.
Ну думаю на железе все выйдет, начнем с кварца.
aaarrr
Цитата(rtl_user @ Dec 6 2017, 21:32) *
Всегда считал что генератор более стабильный. Плюс разброс по частоте меньше.

Надо очень сильно постараться, чтобы не вписаться с кварцем в потребности UART'а.
Эдди
Кварц для UART? Там что, частота в несколько мегагерц что ли?
До 115200 всегда хватало внутреннего RC-генератора, выше просто не проверял (но, судя по тому, что на 115200 ошибок вообще не было на линиях до полуметра, оно и на мегагерце должно на коротких линиях работать).
mantech
Цитата(Эдди @ Dec 7 2017, 00:58) *
Кварц для UART? Там что, частота в несколько мегагерц что ли?
До 115200 всегда хватало внутреннего RC-генератора, выше просто не проверял (но, судя по тому, что на 115200 ошибок вообще не было на линиях до полуметра, оно и на мегагерце должно на коротких линиях работать).


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

Цитата(rtl_user @ Dec 6 2017, 21:32) *
Всегда считал что генератор более стабильный. Плюс разброс по частоте меньше.
Ну думаю на железе все выйдет, начнем с кварца.


Стабильный генератор с термокомпенсацией, но стоит он так, что разницу почувствуете. Для УАРТа подойдет кварц с любым ppm.
rtl_user
Попадалась информация что по uart минимальное число ошибок с кварцем 3.6864. Кто то работал?
Сергей Борщ
QUOTE (rtl_user @ Dec 7 2017, 15:14) *
Попадалась информация что по uart минимальное число ошибок с кварцем 3.6864. Кто то работал?
"Слышал звон, да не знаю, где он". Число ошибок зависит исключительно от помеховой обстановки и разности скоростей приемника и передатчика. Если разница больше какого-то определенного числа (зависит от реализации приемника, обычно - если за время передачи одного слова набегает ошибка более половины длительности бита) - будет ошибка. Частота 3686400 делится нацело на стандартные скорости обмена, т.е. ошибка скорости определяется только нестабильностью и погрешностью кварца. Точно также нацело делится и 7.3728 МГц и 11.0592 МГц. Но это все было актуально для микроконтроллеров 20-летней давности, имевших целочисленный делитель частоты УАПП (UART). Современные же контроллеры практически поголовно имеют дробные делители и в них можно получить приемлемую ошибку для стабильной работы при любой частоте кварца.

Если же у вас не стоит задача общаться с внешними устройствами - вы можете общаться между своими контроллерами на любой скорости с любым кварцем, лишь бы эта скорость была одинаковой для всех контроллеров.
rtl_user
В каком то ДШ была табличка. МК атмега 8 старый или нет?
Сергей Борщ
QUOTE (rtl_user @ Dec 7 2017, 17:25) *
В каком то ДШ была табличка.
Ну да, самим поделить частоту кварца на скорость и найти ошибку нам уже лень, нам надо чтобы дядя посчитал и в табличку свел. Сочувствую.
QUOTE (rtl_user @ Dec 7 2017, 17:25) *
МК атмега 8 старый или нет?
Первое техописание на него было выпущено в 2001 году (см. раздел Datasheet Revision History в конце описания). 16 лет - это старый или нет?
rtl_user
спасибо
mantech
Цитата(rtl_user @ Dec 7 2017, 16:14) *
Попадалась информация что по uart минимальное число ошибок с кварцем 3.6864. Кто то работал?


В МК есть делитель входной частоты, которую он делит на скорость передачи данных. Так вот, если число получается дробное - могут возникнуть ошибки приема, поэтому стараются делать целое число и, если нужна одна из стандартных скоростей передачи (1200, 9600, 115200бит\сек) выбирают соотв. кварцы. Я в своих устройствах стараюсь использовать кварц 11059200 Гц, т.к. в АВРках позволяет работать на 3.3В и быстродействие МК получается очень хорошее.
Эдди
Цитата(Сергей Борщ @ Dec 7 2017, 18:36) *
16 лет - это старый или нет?

Явно лучше не использовать для новых разработок.
Obam
Цитата(Эдди @ Dec 8 2017, 09:17) *
Явно лучше не использовать для новых разработок.

Пока производитель сам не предупредит (по опыту, атмел не замечен в скоропалительности) - "NRND", нечего раньше времени паниковать.
rtl_user
Это не серия, а стендовое оборудование. Плюс есть запас который не используется. И по габаритам отлично подходит можно поставить кроватку что бы легко заменить.
Нашел и генераторы и кварцы, начнем с кварца.
ArtemKAD
Цитата(mantech @ Dec 7 2017, 22:16) *
В МК есть делитель входной частоты, которую он делит на скорость передачи данных. Так вот, если число получается дробное - могут возникнуть ошибки приема, поэтому стараются делать целое число и, если нужна одна из стандартных скоростей передачи (1200, 9600, 115200бит\сек) выбирают соотв. кварцы.

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

У вас, из-за неудачного кварца, может быть и 3% ошибка установки скорости, но пока в диапазоне температур и напряжений скорость не уйдет еще на 2% ошибок не будет от слова СОВСЕМ.
Сергей Борщ
QUOTE (ArtemKAD @ Dec 8 2017, 12:21) *
У вас, из-за неудачного кварца, может быть и 3% ошибка установки скорости, но пока в диапазоне температур и напряжений скорость не уйдет еще на 2% ошибок не будет от слова СОВСЕМ.
На второй стороне тоже может быть 3%, но в другую сторону. Так что урезаем осетра вдвое (до 2.5%) и можем спать спокойно.
@Ark
Цитата(Сергей Борщ @ Dec 8 2017, 15:19) *
На второй стороне тоже может быть 3%, но в другую сторону. Так что урезаем осетра вдвое (до 2.5%) и можем спать спокойно.

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

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

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

ArtemKAD
Может быть и больше. Главное, что в тех таблицах из даташитов в которых написано "Error" это не процент битых пакетов при передаче, а ошибка установки конкретной скорости.
LII
Цитата(@Ark @ Dec 8 2017, 16:56) *
Если есть ограничения на выбор делителя, что часто имеет место в мелких МК, то лучше использовать кварцы с частотами, кратными 115200.

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

Цитата(ArtemKAD @ Dec 8 2017, 12:21) *
Че за глупость вы несете, описание USART-а наконец не желаете прочитать?!
НИКАКИХ ошибок не будет пока взаимная скорость приемника и передатчика не разойдутся на пол бита за ОДИН передаваемый байт

@Ark
Цитата(LII @ Dec 8 2017, 21:19) *
Товарищи, за теоретизированием вы забыли суть решаемой задачи. Связываются два одинаковых микроконтроллера с одинаковыми кварцами. Зачем подгонять скорость обмена к стандартным величинам?

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

mantech
Цитата(@Ark @ Dec 8 2017, 23:30) *
Для порядка. sm.gif
На первый взгляд, полностью изолированные, локальные устройства, нередко, потом становятся частями более сложных систем. Что изначально, возможно, и не планировалось. И сразу встают вопросы совместимости... Даже если не становятся, то в процессе отладки может возникнуть, например, потребность подключить их к порту ПК, для проверки...
P.S. Лучше придерживаться стандартов и "канонов", гласных и негласных. Тем более, когда это ничего не стоит, а необходимость их нарушения ни чем не обоснована. Меньше будет проблем в будущем... wink.gif

Полностью согласен!
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2024 Invision Power Services, Inc.