nesco писал(а):
я сам выложу проверочноую схему с побайтовым чтением бинарного потокаЭтот топик читают: Гость
Ответов: 8926
Рейтинг: 823
|
|||
Ой, как хочется посмотреть! |
|||
карма: 19 |
|
Разработчик
Ответов: 26155
Рейтинг: 2127
|
|||
Выкладываю пример передачи байтового потока длиной 22 символа через COM порт, содержащего внутри символы #00 и #13 с побайтовым приемом. Пример приследует цель показать возможность передачи через порт не служебных символов, и в нем не реализовано командное управление.
code_26131.txt |
|||
карма: 22 |
| ||
файлы: 1 | code_26131.txt [7.4KB] [228] | ||
Голосовали: | ser_davkin |
Ответов: 24
Рейтинг: 0
|
|||
Я возможно сейчас задам вопрос где всё всем понятно,но...вот не разобрался.Сом - порт.Уже получается и приём и передача(форумы почитал) но так и не понял что делает параметр TimeOut.На что и как он влияет.
С уважением... |
|||
карма: 1 |
|
Ответов: 3889
Рейтинг: 362
|
|||
andr_larr писал(а): что делает параметр TimeOutЧего он только не делает. Все возможные задержки и замеры времени при работе с портом инициализируются этим значением, так что, в некоторых случаях, лишний раз трогать его чревато. Измеряется он в миллисекундах и влияет как на скорость работы, так и на правильность определения окончания передачи пакетов. Например, если вы в реальном времени принимаете пакетные данные от медленного устройства и выставите небольшой TimeOut, то при doRead компонент рискует не дождаться очередного байта и завершить операцию чтения. На практике, с учётом буферизации и асинхронности современных ОС и устройств, таймауты можно не трогать. Железо может сильно отличаться и, скажем, на аппаратном порту с отключенными буферами таймаут даст совершенно другой результат по сравнению с виртуальным портом на USB или BlueTooth. |
|||
карма: 1 |
|
Ответов: 24
Рейтинг: 0
|
|||
Понял,спасибо.В общем "вещь в себе" которую лучше не трогать....Будем практиковаться...Как в поговорке
"Практика без теории ценнее, чем теория без практики." Квинтилиан С уважением... |
|||
карма: 1 |
|
Разработчик
Ответов: 26155
Рейтинг: 2127
|
|||
Тут надо еще учесть одну особенность -- при запросе N-го количества байт (до 255), минимальное время окончания чтения буфера будет определяться произведением запрошенных байт на время таймаута, даже, если в буфере будет всего один байт. Короче, чем больше будет запрошено байт на чтение, тем дольше будет время чтения пакета, вне зависимости от состояния буфера.
|
|||
карма: 22 |
|
Ответов: 24
Рейтинг: 0
|
|||
Я так понял что за время одной выборки по тайм-ауту считывается один байт,при следующей ещё один и так до окончания блока байт в буфере ?
Ещё один вопрос.А записывается байт в буфер приходу его на вход буфера или тоже по таймингу ? Хотя...Второй вариант без потери байтов как-то и представить не могу... С уважением... |
|||
карма: 1 |
|
Разработчик
Ответов: 26155
Рейтинг: 2127
|
|||
andr_larr писал(а): Я так понял что за время одной выборки по тайм-ауту считывается один байт,при следующей ещё один и так до окончания блока байт в буфере ?Нет, запрашивается сразу N-е количество, и функция ждет определенное время (я описал в предыдущем посте минимум сколько будет ждать, к этому времени еще можно прибавить таймаут ожидания следующего пакета), после чего отдает запрошенное число байт, если их меньше, то отдает все, что есть. После считывания, считанные байты из буфера удаляются. Если буфер пуст, то на выход будет попадать пустая строка, ее можно использовать для синхронизации данных приема. andr_larr писал(а): А записывается байт в буфер приходу его на вход буфера или тоже по таймингу ?Не понял вопроса, совершенно ------------ Дoбавленo в 16.17: Вот один из вариантов синхронизации чтения по пустой строке
|
|||
карма: 22 |
|
Ответов: 24
Рейтинг: 0
|
|||
Спасибо.Буду разбираться...Второй вопрос действительно не совсем корректен...
С уважением... |
|||
карма: 1 |
|
189