информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Атака на InternetSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[Win32] Подробнее 30.09.03 19:30  Число просмотров: 1326
Автор: vh <Дмитрий> Статус: Member
Отредактировано 30.09.03 19:30  Количество правок: 1
<"чистая" ссылка>
Контроль потока отключен, ибо устройство его не поддерживает.
Для справки: микроконтроллер MSP430F149
В нем реализован UART. Он умеет контроллировать четность, бит (адрес/данные), детектить ошибки, ну и еще несколько фич. Имеет буферный регистр на один байт.
Но про контроль потока (типа Xon Xoff) я ничего там не видел. Скорей всего этого там нет.

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


Далее: компьютер - MH, микроконтроллер - MSP

Алгоритм такой:
1. MH посылает спец. байт в MSP (который остается сидеть в буфере микроконтроллерского UARTa) и ждет ответа (100 мск).
2. MSP как освободится, принимает из буфера этот байт, видит что это спец. байт и посылает ответ - подтверждение об установленной сессии, далее ждет пакета от MH (100 мск).
3. MH посылает заголовок и данные, далее ждет пакета о подтверждении выполнения (100 мск)
4. MSP принимает пакет, выполняет некое действие (команду, которая содержалась в пакете) и посылает пакет с подтверждением выполнения.

проблема возникает сразу на первом шаге.
MSP видет спец. байт и даже отвечает на него (видел в отладчике).
Но MH почему то выходит из функции чтения, так ничего и не прочитав. Такое ощущение, что он вовсе не ждет поступления символа, а просто сразу же выходит не найдя ничего в буфере.
Стоит поставить Sleep перед функцией чтения, все работает.

Если нужно еще подробнее, плз, укажи где.
<programming>
[Win32] COM-port и таймауты 30.09.03 17:44  
Автор: vh <Дмитрий> Статус: Member
Отредактировано 30.09.03 17:55  Количество правок: 2
<"чистая" ссылка>
Всем привет!

Проблема такая:
Использую компорт для общения со своим устройством (реального времени). Программирую из под Windows.
Использую WinApi, причем вроде правильно, все делаю как описано здесь
http://morgeyz.narod.ru/comlpt.htm

Проблема возникает с таймаутами.
Устанавливаю таймаут при каждой попытке чтения N-ого кол-ва символов.

Использую стандартную вещь, для их установки:

COMMTIMEOUTS CommTimeOuts;
CommTimeOuts.ReadIntervalTimeout = 0;
CommTimeOuts.ReadTotalTimeoutMultiplier = 0;
CommTimeOuts.ReadTotalTimeoutConstant = elapse;
CommTimeOuts.WriteTotalTimeoutMultiplier = 0;
CommTimeOuts.WriteTotalTimeoutConstant = 5000;
SetCommTimeouts( m_hIDComDev, &CommTimeOuts );

где m_hIDComDev - хэндл порта



Если я правильно понял таймауты, но при такой расстановке, она должна ждать кол-во запрошенных символом в течении промежутка времени равного elapse.
Но. судя по всему такого не происходит, ибо не работает. А когда я перед чтением делаю чтото вроде: Sleep( 100 ) все работает на ура. Только не нравится мне это. Хочу разобраться. Это важно, так как проект очень серьезный.

спасибо.


p.s. DCB настраиваю вот так

dcb.DCBlength = sizeof( DCB );
GetCommState( m_hIDComDev, &dcb );
dcb.BaudRate = nBaud;
dcb.ByteSize = 8;
dcb.fBinary = 1;
dcb.fParity = 0;
dcb.fOutxCtsFlow = 0;
dcb.fOutxDsrFlow = 0;
dcb.fDtrControl = DTR_CONTROL_DISABLE;
dcb.fDsrSensitivity = false;
dcb.fTXContinueOnXoff = 1;
dcb.fOutX = 0;
dcb.fInX = 0;
dcb.fNull = 0;
dcb.fRtsControl = RTS_CONTROL_DISABLE;
dcb.fAbortOnError = 0;
dcb.wReserved = 0;
dcb.StopBits = ONESTOPBIT;
[Win32] COM-port и таймауты 30.09.03 19:25  
Автор: leo <Леонид Юрьев> Статус: Elderman
<"чистая" ссылка>
Во-первых, всегда нужно помнить, что в NT/W2K/XP/W2K3 все таймеры работают по тикам системного времени, по умолчанию примерно 10 ms. Другими словами, любой таймер сработает только по первому системному тику, после того как истечет установленный период времени.
Кардинально пока это лечиться только установкой realtime надстройкой ядра.
Интервал системных тиков можно менять с помощью timeBeginPeriod (см. PlatformSDK), но следует помнить, что при каждом системном тике производиться scheduling всех активных задач и проверка всех таймеров на expire.

