Леонид Иванович 0 8 августа, 2006 Опубликовано 8 августа, 2006 · Жалоба Сам правда не пробовал, но в FTDI чипах USB-COM есть специальный аппаратный управляющий сигнал для переключения передатчика... В FTDI есть. Но речь шла о COM-порте, а не о USB. Как там? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Sam_ 0 9 августа, 2006 Опубликовано 9 августа, 2006 · Жалоба Все, зарубили идею, а ведь почти получилось Для переключения использовать МК - распоряжение начальства. Теперь все с начала... Ну начальство можно и убедить или в крайнем случае слегка обмануть :) Просто если делать на МК необходимо будет и протокол несколько переписать. Перед началом обмена передавать несколько синхронизирующих байт по которым ваш МК определит скорость с которой будет вестись передача. Или добавить в протокол команды для МК, которые будут передаваться всегда на фиксированной скорости, и в них указывать скорость с которой будет вестись передача. На сотнях метрах и больших скоростях я схему без контроллера не пробовал, но на 30метрах 1мегабит с растяжками по 690Ом будет работать 100% в условиях помех(у меня сейчас под 100 реле без искрогасящих цепочек и электродвигатель на 3кВт). Я смотрел сигналы до 485 и после линии и 485 задержки конечно есть но всего порядка нескольких процентов. Реализовать эту схему гораздо проще и быстрее. Неужели ваше начальство не может вам лишние два часа выделить, чтобы вы во всём до конца разобрались? Если у вас просаживатеся один из сигналов попробуйте отсоединить свои 485приёмопередатчики от линии и посмотреть будет ли просаживаться сигнал на каждом из них. Если всё ок значит надо прозвонить линию, если нет, искать в соотв. 485приёмопередатчике. Кстати если сигнал просаживается хоть МК ставьте хоть ещё один PC всё равно будет криво работать! Проверить работоспособность всей линии в целом можно следующим образом: сигнал до передающего 485 должен совпадать с сигналом после принимающего rs485. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_artem_ 0 9 августа, 2006 Опубликовано 9 августа, 2006 · Жалоба Если применик держать все время в работаюшем положении а после передачи фрейма сразу же принимать данные то по окончанию последнего байта можно и деактивизировать RTS. А как узнать момент окончания передачи последнего байта? На этот счет где то в msdn прочел что надо разговаривать напрямую с драйвером. Посмотрел IOCTL коды примера из ДДК и не нашел ничего подходяшего. Наверно плохо искал. Вроде бы два других варианта есть (первый проверил и как будто ничего): - в полудуплексе rs484 держать прием все время активным так что любой переданный из pc байт будет принят . После передачи последнего байта начинать прочитывание rx буффера и по последнему байту переданного сообшения сбрасывать rts. - второй вариант немного кривоват - измеряется количество байтов в посланном пакете , пакет посылается и сразу же стартует таймер (надо изпользовать мултимедийный - он дает 1-3 миллисекунды разрешения нежели другие). По таймауту - сбрасывать rts. Кривизна этого метода заключается в том что неизвестно точное время начала передачи пакета . Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Леонид Иванович 0 9 августа, 2006 Опубликовано 9 августа, 2006 · Жалоба (надо изпользовать мултимедийный - он дает 1-3 миллисекунды разрешения нежели другие) PerformanceCounter даёт еще лучше разрешение - обычно не хуже микросекунды. Но что толку? Пожалуй, единственным приемлемым решением является использование режима RTS_TOGGLE, а в подчиненном устройстве делать задержку перед передачей ответа в PC. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_VoRoN_ 0 9 августа, 2006 Опубликовано 9 августа, 2006 · Жалоба Все, зарубили идею, а ведь почти получилось Для переключения использовать МК - распоряжение начальства. Теперь все с начала... Ну начальство можно и убедить или в крайнем случае слегка обмануть :) Просто если делать на МК необходимо будет и протокол несколько переписать. Перед началом обмена передавать несколько синхронизирующих байт по которым ваш МК определит скорость с которой будет вестись передача. Или добавить в протокол команды для МК, которые будут передаваться всегда на фиксированной скорости, и в них указывать скорость с которой будет вестись передача. На сотнях метрах и больших скоростях я схему без контроллера не пробовал, но на 30метрах 1мегабит с растяжками по 690Ом будет работать 100% в условиях помех(у меня сейчас под 100 реле без искрогасящих цепочек и электродвигатель на 3кВт). Я смотрел сигналы до 485 и после линии и 485 задержки конечно есть но всего порядка нескольких процентов. Реализовать эту схему гораздо проще и быстрее. Неужели ваше начальство не может вам лишние два часа выделить, чтобы вы во всём до конца разобрались? Если у вас просаживатеся один из сигналов попробуйте отсоединить свои 485приёмопередатчики от линии и посмотреть будет ли просаживаться сигнал на каждом из них. Если всё ок значит надо прозвонить линию, если нет, искать в соотв. 485приёмопередатчике. Кстати если сигнал просаживается хоть МК ставьте хоть ещё один PC всё равно будет криво работать! Проверить работоспособность всей линии в целом можно следующим образом: сигнал до передающего 485 должен совпадать с сигналом после принимающего rs485. Работать должно на расстоянии до 1024 м., для того чтобы использовать схему без МК, потребуются длительные испытания ее работоспособности. Да, МК - это конечно не самое простое решение, но все же в данном случает другого ничего не остается, так что придется выкручиваться. Идеи есть, но вот только на выбранном ранее МК реализовать их не получится, что не может не огорчать. Причиной этому, как показала практика, оказалось время реакции на внешние прерывания, которое оказалось больше периода сигнала на скорости 115200, в рез-те чего "съедалось" нало слова. На 9600 все работало устойчиво, а на 38400 - с переменным успехом. Это что касается идеи, когда сигнал на передачу устанавливается с началом фрейма и удерживается на время его прохождения. Если говорить о варианте использования МК в качестве буффера, т.е. принимая передаваемые данные и "выплевывая" их затем в линию, используя 3-й режим UART, со скоростью, задаваемой таймером, то тут опять же облом, т.к. обеспечить скорость 115200 при частоте кварца 24 МГц при помощи Т1 просто невозможно. Для таких скоростей надо использовать Т2, который в 4051 просто отсутсвует, поэтому пришлось переходить на 8252. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_artem_ 0 10 августа, 2006 Опубликовано 10 августа, 2006 · Жалоба (надо изпользовать мултимедийный - он дает 1-3 миллисекунды разрешения нежели другие) PerformanceCounter даёт еще лучше разрешение - обычно не хуже микросекунды. Но что толку? Пожалуй, единственным приемлемым решением является использование режима RTS_TOGGLE, а в подчиненном устройстве делать задержку перед передачей ответа в PC. А Вы измеряли задержку переключения RTS для toggle mode ? Мне почему то показалось что он медленно переключался после окончания передачи . Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Леонид Иванович 0 11 августа, 2006 Опубликовано 11 августа, 2006 · Жалоба А Вы измеряли задержку переключения RTS для toggle mode ? Мне почему то показалось что он медленно переключался после окончания передачи . Верно, медленно. Но другого решения не видно. Придется делать задержку перед ответом слэйва. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_artem_ 0 11 августа, 2006 Опубликовано 11 августа, 2006 · Жалоба А можете ли Вы попробовать держать RX 485 драйвера в полудуплексном режиме все время рабочим и после передачи пакета сразу же принять оные до последнего байта а затем быстро переключить rts. У меня меньше миллисекунды задежка была . Интересно это особенности моей машины или обшее правило. Насчет Performance counter если его подобие для стандартного API а не NET framework С# или VB ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
