Всем привет!

Нет ли у кого-нибудь информации по отечественным ARM-процесорам с встроенным контроллером RS-485?
Может быть, кто о разработках таких знает?

Может отдельная отечественная микросхема существует?

Сразу отвечаю, что Гугл не помог

Например: все LPC17xx.

Вообще-то, "встроенным контроллером RS-485" является обычный UART. Ну, разве что, с дополнительным сигналом управления передатчиком. Чисто для удобства, если лень в "ручную" переключать с приема на передачу и обратно. А драйвер RS-485 в процессор обычно не встраивают, на что есть свои причины.

Я на этом обжегся на малинке - она делала это настолько медленно, что не успевала прочитать ответ на команду. В результате поставил FT232 и забыл о проблемах.

Когда это мы NXP купить успели?

Да, слова "отечественные" я не заметил
Хотя в то же время ни из сообщения ни из личных данных автора не ясно к какому отечеству он относится.
Так что - откуда Вы знаете, что у Вас с ним одно отечество?

За отечественным RS-485 к Миландру.

http://ic.milandr.ru/products/mikrokontrol...krokontrollery/
+
http://ic.milandr.ru/products/interfeysnye...my/rs485-rs422/

Назовите хоть один отечественный современный МК без UART.
И да, такая существует: http://ic.milandr.ru/products/interfeysnye...my/rs485-rs422/
Даже такая: http://ic.milandr.ru/products/interfeysnye...s422/2011vv024/

Так все ж наверно драйвер это делал медленно, а не процессор, не удивлюсь, если обработку пакетов на каком-нить скрипте делали

А может операционная система? Вот на МК Миландр, т.к. нет ОС, получается рулить направлением передачи с точностью до микросекунд.
Вопрос этой темы очень прост, и ответы такие же простейшие - любой отечественный МК справится с нехитрой задачей работы с моим любимым RS-485.

Именно. В Raspbian работа с GPIO сделана через файловый ввод-вывод - а это затратная операция.

Может любой, а может и нет.... Все зависит от реалзации UART!
В буржуйских вышеупомянутых NXP UART сделан 550 совместимым. И 100% узнать, когда же ушел последний бит наружу, не представляется возможным!
Т.е. микросекундные задержки в управлении направлением передачи не получатся, можно пропустить ответ.

В серии 17ХХ они сделали костыль в виде аппаратной ноги TX_OE.

Прерывание или просто флаг FIFO empty + фиксированное время. Зачем знать последний бит? Скорость мы знаем. Может в каких-то моделях такого флага нет, за всё не ручаюсь.

Вот хочу попробовать в этом плане очень забавный костыль - MAX3109.

А вот не надо было так делать. Потому как есть через mmap. И очень даже быстро. Та же WiringPi для "малинки" отлично работает через mmap.

Если ткнете носом в описания/примеры - буду весьма благодарен. Хотя, RS-485 extensions все равно в Raspbian не включены.

Это у STM32 таймеров как грязи. Не у всех так. А у LPC их впритык.... Выделить на такое дело не всегда возможно.

А что у LPC флаг TEMT , который говорит, что сдвиговый регистр пуст, а значит
передача закончена отменили?

По данному флагу нет прерывания.

Спасибо за ответы, только у Миландра - это приемопередатчики, а нужен бы специализированный контроллер. Почему не можем использовать UART - потому что скорости не хватает - 921600 бод, а нам надо около 2 Мбит (RS-485 с такими скоростями позволяет работать)

извращение, stm 21 мегабит позволяет, а драйверы можно и на 40 найти

Да, у миландра там медленный уарт и кан, что поделаешь... Хотя 485й, как правило используется в низкоскоростном режиме (до 115200).
Используйте Эзернет, там скорость еще больше, гальваноразвязка и еще много плюшек...

Если тактовая частота позволяет, то скоростной UART можно программно реализовать.
Передача вообще не представляет ни какой сложности. С приемом - чуть сложнее.
Нужно задействовать прерывание.

Это вовсе не говорит о том, что передача окончена. После возникновения этого флага еще передается последний бит, биты четности и стоповый.

Мы используем Миландровский 1986ВЕ1Т с тактовой 144 МГц. На такой частоте по Вашей оценке можно реализовать программный контроллер RS-485 со скоростью 2 Мбит/с?

Думаю, да.
Во всяком случае, стоит попробовать.

Примеров софт UART куча, надо тупо попробовать.

2 МБод на 144МГц тактовой? Может как-то и получится, но думаю процессор только этим и будет заниматься.

поставят два

Вот она - веселуха!! Даешь 5 портов из контроллеров



В аппаратном уарте есть фильтр выборок, на мелких скоростях он так-то нафиг не нужен, но на мегагерцах уже вполне, так что прерываний там не 2мульона в сек. будет, а заметно больше.
ИМХО - изврат чистой воды!

Вы это серьезно? Я думал это технический сайт, а не юмористический

