Например TDA7294

Форум РадиоКот • Просмотр темы - Сбор данных с кучи UART
Форум РадиоКот
Здесь можно немножко помяукать :)



Текущее время: Вт янв 28, 2020 10:04:05

Часовой пояс: UTC + 3 часа


ПРЯМО СЕЙЧАС:



Начать новую тему Ответить на тему  [ Сообщений: 31 ]  1,  
Автор Сообщение
Не в сети
 Заголовок сообщения: Сбор данных с кучи UART
СообщениеДобавлено: Пн сен 16, 2019 13:50:12 
Первый раз сказал Мяу!

Зарегистрирован: Пт сен 21, 2012 22:58:16
Сообщений: 20
Рейтинг сообщения: 0
Не подскажите идеи реализации, как одновременно получать данные с кучи устройств (в частности GSM модемы и датчики газа) по UART, чтобы не пропустить эти самые данные. Например, какой-нибудь микросхемы с кучей входов UART, буфером и работой с МК по SPI или IIC?

Пока в идеях только приделать к каждому UART устройству по МК, типа ATMega, ну а он уже может "общаться" с основным контроллером как угодно.


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Пн сен 16, 2019 13:58:45 
Друг Кота
Аватар пользователя

Карма: 86
Рейтинг сообщений: 837
Зарегистрирован: Вт мар 16, 2010 22:02:27
Сообщений: 9983
Откуда: ДОНЕЦК (ЮГО-ВОСТОК ua/DPR)
Рейтинг сообщения: 0
В принципе вполне жизнеспособно - только в любом случае предобработка данных и буфер - накопитель должны сидеть в том модуле с ограниченным мозгом.
Да вопрос приоритетности пересылки информации - вдруг какому из них аварийный запрос для экстренного доступа к "голове" потребуется.
:roll:


Вернуться наверх
 
JLCPCB, всего $2 за прототип печатной платы! Цвет - любой!

Отличное качество, подтвержденное более чем 600,000 пользователей! Более 10,000 заказов в день.

Зарегистрируйтесь и получите два купона по 5$ каждый:https://jlcpcb.com/quote

Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Пн сен 16, 2019 14:17:32 
Первый раз сказал Мяу!

Зарегистрирован: Пт сен 21, 2012 22:58:16
Сообщений: 20
Рейтинг сообщения: 0
Да я понимаю, что жизнеспособно, просто на специализированную микросхему надеялся с интерфейсами (много UART)и(SPI). Приемлемо будет, даже если она обойдется несколько дороже вспомогательных МК.


Вернуться наверх
 
PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $88 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay
Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Пн сен 16, 2019 15:49:29 
Поставщик валерьянки для Кота
Аватар пользователя

Карма: 35
Рейтинг сообщений: 283
Зарегистрирован: Пт сен 07, 2018 20:20:02
Сообщений: 2069
Рейтинг сообщения: 0
afynfpbz, обычно, такие устройства живут на скоростях не более 19200. Чаще - 9600. Так что одним МК программно можно одновременно от двух десятков таких устройств принимать. Вообще без аппаратного UART.


Вернуться наверх
 
DC/DC-преобразователи: принципы работы и уникальные решения Maxim Integrated

Что нового можно сказать про DC/DC? Написаны десятки статей, а самостоятельное изготовление преобразователя мощностью от единиц Вт до нескольких кВт даже в домашних условиях не составляет большого труда. Тем не менее, когда речь идет о микро-, или даже нано-ваттах, проектировщик может столкнуться с рядом трудностей. Грамотная схемотехника системы питания не возможна без знания основ работы DC/DC преобразователей. Освежить базовые знания и узнать об особенностях проектирования узлов питания мобильного устройства с оптимальным энергопотреблением можно из следующей статьи.

Читать статьи>>
Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Пн сен 16, 2019 17:38:43 
Первый раз сказал Мяу!

Зарегистрирован: Пт сен 21, 2012 22:58:16
Сообщений: 20
Рейтинг сообщения: 0
ПростоНуб, а вот такая мысль мне в голову не пришла, спасибо. Да, скорость низкая, у всех 9600. Один контроллер ESP32 теоретически сможет держать связь с центральным по быстрому SPI и принимать\отправлять данные по UART на сколько свободных ног хватит. Прикину, вариант. Вероятно, так будет дешевле и удобнее, чем использовать AVRки.


