aaarrr 69 22 августа, 2008 Опубликовано 22 августа, 2008 · Жалоба Я не демонизирую, а добросовестно не понимаю, что побуждает производителя делать так :) И не такая уж это и мелкая проблема: попробуйте на классическом 550 управлять драйвером RS485. Будет очень криво. А они, понимаете ли, flow-control аппаратный добавляют... :( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 22 августа, 2008 Опубликовано 22 августа, 2008 · Жалоба И не такая уж это и мелкая проблема: попробуйте на классическом 550 управлять драйвером RS485. Я уже писал,что занимался такой реализацией на PC и еще жив. И другие тоже успешно решали и решают. Проблема решаема. А они, понимаете ли, flow-control аппаратный добавляют... :( Правильно. Вот это надежно без резкого падения скорости софтом решить невозможно - поди разберись сколько там процесс приема успел вычитать и снаружи вдули (только чтением заполнения FIFO не обойтись) - вот тут действительно кучу кода наворотить придется и тех-же железных ресурсов типа таймеров потратить и причем БЕЗ гарантии надежной работы. А требования к толщине каналов растут и растут в отличии от давно эксплуатирумого RS485 в промышленном оборудовании. И подстройка бодов под почти любой кварц (тот-же USB 12MHz) эта та проблема которую никак не решить, если подстройки нет. Ее в свежих чипах и добавили. C тем-же некошерным с точки зрения UART 12MHz/произвольным кварцем проблемы работы bootloader на высоких скоростях - тоже не решаемая проблема, если производитель ее не решит. Ее решили. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 22 августа, 2008 Опубликовано 22 августа, 2008 · Жалоба Я уже писал,что занимался такой реализацией на PC и еще жив. И другие тоже успешно решали и решают. Проблема решаема. Но очень плохо решаема. Накладные расходы для решения в железе равны 1 триггеру для бита, разрешающего вывод сигнала TEMPT на пин. А в программе это таймер и дополнительные тормоза. Правильно. Вот это надежно без резкого падения скорости невозможно - поди разберись сколько там процесс приема успел вычитать и снаружи вдули (только чтением заполнения FIFO не обойтись) - вот тут действительно кучу кода наворотить придется и тех-же железных ресурсов типа таймеров потратить и причем БЕЗ гарантии надежной работы. Результаты работы с аппаратным управлением потоком под виндой дали обратные результаты - для надежной работы нужен большой софтварный FIFO, т.к. после выставления RTS может свалиться еще байт 20-60. Trigger level у меня использовался 64, с меньшим были проблемы. А Auto-RTS пришлось выкинуть за бесполезностью. А требования к толщине каналов растут и растут в отличии от давно эксплуатирумого RS485 в промышленном оборудовании. RS485 может быть и 20 мбит/с. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 22 августа, 2008 Опубликовано 22 августа, 2008 · Жалоба Результаты работы с аппаратным управлением потоком под виндой... Для связи с Виндой в общем случае это глухой номер, именно по причине отсутствия железной поддержки со стороны PC железа усугубляемой зачастую и большей глубиной TX FIFO (у меня, например мультипортовки по 128-256 байт). Это, увы, уже только для раскочегаривания канала между контроллерами. RS485 может быть и 20 мбит/с. Естественно, я эти приемопередатчики на синхронных 2-4-8-16 мегабитах широко пользую, вопрос на каких скоростях Вы работаете в симплексе со своим промышленным RS485 оборудованием :)? А в программе это таймер... Ну или обработка эха, или второй UART, или... и дополнительные тормоза. На десятке-другом килобит характерных для промышленого оборудования и дсостаточно больших попугаях у обсуждаемого контроллера тормоза вполне символические. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 22 августа, 2008 Опубликовано 22 августа, 2008 · Жалоба Для связи с Виндой в общем случае это глухой номер, именно по причине отсутствия железной поддержки со стороны PC железа усугубляемой зачастую и большей глубиной TX FIFO (у меня, например мультипортовки по 128-256 байт). Это, увы, уже только для раскочегаривания канала между контроллерами. Ну вот, а часто ли Вам нужен канал между контроллерами с управлением потоком? Естественно, я эти приемопередатчики на синхронных 2-4-8-16 мегабитах широко пользую, вопрос на каких скоростях Вы работаете в симплексе со своим промышленным RS485 оборудованием :)? Ну, на промышленном оборудовании таких скоростей, естественно, нет :) Но в составе отдельной железки используются асинхронные шины до 2-х мегабит довольно часто. Ну или обработка эха, или второй UART, или... Или еще что-нибудь в этом роде - ПЛИСка там внешняя, например. Удобно? На десятке-другом килобит характерных для промышленого оборудования и дсостаточно больших попугаях у обсуждаемого контроллера тормоза вполне символические. На 115.2 килобит уже не совсем символические. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 22 августа, 2008 Опубликовано 22 августа, 2008 · Жалоба Ну вот, а часто ли Вам нужен канал между контроллерами с управлением потоком? Не пользовал, но почему-бы и нет? Тот-же RS422, банальный 4x2 витой кабель и простейший, но мегабитный межблочный канал готов. Но в составе отдельной железки используются асинхронные шины до 2-х мегабит довольно часто. Вот только нафиг там RS485, а не TTL/RS422/.... Удобно? Нот. Но не не слишком и хлопотно во многих случаях можно поступить, например, при работе без parity или с менее, чем 8bit подключаем TX одного имеющихся в избытке UART прямо к управлению предатчиком и запихнув в него нолик с нулевой parity получаем желаемое управление без потери, возможно, нужного таймера. Есть более удобные железки - есть! Есть UART железо максимально приближающееся к идеалу - есть! (у Am186, например). Ну и что? Подчинить выбор контроллера исключительно наличию прямого управления передатчиком у UART? На 115.2 килобит уже не совсем символические. Повторяю вопросы - на каких скоростях работает существующее промышленное оборудование и зачем закладывать RS485 в новое? "Громадность" затрат я представляю более, чем хорошо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 22 августа, 2008 Опубликовано 22 августа, 2008 · Жалоба Вот только нафиг там RS485, а не TTL/RS422/.... Дык межблочный, один мастер - N слейвов. Рядом килоамперы разрываются. ...имеющихся в избытке UART Не имелись они в избытке до последних времен. Ну и что? Подчинить выбор контроллера исключительно наличию прямого управления передатчиком у UART? Я разве это предлагал? Но учитывать эту особенность приходится. Повторяю вопросы - на каких скоростях работает существующее промышленное оборудование и зачем закладывать RS485 в новое? "Громадность" затрат я представляю более, чем хорошо. 1. 19200, 115200. 2. Оборудование не только мое, так что от RS485 никуда не деться. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 22 августа, 2008 Опубликовано 22 августа, 2008 · Жалоба Дык межблочный, один мастер - N слейвов. Ну так - RS422, все сидят слушают мастера. Получив свой адрес подключает передатчик и вперед. Получив не свой адрес - отключает. Линия приема мастера почти всегда хорошо подтянута одним из передатчиков- меньше помех. Но учитывать эту особенность приходится. Ну дык, естественно, приходится. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 22 августа, 2008 Опубликовано 22 августа, 2008 · Жалоба Ну так - RS422, все сидят слушают мастера. Получив свой адрес подключает передатчик и вперед. Получив не свой адрес - отключает. Линия приема мастера почти всегда хорошо подтянута одним из передатчиков- меньше помех. Работа идет в стиле запрос-ответ. В результате получаем практически тот же 485, только проводов больше. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 22 августа, 2008 Опубликовано 22 августа, 2008 · Жалоба В результате получаем практически тот же 485, только проводов больше. Ну а что еще из 485/422 красивого в случае шины сделаешь :( Ну а провода на нескольких метрах межблочных экономить достаточно мелочно, тем более, что в реальности это массовые 2/4 витые пары, к счастью, распространившиеся вместе с Ethernet. Приемо-передатчики тоже не по одному корпусированы. Кроме того это не "практически 485" - "лишняя" пара проводов это это дуплекс с выбранным или любым другим slavе, экстенное прерывание передающего фрейм,... Все это по здравому размышлению приводит к малоцелесообразности использования RS485, там где это не навязано внешними неподвласными факторами. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 23 августа, 2008 Опубликовано 23 августа, 2008 · Жалоба Ну а провода на нескольких метрах межблочных экономить достаточно мелочно, тем более, что в реальности это массовые 2/4 витые пары, к счастью, распространившиеся вместе с Ethernet. Приемо-передатчики тоже не по одному корпусированы. Проблема не в проводах, а в разъемах и месте в них. Кроме того это не "практически 485" - "лишняя" пара проводов это это дуплекс с выбранным или любым другим slavе, экстенное прерывание передающего фрейм,... Дуплекс мне даром не нужен. В оличие от RS485 экстренно передающий слейв в RS422 не увидит конфликта на шине с другим. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 23 августа, 2008 Опубликовано 23 августа, 2008 · Жалоба Дуплекс мне даром не нужен. Потому, что у Вас его нет :). Вы вроде не испытывете никаих особых проблем от отсутствия дуплекса (точнее обходите его отсутствие - вот сразу уже разговоры о коллизиях начались), а я от отсутствия "очень нужного бита" :) для управления передатчиком. Проблема имеющее решение и не проблема вовсе. Дальше голые эмоции "да как могут в современном чипе не приделать прямое управление передатчиком RS485", ну или "да как можно в современном чипе не использовать имеющийся CAN" :). В оличие от RS485 экстренно передающий слейв в RS422 не увидит конфликта на шине с другим. Его увидет master и аккуратно заткнув текущего спросит "ну кто там хотел экстренно столько-то времени тому назад передать". Вообще-то если, как мне показалось,мы уже ведем разговор о своем оборудовании, то... то :) :) :) CAN, а не пляски с двумя проводами RS485 смотрятся много более уместно. Проблема не в проводах, а в разъемах и месте в них. Мы вроде уже до разговора о межблочных связей, причем в своем оборудовании, докатились? А блок, по крайней мере в моем понятии, штука большая, c солидной начинкой, со своим питанием... Какое такое "место в разьеме"? P.S. Может в теме обсудим более суровую периферию чипов поминаемых в топике произволителей? А то ведь, действительно докатимся до споров об оттенках черного у корпусов :(. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 23 августа, 2008 Опубликовано 23 августа, 2008 · Жалоба Так, докатились до CAN'а :) Скажите, а зачем я должен отказываться от RS485? Из-за наличия у используемого мной контроллера поддержки CAN'а? Но это уже даже больший маразм, чем: Подчинить выбор контроллера исключительно наличию прямого управления передатчиком у UART? Ибо уровень решения и объем последствий несоразмерен. CAN меня не устраивает по причине очень уж короткого поля данных. P.S. Может в теме обсудим более суровую периферию чипов поминаемых в топике произволителей? А то ведь, действительно докатимся до споров об оттенках черного у корпусов :(. Давайте. Только вот действительно суровой периферии у них нет практически. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 23 августа, 2008 Опубликовано 23 августа, 2008 · Жалоба CAN меня не устраивает по причине очень уж короткого поля данных. По большому счету у 485 оно вообще байт - все остальное уже протоколы верхнего уровня.Тем не менее все устраивает :). Давайте. Только вот действительно суровой периферии у них нет практически. Неожиданное утверждение. Пожалуй тогда не буду продолжать разговоры :( - хватит мне UARTа. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 23 августа, 2008 Опубликовано 23 августа, 2008 · Жалоба По большому счету у 485 оно вообще байт - все остальное уже протоколы верхнего уровня.Тем не менее все устраивает :). Рад за Вас. Меня, скажем так, устраивает почти все, но это можно пережить :) Неожиданное утверждение. Пожалуй тогда не буду продолжать разговоры :( - хватит мне UARTа. Обсуждать действительно почти нечего: EMAC, USB, архитектура подсистемы памяти и т.п. у Atmel'а объективно хуже, чем аналогичные модули современных NXP. Хотя вполне работоспособны. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться