[aaarrr 69]

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

 

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

 

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

[zltigo 1]

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

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

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

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

[aaarrr 69]

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

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

 

Правильно. Вот это надежно без резкого падения скорости невозможно - поди разберись сколько там процесс приема успел вычитать и снаружи вдули (только чтением заполнения FIFO не обойтись) - вот тут действительно кучу кода наворотить придется и тех-же железных ресурсов типа таймеров потратить и причем БЕЗ гарантии надежной работы.

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

 

А требования к толщине каналов растут и растут в отличии от давно эксплуатирумого RS485 в промышленном оборудовании.

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

[zltigo 1]

Результаты работы с аппаратным управлением потоком под виндой...

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

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

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

 

А в программе это таймер...

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

и дополнительные тормоза.

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

[aaarrr 69]

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

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

 

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

Ну, на промышленном оборудовании таких скоростей, естественно, нет :)

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

 

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

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

 

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

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

[zltigo 1]

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

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

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

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

Удобно?

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

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

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

[aaarrr 69]

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

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

 

...имеющихся в избытке UART

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

 

Ну и что? Подчинить выбор контроллера исключительно наличию прямого управления передатчиком у UART?

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

 

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

1. 19200, 115200.

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

[zltigo 1]

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

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

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

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

[aaarrr 69]

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

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

[zltigo 1]

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

Ну а что еще из 485/422 красивого в случае шины сделаешь :(

Ну а провода на нескольких метрах межблочных экономить достаточно мелочно, тем более, что в реальности это массовые 2/4 витые пары, к счастью, распространившиеся вместе с Ethernet. Приемо-передатчики тоже не по одному корпусированы.

Кроме того это не "практически 485" - "лишняя" пара проводов это это дуплекс с выбранным или любым другим slavе, экстенное прерывание передающего фрейм,...

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

[aaarrr 69]

Ну а провода на нескольких метрах межблочных экономить достаточно мелочно, тем более, что в реальности это массовые 2/4 витые пары, к счастью, распространившиеся вместе с Ethernet. Приемо-передатчики тоже не по одному корпусированы.

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

 

Кроме того это не "практически 485" - "лишняя" пара проводов это это дуплекс с выбранным или любым другим slavе, экстенное прерывание передающего фрейм,...

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

[zltigo 1]

Дуплекс мне даром не нужен.

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

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

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

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

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

P.S.

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

[aaarrr 69]

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

Но это уже даже больший маразм, чем:

Подчинить выбор контроллера исключительно наличию прямого управления передатчиком у UART?

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

 

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

 

P.S.

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

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

[zltigo 1]

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

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

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

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

[aaarrr 69]

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

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

 

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

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