Во-вторых, советую взять нормальный драйвер (http://leo.yuriev.ru/SerialXP/) вместо serial.sys
[Win32] Поясни пожалуйста фразу 30.09.03 19:33  
Автор: vh <Дмитрий> Статус: Member
<"чистая" ссылка>
> Во-первых, всегда нужно помнить, что в NT/W2K/XP/W2K3 все
> таймеры работают по тикам системного времени, по умолчанию
> примерно 10 ms. Другими словами, любой таймер сработает
> только по первому системному тику, после того как истечет
> установленный период времени.

Не совсем понял. Чем это конкретно грозит?
[Win32] Что именно не работает? 30.09.03 19:11  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Если я правильно понял таймауты, но при такой расстановке,
> она должна ждать кол-во запрошенных символом в течении
> промежутка времени равного elapse.
> Но. судя по всему такого не происходит, ибо не работает. А
Он не ждет или данные теряются? Вообще слишком большой TotalTimeout - это не есть хорошо. В конце концов можно просто собирать данные пока не наберется сколько надо.

> когда я перед чтением делаю чтото вроде: Sleep( 100 ) все
> работает на ура. Только не нравится мне это. Хочу
> разобраться. Это важно, так как проект очень серьезный.
Если же теряются данные, то проблема в отключенном (а он у тебя отключен, если верить твоему DCB) контроле потока (flow control). Попробуй включить и будет счастье.

А вообще нужно бы более подробное описание проблемы. В частности, что делается (кто передает и сколько, кто принимает и как) и что не работает (потери данных, задержки, лишние данные и пр.)
[Win32] Подробнее 30.09.03 19:30  
Автор: vh <Дмитрий> Статус: Member
Отредактировано 30.09.03 19:30  Количество правок: 1
<"чистая" ссылка>
Контроль потока отключен, ибо устройство его не поддерживает.
Для справки: микроконтроллер MSP430F149
В нем реализован UART. Он умеет контроллировать четность, бит (адрес/данные), детектить ошибки, ну и еще несколько фич. Имеет буферный регистр на один байт.
Но про контроль потока (типа Xon Xoff) я ничего там не видел. Скорей всего этого там нет.

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


Далее: компьютер - MH, микроконтроллер - MSP

Алгоритм такой:
1. MH посылает спец. байт в MSP (который остается сидеть в буфере микроконтроллерского UARTa) и ждет ответа (100 мск).
2. MSP как освободится, принимает из буфера этот байт, видит что это спец. байт и посылает ответ - подтверждение об установленной сессии, далее ждет пакета от MH (100 мск).
3. MH посылает заголовок и данные, далее ждет пакета о подтверждении выполнения (100 мск)
4. MSP принимает пакет, выполняет некое действие (команду, которая содержалась в пакете) и посылает пакет с подтверждением выполнения.

проблема возникает сразу на первом шаге.
MSP видет спец. байт и даже отвечает на него (видел в отладчике).
Но MH почему то выходит из функции чтения, так ничего и не прочитав. Такое ощущение, что он вовсе не ждет поступления символа, а просто сразу же выходит не найдя ничего в буфере.
Стоит поставить Sleep перед функцией чтения, все работает.

Если нужно еще подробнее, плз, укажи где.
[Win32] Подробнее 30.09.03 20:10  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> проблема возникает сразу на первом шаге.
> MSP видет спец. байт и даже отвечает на него (видел в
> отладчике).
> Но MH почему то выходит из функции чтения, так ничего и не
> прочитав. Такое ощущение, что он вовсе не ждет поступления
Можно попробовать SetCommMask(hFile, EV_RXCHAR) и подождать WaitCommEvent. Когда придет event - можно забирать символы.

> символа, а просто сразу же выходит не найдя ничего в
> буфере.
> Стоит поставить Sleep перед функцией чтения, все работает.
>
> Если нужно еще подробнее, плз, укажи где.

ЗЫ: И еще, вспомнил. ReadIntervalTimeout нужно ставить в MAX_DWORD, а не в 0 для выключения интервального таймаута. Хотя с ожиданием событий все равно правильнее.
[Win32] Использование событий... 30.09.03 20:39  
Автор: vh <Дмитрий> Статус: Member
<"чистая" ссылка>
> > проблема возникает сразу на первом шаге.
> > MSP видет спец. байт и даже отвечает на него (видел в
> > отладчике).
> > Но MH почему то выходит из функции чтения, так ничего
> и не
> > прочитав. Такое ощущение, что он вовсе не ждет
> поступления
> Можно попробовать SetCommMask(hFile, EV_RXCHAR) и подождать
> WaitCommEvent. Когда придет event - можно забирать символы.
>
> > символа, а просто сразу же выходит не найдя ничего в
> > буфере.
> > Стоит поставить Sleep перед функцией чтения, все
> работает.
> >
> > Если нужно еще подробнее, плз, укажи где.
>
> ЗЫ: И еще, вспомнил. ReadIntervalTimeout нужно ставить в
> MAX_DWORD, а не в 0 для выключения интервального таймаута.
> Хотя с ожиданием событий все равно правильнее.

Изменил на MAXDWORD, ничего не изменилось.

А как ты предлагаешь организовать ожидание событий?
WaitCommEvent - он же не выходит как я понимаю по таймауту.
[Win32] Многопоточность 01.10.03 15:18  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Изменил на MAXDWORD, ничего не изменилось.
>
> А как ты предлагаешь организовать ожидание событий?
> WaitCommEvent - он же не выходит как я понимаю по таймауту.
Если нужно выполнять какую-то работу во время ожидания, то можно ждать событий в другом потоке.

Убить поток, когда пройдет время конечно можно, но я не совсем понимаю зачем. Если открывать порт в OVERLAPPED режиме, то никто не мешает продолжать слать данные в порт, когда ждешь из него событий. Так что обработчик можно и не снимать до самого завершения программы (или работы с портом).
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach