Читаю данные из ком-порта в отдельном потоке.
В определенные моменты я посылаю данные в ком-порт для управления устройством, и после посылки никаких данных не жду. Как сделать так, что если данные все же пришли (допустим комманда была не верная), после посылки данных в ком-порт компу дать указание, что если данные и прийдут, то их надо обнулить?
PURGE_TXCLEAR or PURGE_RXCLEAR - это подойдет?

>  после посылки данных в ком-порт

нужно быть уверенным, что они ушли.
так что, PURGE_TXCLEAR не всегда будет полезна ;)

> компу дать указание, что если данные и прийдут, то их надо
> обнулить

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

http://www.pcports.ru/ - там есть многого. и книжки в т.ч.

> Alex_C   (10.02.11 11:26)
>
> Читаю данные из ком-порта в отдельном потоке.
> В определенные моменты я посылаю данные в ком-порт для управления
> устройством, и после посылки никаких данных не жду. Как
> сделать так, что если данные все же пришли (допустим комманда
> была не верная), после посылки данных в ком-порт компу дать
> указание, что если данные и прийдут, то их надо обнулить?
>
> PURGE_TXCLEAR or PURGE_RXCLEAR - это подойдет?

1. "Отдельный поток" - нафиг!
2. Нормальная работа с внешними устройствами на СОМ-порте - это работа с "событиями".
3. "В определенные моменты я посылаю данные в ком-порт для управления
> устройством, и после посылки никаких данных не жду".
Это вообще бред.

> 3. "В определенные моменты я посылаю данные в ком-порт для
> управления
> > устройством, и после посылки никаких данных не жду".
> Это вообще бред.

ну почему же, может, там что-типа пульта ду для телевизора.

> http://www.pcports.ru/ - там есть многого. и книжки в т.
> ч.


Большое спасибо за ссылку! Очень интересно!


> 1. "Отдельный поток" - нафиг!


Есть такая замечательная (и по моему единственная) книжка (она тут часто в плане работы с ком-портами упоминается) ... забыл сейчас ее название...
Так вот - советую почитать! Там прием данных осуществляется как раз по событию в отдельном потоке - так у меня так и сделано :)


> Это вообще бред.


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


> ну почему же, может, там что-типа пульта ду для телевизора.


Ну по большому счету так и есть. Только это не ДУ телевизора, а радиостанция :)

> "Отдельный поток" - нафиг!


Ага, щаз...
А если работа с портом 24/7? У меня, например, в секунду уходит/приходит 20 пакетов. А юзер может "тормозить" работу ПК. Доп. поток обязан быть! Не всегда, но часто.

> А юзер может "тормозить" работу ПК

и что? или нет: смотря как...

2 brother ©   (11.02.11 11:47) [7]

А то, что потоку программы будет выделено мало времени. Черевато это тем, что от устройства начнут приходить "плохие" (склеенные пакеты или не все части пакета) данные.

>смотря как...

Касперский запустился и отнял 80% процессорного времени, скринсейверы, игры и много всего остального.

> Черевато это тем, что от устройства начнут приходить "плохие"
> (склеенные пакеты или не все части пакета) данные.


Вот с этим я тоже столкнулся. Тут кстати весьма большая проблема: недопущение "склеенных" пакетов (их потом невозможно раскодировать) и ожидание прихода полного пакета.

2 Alex_C   (11.02.11 12:55) [9]

Отож.
У меня сделано следующим образом. Во-первых, это отдельный поток для работы с портом. Во-вторых, после создания этого доп. потока я ему еще и приоритет увеличиваю чуток.

И только тогда начинается счастье.

2 Неважно:
У меня в потоке установлен таймер, в течение которого я жду данные (задается пользователем) и проверка на валидность приходящих данных. Т.е. если данные валидны - пришло что ожидали - отправляем следующий запрос, или же просто ждем по времени перед отправкой следующего запроса. Зачем таймер - а чтоб можно было датчик включать/выключать без проблем.

Но выяснилась такая проблема (это зачем я этот топик поднял): если датчику приходит комманда установки, а он ее не понимает, некоторые датчики ничего не отвечают, а некоторые присылают в ответ типа ??? - вот это вот и сбивает целостность приходящих данных. Мы то вроде в ответ ничего не ждем, а тут на тебе, пришло :)

Ну, это плохо. Никаких таймеров не нужно вообще.
Работай с портом асинхронно. В ф-циях WaitFor задавай константы по времени чтения или записи.

> Alex_C   (11.02.11 14:47) [11]

а
>  некоторые присылают в ответ типа ??? -

Я так понимаю, что протокола для гарантированного выделения пакета нет? Есть просто поток данных от устройства. В этом случае мне кажется, что
после посылки команды установки надо делать небольшую паузу перед следующей посылкой датчику.  Пауза должна быть достаточной, что бы в случае ошибки датчик успел ответить "типа ???", ты принимаешь эти данные и  игнорируешь их.


> недопущение "склеенных" пакетов

 Как ты видишь, что пакет склеен? Сформулируй это и попробуй написать нужный код

> Неважно   (11.02.11 11:43) [6]
>
>
> > "Отдельный поток" - нафиг!
>
>
> Ага, щаз...
> А если работа с портом 24/7?


> Неважно   (11.02.11 15:53) [12]
>
> Ну, это плохо. Никаких таймеров не нужно вообще.
> Работай с портом асинхронно. В ф-циях WaitFor задавай константы
> по времени чтения или записи.
>

Как понять тебя, Саид?

Нормальная асинхронная работа с СОМ-портом заключается в том, что доппоток создается только для ожидания WaitCommEvents. И ни для чего более. Запись и чтение производится в основном потоке.

нормальная работа с железом заключается в точном понимании задачи, и процессов, возникающих при ее реализации (не только программных). Для чего просто читается документация. Работа же с СОМ-портом документирована полностью, примеры есть чуть ли не на все случаи жизни.

http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1126

рекомендую так же обратиться к книгам Павла Агурова.

> KilkennyCat ©   (12.02.11 04:18) [16]

Ты меня опередил.
Но я всё равно готов, дать TC эту книгу бесплатно. Если он захочет.

Удалено модератором