Я не демонизирую, а добросовестно не понимаю, что побуждает производителя делать так

И не такая уж это и мелкая проблема: попробуйте на классическом 550 управлять драйвером RS485. Будет очень криво.

А они, понимаете ли, flow-control аппаратный добавляют...

Я уже писал,что занимался такой реализацией на PC и еще жив. И другие тоже успешно решали и решают. Проблема решаема.

Правильно. Вот это надежно без резкого падения скорости софтом решить невозможно - поди разберись сколько там процесс приема успел вычитать и снаружи вдули (только чтением заполнения FIFO не обойтись) - вот тут действительно кучу кода наворотить придется и тех-же железных ресурсов типа таймеров потратить и причем БЕЗ гарантии надежной работы. А требования к толщине каналов растут и растут в отличии от давно эксплуатирумого RS485 в промышленном оборудовании. И подстройка бодов под почти любой кварц (тот-же USB 12MHz) эта та проблема которую никак не решить, если подстройки нет. Ее в свежих чипах и добавили. C тем-же некошерным с точки зрения UART 12MHz/произвольным кварцем проблемы работы bootloader на высоких скоростях - тоже не решаемая проблема, если производитель ее не решит. Ее решили.

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


Результаты работы с аппаратным управлением потоком под виндой дали обратные результаты - для надежной работы нужен большой софтварный FIFO, т.к. после выставления RTS может свалиться еще байт 20-60. Trigger level у меня использовался 64, с меньшим были проблемы. А Auto-RTS пришлось выкинуть за бесполезностью.


RS485 может быть и 20 мбит/с.

Для связи с Виндой в общем случае это глухой номер, именно по причине отсутствия железной поддержки со стороны PC железа усугубляемой зачастую и большей глубиной TX FIFO (у меня, например мультипортовки по 128-256 байт). Это, увы, уже только для раскочегаривания канала между контроллерами.

Естественно, я эти приемопередатчики на синхронных 2-4-8-16 мегабитах широко пользую, вопрос на каких скоростях Вы работаете в симплексе со своим промышленным RS485 оборудованием ?


Ну или обработка эха, или второй UART, или...

На десятке-другом килобит характерных для промышленого оборудования и дсостаточно больших попугаях у обсуждаемого контроллера тормоза вполне символические.

Ну вот, а часто ли Вам нужен канал между контроллерами с управлением потоком?


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


Или еще что-нибудь в этом роде - ПЛИСка там внешняя, например. Удобно?


На 115.2 килобит уже не совсем символические.

Не пользовал, но почему-бы и нет? Тот-же RS422, банальный 4x2 витой кабель и простейший, но мегабитный межблочный канал готов.

Вот только нафиг там RS485, а не TTL/RS422/....

Нот. Но не не слишком и хлопотно во многих случаях можно поступить, например, при работе без parity или с менее, чем 8bit подключаем TX одного имеющихся в избытке UART прямо к управлению предатчиком и запихнув в него нолик с нулевой parity получаем желаемое управление без потери, возможно, нужного таймера. Есть более удобные железки - есть! Есть UART железо максимально приближающееся к идеалу - есть! (у Am186, например). Ну и что? Подчинить выбор контроллера исключительно наличию прямого управления передатчиком у UART?

Повторяю вопросы - на каких скоростях работает существующее промышленное оборудование и зачем закладывать RS485 в новое? "Громадность" затрат я представляю более, чем хорошо.

Дык межблочный, один мастер - N слейвов. Рядом килоамперы разрываются.


Не имелись они в избытке до последних времен.


Я разве это предлагал? Но учитывать эту особенность приходится.


1. 19200, 115200.
2. Оборудование не только мое, так что от RS485 никуда не деться.

Ну так - RS422, все сидят слушают мастера. Получив свой адрес подключает передатчик и вперед. Получив не свой адрес - отключает. Линия приема мастера почти всегда хорошо подтянута одним из передатчиков- меньше помех.

Ну дык, естественно, приходится.

Работа идет в стиле запрос-ответ. В результате получаем практически тот же 485, только проводов больше.

Ну а что еще из 485/422 красивого в случае шины сделаешь
Ну а провода на нескольких метрах межблочных экономить достаточно мелочно, тем более, что в реальности это массовые 2/4 витые пары, к счастью, распространившиеся вместе с Ethernet. Приемо-передатчики тоже не по одному корпусированы.
Кроме того это не "практически 485" - "лишняя" пара проводов это это дуплекс с выбранным или любым другим slavе, экстенное прерывание передающего фрейм,...
Все это по здравому размышлению приводит к малоцелесообразности использования RS485, там где это не навязано внешними неподвласными факторами.

Проблема не в проводах, а в разъемах и месте в них.


Дуплекс мне даром не нужен. В оличие от RS485 экстренно передающий слейв в RS422 не увидит конфликта на шине с другим.

Потому, что у Вас его нет . Вы вроде не испытывете никаих особых проблем от отсутствия дуплекса (точнее обходите его отсутствие - вот сразу уже разговоры о коллизиях начались), а я от отсутствия "очень нужного бита" для управления передатчиком. Проблема имеющее решение и не проблема вовсе. Дальше голые эмоции "да как могут в современном чипе не приделать прямое управление передатчиком RS485", ну или "да как можно в современном чипе не использовать имеющийся CAN" .

Его увидет master и аккуратно заткнув текущего спросит "ну кто там хотел экстренно столько-то времени тому назад передать". Вообще-то если, как мне показалось,мы уже ведем разговор о своем оборудовании, то... то CAN, а не пляски с двумя проводами RS485 смотрятся много более уместно.

Мы вроде уже до разговора о межблочных связей, причем в своем оборудовании, докатились? А блок, по крайней мере в моем понятии, штука большая, c солидной начинкой, со своим питанием... Какое такое "место в разьеме"?
P.S.
Может в теме обсудим более суровую периферию чипов поминаемых в топике произволителей? А то ведь, действительно докатимся до споров об оттенках черного у корпусов .

Так, докатились до CAN'а Скажите, а зачем я должен отказываться от RS485? Из-за наличия у используемого мной контроллера поддержки CAN'а?
Но это уже даже больший маразм, чем:

Ибо уровень решения и объем последствий несоразмерен.

CAN меня не устраивает по причине очень уж короткого поля данных.


Давайте. Только вот действительно суровой периферии у них нет практически.

По большому счету у 485 оно вообще байт - все остальное уже протоколы верхнего уровня.Тем не менее все устраивает .

Неожиданное утверждение. Пожалуй тогда не буду продолжать разговоры - хватит мне UARTа.

Рад за Вас. Меня, скажем так, устраивает почти все, но это можно пережить


Обсуждать действительно почти нечего: EMAC, USB, архитектура подсистемы памяти и т.п. у Atmel'а объективно хуже, чем аналогичные модули современных NXP. Хотя вполне работоспособны.