Поиск:

Ответ в темуСоздание новой темы Создание опроса
> И снова COM port, проблемы при работе с комм портом. 
:(
    Опции темы
EugenOS
Дата 21.11.2007, 22:02 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 9
Регистрация: 21.11.2007

Репутация: нет
Всего: нет



Доброго времени суток всем. 
Собрал свое устройство, по сути преобразователь протоколов. С одной стороны COM порт c другой устройство с инфракрасной связью, своим специфическим протоколом и набором комманд. Написал свою прогу(вернее написание в процессе, но кое-что уже работает) 
Использовал найденный в инете TComThread. Наследованный от TThread. Суть не в этом. Скорость выше 57600 использовать не могу, дальше слишком большой разбег между желаемой и реальной частотой, комп уже адекватно не воспринимает данные от контроллера. (Изменить кварц тоже не легко, инфракрасный девайс не менее критичен)  Сообщения передаваемые от/к девайсу имеют длину от 3-х до 12 байт.
При трех в принципе проблем не возникает, а вот при 12... Время передачи 12-и байт через COM-порт равно 2086 мкс, а время ожидания ответа оптическим девайсом, не превосходит 4500 мкс. Если бы я писал под ДОС, то у меня было бы прерываание по приходу символа, и соответственно время реакции программы было бы минимальным, мне в полне хватило бы чтобы принять посылку, сформировать ответ и передать его, тем более что мое устройство начало бы передавать сразу же. ( время передачи по оптике одного байта, процентов на 20 больше чем передачи его же по COM, так  что все было бы в ажуре ) Но как я понял дядя Билли не снабдил COM порт механизмом сообщений,
и все существующие компоненты и библиотеки работают по принципу "подождал, проверил количество принятых байт, если не ноль вызвал обработчик" При этом времени проходит достаточно, чтоб девайс перестал ждать ответа  smile 

Уменьшая время ожидания я добился того что интерфейс стал почти не юзабельным, но положительных сдвигов не наметилось. smile 

Может кто подскажет есть ли какие либо драйвера или может исходники, как обойти микрософтовскую заглушку на COM и получит возможность "получать" ( извините за тафталогию ) прерывание от COM и обрабатывать его своей функцией?

Слыхал что в .NET есть стандартный компонент работы с COMом, но боюсь что там тот же принцип.
Кто работал с DirectX, может  там есть такая возможность?

Заранее и в любом случае всем спасибо.

P.S. Стандартный файловый доступ пробовал, оверлапед тоже, TComPort и TPAPro работают схожими с TComThread способами.
PM MAIL   Вверх
xvr
Дата 22.11.2007, 15:54 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Комодератор
Сообщений: 7046
Регистрация: 28.8.2007
Где: Дублин, Ирландия

Репутация: 48
Всего: 223



Цитата(EugenOS @ 21.11.2007,  22:02)
Если бы я писал под ДОС, то у меня было бы прерываание по приходу символа, и соответственно время реакции программы было бы минимальным, мне в полне хватило бы чтобы принять посылку, сформировать ответ и передать его, тем более что мое устройство начало бы передавать сразу же. ( время передачи по оптике одного байта, процентов на 20 больше чем передачи его же по COM, так  что все было бы в ажуре ) Но как я понял дядя Билли не снабдил COM порт механизмом сообщений,
и все существующие компоненты и библиотеки работают по принципу "подождал, проверил количество принятых байт, если не ноль вызвал обработчик" При этом времени проходит достаточно, чтоб девайс перестал ждать ответа


Вообще то снабдил - overlapped называется. Так же надо не забывать настроить timeout'ы на прием байта (выкрутить их в 0). Еще надо тому thread'у, на котором висит обработка COM порта выкрутить приоритет в real-time, иначе переключение thread'ов сожрет все время.

Цитата

Может кто подскажет есть ли какие либо драйвера или может исходники, как обойти микрософтовскую заглушку на COM и получит возможность "получать" ( извините за тафталогию ) прерывание от COM и обрабатывать его своей функцией?

Написать свой драйвер и вставить в него все преобразование - Windows не real-time система :(

Цитата

Слыхал что в .NET есть стандартный компонент работы с COMом, но боюсь что там тот же принцип.
Угу, еще можно в Java поискать  smile 

PM MAIL   Вверх
EugenOS
Дата 22.11.2007, 17:26 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 9
Регистрация: 21.11.2007

Репутация: нет
Всего: нет



Если таймаут выкрутить в 0 и дать треду приоритет real-time, то интерфейс вообще повиснет ;(
overlaped - не тоже, что обработка прерывания по приходу байта. После запуска чтения порта в оверлаппед режиме, необходимо постоянно опрашивать систему о том принято ли какое-либо количество байт. Что в принципе и реализовано. Единственный выход, как я сам думаю, написать свой драйвер, который будет делать то что мне нужно, но подумал спросить у людей, вдруг я ошибаюсь и есть другие методы.
Тем более что с DDK никогда не работал( ставил как-то DDK2000, но дальше просмотра примеров не пошел, тем более что DDK2000 требовал VC4, а я тогда смог найти только VC6.

Есть у меня правда другой вариант, даже два:
1) Написать что либо под ДОС, тем более в свое время работал с Turbo Vision
2) Задействовать BigPIC4 в качестве платформы, и писать под PIC18.

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

Спасибо.
PM MAIL   Вверх
xvr
Дата 22.11.2007, 19:02 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Комодератор
Сообщений: 7046
Регистрация: 28.8.2007
Где: Дублин, Ирландия

Репутация: 48
Всего: 223



Цитата(EugenOS @ 22.11.2007,  17:26)
Если таймаут выкрутить в 0 и дать треду приоритет real-time, то интерфейс вообще повиснет ;(

Не повиснет, если делать с умом: ReadIntervalTimeout и ReadTotalTimeoutMultiplier в 0, ReadTotalTimeoutConstant во что-нибудь осмысленное. Но в случае бага в этой нитке машину придется перезагружать smile

Цитата

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

Хм, вообще то для этого используют поле hEvent в OVERLAPPED структуре и WaitForSingleObject. Ничего постоянно опрашивать не надо.

PM MAIL   Вверх
EugenOS
Дата 24.11.2007, 18:03 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 9
Регистрация: 21.11.2007

Репутация: нет
Всего: нет



Цитата

Хм, вообще то для этого используют поле hEvent в OVERLAPPED структуре и WaitForSingleObject. Ничего постоянно опрашивать не надо.


Тут соглашусь, я с оверлапедом игрался лет пять-семь назад. Тогда о паралельном выполнении двух потоков (тредов) я и не помышлял ;)
Сейчас уже не помню деталей, но по-моему у меня программа не могла ничего сделать пока не получит этот самый эвент, возможно я делал что не так. Вот и отложилось в памяти. В понедельник попробую(сейчас дел по горло, даже некогда за комп по нормальному сесть). Спасибо еще раз гляну хелп по API ;)
PM MAIL   Вверх
  
Ответ в темуСоздание новой темы Создание опроса
Правила форума "С++ Builder"
Rrader

Запрещается!

1. Публиковать ссылки на вскрытые компоненты

2. Обсуждать взлом компонентов и делиться вскрытыми компонентами

  • Литературу по С++ Builder обсуждаем здесь
  • Действия модераторов можно обсудить здесь
  • С просьбами о написании курсовой, реферата и т.п. обращаться сюда
  • Настоятельно рекомендуем заглянуть в DRKB (Delphi Russian Knowledge Base) - крупнейший в рунете сборник материалов по Дельфи


Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, Rrader.

 
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | C++ Builder | Следующая тема »


 




[ Время генерации скрипта: 0.0819 ]   [ Использовано запросов: 21 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.