Вернуться наверх
 
Руководство для разработчика приложений на базе STM32WB55

Представив двухъядерные беспроводные микроконтроллеры STM32WB для IoT-приложений, компания STMicroelectronics предлагает разработчикам экосистему, включающую в себя отладочные платы, примеры кода для микроконтроллера, готовое ПО всех уровней и большой массив документации.

Читать статью>>
Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Вт сен 17, 2019 09:15:54 
Друг Кота
Аватар пользователя

Карма: 86
Рейтинг сообщений: 837
Зарегистрирован: Вт мар 16, 2010 22:02:27
Сообщений: 9983
Откуда: ДОНЕЦК (ЮГО-ВОСТОК ua/DPR)
Рейтинг сообщения: 0
В принципе никто не запрещает присвоить индивидуальный адрес каждому внешнему устройству и работать на одной линии всем устройствам...
Единственно рассмотреть статус "экстренного вызова"...
:roll:


Вернуться наверх
 


Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Вт сен 17, 2019 10:26:25 
Потрогал лапой паяльник
Аватар пользователя

Карма: 7
Рейтинг сообщений: 31
Зарегистрирован: Сб сен 19, 2009 07:02:19
Сообщений: 327
Рейтинг сообщения: 0
IMHO "железное" решение всегда надежнее. Я-бы на каждую линию поставил PIC12F1822, они даже по названию для подобных задач предназначены :-). 8 выводов, т.е. минимум занимаемого места, есть в корпусах SOIC и в микроскопических DFN. Снаружи информация принимается по UART, ЦП отдается по SPI. Встроенный генератор на 32MHz, т.е. с UART-ом может работать на высоких скоростях. RAM маловато, но от задачи зависит, как много её потребуется. Кроме PIC ещё подобные МК имеются, среди тех-же AVR поискать можно, были восьминогие ATTiny85, но не знаю, есть-ли у них UART, про 8-ногие ARM информация пролетала.


Вернуться наверх
 


Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Вт сен 17, 2019 12:47:14 
Поставщик валерьянки для Кота
Аватар пользователя

Карма: 35
Рейтинг сообщений: 283
Зарегистрирован: Пт сен 07, 2018 20:20:02
Сообщений: 2069
Рейтинг сообщения: 0
BOB51, а как по этой одной линии Вы будете получать сообщения, если сразу несколько датчиков одновременно начнут их слать по RS232? Ладно если датчики уже с буферами и могут корректно реагировать на DTR/RTS. А если нет?
shindax, надежность еще зависит от количества корпусов в схеме. Например, один STM8S103K3 вместо двух десятков PIC-ов, будет явно в итоге надежней.
А если уж ставить что-то копеечное, то тогда уж PDK13 (PMS150C-S08 - от 10 шт. по $0.0424), а если смущает OTP, то PDK14 (PFS154-S08 - от 50 шт. по $0.0659). Ну да, аппаратных UASRT/SPI/I2C у них нет, но программно это все реализуемо. Зато двадцать PMS150C-S08 обойдутся дешевле $1 )


Вернуться наверх
 
Распродажа паяльных станций ATTEN и аксессуаров!
Индукционная паяльная станция AT315D - 3 977 ₽, станция паяльная AT80D – 2177 ₽, станция паяльная AT936b – 1000 ₽!

Заходите в раздел акции и спецпредложения на сайте prist.ru, покупайте измерительные приборы, инструмент и паяльно-ремонтное оборудование по специальным ценам.
Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Вт сен 17, 2019 19:55:21 
Друг Кота
Аватар пользователя

Карма: 44
Рейтинг сообщений: 597
Зарегистрирован: Вт апр 24, 2007 07:45:40
Сообщений: 4138
Откуда: Minsk
Рейтинг сообщения: 0
BOB51, а как по этой одной линии Вы будете получать сообщения, если сразу несколько датчиков одновременно начнут их слать по RS232?

Зависит от примененного протокола. Если каждый лопочет, когда ему взбредет, то х.з. Но по уму они должны отвечать по запросу. Хотя - если он датчик крайнего положения, то: "Выключай двигатель, тормози!" - лаг недопустим. Не зная конкретно - и совет может быть только абстрактный.
ТС ничего не говорил об RS232. Может, у него все датчики рядом, и работа идет по чистому UART без MAX232?

