Dima1060 0 23 декабря, 2015 Опубликовано 23 декабря, 2015 · Жалоба Как это? Т.е. датчики имеют прямой доступ к оперативной памяти процессора? в определенный момент - да)) а что? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 23 декабря, 2015 Опубликовано 23 декабря, 2015 · Жалоба 1 байт запрос - 16 байт ответ собственно, столько полезной информации и есть - 16 байт за 2,5 мс Время реакции чего на чего? Когда пришел запрос - датчик должен сразу передать данные, чтобы уложиться в тайминг. Пример: есть дискретный вход на котором может появиться сигнал в виде очень короткого импульса, скажем 1 мс, но не чаще 1 раза в секунду. Импульсы нужно считать, а в конце смены мастер смены (человек на производстве) переписывает показания. Один программист сделает опрос каждые 0.5мс, чтоб "не прозевать" импульс и будет передавать текущее состояние дискретного входа. Второй программист сделает обработку входных данных - будет опрашивать вход с периодом 0.5 мс, и при возникновении фронта инкрементировать некий счетчик. Опрос датчика сделает раз в 0.5 сек и будет передавать не состояние входа, а значение счетчика. Да, будет задержка между приходом импульса и получением этого события (<0.5 сек), но с учетом того, что показания снимаются раз в смену, опрос вообще можно проводить хоть раз в 10 секунд. Третий программист поставит CAN и сделает отправку пакета при возникновении фронта на входе. Отсюда вопрос: почему вы не второй или третий программист? Какие данные могут меняться 1000 раз в секунду и аж 16 байт? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FluktuacyaVaccuma 0 23 декабря, 2015 Опубликовано 23 декабря, 2015 · Жалоба в определенный момент - да)) а что? Что за датчики? Просто впервые слышу про термопары или терморезисторы которые сами умеют лезть напрямую без участия контроллера к нему в память И зачем такая скорость (мегабоды)? что? У вас АСУ сверхбыстродействующими процессами? Какие данные могут меняться 1000 раз в секунду и аж 16 байт? Вот вот. Это очень мало где такая скорость. Разве что взрыв контролировать В большинстве случаев раз в 100 миллисекунд опрашивать датчик более чем достаточно. Почти во всемх АСУТП цикл 100 мс и более Или топикстартер собрался по UART-у гигабайтные видео в HD-качестве гонять? :laugh: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Eddy_Em 2 23 декабря, 2015 Опубликовано 23 декабря, 2015 (изменено) · Жалоба Какую шину??? UART - это не шина. Он допускает соединение только двух устройств. Читаем учебники. Я уже несколько раз о девяти битах говорил. UART на коротких расстояниях можно использовать совершенно аналогично CAN-шине: все устройства сидят на двух проводах шине, разделяя Rx/Tx. Мастер перекрестно подключен. Выбор устройства - командой с установленным девятым битом. Далее - общение. После - выбор следующего устройства. И так в цикле. А ваши бешенные скорости мне совершенно непонятны, разве что вы пытаетесь ЭБУ для автомобиля забульбенить. Но даже там за глаза килогерца на опрос критичных датчиков, что составляет чуть меньше двенадцати килобит на датчик при самых кошерных АЦП. Итого, в максимуме получаем два десятка датчиков → 240 кбит/с. Не такая уж и большая скорость. Изменено 23 декабря, 2015 пользователем Эдди Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 24 декабря, 2015 Опубликовано 24 декабря, 2015 · Жалоба Дело в том, что нужно 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кБит/с (хотя тоже не очень хорошо так делать). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
spf 0 24 декабря, 2015 Опубликовано 24 декабря, 2015 · Жалоба UART на коротких расстояниях можно использовать совершенно аналогично CAN-шине: все устройства сидят на двух проводах шине, разделяя Rx/Tx. а так же Ethernet и всем другим сетевым интерфейсам. После подобных постов начинающие начинают думать, что UART, это CAN или CAN, это UART. ;-), всего три провода !!! PS: Неоднократно задан вопрос целесообразности построения системы с использованием UART. И не раз всплывал CAN. Этот интерфейс (несколько уровней OSI) может позволить значительно упростить и построение сети и программу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 24 декабря, 2015 Опубликовано 24 декабря, 2015 · Жалоба И не раз всплывал CAN. Этот интерфейс (несколько уровней OSI) может позволить значительно упростить и построение сети и программу. Возможно в использованных ТС-ом МК в датчиках CAN-а нет. Скорей всего там стоят какие-то простенькие дешёвые МК, так что возможно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
spf 0 24 декабря, 2015 Опубликовано 24 декабря, 2015 · Жалоба Возможно в использованных ТС-ом МК в датчиках CAN-а нет. Скорей всего там стоят какие-то простенькие дешёвые МК, так что возможно. Лет 10 назад CAN был дорогим, сейчас он много дешевле и шире представлен. STM32F091CB - ~2у.е. STM32F048G6 - ~ 1у.е. Ещё не поднималась тема надёжности данных, которые гоняются на высокой скорости, физический уровень какой? Так что вопрос на самом деле не в количестве UART, а в принципах построения сети, начиная от физического уровня и заканчивая обработкой пакетов. PS: Данная тема - наглядный пример, когда опрометчиво заложенные очень простые решения, вырастают в большой "колхоз" (ОК на 350кбит и непонятный кабель). PS2: При разработке крайне желательно закладывать запас прочности, чтобы потом можно было иметь возможность для манёвра. Закладывать 100% использование ресурсов - потенциальные грабли. В данной теме ресурсов не хватает - стоит подумать шире, чем лепить заплаты. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dima1060 0 24 декабря, 2015 Опубликовано 24 декабря, 2015 · Жалоба Тогда Вам тем более нужно выдавать запрос как я написал - с одного 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кБит/с (хотя тоже не очень хорошо так делать). вчера посчитал, оказывается у меня почти трехкратный запас по скорости, то есть по идее, скорость можно уменьшить как Вы считаете, какая скорость на таком расстоянии была бы более-менее приемлемой? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Plain 226 24 декабря, 2015 Опубликовано 24 декабря, 2015 · Жалоба Все не правы, потому что автор сам не знает, что хочет, а тему создал как эмоцию на "по идее, 8 должны примерно одновременно работать". мне надо выдерживать определенную частоту опроса датчиков. если этот опрос делать по одной шине, то нужно скорость в 8 раз больше Снова ни разу не прояснили назначение темы, потому что до неё задача по-прежнему изначально уже была полностью решена чередованием USART'ов штатным перенаправителем выводов — USART1 доступен всегда для выгона наружу, 6 других подключены к датчикам постоянно и один USART перенаправитель чередует на два датчика. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dima1060 0 24 декабря, 2015 Опубликовано 24 декабря, 2015 · Жалоба полностью решена чередованием USART'ов штатным перенаправителем выводов — USART1 доступен всегда для выгона наружу, 6 других подключены к датчикам постоянно и один USART перенаправитель чередует на два датчика. не понял, что Вы называете штатным перенаправителем выводов? ремапинг выводов? у меня есть сомнения насчет того, какое состояние примет выход push pull после ремапинга. ну и интересно, может еще какие то идеи будут по решению этой проблемы... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Plain 226 24 декабря, 2015 Опубликовано 24 декабря, 2015 · Жалоба у меня есть сомнения насчет того, какое состояние примет выход push pull после ремапинга Ответ Вам давно дан на первой странице темы: Про состояние пинов когда их от UART на GPIO переключаете - как установите так и будет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dima1060 0 25 декабря, 2015 Опубликовано 25 декабря, 2015 · Жалоба Ответ Вам давно дан на первой странице темы: Про состояние пинов когда их от UART на GPIO переключаете - как установите так и будет. я это не очень понял, что значит как установите, так и будет? я просто назначаю пины на UART, включаю UART и он устанавливает TX в "1". я пин отдельно никак не устанавливаю. когда буду ремапить, сначала надо выключить UART - логично, что TX сбросится в "0" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 25 декабря, 2015 Опубликовано 25 декабря, 2015 · Жалоба когда буду ремапить, сначала надо выключить UART - логично, что TX сбросится в "0" С чего бы это??? Неужто STM32 настолько крив? :smile3009: Во всех нормальных МК, состояние GPIO сохраняется при переключении мультиплексора входов. Вам, юноша, лучше открыть даташит на странице "Схемотехника входов" и посмотреть схему. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 25 декабря, 2015 Опубликовано 25 декабря, 2015 · Жалоба когда буду ремапить, сначала надо выключить UART - логично, что TX сбросится в "0" Если перед этим вывести в порт "1", то после ремапа будет, логично, "1". У F10x и F09x ремап сильно отличается. У новых F09x достаточно просто изменять GPIOn->MODER регистр (с OUTPUT на AF и обратно). При этом GPIOn->AFR можно связать с функциями UART и не менять в ходе ремапа. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
