Jump to content

    

Не хватает UART-ов

Как это?

Т.е. датчики имеют прямой доступ к оперативной памяти процессора? :wacko:

в определенный момент - да)) а что?

Share this post


Link to post
Share on other sites
1 байт запрос - 16 байт ответ

собственно, столько полезной информации и есть - 16 байт за 2,5 мс

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

Пример: есть дискретный вход на котором может появиться сигнал в виде очень короткого импульса, скажем 1 мс, но не чаще 1 раза в секунду.

Импульсы нужно считать, а в конце смены мастер смены (человек на производстве) переписывает показания.

Один программист сделает опрос каждые 0.5мс, чтоб "не прозевать" импульс и будет передавать текущее состояние дискретного входа.

Второй программист сделает обработку входных данных - будет опрашивать вход с периодом 0.5 мс, и при возникновении фронта

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

Да, будет задержка между приходом импульса и получением этого события (<0.5 сек), но с учетом того, что показания снимаются раз в смену,

опрос вообще можно проводить хоть раз в 10 секунд.

Третий программист поставит CAN и сделает отправку пакета при возникновении фронта на входе.

Отсюда вопрос: почему вы не второй или третий программист?

Какие данные могут меняться 1000 раз в секунду и аж 16 байт?

 

Share this post


Link to post
Share on other sites
в определенный момент - да)) а что?

Что за датчики?

Просто впервые слышу про термопары или терморезисторы которые сами умеют лезть напрямую без участия контроллера к нему в память :wacko:

 

И зачем такая скорость (мегабоды)?

что? У вас АСУ сверхбыстродействующими процессами?

 

Какие данные могут меняться 1000 раз в секунду и аж 16 байт?

Вот вот. Это очень мало где такая скорость.

Разве что взрыв контролировать

 

В большинстве случаев раз в 100 миллисекунд опрашивать датчик более чем достаточно.

Почти во всемх АСУТП цикл 100 мс и более

 

Или топикстартер собрался по UART-у гигабайтные видео в HD-качестве гонять? :laugh:

Share this post


Link to post
Share on other sites
Какую шину??? UART - это не шина. Он допускает соединение только двух устройств. Читаем учебники.

 

Я уже несколько раз о девяти битах говорил. UART на коротких расстояниях можно использовать совершенно аналогично CAN-шине: все устройства сидят на двух проводах шине, разделяя Rx/Tx. Мастер перекрестно подключен. Выбор устройства - командой с установленным девятым битом. Далее - общение. После - выбор следующего устройства. И так в цикле.

А ваши бешенные скорости мне совершенно непонятны, разве что вы пытаетесь ЭБУ для автомобиля забульбенить. Но даже там за глаза килогерца на опрос критичных датчиков, что составляет чуть меньше двенадцати килобит на датчик при самых кошерных АЦП. Итого, в максимуме получаем два десятка датчиков → 240 кбит/с. Не такая уж и большая скорость.

Edited by Эдди

Share this post


Link to post
Share on other sites
Дело в том, что нужно 9 UART-ов) еще один, чтобы данные от всех датчиков слать по RS-485

Запрос - чтобы синхронизировать данные от датчиков. У них же частоты выдачи данных гуляют немного. А тут получается, я их выравниваю.

Тогда Вам тем более нужно выдавать запрос как я написал - с одного UART.TX на все RX датчиков сразу. Все RX датчиков соединить в параллель.

9-й UART можно сделать софтовым.

 

то, что датчики работают через DMA, а для общего UART-а, как тут посчитали, нужна скорость 1,4 мбит

Вам пишут про софтовый UART для каждого датчика. Заводите 8 TX-ов от датчиков на один 8-разрядный GPIO-порт. Сэмплируете его DMA-каналом тактируемым таймером (битовая_частота * 16).

Далее - программно разбираете все 8 потоков сэмплов.

 

Вобщем - либо 8 софтовых UART на датчики, 1 аппаратный UART - на RS-485.

Либо - 8 аппаратных UART на датчики, 1 софтовый на RS-485.

 

Я уже несколько раз о девяти битах говорил. UART на коротких расстояниях можно использовать совершенно аналогично CAN-шине: все устройства сидят на двух проводах шине, разделяя Rx/Tx. Мастер перекрестно подключен. Выбор устройства - командой с установленным девятым битом. Далее - общение. После - выбор следующего устройства. И так в цикле.

Это называется RS-485. Иначе Вы никак не объедините 8 TX-ов от датчиков. Никакие наколенные колхозы на открытых коллекторах и монтажных ИЛИ/И на длинных линиях (как у ТС на метрах кабеля) работать не будут - будут только помехи ловить. Тем более на таких скоростях. Тем более с таким кол-вом узлов (9шт), посчитайте хотя-бы общую паразитную ёмкость всех выходов, подключенных к шине и суммарную индуктивность проводов. Даже просто активный TTL-выход МК и то стоит выбрать сильноточный (если позволяет МК), а уж ОК ну никак нельзя.

А для нормального соединения устройств с UART-интерфейсом в шину придумана RS-485. Только это уже не голый UART и требует много обвязки (доп. микросхем) на каждый датчик и центр.

А вот обычный UART с нормальным TTL-выходом (а не ОК) вполне себе нормально будет работать на 2 метрах кабеля. И возможно даже и на 350кБит/с (хотя тоже не очень хорошо так делать).

Share this post


Link to post
Share on other sites
UART на коротких расстояниях можно использовать совершенно аналогично CAN-шине: все устройства сидят на двух проводах шине, разделяя Rx/Tx.

а так же Ethernet и всем другим сетевым интерфейсам.