_________________
Изображение


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Вт сен 17, 2019 21:35:29 
Поставщик валерьянки для Кота
Аватар пользователя

Карма: 35
Рейтинг сообщений: 283
Зарегистрирован: Пт сен 07, 2018 20:20:02
Сообщений: 2069
Рейтинг сообщения: 0
Jack_A, ну на то он и датчик газа, чтобы просыпаться и слать информацию по событию, а не по опросу. А RS232 - лишь предположение. Раз датчиков много, то рядом им делать нечего. А UART на логических уровнях уже на десять метров не надёжен.


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Ср сен 18, 2019 04:18:41 
Потрогал лапой паяльник
Аватар пользователя

Карма: 7
Рейтинг сообщений: 31
Зарегистрирован: Сб сен 19, 2009 07:02:19
Сообщений: 327
Рейтинг сообщения: 0
BOB51...надежность еще зависит от количества корпусов в схеме. Например, один STM8S103K3 вместо двух десятков PIC-ов, будет явно в итоге надежней...
Зависит, но не в абсолютном выражении. Надежность зависит от квалификации разработчика, его чувства меры и от степени уместности применяемых инструментов. Повторюсь: аппаратное решение не всегда дешевле, но всегда надежнее программного. Для разовой, хоббийной поделки, или экспериментального прототипа применение программного UART допустимо, но не в промышленном изделии и именно из соображений надежности. Одно дело, когда такой подход используется для второстепенных, или сервисных задач, совсем другое, когда работа такого порта является основной задачей, как у ТС. Я по-крайней мере в производстве подобного не встречал. Малоногие МК и предназначены для подобных задач. Дополнительный плюс подобного решения - масштабируемость. ТС не озвучил, насколько велика эта "куча" устройств и насколько интенсивно идет информационный обмен с приборам, каков объем данных, имеются-ли какие-то приоритеты и.т.д.
2TC. Раз Вы работали с AVR, то может стОит посмотреть в сторону ATxmega16A4U: 44-pin 5 UART 7SPI.


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Ср сен 18, 2019 07:27:57 
Друг Кота
Аватар пользователя

Карма: 86
Рейтинг сообщений: 837
Зарегистрирован: Вт мар 16, 2010 22:02:27
Сообщений: 9983
Откуда: ДОНЕЦК (ЮГО-ВОСТОК ua/DPR)
Рейтинг сообщения: 0
А я этот (аварийный) вариант оговаривал - отдельный интерфейс для аварийных запросов.
Обмен данными с ведущим головным МК и адресуемыми индивидуально датчиками по единому каналу,
А аварийка - отдельный порт с прерыванием по изменению состояния выводов и последующим анализом полученной маски событий таблично.
8)


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Ср сен 18, 2019 08:07:45 
Поставщик валерьянки для Кота
Аватар пользователя

Карма: 35
Рейтинг сообщений: 283
Зарегистрирован: Пт сен 07, 2018 20:20:02
Сообщений: 2069
Рейтинг сообщения: 0
BOB51, и что Вы будете делать, когда обнаружите низкий уровень стартового бита, возможно, одновременно от десятка передатчиков?

Добавлено after 29 minutes 48 seconds:
надежность еще зависит от количества корпусов в схеме.
Зависит, но не в абсолютном выражении.

Что значит "в абсолютном"? Если вероятность выхода из строя одного МК за 10 лет 1%, то вероятность выхода из строя решения на 20 МК за тот же срок уже 18%.

shindax писал(а):
аппаратное решение не всегда дешевле, но всегда надежнее программного.

Это ещё откуда? Пруф?
Надёжность и аппаратных, и программных решений в начальный период эксплуатации одинаково низка. Но исправление программных ошибок существенно проще, чем аппаратных. А со временем, надёжность программных систем остаётся неизменной или даже повышается, тогда как надёжность аппаратных систем только снижается в связи с износом.


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Ср сен 18, 2019 09:00:01 
Друг Кота
Аватар пользователя

Карма: 44
Рейтинг сообщений: 597
Зарегистрирован: Вт апр 24, 2007 07:45:40
Сообщений: 4138
Откуда: Minsk
Рейтинг сообщения: 0
Jack_A, ну на то он и датчик газа, чтобы просыпаться и слать информацию по событию, а не по опросу.

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

_________________
Изображение


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Ср сен 18, 2019 09:02:57 
Поставщик валерьянки для Кота
Аватар пользователя

