Прием символов по СОМ

← →
COMMODORE-128 (2012-07-01 02:09) [0]

Привет всем! Как правильно организовать прием символов по СОМу.
Открываю порт и засылаю по одному символу (WriteFile) сколько угодно символов(), на конце в любой момент может прийдти ответ (тоже один символ). Вопрос как его поймать? или после каждой отправки символа вызывать ReadFile и смотреть, если количество принятых символов=0, то ничего не получили? Хотелось бы простоту как в WM_MESSAGE ставим хук,
и если передало - то читаем меняем глобальные переменные итд...

← →
Германн © (2012-07-01 02:32) [1]

Вот тебе пока что сюда http://delphimaster.net/view/4-1336987124/

← →
Дмитрий С © (2012-07-01 04:35) [2]

Читай в отдельном потоке.

← →
COMMODORE-128 (2012-07-01 11:19) [3]

спасибо!

← →
COMMODORE-128 (2012-07-01 13:25) [4]

пока не очень получается
с ассинхронной
видимо на конце тоже должно быть открыт порт как ассинхронный

← →
MBo © (2012-07-01 14:20) [5]

>открыт порт как ассинхронный
такого понятия нет. Синхронным или асинхронным может быть способ приёма.

Используй TComPort Dejan Crnila http://sourceforge.net/projects/comport/files/

← →
COMMODORE-128 (2012-07-01 23:12) [6]

неохота компоненты использовать...
решилось - сделал протокол железный
прием и отправка байта на устройстве
в проге - отсылка и прием байта (WriteFile+ReadFile)
пока тестовом методе работает четко

← →
Дмитрий С © (2012-07-02 00:12) [7]

А если устройство отвалится, прога твоя зависнет чтоли?)

← →
COMMODORE-128 (2012-07-02 01:07) [8]

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

← →
Германн © (2012-07-02 01:11) [9]

> Дмитрий С © (02.07.12 00:12) [7]
>
> А если устройство отвалится, прога твоя зависнет чтоли?

Если грамотно выставить таймауты не зависнет. А вот то, что будет "замораживаться" интерфейс программы при достаточно частом общении с железякой - это факт! А перенос работы с СОМ-портом в отдельный поток запросто может привести к очень неприятным глюкам.

← →
Дмитрий С © (2012-07-02 01:53) [10]

> А перенос работы с СОМ-портом в отдельный поток запросто
> может привести к очень неприятным глюкам.

А точнее?

← →
COMMODORE-128 (2012-07-02 01:54) [11]

application.ProcessMessages;
не поможет?
скорость будет ориентировочно, 1-100 символов в секунду,
и соотвественно обратных (ответов)

← →
Германн © (2012-07-02 02:06) [12]

> application.ProcessMessages;
> не поможет?

А чему он должен помочь?

← →
Германн © (2012-07-02 02:13) [13]

> Дмитрий С © (02.07.12 01:53) [10]
>
>
> > А перенос работы с СОМ-портом в отдельный поток запросто
> > может привести к очень неприятным глюкам.
>
> А точнее?

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

← →
Дмитрий С © (2012-07-02 03:17) [14]

> Германн © (02.07.12 02:13) [13]

try except на весь Execute а там передавай ошибку как тебе угодно. Видимо это личный опыт сказыватся?)

← →
COMMODORE-128 (2012-07-02 07:28) [15]

Германн
обновлению формы (Form1)

← →
tesseract © (2012-07-02 09:04) [16]

> Точнее сложно. Но у меня весьма стойкое предубеждение об
> исключениях в доппотоках.

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

← →
Вариант (2012-07-02 09:07) [17]

> COMMODORE-128 (01.07.12 13:25) [4]
> пока не очень получается
> с ассинхронной
> видимо на конце тоже должно быть открыт порт как ассинхронный
>

Расшифруй конец фразы - "видимо на конце тоже должно быть открыт порт как асинхронный"

← →
COMMODORE-128 (2012-07-02 12:24) [18]

устройство открывает порт как обычно,
а прога на делфи может как атрибуты ассинхронно FILE_FLAG_OVERLAPPED

← →
tesseract © (2012-07-02 12:34) [19]

