Коммутатор USART на STM32

[Гость Sfort]

Необходимо на STM32 сделать связь по одному UART с 5 разными устройствами, которые опрашиваются по очереди. Можно ли осуществить это испоьзуя один UART, подключенный к двум GPIO (этого же МК), на который можно дублировать сигналы от других GPIO (этого же МК), подключенных к UART подключаемых устройств? То есть коммутатор UART получается.

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[ART_ME]

На этих пяти разных устройствах какой протокол и какой стандарт?

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[Гость Sfort]

На тех устройствах тоже STM32 с аппаратным USART.

Тоже STM32 c тем же UARTом.

[Реклама]

Выбираем схему BMS для корректной работы литий-железофосфатных (LiFePO4) аккумуляторов

 Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ, также как и для других, очень важен контроль процесса заряда и разряда, а специализированных микросхем для этого вида аккумуляторов не так много. Инженеры КОМПЭЛ подготовили список имеющихся микросхем и возможных решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[ART_ME]

Тогда либо ставить известный протокол с адресацией, например модбас, либо самому такой протокол сочинить в упрощенном варианте.

[Sfort2]

А зачем адресация? Не нужна она.

Проводками соединяем:

UART RX ---> GPIO1, UART TX --->GPIO2,

UART RX устройства n --->GPIO3, UART TX устройства n --->GPIO4.

Если хочу подключиться к устройству n по UART, пишу

GPIO1 = GPIO4;

GPIO3 = GPIO2;

Включаю UARTы и все должно работать. Или что-то не получится? Например, может порты GPIO не будут успевать передавать, но ведь UART работает с DMA и он независим.

[MasterElectric]

@Sfort2 поставь драйвер RS485. 

[Yurkin2015]

2 hours ago, Sfort2 said:

UART RX ---> GPIO1,

Если GPIO1 является входом Rx UART, то изнутри процессора в него уже ничего записать невозможно. То есть такая конструкция не будет работать

2 hours ago, Sfort2 said:

GPIO1 = GPIO4;

Вам нужно реализовать софтверный UART. Тогда можно сделать да хоть и 5 таких уартов и назначить любые ноги для них. Будет 5 входов Rx и 5 выходов Tx на обычных GPIO ногах.

[ART_ME]

32 минуты назад, Yurkin2015 сказал:

Вам нужно реализовать софтверный UART.

Пои таком подходе UART вообще не нужен, считывание данных можно организовать и побитно. Например азбукой Морзе. 

[Yurkin2015]

4 minutes ago, ART_ME said:

UART вообще не нужен

А те, внешние 5 устройств, тоже придётся переделать и перевести на азбуку Морзе? 

[ART_ME]

8 минут назад, Yurkin2015 сказал:

внешние 5 устройств, тоже придётся переделать и перевести на азбуку Морзе? 

Необязательно.

Можно кинуть между всеми МК шину данных, шину адресов и шину управления. 

[mixan23]

Может лучше использовать SPI или I2C? Или обязательное требование uart?

[Гость Sfort]

RS485 выход, но не хочу усложнять и удорожать схему.
GPIO1 не является входом Rx UART, а подключчен к нему цветным проводочком, он явлетя именно логическим выходом.
Софтверный UART я бы с удовольствием, но не знаю как (не нашел для STM32F1xx). Подскажете где - буду благодарен.
Азбука морзе можно, но лучше тогда софтверный UART.
Шина данных не годится, так как устройства на удалении 2м, будут соединятся проводом 2питание 2связь.
SPI или I1C не годится, так как расстояние 2м по проводам, да и устройства не должны иметь постоянного адреса. Устройства подключаются штеккером, могут меняться местами, и т.д..

Значит выход такой: софтверный UART или моя предложенная в самом начале схема с цветными проводочками :), так как я явного ответа, что это работать не будет, не услышал.

Буду пробовать, если получится - расскажу.
Спасибо за ответы всем!

[mr_smit]

А не проще поставить коммутатор который будет просто перекидывать вход на нужный выход? Микросхемы есть вроде такие и не дефицит. Да хоть на реле. Тогда и stm32 не нужен.

[AVI-crak Home]

Сомневаюсь что пять разных устройств имеют надёжную землю, с блокировкой по ВЧ импульсам. Это они должны очень близко находиться, в пределах двадцати сантиметров.

А для всего остального остальной мир уже давно использует CAN.

[mail_robot]

4 часа назад, AVI-crak Home сказал:

А для всего остального остальной мир уже давно использует CAN