Карма: 35
Рейтинг сообщений: 283
Зарегистрирован: Пт сен 07, 2018 20:20:02
Сообщений: 2069
Рейтинг сообщения: 0
Jack_A, зависит от протокола. Я уже писал выше:
ПростоНуб писал(а):
Ладно если датчики уже с буферами и могут корректно реагировать на DTR/RTS. А если нет?

Датчик может просто не поддерживать режим опроса.


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Ср сен 18, 2019 20:16:08 
Первый раз сказал Мяу!

Зарегистрирован: Пт сен 21, 2012 22:58:16
Сообщений: 20
Рейтинг сообщения: 0
Jack_A,
>> Но по уму они должны отвечать по запросу.
Нет, все отвечают по своему событию. Например, GPS постоянно сообщает координаты и состояние спутников; GSM модем - о приеме СМС, звонке; газоанализаторы - аналогично GPS, постоянно (но можно отключить)

>> ТС ничего не говорил об RS232. Может, у него все датчики рядом, и работа идет по чистому UART без MAX232?
Все верно, ничего. Конкретно в этой задаче GSM модемы, рядом. Около 200 штук. Чистый UART.

shindax
>> Малоногие МК и предназначены для подобных задач.
Всё же склоняюсь к этому

>> Дополнительный плюс подобного решения - масштабируемость
Да, т.к. у UART появляется "адрес", который сделает этот микроконтроллер

>> ТС не озвучил, насколько велика эта "куча" устройств и насколько интенсивно идет информационный обмен с приборам, каков объем данных, имеются-ли какие-то приоритеты и.т.д.
Примерно 90 GSM модемов на приеме СМС. События приёма относительно редкие, не более 1000 СМС в день.
Сейчас это реализовано в USB модемах ("свистки"), администрирование затруднено, масштабируемость тоже + есть проблемы с потерей СМС (при одновременном получении от разных отправителей может быть глюк; с SIM800L такой проблемы не замечено).
Плюс необходима реализация самостоятельной отправки СМС, без использования сторонних провайдеров.
Приоритетов нет, все устройства равнозначны.

>> Раз Вы работали с AVR, то может стОит посмотреть в сторону ATxmega16A4U: 44-pin 5 UART 7SPI.
Уже не вариант, но спасибо за наводку.
Принял другую архитектуру: каждый GMS модем со своим МК (возможно даже DIP в сокете или выводом программатора), с поддержкой аварийного протока - например, выключить модем, если потеряна связь с ПК или родительским контроллером и реализация этого в виде платы для горячей замены.
А корневой контроллер с микросхемами расширения GPIO (или просто, сдвиговыми регистрами) - чтобы ему узнавать, какие слоты заняты и выбирать плату, с которой он будет вести обмен.

Jack_A,
>> Не думаю, что если опрашивать датчики хотя бы раз в секунду - концентрация газа за это время повысится до опасных пределов
Легко, при повреждении балона с газом или повреждении газопровода с давлением. Последнее не так страшно, т.к. часто есть защитные механизмы, как раз на контроле давления.
Но хуже другое - датчик может не успеть "унюхать" уже опасную концентрацию, находясь на расстоянии.


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Чт сен 19, 2019 07:17:36 
Поставщик валерьянки для Кота
Аватар пользователя

Карма: 35
Рейтинг сообщений: 283
Зарегистрирован: Пт сен 07, 2018 20:20:02
Сообщений: 2069
Рейтинг сообщения: 0
afynfpbz, 200 на одну шину не посадите из-за электрических ограничений. Обычно, на одной шине удается держать не более чем два-три десятка устройств. Получается в любом случае трехуровневая архитектура:
1. Головной МК для сбора данных. Возможно, два головных МК в режиме активный-резервный.
2. Концентраторы, к каждому из которых подключено 10-30 датчиков.
3. Собственно датчики
Для связи между концентраторами и головным МК предпочтительней выглядит I2C. Связь между концентратором и датчиком может происходить и навешиванием на датчик своего МК типа PDK13/PDK14. Но так как без концентраторов все равно не обойтись, то смысл этого решения мне не виден. Проще реализовать коммуникацию концентратора и датчика по программному UART.


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Пт сен 20, 2019 02:59:20 
Первый раз сказал Мяу!