> COMMODORE-128 (02.07.12 12:24) [18]
> устройство открывает порт как обычно,
> а прога на делфи может как атрибуты ассинхронно FILE_FLAG_OVERLAPPED

Это всё программная реализация. Скорее всего у тебя таймауты не выдерживаются.

← →
Вариант (2012-07-02 13:03) [20]

> COMMODORE-128 (02.07.12 12:24) [18]

И каким образом асинхронная работа с портом в твоей программе на дельфи связана с работой какого-то устройства на другом конце провода? Никаким. Как ты написал программу, так она и будет работать. Если ты открыл порт с
FILE_FLAG_OVERLAPPED, то соответственно и используешь OVERLAPPED структуру при вызовах ReadFile и WriteFile и других функций, которые требуют указатель на эту структуру. В этой структуре указывается Event, который будет взводится при завершении операции ввода вывода. Так же рекомендую почитать о WaitCommEvent. Хотя данная функция и не является обязательной, но довольно удобна. Организовать работу с портом можно как с использованием доп. потоков, так и без них и без зависания интерфейса, если используется асинхронный режим.

MBo © (01.07.12 14:20) [5] дал ссылку на компонент, который можно просто использовать для работы с портом, так и изучить его исходные тексты. Основа в CPort.pas

← →
VICTOR_ (2012-07-02 13:24) [21]

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

> COMMODORE-128 (02.07.12 01:54) [11]
>
> application.ProcessMessages;
> не поможет?

> COMMODORE-128 (02.07.12 07:28) [15]
>
> Германн
> обновлению формы (Form1)
>

Теоретически поможет. Примерно так как помогают костыли инвалиду. Ходить то он сможет, но...
ProcessMessages хорошо помогает тогда, когда можно наперёд рассчитать времена цикла. А как их наперёд рассчитать в случае, когда в цикле выполняется общение с внешним железом? В случае синхронного общения с железом по СОМ-порту придётся опытным путём подбирать таймауты. И не факт, что результат такого подбора будем всегда удачным.

> COMMODORE-128 (01.07.12 23:12) [6]
>
> неохота компоненты использовать

> MBo © (01.07.12 14:20) [5] дал ссылку на компонент, который
> можно просто использовать для работы с портом, так и изучить
> его исходные тексты.

Прислушайся к этому совету.
P.S. Я правда с этим компонентом мало знаком, но он вроде значительно проще, чем мой любимый TApdComPort.

> VICTOR_ (02.07.12 13:24) [21]

В книге Павла Агурова тоже самое описано гораздо лучше.
P.S.
Чем-то стиль этой статьи напомнил мне опусы Флёнова. Наверно тем, что слишком часто звучат утверждения типа "Не знаю почему, но именно так работает". :)

> В случае синхронного общения с железом по СОМ-порту придётся
> опытным путём подбирать таймауты.

В инструкции к девайсу можно посмотреть предельное время ожидания синхро/ответа.

← →
VICTOR_ (2012-07-03 10:51) [26]

>
> В книге Павла Агурова тоже самое описано гораздо лучше.
> P.S.
> Чем-то стиль этой статьи напомнил мне опусы Флёнова. Наверно
> тем, что слишком часто звучат утверждения типа "Не знаю
> почему, но именно так работает". :)

У меня на основе данного кода безперебойно работает ~ 5 различных по типу девайсов. Некоторые круглосуточно и годами. Правда нагрузка как правило периодическая и не очень высокая. Напр. считывание радиокарточки 1-2 раза в минуту.
Но тем не менее - "Не знаю почему, но именно так работает" :)
А за книжку спасибо - действительно там более капитально описаны базовые понятия

> tesseract © (03.07.12 10:01) [25]
>
>
> > В случае синхронного общения с железом по СОМ-порту придётся
> > опытным путём подбирать таймауты.
>
>
> В инструкции к девайсу можно посмотреть предельное время
> ожидания синхро/ответа.

Можно я не спорю. Но знаешь ли предельное время может быть довольно большим. Например стирание достаточно большой флеш-памяти займёт достаточно много времени, чтобы заморозить интерфейс.

← →
COMMODORE-128 (2012-07-06 16:30) [28]

инструкции к девайсу нету, так контроллер программирую сам,
там обрезанный сишный язык, проблем там нету.

Прием символов по СОМ Найти похожие ветки