| |
 Об RS232, Как узнать конец посылки? |
|
|
|
|
 Sep 2 2009, 08:41
|
Местный
Группа: Свой
Сообщений: 435
Регистрация: 12-09-07
Пользователь №: 30 482
|
Цитата(MrYuran @ Sep 2 2009, 11:17)  При использовании EV_TXEMPTY есть одна подлая особенность - то, что буфер пуст, не означает, что последний байт передан.
Поэтому, например, когда мне нужно было переключать направление в полудуплексном RS-485, я добавлял в конец пакета фиктивный байт, по опустошению буфера переключал направление (ногой DTR) и последний байт "улетал в пустоту".
Можно отсчитать паузу от эвента, но это дополнительная морока. Какую задержку нужно выставить, пару милисекунд? У меня тоже полудуплексный RS-485. Сделал так (без отслеживвания EV_TXEMPTY ): поставил задержку после запуска передачи 10 мс, потом переключаю направление ногой RTS. Так не всегда успевает или все передать, или все принять. Добавил еще задержку 20 мс ответа в приборе. Пока помогло, но что будет на другом ПК, или если операционка еще что-то будет делать. Это заставило поискать альтернаттиву.
|
|
|
|
|
|
|
|
Sep 2 2009, 08:49
|
Гуру
Группа: Свой
Сообщений: 3 615
Регистрация: 12-01-09
Из: США, Главное разведовательное управление
Пользователь №: 43 230
|
Цитата(kolisnichenko_r @ Sep 2 2009, 11:41) Какую задержку нужно выставить, пару милисекунд?
У меня тоже полудуплексный RS-485. Сделал так (без отслеживвания EV_TXEMPTY ):
поставил задержку после запуска передачи 10 мс, потом переключаю направление ногой RTS. Так не всегда успевает или все передать, или все принять. Добавил еще задержку 20 мс ответа в приборе. Пока помогло, но что будет на другом ПК, или если операционка еще что-то будет делать.
Это заставило поискать альтернаттиву. Самый мне понравившийся вариант, это просто слушать сам себя. Принимать сообщение, которое уходит в линию. Как только декодировал отправленное сообщение, сразу вырубать передачу.
|
|
|
|
|
|
|
|
Sep 2 2009, 09:24
|
Местный
Группа: Участник
Сообщений: 403
Регистрация: 14-05-07
Из: Россия, г.Пенза
Пользователь №: 27 719
|
Блин, у меня тоже похожая , но немножко другая "беда"... Пишу сейчас маленькую "прогу" на Visual C++ , типа "оболочки". Программа обмена данными между компьютером и МК. Получается интересная вещь. Программа работает нормально, обмен идет, но стоит выключить "таргет" и включить его снова , как то-ли драйвер СОМ порта, то-ли сам СОМ порт впадает в интересный ступор. С компьютера все идет нормально, "таргет" на команды реагирует, только вот отвечать перестает... т.е. отвечать то он отвечает, но моя программа не видит ничего. Вывод из "ступора" происходит закрыванием моей программы, включением "терминала" и открыванием а затем закрыванием СОМ порта. использую библиотеку SerialGate.dll там тоже имеются команды Открытия порта, Закрытия порта, Очистки буфера... но не помогает  Возможно библиотека "кривая", возможно я "кривой" но вот такая петрушка... Может у кого ссылки есть на более продвинутые библиотеки+описание для Visual C++ ?
--------------------
" Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий." (с) К.Прутков.
|
|
|
|
|
|
|
|
Sep 2 2009, 09:33
|
Беспросветный оптимист
Группа: Свой
Сообщений: 4 640
Регистрация: 26-12-07
Из: Н.Новгород
Пользователь №: 33 646
|
Цитата(manul78 @ Sep 2 2009, 13:24) использую библиотеку SerialGate.dll Вот., посмотрите. Третья ссылка сверху - удобный ПДФ. А потом решите, нужны ли ещё какие-то дополнительные обёртки к стандартному API
--------------------
Программирование делится на системное и бессистемное. ©Моё :)
— а для кого-то БГ — это Bill Gilbert =)
|
|
|
|
|
|
|
|
Sep 2 2009, 09:39
|
Местный
Группа: Участник
Сообщений: 403
Регистрация: 14-05-07
Из: Россия, г.Пенза
Пользователь №: 27 719
|
Цитата(Dog Pawlowa @ Sep 2 2009, 13:32) Это обычная реакция ПиСишного порта на брейк, который формируется при отключении устройства.
Это состояние нужно обрабатывать. Каким образом ? И если не трудно объясните пожалуйста, что "там" происходит ? Я компьютеры на аппаратном уровне программировал только под ДОС лет 15 назад... Возможно и сам-бы разобрался, но у XP Вындоуз заморочки с прямым доступом к портам, отсюда такие головоломки что приходится пользоваться чужими библиотекам...
--------------------
" Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий." (с) К.Прутков.
|
|
|
|
|
|
|
|
Sep 2 2009, 09:54
|
Беспросветный оптимист
Группа: Свой
Сообщений: 4 640
Регистрация: 26-12-07
Из: Н.Новгород
Пользователь №: 33 646
|
Цитата(manul78 @ Sep 2 2009, 13:39) приходится пользоваться чужими библиотекам... пешыте на обшарпанном. Коллега вот писает кипятком по поводу тамошних готовых классов. Тем более всё равно в студии...
--------------------
Программирование делится на системное и бессистемное. ©Моё :)
— а для кого-то БГ — это Bill Gilbert =)
|
|
|
|
|
|
|
|
Sep 2 2009, 10:17
|
Местный
Группа: Участник
Сообщений: 403
Регистрация: 14-05-07
Из: Россия, г.Пенза
Пользователь №: 27 719
|
Цитата(MrYuran @ Sep 2 2009, 13:54) пешыте на обшарпанном. Это на "Шарпе" что-ли ? Вникать долго, да и смысла нет, я просто "оболочку" пишу, раз в 100 лет. Вот нашел готовую библиотеку: public: enum IN_LINES_NAME {CTS, DSR, RING, RLSD}; enum OUT_LINES_NAME {DTR, RTS}; SerialGate(); ~SerialGate(); bool Open(int port, int baud); // открытие порта int Send(char* buff, int szBuff); // отправить int Recv(char* buff, int szBuff); // получить void SetLine(OUT_LINES_NAME ln, bool state); // установить линии bool GetLine(IN_LINES_NAME ln); // получить состояние линий void GetPortsInfo(PortInfo* pi); // проверка портов и их состояние void Close(); // закрыть порт void Clean(); // очистить буфер Может я что не так делаю ? Я думал, если открыть порт, очистить, закрыть и опять открыть - поможет. Не помогло За API функции конечно спасибо, но я в них "зароюсь", квалификация не та
--------------------
" Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий." (с) К.Прутков.
|
|
|
|
|
|
|
|
Sep 2 2009, 10:22
|
Знающий
Группа: Свой
Сообщений: 648
Регистрация: 11-02-06
Из: Санкт-Петербург
Пользователь №: 14 237
|
Цитата(MrYuran @ Sep 2 2009, 12:59) Мне вот почему-то кажется, что должен быть режим, в котором DTR (Data Transmit) сам обозначает время передачи. То есть автоматически. Правда, глубоко в этом вопросе не копал, а наскоком сделать не получилось. Довольствуюсь ранее описанными костылями У некоторых чипов UART (например, PCI-UART фирмы Exar) есть специальный режим работы, который называется "Auto RS485 Mode". Режим включается взведением бита в соотв. регистре, или через IOCTL драйвера. Суть режима в том, что он с помощью ножки RTS автоматически включает передатчик RS-485, с момента появления в передающем буфере данных до момента отправки последнего байта. В стандартном 16550А такой возможности, насколько мне известно, нет. P.S. Кстати, DTR - это не Data Transmitt ... это Data Terminal Ready, сигнализирует противоположной стороне готовность как раз принимать данные.
--------------------
Сделано в Китае. Упаковано в России.
|
|
|
|
|
|
|
|
Sep 3 2009, 21:51
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(Demeny @ Sep 2 2009, 14:22) В стандартном 16550А такой возможности, насколько мне известно, нет. Да, в стандартном 16550А такой возможности нет, но в 16550А совместимых(а это практически 100% современных ПЦ) есть возможность отсылать не весь пакет, а пакет без последнего байта, при приходе TXEMPTY этого пакета шлем последний байт, тогда следующий TXEMPTY придет только на стоповом бите последнего байта, и нужно подождать только 1 бит перед переключением направления(на большинстве чипсетов можно вобще не ждать т.к. стоп бит == неактивное состояние) Единственно, это гарантированно работает только на уровне драйвера ядра(только что сделал так на линух), в юзерспейсе, при сильной нагрузке, последний(отдельный) байт может "отрываться" от остального пакета.
|
|
|
|
|
|
|
Guest_@Ark_*
|
Sep 3 2009, 22:16
|
Guests
|
По-моему, проблема слегка надумана. Если речь идет о передаче по RS485, то на выходе COM-порта (физического или виртуального) неизбежно стоит преобразователь RS232-RS485 либо USB-RS485. Все проблемы с преобразованием дуплекса в полудуплекс и обратно он должен брать на себя. В том числе и переключение драйвера RS485 c передачи на прием и обратно. Нормальные преобразователи успешно выполняют эту функцию самостоятельно, в автоматическом режиме. Перекладывать эту задачу (управление направлением передачи) на прикладную программу в ПК, на мой взгляд не совсем правильно. Точнее - совсем не правильно.
|
|
|
|
|
|
|
|
Sep 3 2009, 22:45
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(@Ark @ Sep 4 2009, 02:16) Нормальные преобразователи успешно выполняют эту функцию самостоятельно, в автоматическом режиме. Какие нормальные ? для RS232-RS485 ? ADM2483 например нормальный преобразователь ? Конечно идеальный вариант прикрутить к каждому преобразователю мелко-мелкоконтроллер который будет сам считать нужные паузы и переключать направление, но увы так делают не всегда...
|
|
|
|
|
|
|
Guest_@Ark_*
|
Sep 3 2009, 23:02
|
Guests
|
Цитата Конечно идеальный вариант прикрутить к каждому преобразователю мелко-мелкоконтроллер который будет сам считать нужные паузы и переключать направление, но увы так делают не всегда... Это не идеальный вариант, а, как раз, обычный, нормальный и стандартный. Преобразователь - с одной стороны которого стандартный RS232, а с другой - стандартный RS485. И еще, желательно, гальваническая развязка между ними. Стандартный RS232 не предполагает специального сигнала для указания направления передачи, т.к. он полнодуплексный...
|
|
|
|
|
|
|
|
Sep 4 2009, 05:48
|
Местный
Группа: Свой
Сообщений: 435
Регистрация: 12-09-07
Пользователь №: 30 482
|
Цитата(@Ark @ Sep 4 2009, 02:02) Это не идеальный вариант, а, как раз, обычный, нормальный и стандартный. Преобразователь - с одной стороны которого стандартный RS232, а с другой - стандартный RS485. И еще, желательно, гальваническая развязка между ними. Стандартный RS232 не предполагает специального сигнала для указания направления передачи, т.к. он полнодуплексный... А каким способом Вы разделяете передачу, прием в полудутлексном режиме?
|
|
|
|
|
|
|
Guest_@Ark_*
|
Sep 4 2009, 07:04
|
Guests
|
Цитата Хорош способ, только мне не подходит, в преобразователь микроконтроллер ставить не разрешают. Поищите по форуму темы о преобразователях RS232-RS485. Где-то предлагались и чисто аппаратные решения.
|
|
|
|
|
|
|
Guest_@Ark_*
|
Sep 4 2009, 07:17
|
Guests
|
Я думаю, что автоматический режим, описанный выше, можно на какой-нибудь логике воспроизвести.
Только громоздко получится... Не понятно, чем не нравится микроконтроллер заказчикам автора...
|
|
|
|
|
|
|
|
Sep 4 2009, 19:20
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(demiurg_spb @ Sep 4 2009, 12:23) С USB и чипом от ftdi у нас получилcя такой девайс: ссылкас USB не так интересно, патамушто все понятно, у нас и USB <-> 3xRS485 есть А вот про момент переключения интересно, у @Ark по ссылке не очень понятно, поток пропускается через микропроц или нет ? То есть там только руление переключением или и "буферизация" ?
|
|
|
|
|
|
|
|
Sep 4 2009, 21:05
|
Гуру
Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882
|
Цитата(demiurg_spb @ Sep 4 2009, 14:23) С USB и чипом от ftdi у нас получилcя такой девайс: ссылкаЭто вы разработчик этого девайса? Можно чуток покритиковать и его и документацию?  Критика конструктивная. Может во благо будет и вы чего-то подправите. Во-первых, на клеммнике нет 3-го провода для выравнивания потенциалов с другими точками подключения. Это чревато тем, что на большом расстоянии амплитуда синфазной помехи может превысить допустимые для драйвера RS485 пределы. Это в лучшем случае приведет к его неработоспособности. В худшем - при возникновении искровых или дуговых разрядов вблизи линии передачи (микросекундные помехи) пробьется изоляция DC/DC в конвертере. Во-вторых, в документации указано Цитата Потребляемый ток, А, не более ..................................... 0,2
Напряжение изоляции гальванической развязки, В ..... 1000
Максимальное количество приборов в сети ................. 32
Максимальная скорость передачи данных, Кбит/с....... 921,6
Максимальная длина линии связи, м ............................ 1200 но нигде нет примечания по ограничению на применение последних двух параметров. Кто-то просто тупо списал параметры, не удосужившись их проверить (а чего же тогда не 3Мегабита?, ведь м/с FTDI позволяет) или хотя бы осмыслить. Вы сами-то понимаете, что в совокупности (одновременно) они не работают? Даже если вы применили очень хорошие драйверы RS485 (10Мбит или выше), то либо скорость Мегабит, либо расстояние километр, но не одновременно! Тем более, что судя по параметрам тока потребления и напряжения изоляции, внутри конвертера стоит дешевый нерегулируемый 1Вт DC/DC 5V-to-5V. И предельный ток потребления устройства также из даташита DC/DC списан, без реальной проверки на готовом преобразователе. Не нужно потребителя в заблуждение вводить. В-третьих, а зачем в комплект драйверов входит хедер и либы? Предполагается, что пользователь сам будет сможет прикрутить конвертер к своей программе (к OPC-серверу, например)? Тогда где на странице продукта руководство по программированию? Будьте уж последовательны в своих намерениях. Выкладывайте полную документацию. Я ни в коей мере не хочу "очернить" ваше устройство!  Я указал на факты, которые просто сходу бросаются в глаза специалисту. Доведите до сведения людей вашей фирмы, отвечающих за разработку и продажу.
|
|
|
|
|
|
|
|
Sep 5 2009, 09:49
|
неотягощённый злом
Группа: Свой
Сообщений: 2 746
Регистрация: 31-01-08
Из: Санкт-Петербург
Пользователь №: 34 643
|
Цитата(rezident @ Sep 5 2009, 01:05) Это вы разработчик этого девайса? Можно чуток покритиковать и его и документацию? Критика конструктивная. Может во благо будет и вы чего-то подправите. Во-первых, на клеммнике нет 3-го провода для выравнивания потенциалов с другими точками подключения. Это чревато тем, что на большом расстоянии амплитуда синфазной помехи может превысить допустимые для драйвера RS485 пределы. Это в лучшем случае приведет к его неработоспособности. В худшем - при возникновении искровых или дуговых разрядов вблизи линии передачи (микросекундные помехи) пробьется изоляция DC/DC в конвертере. Да. Разработчик - наш сотрудник. Спасибо за хинт. Добавим третий клеммник COM или GND. Цитата(rezident @ Sep 5 2009, 01:05) но нигде нет примечания по ограничению на применение последних двух параметров. Кто-то просто тупо списал параметры, не удосужившись их проверить (а чего же тогда не 3Мегабита?, ведь м/с FTDI позволяет) или хотя бы осмыслить. Вы сами-то понимаете, что в совокупности (одновременно) они не работают? Даже если вы применили очень хорошие драйверы RS485 (10Мбит или выше), то либо скорость Мегабит, либо расстояние километр, но не одновременно! Скорость в один мегабит обусловлена максимальной скоростью изолятора. Мы всё прекрасно понимаем. Это указаны (absolute maximum ratings), как говорится. Но Вы правы, в паспорте следует указать характеристики более подробно. Драйвера идут от производителя ftdi "as is", и если в комплекте идёт либа - пусть идёт. Хлеба не просит... А Вы мастер, докапаться и до фонарного столба сможете  А если серьёзно - спасибо за критику. Учту. Ваши предложения разумны. PS. Для того, чтобы прикрутить конвертер к OPC-серверу и любой другой программе либа не требуется, т.к. разработчику доступно API операционной системы, в которой конвертер виден как ком-порт (это на примере ОС windows). Руководство по программированию берётся из руководства по API конкретной ОС. Ну а кому надо непосредственно работать с чипом как например Real'у с ft2232, то тот достаточно компетентен в этом вопросе и зайдёт на сайт производителя и самостоятельно найдёт себе требуемую документацию. Для 99,9 пользователей это не потребуется никогда в жизни. PS2. Внутри конвертера стоит оптимальный по характеристикам DC-DC преобразователь. И за почти 5-и летнюю историю продаж было всего несколько гарантийных случаев, связанных в основном с непропаем, а продано уже боле 3 сотен таких приборов. PS3. Все тесты на МИПы и НИПы данный прибор проходит на сертификационных испытания с успехом.
--------------------
“Будьте внимательны к своим мыслям - они начало поступков” (Лао-Цзы)
|
|
|
|
|
|
|
|
Sep 7 2009, 05:52
|
Местный
Группа: Свой
Сообщений: 435
Регистрация: 12-09-07
Пользователь №: 30 482
|
Цитата(@Ark @ Sep 4 2009, 10:17) Я думаю, что автоматический режим, описанный выше, можно на какой-нибудь логике воспроизвести.
Только громоздко получится... Не понятно, чем не нравится микроконтроллер заказчикам автора... Должно быть дешевое. А микроконтроллер это: пару деталюшек; разовая оплата программисту; постоянная оплата процеса программирования чипа. На этом будут экономить.
|
|
|
|
|
|
|
|
Sep 7 2009, 07:37
|
Гуру
Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095
|
Цитата(kolisnichenko_r @ Sep 7 2009, 08:52) Должно быть дешевое. Гляньте тут. Там схема с автоматическим переключением на любую скорость до 115200 на коротких линиях. Вы так и не ответили, фиксированная ли у вас скорость? На фиксированную скорость одновибратор на время одного байта строится вообще на диоде, резисторе и конденсаторе как в схеме по ссылке.
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
|
|
|
Sep 7 2009, 09:30
|
Местный
Группа: Свой
Сообщений: 435
Регистрация: 12-09-07
Пользователь №: 30 482
|
Цитата(Сергей Борщ @ Sep 7 2009, 10:37) Гляньте тут. Там схема с автоматическим переключением на любую скорость до 115200 на коротких линиях. Вы так и не ответили, фиксированная ли у вас скорость? На фиксированную скорость одновибратор на время одного байта строится вообще на диоде, резисторе и конденсаторе как в схеме по ссылке. Скорость от 1200 до 19200. Тут еще такая заморочка: из прибора выходит 124 байта, ПК отлавливает только 120. Может где размер буфера СОМ порта явно указывается?
|
|
|
|
|
|
3 чел. читают эту тему (гостей: 3, скрытых пользователей: 0)
Пользователей: 0
|
|
|