Зарегистрирован: Пт сен 21, 2012 22:58:16
Сообщений: 20
Рейтинг сообщения: 0
Это из-за каких ограничений? Выбор устройства со своим МК, которое опрашиваем, через сдвиговый регистр; не выбранные переводят свои пины, подключенные к шине, как вход (Z-состояние) и утечкой тока можно пренебречь.

>> Для связи между концентраторами и головным МК предпочтительней выглядит I2C.
Вот честно, никогда для связи МК (особенно близко расположенных) не предпочту использовать IIC. По мне, очевидно, лучше SPI подобный протокол. Тем более его частота для этой задачи может быть менее 1МГц, а длина линии явно менее 3 метров.

>> Но так как без концентраторов все равно не обойтись, то смысл этого решения (свой МК на модеме) мне не виден.
Там помимо UART ещё есть пины: перезагрузки, вывод из спящего режима, оповещение о входящем звонке (хотя он и так "RING" в UART пишет) - вдруг понадобятся. В частности, может оказаться нужным пин перезагрузки, но, к нему можно обращаться сдвиговыми регистрами.


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Пт сен 20, 2019 08:11:16 
Поставщик валерьянки для Кота
Аватар пользователя

Карма: 35
Рейтинг сообщений: 283
Зарегистрирован: Пт сен 07, 2018 20:20:02
Сообщений: 2069
Рейтинг сообщения: 0
afynfpbz, I2C имеет встроенную адресацию, что позволяет обойтись без регистров и дешифраторов, и работает по двум проводам, вместо четырех у SPI. В Вашем решении в разы больше корпусов, а значит и существенно ниже надёжность. А проблемы управления прочими сигналами на клиентских устройствах на коммутаторах решаются всяко проще, чем при персональном коммутаторе для каждого клиента.


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: Сбор данных с кучи UART
СообщениеДобавлено: Пт сен 20, 2019 08:27:30 
Мучитель микросхем

Зарегистрирован: Пт июл 12, 2019 22:52:01
Сообщений: 436
Рейтинг сообщения: 0
ПростоНуб, почитайте на досуге errata разных микроконтроллеров по поводу I2C!
Почти везде он сделан из рук вон плохо!!! Скажем, работать слейвом с DMA на некоторых STM8 и STM32 — тот еще цирк. А на кривом STM32F103 даже мастер имеет дикую уйму проблем. На STM8S003 тоже не сильно лучше (возможно, поэтому криворукие китайцы в своих вольтметрах вместо аппаратного I2C пользуются софтовым).
С SPI такой проблемы нет.
Но, конечно, насчет количества проводов вы правы, здесь SPI проигрывает.

Вообще же, если речь не идет об эксплуатации прибора где-то, где постоянно шарахают разряды и гуляют мощные наводки, то для "общения" кучи близко расположенных устройств за глаза хватает UART'а! У нас несколько старых железяк так работают: одна общая шина (Rx/Tx/питание/земля), на которой сидит до 64 устройств. Любой команде от мастера предшествует адрес — какое устройство должно откликнуться, в этом случае бит четности ==1, дальше все идет с битом четности==0, и никто из МК случайно не воспримет поток данных как обращение с командой к нему.
При длине линии до двух метров на скорости 57600 никаких проблем не наблюдалось. Даже контроль целостности пакетов не нужен был.

Добавлено after 5 minutes 8 seconds:
просто на специализированную микросхему надеялся с интерфейсами (много UART)и(SPI)

Посмотрите линейки STM32 — есть МК с четырьмя UART'ами и двумя SPI. Возможно, найдется и больше... Скажем, в хронометре я одновременно три уарта на разных скоростях использую (USART1 — для отладки, а в работе — для проксирования сообщений GPS либо сюда можно будет подключить bluetoot-модуль, чтобы соединяться с планшетом/смартфоном дистанционно; USART2 работает с GPS; на USART3 висит лидар), и никто никому не мешает...

_________________
Я на гитхабе, в ЖЖ


Вернуться наверх
 
Показать сообщения за:  Сортировать по:  Вернуться наверх
Начать новую тему Ответить на тему  [ Сообщений: 31 ]  1,  

Часовой пояс: UTC + 3 часа


Кто сейчас на форуме

Сейчас этот форум просматривают: alexbau и гости: 13


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  


Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB
Extended by Karma MOD © 2007—2012 m157y
Extended by Topic Tags MOD © 2012 m157y