Перейти к содержанию

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


Гость Sfort

Рекомендуемые сообщения

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

Ссылка на комментарий
Поделиться на другие сайты

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

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

Никогда не спорьте с дураками. Они опустят Вас до своего уровня и победят за счет опыта.

 

 

Ссылка на комментарий
Поделиться на другие сайты

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

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

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

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

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

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

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

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

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

Никогда не спорьте с дураками. Они опустят Вас до своего уровня и победят за счет опыта.

 

 

Ссылка на комментарий
Поделиться на другие сайты

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

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

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

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

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

GPIO1 = GPIO4;

GPIO3 = GPIO2;

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

Ссылка на комментарий
Поделиться на другие сайты

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 ногах.

Ссылка на комментарий
Поделиться на другие сайты

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

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

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

Никогда не спорьте с дураками. Они опустят Вас до своего уровня и победят за счет опыта.

 

 

Ссылка на комментарий
Поделиться на другие сайты

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

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

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

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

Никогда не спорьте с дураками. Они опустят Вас до своего уровня и победят за счет опыта.

 

 

Ссылка на комментарий
Поделиться на другие сайты

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

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

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

Ссылка на комментарий
Поделиться на другие сайты

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

Ссылка на комментарий
Поделиться на другие сайты

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

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

Ссылка на комментарий
Поделиться на другие сайты

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

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

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

Нужно делать то, что нужно. А то, что не нужно, делать не нужно. (С) Винни Пух

Ссылка на комментарий
Поделиться на другие сайты

  • 1 месяц спустя...

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

Связь по одному 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 все-таки иногда буду использовать, понравился он. Спасибо.

Ссылка на комментарий
Поделиться на другие сайты

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

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

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

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

Ссылка на комментарий
Поделиться на другие сайты

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

Нужно делать то, что нужно. А то, что не нужно, делать не нужно. (С) Винни Пух

Ссылка на комментарий
Поделиться на другие сайты

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

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

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

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

Ссылка на комментарий
Поделиться на другие сайты

  • 5 месяцев спустя...
25.11.2019 в 12:36, AVI-crak Home сказал:

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

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

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

Ссылка на комментарий
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Ответить в этой теме...

×   Вставлено с форматированием.   Восстановить форматирование

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

Загрузка...
  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
  • Сообщения

    • Вероятно, в разделе "Работа" вам помогут. При условии предоставления чёткого и недвусмысленного технического задания.
    • Привет кто это еще читает. Знакомый купил в Москве по адекватной цене пару  B615D, дал на диагностику перед уверенной эксплуатацией. Одна сразу в защите, большой динамик спален, усилители на высокоомную нагрузку поют, буду позже разбираться. А вот вроде бы вполне работоспособная не сдюжила и 10 минут на хорошей мощности на плотном прогрессиве. Вылетели ключи в БП и драйвера на MMBTA56. Видно что был в ремонте, возможно ключи оказались палёнкой. Есть мысль впаять вместо FQPF13N50  чуток помощней по току 18N50-e. По параметру Qg аналогичные, а по  Сg будут потяжелей, 2350пф против 1800 у 13н50-х. 
    • Ну так теперь фигня вопрос. Проверить, что кнопки невозможно замкнуть одновременно, да определить, на какой ток транзисторы нужны. По характеристикам мотора или по максимально-допустимому току диодов D1-D4. Навскидку, моторчик низковольтный, диоды тоже. Транзисторы тогда на PBSS4350 можно заменить. Они на Али почти задаром продаются.
    • Сами же понимаете, что так не может быть. Или нет "сквозняка", или схема неправильно собрана, элементы не те, битые и пр., и схема защиты не работает. Проверьте сначала работу защёлки защиты при питании от 15 В, отпаяв R19 и подавая туда медленно увеличивающееся напряжение до 1,5 - 2 В (можно с потенциометра ом на 100-500). Добейтесь, чтобы работала. Порог срабатывания измерьте. Пересчитайте в ток через резистор 0,1 Ом. Соответствует ли "правильному"? Проверьте, что у этого резистора сопротивление действительно 0,1 Ом. Запаяйте 0,1 Ом обратно. Напишите, какая лампочка. А то мало ли какая, может она не от "сквозняка", а от броска тока заряда С18 С16 мигает. Транзисторы ключей проверьте. Впаяйте вместо первичной трансформатора резистор ом 150 - 300, чтобы ток с ключей в этот "эквивалент трансформатора" не больше 50-100 мА был. Посмотрите форму напряжения на выходе ключей, в точке соединения С16 и С18, на питании после лампочки. Ищите, где ляп. Умозрительно подсказать можно только по каким-то измеренным данным. Кроме вас никто их не добудет. В общем, как в анекдоте: - Молодой человек, ну делайте же уже хоть что-нибудь!
    • Ну так можно увеличить глубину ООС, тем самым понизив чувствительность и повысив линейность
    • Судя по этой картинке   в трухе передней панели под выступающие болты и шишки паек ЗК динамиков выковыряныфрезерованы выемки, иначе бы динамики так плотно не прилегали бы к ДВП.    А оно тебе надо? "Работает - не мешай"(с)/это уже аксиома, не требующая доказательств/ , пытаясь сделать лучше, чем сделано на заводе. Сanton-ят, т.е. поют, и лучше, чем есть, тебе не сделать. Ну перенесёшь ты динамики наружу, а что тебе это даст? Кроме того, что при попытке их продать(а продавать их когда-нибудь придётся, т.к. эта акустика бюджетного сегмента без потуг на высший класс Hi-Fi) , тебе придётся объяснять потенциальному покупателю причину, по которой какой-то умник заколхозил такую переделку с акустикой, ты ничего хорошего не получишь. Задуманная тобой переделка - это по сути возня ради возни. 
×
×
  • Создать...