Re: Сбор данных с кучи UART
Пт сен 20, 2019 08:53:39
Eddy_Em, а кто заставляет использовать именно те МК, у которых есть проблема с I2C, которая именно в Вашем случае критична? В подавляющем большинстве случаев, проблемы на I2C начинаются при наличии более одного мастера. Зачем Вам больше одного мастера в данном случае? Лично мне не попадался пока ни один МК, в котором не получилось бы успешно общаться с той же PCF8574. И зачем DMА для I2C? Это же не скоростной протокол, а прерывание по ошибке все равно обрабатывать. Больше времени потратите на управление DMA, чем выиграете на нескольких передаваемых/принимаемых байтах.
Четрые десятка STM32, чтобы обеспечить работу 200 UART? Вы бы сразу комп с двухста USB2UART преобразователями тогда лучше предложили )))
Четрые десятка STM32, чтобы обеспечить работу 200 UART? Вы бы сразу комп с двухста USB2UART преобразователями тогда лучше предложили )))
Re: Сбор данных с кучи UART
Пт сен 20, 2019 09:52:41
ПростоНуб, никто не заставляет. Я с I2C почти не работаю, разве что иной раз дурацкие датчики (вроде тех же термодатчиков для зеркала) нужно подключать, но у STM32F042 с I2C особых проблем нет.
Если нужны раздельные UART'ы, то как-то других вариантов нет. Но я не представляю себе ситуации, когда потребовалось бы одновременно с двумя сотнями раздельных уартов работать. Чушь какая-то... Вот пять одновременно — да, можно представить.
Ну и никто не отменял возможности использовать конвертеры интерфейсов (хоть на 20-рублевых STM8, хоть на 15-рублевых ch55x): брать с UART'а и выплевывать в 485, например...
Четрые десятка STM32, чтобы обеспечить работу 200 UART?
Если нужны раздельные UART'ы, то как-то других вариантов нет. Но я не представляю себе ситуации, когда потребовалось бы одновременно с двумя сотнями раздельных уартов работать. Чушь какая-то... Вот пять одновременно — да, можно представить.
Ну и никто не отменял возможности использовать конвертеры интерфейсов (хоть на 20-рублевых STM8, хоть на 15-рублевых ch55x): брать с UART'а и выплевывать в 485, например...
Re: Сбор данных с кучи UART
Пт сен 20, 2019 10:15:46
ПростоНуб,
>> I2C имеет встроенную адресацию
На 127 устройств или использовать IIC-подобную связь с большим числом байт для адреса.
>> что позволяет обойтись без регистров и дешифраторов
Не вижу ничего плохого.
Как раз сегодня ночью подумал, что огромный плюс: с регистрами я смогу сообщить физический слот, где проблема с устройством.
>> и работает по двум проводам, вместо четырех у SPI.
Тоже ничего плохого. Меньше меди будет стравлено с печатной платы
Я бы считал, что "проводов" три (clock,miso,mosi) + ещё 2 на обслуживание кучи CS от сдвиговых регистров.
>> Вы бы сразу комп с двухста USB2UART преобразователями тогда лучше предложили )))
Было бы смешно, если бы не было так грустно: сейчас решение формально работает практичесеки такое )))
Eddy_Em
STM32 не более 5 (3 USART, 2 UART)
>> Но я не представляю себе ситуации, когда потребовалось бы одновременно с двумя сотнями раздельных уартов работать.
Элементарнейшая ситуация, уже написал: GSM модемы на приеме\отправке SMS и пропускать данные от них нельзя
---
P.S.
На тему финансовой стороны персонального аппаратного UART к каждому устройству
Нашел микросхемы от NXP и MaxLinear в QFP
8 UART не менее 33 евро
Однозначно идут лесом из-за стоимости, сложности и недоступности
MAX14830 в QFN-48
4 UART, не менее 400 руб.\шт.
ATXMega 128a3u в QFP-64 (что куда лучше)
7 UART, около 680 руб.\шт.
ATMega8 (сверхдоступность и, если DIP, можно и руками заменять)
1 UART, менее 44 руб.\шт.
>> I2C имеет встроенную адресацию
На 127 устройств или использовать IIC-подобную связь с большим числом байт для адреса.
>> что позволяет обойтись без регистров и дешифраторов
Не вижу ничего плохого.
Как раз сегодня ночью подумал, что огромный плюс: с регистрами я смогу сообщить физический слот, где проблема с устройством.
>> и работает по двум проводам, вместо четырех у SPI.
Тоже ничего плохого. Меньше меди будет стравлено с печатной платы
Я бы считал, что "проводов" три (clock,miso,mosi) + ещё 2 на обслуживание кучи CS от сдвиговых регистров.
>> Вы бы сразу комп с двухста USB2UART преобразователями тогда лучше предложили )))
Было бы смешно, если бы не было так грустно: сейчас решение формально работает практичесеки такое )))
Eddy_Em
STM32 не более 5 (3 USART, 2 UART)
>> Но я не представляю себе ситуации, когда потребовалось бы одновременно с двумя сотнями раздельных уартов работать.
Элементарнейшая ситуация, уже написал: GSM модемы на приеме\отправке SMS и пропускать данные от них нельзя
---
P.S.
На тему финансовой стороны персонального аппаратного UART к каждому устройству
Нашел микросхемы от NXP и MaxLinear в QFP
8 UART не менее 33 евро
Однозначно идут лесом из-за стоимости, сложности и недоступности
MAX14830 в QFN-48
4 UART, не менее 400 руб.\шт.
ATXMega 128a3u в QFP-64 (что куда лучше)
7 UART, около 680 руб.\шт.
ATMega8 (сверхдоступность и, если DIP, можно и руками заменять)
1 UART
, менее 44 руб.\шт.
Re: Сбор данных с кучи UART
Пт сен 20, 2019 11:08:52
afynfpbz, налепите преобразователи UART<>RS485 на 16-рублевые STM8S003, раз вам нужно так много устройств обслуживать. Разместите на плате bit-switch, которым задавайте адрес устройства. В итоге у вас будет буферизация и ничего важного не пропустите.
Можно, кстати, и "общение" чуть упростить, если вместо 485 CAN использовать (даже среди STM8 многие дешевые — от 20 до 40 рублей — модели это умеют, правда, может выйти так, что МК получается чуть ли не дешевле, чем CAN-драйвер)…
Еще более дешевые МК — ch55x, но с ними работать сложно (программатор очень дорогой и грамотно переведенной с китайского на английский документации крайне мало).
Если хочется несколько на один МК повесить, то, скажем, у STM32F09[18][RV] есть 8 UART'ов! STM32F091RBT6 за <270 рублей…
Можно, кстати, и "общение" чуть упростить, если вместо 485 CAN использовать (даже среди STM8 многие дешевые — от 20 до 40 рублей — модели это умеют, правда, может выйти так, что МК получается чуть ли не дешевле, чем CAN-драйвер)…
Еще более дешевые МК — ch55x, но с ними работать сложно (программатор очень дорогой и грамотно переведенной с китайского на английский документации крайне мало).
Если хочется несколько на один МК повесить, то, скажем, у STM32F09[18][RV] есть 8 UART'ов! STM32F091RBT6 за <270 рублей…
Re: Сбор данных с кучи UART
Пт сен 20, 2019 11:40:24
afynfpbz писал(а):На 127 устройств
I2C поддерживает 10-битную адресацию. На AVR программно, на STM8/STM32 - аппаратно.
afynfpbz писал(а):с регистрами я смогу сообщить физический слот, где проблема с устройством
Это может делать и концентратор.
afynfpbz писал(а):меньше меди будет стравлено с печатной платы
С чего бы это, если размер платы будет больше в несколько раз из-за большего количества корпусов и коммутаций?
afynfpbz писал(а):менее 44 руб.\шт.
Я же предлагал выше:
ПростоНуб писал(а):PDK13 (PMS150C-S08 - от 10 шт. по $0.0424), а если смущает OTP, то PDK14 (PFS154-S08 - от 50 шт. по $0.0659).
2 руб. 70 коп. и даже 4 руб. 20 коп. выглядят на порядок привлекательней 44 руб. А отсутствие железного UART полностью компенсируется его автоматизированной программной реализацей в штатном IDE )
Eddy_Em писал(а):Если нужны раздельные UART'ы, то как-то других вариантов нет.
С чего это вдруг? Один STM8S103K3 вполне в состоянии одновременно принимать от двух десятков клиентов программным UART, передавая им и управляя ими последовательно через мультиплексор. Так как он все равно, кроме этого и обмена по I2C ничем заниматься не будет, то производительности хватит с лихвой. Или Вы так привыкли к CMSIS, что для Вас реализация высокоскоростной обработки на низком уровне без использования библиотек кажется не выполнимой?
Re: Сбор данных с кучи UART
Пт сен 20, 2019 12:10:57
ПростоНуб писал(а):программным UART
Крайне рукожопое решение!
Re: Сбор данных с кучи UART
Пт сен 20, 2019 12:39:22
Eddy_Em, не позорились бы хоть публично. Если для Вас программная реализация того, что в каких-то МК реализовано аппаратно - непомерный труд, то для обычных любителей - это привычное нудное программирование )))
Re: Сбор данных с кучи UART
Пт сен 20, 2019 12:58:27
Это называется не "привычное нудное программирование", а полная тупость и разложение!
Re: Сбор данных с кучи UART
Пт сен 20, 2019 14:05:22
Eddy_Em, "полная тупость и разложение" не только свое бабло тратить на дорогие IC, но и других агитировать на это, когда решение можно сделать за три копейки. Складывается ощущение, что или ST Вам процент с продаж платит, или Вы просто фанатик, бесплатно им делающий рекламу )))
Если что-то можно сделать программно без ущерба для результата конкретного проекта, то совершенно не зачем повышать себестоимость готовой продукции, экономя на её проектировании. Вы же готовы тратить лишние деньги на каждый экземляр ГП, лишь бы не утруждать себя кодированием чего-то более сложного, чем вызова готовой функции для связи с конкретным железом.
Если что-то можно сделать программно без ущерба для результата конкретного проекта, то совершенно не зачем повышать себестоимость готовой продукции, экономя на её проектировании. Вы же готовы тратить лишние деньги на каждый экземляр ГП, лишь бы не утруждать себя кодированием чего-то более сложного, чем вызова готовой функции для связи с конкретным железом.
Re: Сбор данных с кучи UART
Пт сен 20, 2019 15:06:01
Да уж, подход у вас, конечно, какой-то совсем через одно место...
Re: Сбор данных с кучи UART
Пн окт 14, 2019 13:31:53
До того как освоили шину CAN датчики и центральный MCU соединяли по RS232 в кольцо. TX->RX:TX->RX и так далее. Плюс свой протокол и UID на каждый датчик.