листал листал, думаю - почему никто САN до сих пор не предложил?

[Sfort2]

Всё, эксперимент завершен.

Связь по одному UART с 5 разными устройствами, которые опрашиваются по очереди осуществил, испоьзуя один UART, подключенный к двум GPIO (этого же МК), на который дублировал сигналы от других GPIO (этого же МК), подключенных к UART подключаемых устройств.

Схематично выглядит так:

Безымянные устройства подключаются своими UARTами к пинам ведущего камушка:

устройство_a_Тх к a_in; устройство_a_Rх к a_out;

устройство_b_Тх к b_in; устройство_b_Rх к b_out;

устройство_c_Тх к c_in; устройство_c_Rх к c_out;

устройство_d_Тх к d_in; устройство_d_Rх кd_out;

устройство_e_Тх к e_in; устройство_e_Rх к e_out.

В ведущем камушке проводками:

comm_in подключен к USART3_TX; 

comm_out подключен к USART3_RX.

Если хотим пообщаться с устройством b, то в бесконечном цикле, то:

    if(HAL_GPIO_ReadPin(b_in_GPIO_Port, b_in_Pin) == GPIO_PIN_SET) HAL_GPIO_WritePin(comm_out_GPIO_Port, comm_out_Pin, GPIO_PIN_SET);
    else HAL_GPIO_WritePin(comm_out_GPIO_Port, comm_out_Pin, GPIO_PIN_RESET);

    if(HAL_GPIO_ReadPin(comm_in_GPIO_Port, comm_in_Pin) == GPIO_PIN_SET) HAL_GPIO_WritePin(b_out_GPIO_Port, b_out_Pin, GPIO_PIN_SET);
    else HAL_GPIO_WritePin(b_out_GPIO_Port, b_out_Pin, GPIO_PIN_RESET);

UART3 используем с DMA и, естественно, с прерываниями.

При тактировании камушка 8МГц, скорость передачи не более 9600к.

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

04.10.2019 в 03:44, mail_robot сказал:

листал листал, думаю - почему никто САN до сих пор не предложил?

А CAN все-таки иногда буду использовать, понравился он. Спасибо.

[AVI-crak Home]

2 часа назад, Sfort2 сказал:

Всё, эксперимент завершен.

То-есть общение в пакетном режиме так и не получилось...

Жаль, там чуть чуть подумать нужно было. 

[mail_robot]

@Sfort2 весьма кривоногое решение у вас вышло. И я думаю в реальных условиях будет довольно нестабильным. Лучше поискать другое решение, пока не поздно. Я не знаю что у вас за задача. Там может и кан будет не лучшим решением, потому как он заточен на обмен телеграммами между самостоятельными локальными устройствами, которые довольно лаконичны по своей сути. Но есть же и другие решения. Как то например адресуемый UART. Если речь идет о передаче пакетов только ведомым устройствам. Хотя там на самом деле можно у двусторонний обмен достаточно легко организовать. От ведущего пакеты ведомому, от ведомого на нулевой адрес. Проблема такого решения состоит в постоянной загрузке обработчиков UART в каждом из устройств. Если данных не много, то кан идеален как с точки зрения аппаратных ресурсов, так и по организации самой сети.

[Sfort2]

15 часов назад, mail_robot сказал:

@Sfort2 весьма кривоногое решение у вас вышло. И я думаю в реальных условиях будет довольно нестабильным. Лучше поискать другое решение, пока не поздно. Я не знаю что у вас за задача. Там может и кан будет не лучшим решением, потому как он заточен на обмен телеграммами между самостоятельными локальными устройствами, которые довольно лаконичны по своей сути. Но есть же и другие решения. Как то например адресуемый UART. Если речь идет о передаче пакетов только ведомым устройствам. Хотя там на самом деле можно у двусторонний обмен достаточно легко организовать. От ведущего пакеты ведомому, от ведомого на нулевой адрес. Проблема такого решения состоит в постоянной загрузке обработчиков UART в каждом из устройств. Если данных не много, то кан идеален как с точки зрения аппаратных ресурсов, так и по организации самой сети.

Я согласен, поэтому смотрю в сторону CAN.

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

[Sfort2]

25.11.2019 в 12:36, AVI-crak Home сказал:

То-есть общение в пакетном режиме так и не получилось...

Жаль, там чуть чуть подумать нужно было. 

Получилось организовать передачу данных с использованием прерываний по фронтам. Скорость выросла. стабильность выросла. Работает просто отлично.