Пропуски данных при приёме по Com порту компонент CPort

← →
MegaVolt © (2007-03-17 15:51) [0]

Подскажите кто работал с этим компонентом как убрать пропуски данных?

Есть подозрение что проблема в неиспользовании буфера так как OnRxBuf вызывается с количеством данных в буфере 8 байт. Изредка 16.

Пробовал увеличивать приоритет мониторящего потока, пробовал менять метод синхронизации.

Обработчик OnRxBuf работает только с данными без обращения к VCL занимает очень мало времени (практически только контроль количества переданных байт)

Что можно сделать чтобы компонент работал нормально?

Как вариант как сделать так чтобы он принимал не по 8 байт а целыми буферами.

← →
S@shka © (2007-03-17 22:50) [1]

Вариант написать работу с Com-портом самому с помощью WinAPI
Поищи - неоднократно здесь тема поднималась/

+ http://delphimaster.ru/articles/comport2/index.html

← →
Германн © (2007-03-18 02:05) [2]

> S@shka © (17.03.07 22:50) [1]
>
> Вариант написать работу с Com-портом самому с помощью WinAPI
> Поищи - неоднократно здесь тема поднималась/

Поднималась, но грамотного решения ни разу не было.

> MegaVolt © (17.03.07 15:51)

Я не знаю этот конкретно компонент, но видел многие другие. Вообще в сабже очень мало конкретной информации. Что есть "пропуски информации"?
В целом у меня сложилось мнение, что ты неправильно понимаешь суть события OnRxBuf. Как правило, события OnRxXXXX всевозможных сомпонент, позволяют прочитать в прикладную программу из буфера СОМ-порта очередную порцию принятой им информации. Т.е. в прикладной программе следует создать свой буфер, в котором собирается набор байт полученных в событиях OnRxXXXX. А уж анализ того факта, что "принято всё или не всё" делать на основе данных в буфере самой программы.

← →
MegaVolt © (2007-03-19 10:47) [3]

>Вариант написать работу с Com-портом самому с помощью WinAPI

