Форум: "Система";
Текущий архив: 2003.11.13;
Скачать: [xml.tar.bz2];
ВнизFIFO event Найти похожие ветки
← →
Olexandr (2003-08-27 13:45) [0]Привет мастерам!
Использую Aysnc Pro
Но мне нужно отследить событие очистки АППАРАТНОГО исходящего буфера ФИФО. В компоненте естьтолько event очичтки буфера компонента, но это разые, понятно вещи.
По-этому приходится вставялть задержку - на всякий случай, чтоб ушло точно. Но поскольку скорость 1200 - получается потеря в скорости в пару раз.
Собственно вопрос - как отследить это событие, и можно ли использовать параллельно с компонентом АПИ функции (им нужен handleб который получается при handle := OpenFile(Com))??
thanks
← →
jack128 (2003-08-27 14:56) [1]cм WaitCommEvent и флаг EV_TXEMPTY
← →
Германн (2003-08-28 03:05) [2]2 jack128 © (27.08.03 14:56) [1]
Дык про это автор и говорит, имхо, что EV_TXEMPTY сигнализирует о пустоте буфера драйвера, но не о пустоте буфера FIFO микросхемы COM-порта.
← →
jack128 (2003-08-28 11:35) [3]
> Германн © (28.08.03 03:05) [2]
Тогда, имхо, нерезрешимая проблема..Покрайней мере я так и не смог ее решить..
← →
Reindeer Moss Eater (2003-08-28 12:17) [4]По-этому приходится вставялть задержку - на всякий случай, чтоб ушло точно.
А триггер на пустоту буфера на помогает разве?
← →
N169 (2003-08-28 12:21) [5]А задержку сделать после WaitCommEvent на (количество байт) * (Период следования бит, мс) * (Количество бит на байт передачи) ?
← →
wal (2003-08-28 12:26) [6]Можно попробовать установить аппаратное управление потоком, на разъеме соединить соответствующие выводы (DTR-DSR вроде), а в программе проверять DSR - 1 - идет передача, 0 - передача завершена.
ЗЫ. Все это только домыслы, на практике на проверялось.
С уважением.
← →
Reindeer Moss Eater (2003-08-28 12:42) [7]Там (APro) есть штатные средства определения наполненности буфера. И никаких проводов не надо.
← →
Olexander (2003-08-28 13:25) [8]2 jack128 © (28.08.03 11:35) [3]
> Германн © (28.08.03 03:05) [2]
> Тогда, имхо, нерезрешимая проблема..Покрайней мере я так и
> смог ее решить..
Есть похожее мнение, что, поскольку Windows - не система реального времени, то это невозможно программно.
-----------------
2 Reindeer Moss Eater © (28.08.03 12:17) [4]
> По-этому приходится вставялть задержку - на всякий случай, > чтоб ушло точно.
> А триггер на пустоту буфера на помогает разве?
Смотря какого буфера ?? Есть программный буфер компонента, есть буфер драйвера порта в винде, есть аппаратный буфер ФИФО - сверху вниз, освобождаются они последовательно, и, надо полагать, в разное время. Мне нужен последний. Вовпрос в том как узнать что ушел последний байт физически.
----------
2 N169 (28.08.03 12:21) [5]
> А задержку сделать после WaitCommEvent на (количество байт) *
> (Период следования бит, мс) * (Количество бит на байт
> передачи) ?
Это вариант - хотя опять же, речь о буфере драйвера...
С моего нынешнего уровня понимания проблемы...
---------
2 wal © (28.08.03 12:26) [6]
> Можно попробовать установить аппаратное управление потоком,
> на разъеме соединить соответствующие выводы (DTR-DSR вроде), > а в программе проверять DSR - 1 - идет передача, 0 - передача > завершена.
> ЗЫ. Все это только домыслы, на практике на проверялось.
> С уважением.
RTS-CTS!
Но они существуют, чтобы устанавливать и проверять их программно, а не спаивать :)
Установил RTS, подождал CTS (модем готов к передаче), послал,
опустил RTS, принимаешь - вроде так.
← →
wal (2003-08-28 13:35) [9]
> RTS-CTS!
> Но они существуют, чтобы устанавливать и проверять их программно,
> а не спаивать :)
> Установил RTS, подождал CTS (модем готов к передаче), послал,
> опустил RTS, принимаешь - вроде так.
А что мешает спаять? При передече RTS установился. CTS соответственно, тоже (они же спаяны). Когда передача завершена физически, RTS сбросился, ну и CTS, естественно, тоже. Отсюда алгоритм:
1. Передаем пакет.
2. Проверяем CTS.
3. Если CTS установлен, то п.2, иначе передача завершена.
С уважением.
← →
Olexander (2003-08-28 15:09) [10]> RTS-CTS!
> Но они существуют, чтобы устанавливать и проверять их программно,
> а не спаивать :)
> Установил RTS, подождал CTS (модем готов к передаче), послал,
> опустил RTS, принимаешь - вроде так.
> А что мешает спаять? При передече RTS установился. CTS
> соответственно, тоже (они же спаяны). Когда передача
> завершена физически, RTS сбросился, ну и CTS, естественно,
> тоже. Отсюда алгоритм:
> 1. Передаем пакет.
> 2. Проверяем CTS.
> 3. Если CTS установлен, то п.2, иначе передача завершена.
> С уважением.
В общем ничего, для решения проблемы подходит-
только дело в том что CTS для того и предназначен - чтобы показывать готовность модема к передаче, и устанавливать его должен модем, а не перемычка.
Ну вообщем, наверное так можно, но не правильно :)
---------
А вот кстати что говорит МСДН:
Table 1. Communications Event Flags
Event Flag Description
EV_TXEMPTY The last character in the output buffer was sent to the serial port device. If a hardware buffer is used, this flag only indicates that all data has been sent to the hardware. There is no way to detect when the hardware buffer is empty without talking directly to the hardware with a device driver.
Кто б еще объясни что это значит
"talking directly to the hardware with a device driver"
← →
wal (2003-08-28 15:41) [11]Нет способа определить, что аппаратный буфер пуст, если аппаратура не сообщает об этом драйверу (или драйвер не запрашивает аппаратуру).
← →
Германн (2003-08-29 03:23) [12]2 Olexander
Есть еще вариант. Для задач специфичных к окончанию передачи данных через COM-порт, можно выключить использование буфера FIFO микросхемы COM-порта.
← →
wal (2003-08-29 09:49) [13]2 Германн
Не поможет. Останется регистр передачи UARTа, передача начнется только после записи в него. Итого - поведение примерно такое же, как при наличии буфера, размером в 1 байт.
С уважением.
Страницы: 1 вся ветка
Форум: "Система";
Текущий архив: 2003.11.13;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.038 c