Сбор данных с кучи UART

[afynfpbz]

Не подскажите идеи реализации, как одновременно получать данные с кучи устройств (в частности GSM модемы и датчики газа) по UART, чтобы не пропустить эти самые данные. Например, какой-нибудь микросхемы с кучей входов UART, буфером и работой с МК по SPI или IIC?

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

[BOB51]

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

[afynfpbz]

Да я понимаю, что жизнеспособно, просто на специализированную микросхему надеялся с интерфейсами (много UART)и(SPI). Приемлемо будет, даже если она обойдется несколько дороже вспомогательных МК.

[ПростоНуб]

afynfpbz, обычно, такие устройства живут на скоростях не более 19200. Чаще - 9600. Так что одним МК программно можно одновременно от двух десятков таких устройств принимать. Вообще без аппаратного UART.

[afynfpbz]

ПростоНуб, а вот такая мысль мне в голову не пришла, спасибо. Да, скорость низкая, у всех 9600. Один контроллер ESP32 теоретически сможет держать связь с центральным по быстрому SPI и принимать\отправлять данные по UART на сколько свободных ног хватит. Прикину, вариант. Вероятно, так будет дешевле и удобнее, чем использовать AVRки.

[BOB51]

В принципе никто не запрещает присвоить индивидуальный адрес каждому внешнему устройству и работать на одной линии всем устройствам...
Единственно рассмотреть статус "экстренного вызова"...

[shindax]

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

[ПростоНуб]

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 )

[Jack_A]

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3702303#p3702303"]BOB51, а как по этой одной линии Вы будете получать сообщения, если сразу несколько датчиков одновременно начнут их слать по RS232?[/uquote]
Зависит от примененного протокола. Если каждый лопочет, когда ему взбредет, то х.з. Но по уму они должны отвечать по запросу. Хотя - если он датчик крайнего положения, то: "Выключай двигатель, тормози!" - лаг недопустим. Не зная конкретно - и совет может быть только абстрактный.
ТС ничего не говорил об RS232. Может, у него все датчики рядом, и работа идет по чистому UART без MAX232?

[ПростоНуб]

Jack_A, ну на то он и датчик газа, чтобы просыпаться и слать информацию по событию, а не по опросу. А RS232 - лишь предположение. Раз датчиков много, то рядом им делать нечего. А UART на логических уровнях уже на десять метров не надёжен.

[shindax]

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3702303#p3702303"]BOB51...надежность еще зависит от количества корпусов в схеме. Например, один STM8S103K3 вместо двух десятков PIC-ов, будет явно в итоге надежней...[/uquote]Зависит, но не в абсолютном выражении. Надежность зависит от квалификации разработчика, его чувства меры и от степени уместности применяемых инструментов. Повторюсь: аппаратное решение не всегда дешевле, но всегда надежнее программного. Для разовой, хоббийной поделки, или экспериментального прототипа применение программного UART допустимо, но не в промышленном изделии и именно из соображений надежности. Одно дело, когда такой подход используется для второстепенных, или сервисных задач, совсем другое, когда работа такого порта является основной задачей, как у ТС. Я по-крайней мере в производстве подобного не встречал. Малоногие МК и предназначены для подобных задач. Дополнительный плюс подобного решения - масштабируемость. ТС не озвучил, насколько велика эта "куча" устройств и насколько интенсивно идет информационный обмен с приборам, каков объем данных, имеются-ли какие-то приоритеты и.т.д.
2TC. Раз Вы работали с AVR, то может стОит посмотреть в сторону ATxmega16A4U: 44-pin 5 UART 7SPI.

[BOB51]

А я этот (аварийный) вариант оговаривал - отдельный интерфейс для аварийных запросов.
Обмен данными с ведущим головным МК и адресуемыми индивидуально датчиками по единому каналу,
А аварийка - отдельный порт с прерыванием по изменению состояния выводов и последующим анализом полученной маски событий таблично.

[ПростоНуб]

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

Добавлено after 29 minutes 48 seconds:
[uquote="shindax",url="/forum/viewtopic.php?p=3702718#p3702718"][uquote="ПростоНуб",url="/forum/viewtopic.php?p=3702303#p3702303"]надежность еще зависит от количества корпусов в схеме.[/uquote]Зависит, но не в абсолютном выражении.[/uquote]
Что значит "в абсолютном"? Если вероятность выхода из строя одного МК за 10 лет 1%, то вероятность выхода из строя решения на 20 МК за тот же срок уже 18%.

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

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

[Jack_A]

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3702665#p3702665"]Jack_A, ну на то он и датчик газа, чтобы просыпаться и слать информацию по событию, а не по опросу.[/uquote]
Не думаю, что если опрашивать датчики хотя бы раз в секунду - концентрация газа за это время повысится до опасных пределов. Ведь постепенное повышение концентрации может быть зафиксировано заранее,и опрос этого датчика можно проводить чаще. Впрочем, это дело конкретной ситуации.

[ПростоНуб]

Jack_A, зависит от протокола. Я уже писал выше:

Ладно если датчики уже с буферами и могут корректно реагировать на DTR/RTS. А если нет?

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

[afynfpbz]

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

[ПростоНуб]

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

[afynfpbz]

Это из-за каких ограничений? Выбор устройства со своим МК, которое опрашиваем, через сдвиговый регистр; не выбранные переводят свои пины, подключенные к шине, как вход (Z-состояние) и утечкой тока можно пренебречь.

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

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

[ПростоНуб]

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

[Eddy_Em]

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

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

Добавлено after 5 minutes 8 seconds:
[uquote="afynfpbz",url="/forum/viewtopic.php?p=3701741#p3701741"]просто на специализированную микросхему надеялся с интерфейсами (много UART)и(SPI)[/uquote]
Посмотрите линейки STM32 — есть МК с четырьмя UART'ами и двумя SPI. Возможно, найдется и больше... Скажем, в хронометре я одновременно три уарта на разных скоростях использую (USART1 — для отладки, а в работе — для проксирования сообщений GPS либо сюда можно будет подключить bluetoot-модуль, чтобы соединяться с планшетом/смартфоном дистанционно; USART2 работает с GPS; на USART3 висит лидар), и никто никому не мешает...