Для этого у меня не хватет знаний принципов внутренней организации СОМ порта :( (Как работает сама микруха представляю прекрасно)

>Вообще в сабже очень мало конкретной информации.
Спроси что нужно уточнить?

>Что есть "пропуски информации"?
Пропуски означают что если во время приёма пол мегабайта информации начать активно юзать комп то доходит не вся информация. В часности например запуск просмотра видео. Если же не трогать комп то данные доезжают все без проблем.

Где то в инете втретил мысль про то что приоритет у веника выше чем у ком порта и поэтому так и происходит. Может ли кто то это подтвердить? Вариантом борьбы с этим была предложено отключать в биосе пакетное чтение с веника. Но как то мне этот вариант не близок :(

← →
S@shka © (2007-03-19 11:13) [4]

> Поднималась, но грамотного решения ни разу не было.

Интересно это что значит?

А граматное решение работы с работы с текстовыми файлами было?

Нет смысла работать с CPort - все элементарно пишется на API.
(Уж тем более если возникают проблемы - в виде как считает аффтар неадекватности его работы)

http://delphimaster.net/view/6-1173167422/

← →
Evgeny V © (2007-03-19 11:23) [5]

> MegaVolt © (17.03.07 15:51)

Библиотека хорошая, в свое время использовал, правда давно очень...
При сильной загрузке компа, высокой скорости передачи возможна потеря данных. Используй аппаратный контроль за потоком данных, если у тебя это не используется... в этом случае потерь не будет. Принимать целым буфером.... это ты сам должен отслеживать и собирать в пакеты (хотя насколько помнится в библиотеки был компанент уже делающий это, обеспечивающий пакетную передачу и прием данных типа TComDataPacket)

← →
MegaVolt © (2007-03-19 12:05) [6]

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

Это понятно. Но линий всего две Tx и Rx так что исспользование CTS RTS отпадает. Поток непрерывный.

>Нет смысла работать с CPort - все элементарно пишется на API.

Если я не могу нормально запустить отлаженный компонент со всеми исходниками что изменится если я напишу сам этот компонент?

← →
S@shka © (2007-03-19 12:14) [7]

Цитирую [1]

> Что можно сделать чтобы компонент работал нормально?

> Если я не могу нормально запустить отлаженный компонент

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

-- Поgробуй приоретет поднять у своего приложения (потока CPort) до tpHigher

← →
MegaVolt © (2007-03-19 12:21) [8]

>Вот в том то и дело, что сказать со 100% уверенности об отлаженности работы компонента написанного не тобой к сож. нельзя.

Согласен. Но вроде там всё прозрачно. Если бы мне хватило уровня написать своё то и там бы я нашел ошибку. Опять же проблема не в его работе а в его работе при загрузке машины другими задачами.

>Поgробуй приоретет поднять у своего приложения (потока CPort) до tpHigher

Сделано. Польза есть но всё равно есть пропуски.

← →
Evgeny V © (2007-03-19 12:33) [9]

> MegaVolt © (19.03.07 12:21) [8]

Приоритеты не панацея. Если не можешь использовать аппаратный или программный контроль потоком данных, то надо вынести задачу приема и обработки данных на отдельное устройство с приличным буфером, которое только этим и будет заниматься - прием и обработка потока данных и выдача результатов на компьютер пользователя. Там и выдачу результата ты уже можешь реализовать, используя контроль потоков. В качестве отдельного устройства можно использовать и устройство на основе PIC или других однокристалок или микроконтроллеров, или одноплатные компьютеры, бисквит PC.... не так важно. Важно иметь независимое буферное устройство, которое успевало бы принимать и обрабатывать данные.
PS: Кстати библиотека CPort на самом деле весьма качественная, в свое время смотрел исходные коды, многое для себя подглядел...

← →
MegaVolt © (2007-03-19 13:28) [10]

>Важно иметь независимое буферное устройство, которое успевало бы принимать и обрабатывать данные.

Это понятно. Связь итак идёт от однокристалки. Ставить ещё одну для буферизации изврат :) Проще протокол наваять с подтверждениями.

Хотя я думал что винда вполне с этим может справится :( Тем более что исспользуя SetupComm можно выставить порту размер буфера. Я так понимаю это как раз и есть буфер уровня драйвера. Или я ошибаюсь?

← →
Evgeny V © (2007-03-19 14:02) [11]

> MegaVolt © (19.03.07 13:28) [10]

Если своя однокристалка, то делайте аппаратный или програмный контроль управлением потока, тогда проблемы должны уйти. Про буфе и драйвер - да... Но такой параметр есть у тебя в TComPort, так что мучать SetupComm, если ты работаешь чеоез компонент нет смысла

← →
orinoko (2007-03-19 14:19) [12]

я одно время использовал CPort. В общем он неплох и очень быстро работает. НО... сабж является одним из минусов. У него проблема в том что это проявляется когда в буфере накапливается больше примерно 400 байт, что при большой загрузке компа вполне реально. Не лечится. Можно попробовать уменьшить количество разрешённых Events (оставить только evRxChar и evRxFlag) и изменить SyncMethod на smWindowSync. Возможно этого хватит. Если нет - использовать другой компонент. Что я и сделал в последствии.
И вернулся на старый проверенный компонент TCommPortDriver (by Marco Cocco).

>Про буфе и драйвер - да...
Если я прав то почеу мне данные приходят размером по 8 байтиков? Или буфер исспользуется только тогда когда я данные не могу забрать?

>Но такой параметр есть у тебя в TComPort, так что мучать SetupComm, если ты работаешь чеоез компонент нет смысла
Само собой :) Я просто в исходниках глянул что они используют.

В каких случаях я могу терять данные?
Я вижу пока несколько:
1. Драйвер не успевает складывать данные в собственный програмный буфер. (Как это проверить я не знаю)
2. Прога не успевает обрабатывать данные до переполнение буфера.
(вроде тогда должен быть флаг ошибки а его нет)
3. Ещё что то?

>У него проблема в том что это проявляется когда в буфере накапливается больше примерно 400 байт, что при большой загрузке компа вполне реально. Не лечится.

Странно а что же в нём такого особенного чем он отличается от других?

>изменить SyncMethod на smWindowSync

Я сейчас работаю с SyncMethod:=smNone т.е. принимаю данные в процедуре относящейся к самому мониторящему потоку. По наблюдениям это даёт самый минимальный уровень потерь.

> MegaVolt © (19.03.07 14:22) [13]

Терять данные можно по разным причинам, наиболее вероятная мне кажется причина 1- UART выставил прерывание, что есть в буфере UART символ(ы) (буфер самого UART-a, а он небольшй, дай бог памяти 8 или 16, но могу соврать... в любом случае небольшой), но кмопьютер будучи сильно занят неуспел обработать прерывание и считать символы из буфера, а пришли новые.... при этом возникает ошибка, прием прекращается до обработки ошибки, данные теряются... А проверить - надо отслеживать и анализировать ошибки возникшие на порту.
Вариант два возможен, когда большие скорости передачи, комп нагружен нууу очччень сильно а буфер мал, а посылки данных большие, постоянно идет информация... и ты сильно много времени висишь в обработчике буфера, тормозя тем самым начало нового цикла чтения.... Но тоже как вариант возможно... наверное. Опять таки отслеживать и анализировать ошибки порта... Получишь ответ в виде кода ошибки.

>наиболее вероятная мне кажется причина: буфер самого UART-a, небольшй а компьютер будучи сильно занят неуспел обработать прерывание и считать символы из буфера, а пришли новые....
Ага Я так и думаю. Но получается что проблема в драйвере Com порта и решить эту проблему програмно неполучится. Кроме как организации квитирования програмного или аппаратного.

Ошибки попробую ловить :) Только найду нульмодемный кабель.

Пропуски данных при приёме по Com порту компонент CPort Найти похожие ветки