От загрузки канала зависит. Сколько времени идет прием/передача, столько и будет отвлекаться на это процессор. Плюс небольшие накладные расходы.
Если по RS485 идет сплошной поток в ту или другую сторону, то на остальное времени почти не останется...

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

У вас наверняка устаревшие данные. В описании сказано UART до 9 Мбит/сек, IrDA 460800 Мбит/сек. (Описание от 31.01.2014 г. стр 323)

Не всегда.
Например, для внешнего устройства, работающего в связке с ПК, зачастую предпочтительнее быстро передать пакет данных на высокой скорости. Чтобы освободить линию связи и собственные ресурсы МК до передачи следующего пакета. А не растягивать этот процесс на низкой скорости.
А когда устройств на линии предполагается много, то их максимальное количество будет напрямую зависеть от выбранной скорости обмена. "Сильно недогруженный канал" с точки зрения МК, "догружается" другими устройствами на линии, вплоть до непрерывного потока.

И что?
Эти данные, передаваемые "другими устройствами" будут также поступать на вход RX микроконтроллера и загружать его процедурой приёма байт.
В чём разница-то?
Ситуация даже хуже получается: даже когда к устройству нет обращений от ПК, его процессор всё равно будет сильно загружен приёмом чужих обменов.

Контроллеру среда передачи пофигу должна быть, хоть RS-232, хоть RS-485, хоть RS-422.
Зависит от устройства и способов его использования.
Уровень приложения знать не должен, какая среда используется.
Только максимум в драйвере протокола может быть управление направлением передачи.

P.S. С каких пор полудуплекс стал быстрее полного дуплекса?

Разница в том, что линия связи освобождается для работы других устройств.
МК, конечно, придется анализировать поток на линии. Чем он, в основном, и будет заниматься. Когда придет запрос, адресованный именно данному устройству, он обрабатывается, передается ответ. А дальше устройство снова "курит бамбук", анализируя линию и ожидая следующего запроса. Это достаточно часто встречающаяся ситуация...

Я Вам говорю о том, что это "курит бамбук" при программном UART-е на 2МБод-а выльется в очень большую загрузку CPU. Что уже как-то не похоже на "курит бамбук".
И как раз часто встречающаяся ситуация, когда устройство занимается ещё чем-то, кроме того, что ждёт запроса от ПК. Оно же для чего-то создавалось, чтобы выполнять какую-то работу, а не просто "курить бамбук".
И при программном UART-е 2МБод оно будет в основном заниматься анализом потока на линии, как Вы правильно заметили. И на другие (полезные) дела ресурсов уже не останется.


Как Вы себе представляете полный дуплекс на 2х-проводном RS-485 (автор вроде его имел в виду) ?

.. За исключением случаев, когда "полезные дела" выполняются устройством только "по команде" (по запросу). Что, поверьте, не редкость...
Устройства разные бывают, в том числе совсем простые, с очень ограниченными ресурсами. И их может быть много на одной линии. Ставить в каждое процессор с аппаратной поддержкой 2Мбит по UART не всегда рационально. Вот тогда программный UART рулит...

? 450Гбит/с ??? Запятая где, всё-таки, должна стоять?

ну это же православный контроллер

Да ладно гнать, ядро бесовскОе-англичанское (;

Часто, но на более медленных скоростях, когда "долбежка" проца не отнимает много времени. Для скоростной связи с компом лучше выбрать другой интерфейс, например еще один уарт(485), усб или эзернет, как уже говорил.



Только тогда, когда нет никакой возможности использовать аппаратный порт.

Еще один RS485 - это еще одна линия...
USB - это только для "настольных игр"...
Эзернет... - про цену вопроса не забывайте.
И умножьте ее, скажем, на 100 (устройств в линии)...

Задача топикстартера попахивает колхозом изначально, который всё больше уточняется.
МК нужен со встроенным RS-485 (прям представляю как оптическая развязка и прочие элементы защиты, в том числе грозозащиты, из корпуса контроллера торчят, эффективно обеспечивая ему ЭМИ-защиту), причем передача всего по двум проводам, но не менее 2 МБайта в секунду.
Что мешает использовать стандартные решения, исходя из условий эксплуатации?

К требованию "отечественный" претензий нет, т.к. принимается как данность, которую нужно соблюсти, ибо требование Заказчика.

Без обид, про колхоз.
Честное слово.



Разумеется, никак.
RS-422 в помощь, если нужно линию далеко утащить с раздельными RX и TX.

Я лишь только сказал, как правильно, разумеется, это надо учитывать еще на этапе разработки, да и стоимость физики для эзернета невелика, мак уже есть в контроллере. Да и для связи с компом это намного удобнее, т.к. можно поднять фтп для работы с файлами и просто сокетный ввод\вывод для управления, чем колхозить всякие переходники с 485 в усб и потом в комп.

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

это ethernet менее эффективен, чем rs485 ?



считали ?

Считали.
Ясно же сказано - зависит от задачи.
Вы в устройство "за 3 копейки" будете ethernet вставлять?
Это для любителей "палить из пушки по воробьям".