После подобных постов начинающие начинают думать, что UART, это CAN или CAN, это UART. ;-), всего три провода !!!

 

PS:

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

И не раз всплывал CAN.

Этот интерфейс (несколько уровней OSI) может позволить значительно упростить и построение сети и программу.

Share this post


Link to post
Share on other sites
И не раз всплывал CAN.

Этот интерфейс (несколько уровней OSI) может позволить значительно упростить и построение сети и программу.

Возможно в использованных ТС-ом МК в датчиках CAN-а нет. Скорей всего там стоят какие-то простенькие дешёвые МК, так что возможно.

Share this post


Link to post
Share on other sites
Возможно в использованных ТС-ом МК в датчиках CAN-а нет. Скорей всего там стоят какие-то простенькие дешёвые МК, так что возможно.

Лет 10 назад CAN был дорогим, сейчас он много дешевле и шире представлен.

 

STM32F091CB - ~2у.е.

STM32F048G6 - ~ 1у.е.

 

Ещё не поднималась тема надёжности данных, которые гоняются на высокой скорости, физический уровень какой?

 

Так что вопрос на самом деле не в количестве UART, а в принципах построения сети, начиная от физического уровня и заканчивая обработкой пакетов.

 

PS:

Данная тема - наглядный пример, когда опрометчиво заложенные очень простые решения, вырастают в большой "колхоз" (ОК на 350кбит и непонятный кабель).

 

PS2:

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

Закладывать 100% использование ресурсов - потенциальные грабли.

В данной теме ресурсов не хватает - стоит подумать шире, чем лепить заплаты.

Share this post


Link to post
Share on other sites
Тогда Вам тем более нужно выдавать запрос как я написал - с одного UART.TX на все RX датчиков сразу. Все RX датчиков соединить в параллель.

9-й UART можно сделать софтовым.

 

 

Вам пишут про софтовый UART для каждого датчика. Заводите 8 TX-ов от датчиков на один 8-разрядный GPIO-порт. Сэмплируете его DMA-каналом тактируемым таймером (битовая_частота * 16).

Далее - программно разбираете все 8 потоков сэмплов.

 

Вобщем - либо 8 софтовых UART на датчики, 1 аппаратный UART - на RS-485.

Либо - 8 аппаратных UART на датчики, 1 софтовый на RS-485.

не, софтовые UART-ты городить совсем не хочется. я этого никогда не делал, не совсем представляю глубину и ширину этого вопроса.

честно говоря, мне проще поставить простенький МК (который уже стоит на датчиках например), который будет тупо принимать байт по SPI и отправлять по UART дальше на RS-485.

еще была мысль - поставить два МК (каждый с 5-ю UART-ами), по 4 UART-a на датчики, а 2 UART-a объединить.

но два МК у нас почему то не очень одобряют...

 

А вот обычный UART с нормальным TTL-выходом (а не ОК) вполне себе нормально будет работать на 2 метрах кабеля. И возможно даже и на 350кБит/с (хотя тоже не очень хорошо так делать).

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

как Вы считаете, какая скорость на таком расстоянии была бы более-менее приемлемой?

 

Share this post


Link to post
Share on other sites
Все не правы, потому что автор сам не знает, что хочет, а тему создал как эмоцию на "по идее, 8 должны примерно одновременно работать".

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

Снова ни разу не прояснили назначение темы, потому что до неё задача по-прежнему изначально уже была полностью решена чередованием USART'ов штатным перенаправителем выводов — USART1 доступен всегда для выгона наружу, 6 других подключены к датчикам постоянно и один USART перенаправитель чередует на два датчика.

Share this post


Link to post
Share on other sites
полностью решена чередованием USART'ов штатным перенаправителем выводов — USART1 доступен всегда для выгона наружу, 6 других подключены к датчикам постоянно и один USART перенаправитель чередует на два датчика.

не понял, что Вы называете штатным перенаправителем выводов? ремапинг выводов? у меня есть сомнения насчет того, какое состояние примет выход push pull после ремапинга.

ну и интересно, может еще какие то идеи будут по решению этой проблемы...

 

Share this post


Link to post
Share on other sites
у меня есть сомнения насчет того, какое состояние примет выход push pull после ремапинга

Ответ Вам давно дан на первой странице темы:

 

Про состояние пинов когда их от UART на GPIO переключаете - как установите так и будет.

Share this post


Link to post
Share on other sites
Ответ Вам давно дан на первой странице темы:

Про состояние пинов когда их от UART на GPIO переключаете - как установите так и будет.

я это не очень понял, что значит как установите, так и будет?

я просто назначаю пины на UART, включаю UART и он устанавливает TX в "1". я пин отдельно никак не устанавливаю.

когда буду ремапить, сначала надо выключить UART - логично, что TX сбросится в "0"

Share this post


Link to post
Share on other sites
когда буду ремапить, сначала надо выключить UART - логично, что TX сбросится в "0"

С чего бы это??? Неужто STM32 настолько крив? :smile3009:

Во всех нормальных МК, состояние GPIO сохраняется при переключении мультиплексора входов.

Вам, юноша, лучше открыть даташит на странице "Схемотехника входов" и посмотреть схему.

Share this post


Link to post
Share on other sites
когда буду ремапить, сначала надо выключить UART - логично, что TX сбросится в "0"

Если перед этим вывести в порт "1", то после ремапа будет, логично, "1".

У F10x и F09x ремап сильно отличается.

У новых F09x достаточно просто изменять GPIOn->MODER регистр (с OUTPUT на AF и обратно).

При этом GPIOn->AFR можно связать с функциями UART и не менять в ходе ремапа.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this