Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Точность измерения временных интервалов для UART в windows

Страницы: 1 2 3 >
vertal © (2006-12-24 17:20:00)
По com-порту отправляю сообщение (WriteFile). Жду завершения его отправки через FlushFileBuffers. Пытаюсь принять ответ, состоящий из символов. Признаком конца сообщения-ответа служит отсутствие прибытия нового символа после предыдущего в течение более 4 милисекунд. Максимальная длина ответа - 256 символов. Осуществляется это все как:
PurgeComm(fPort, PURGE_RXCLEAR); OpResult = WriteFile(fPort, Msg, cnt, &Garbage, NULL); FlushFileBuffers(fPort); OpResult = ReadFile(fPort, OutBuf, 257, &ActualRead, NULL);
Для того, чтобы после 4 милисекунд отсутствия символов на линнии ReadFile вернула то, что было прочитано, предварительно вызываю SetCommTimeouts, со значением 4 в ReadIntervalTimeout. Проблема в том, что при таких условиях _иногда_ (через раз примерно) прием сообщения-ответа прекращался на середине. То есть я предполагаю, что это из-за неточности измерения таких промежутков времени windows или стандартными драйверами. После установки ReadIntervalTimeout в значение 16 (8 не помогло) сбои исчезли. Сталкивался ли кто-нибудь с подобным? Или что-то не так в приведенном коде?

tesseract (2007-01-05 19:51:00) [1]

> Да, слабо тянет, были в свое время по этому поводу большие
> споры, вроде бы ее отнесли к системам мягкого реального
> времени.

3-я вроде с натяжкой 4.2+ -уже полностью нет. Palm - другое дело, можно отнести.

RayGun (2007-01-05 19:25:00) [2]
> tesseract © (05.01.07 19:13) [39]

> Windows CE

> На RTOS слабо тянет.

Да, слабо тянет, были в свое время по этому поводу большие споры, вроде бы ее отнесли к системам мягкого реального времени.

tesseract (2007-01-05 19:13:00) [3]

> Windows CE

На RTOS слабо тянет.

RayGun (2007-01-05 19:11:00) [4]
Есть вроде бы неплохая REAL TIME OS жесткого реального времени, которая в определенной степени поддерживает WinAPI - называется RTOS-32, под нее некоторые люди даже на Delphi пишут, в силу личных симпатий и предпочтений. Но стОит денег, для утилит настройки/конфигурирования/тестирования не годится, больше подходит в качестве альтернативы Windows XX Embedded, QNX, Windows CE для АСУшных задач, а также для любых других серьезных задач, где требуется жесткий real-time.

tesseract (2007-01-05 15:51:00) [5]

> как минимум нужна Windows XX Embeded,

Да это та же винда, только тебе дают лицензию, что ты лично можешь порезать как захочешь. Типа nanoBSD. И вроде своп по умолчанию вырублен.

ЗЫ: Ну почему я все приглашения на семинары МS embedded выкидывал в урну?

Anatoly Podgoretsky (2007-01-05 13:37:00) [6]
> RayGun (05.01.2007 10:12:35) [35]

Вообще то REAL TIME OS, но они разные эти REAL TIME OS бывают. Для данной задачи данная вариант не подходит, как минимум нужна Windows XX Embeded, а лучше ДОС, более жесткой системы реального времени нет.

RayGun (2007-01-05 10:12:00) [7]
> Anatoly Podgoretsky © (05.01.07 10:08) [33]

> О какой ошибки ты говоришь?

Видимо, о том, что Windows не REAL TIME OS

RayGun (2007-01-05 10:10:00) [8]
> Германн © (05.01.07 01:55) [32]

> Кстати, имхо, "идиотский" протокол этот ModBus. Хорошо, что мы о нём не
> слыхали, когда разрабатывали свои первые устройства. Нормальная работа по
> такому протоколу возможна только в рамках, которые привёл АП в [17].

Да, Ваше мнение склонны разделять практически все, кто имел удовольствие работать с этим "замечательным" протоколом под Windows и Linux. К сожалению, это стандарт, и многие девайсы его используют.

Anatoly Podgoretsky (2007-01-05 10:08:00) [9]
vertal © (05.01.07 00:01) [30]
О какой ошибки ты говоришь?

Германн (2007-01-05 01:55:00) [10]

> Хоть кто-то меня слушает. Протокол жестко задан. Линия связи
> в ModBus - всего два провода, перед компьютером стоит конвертер
> RS-485<->RS-232, CTS и RTS не используются.

Да не внимательно читал, увы. Кстати, имхо, "идиотский" протокол этот ModBus. Хорошо, что мы о нём не слыхали, когда разрабатывали свои первые устройства. Нормальная работа по такому протоколу возможна только в рамках, которые привёл АП в [17].

kaZaNoVa (2007-01-05 00:06:00) [11]
Удалено модератором
Примечание: Offtopic

vertal (2007-01-05 00:01:00) [12]

> С (03.01.07 21:19) [19]

Пробовал, ни на что значение ReadTotalTimeoutConstant не влияет, дело не в ней.
Не понял???Проверка работоспособности, имхо, обязанность ОТК производителя!
Понятно, что все модули после изготовления (если еще дойдет до серийного производства) будут проверяться. А с помощью этой утилитки можно будет проверить модуль в любой момент, сконфигурировать его через удобный интерфейс, и просто наглядно увидеть выполняемые им функции и возможные настройки. Подобную утилитку распространяет Advantech для своих промышленных контроллеров ADAM-4000-5000.
RayGun © (04.01.07 16:03) [29]
Хоть кто-то меня слушает. Протокол жестко задан. Линия связи в ModBus - всего два провода, перед компьютером стоит конвертер RS-485<->RS-232, CTS и RTS не используются.

Остановлюсь действительно на варианте с увеличенным таймаутом. Специально привел в вопросе фрагмент кода - но с самим кодом видимо действительно все в порядке, раз до сих пор никто в нем не увидел ошибок. Для меня несколько неожиданно было обнаружить такую я бы сказал недоработку в Windows.

RayGun (2007-01-04 16:03:00) [13]
> tesseract © (04.01.07 09:22) [26]

> А почему бы CTS/RTS не использовать? Стандартный механизм RS232C?

> Обычно для контроля хватает и просто посылки, длину из знакомых устройств
> никто не посылал. И время ожидания не -4 мс, а 200 мс. Окончание посылки
> можно и байтом посылать, и CRC для точночти добавить.

CRC16 является частью протокола ModBus RTU, используемого автором темы.
По стандарту передача ведется в полудуплексном режиме, в случае RS-485 это два-три провода (DATA+, DATA- и IGND по желанию), в случае RS-232 - три провода (Rx, Tx, GND).
Как уже говорил автор, протокол переделывать нельзя.
Остается вопрос - либо превращать Windows в некоторое подобие REAL TIME OS (такое в общем-то возможно, если переписать нужную часть HAL:), либо иметь гемор с потоками TimeCritical и "высокоточными" средствами измерения времени, либо просто увеличить таймаут, как в основном делают АСУшники:)

Что касается вопроса автора темы, уважаемого vertal © "Просто хочется понять причину такого поведения системы", так на этот вопрос уже ответили уважаемые С (02.01.07 15:46) [7] и Anatoly Podgoretsky © (03.01.07 15:34) [17]

tesseract (2007-01-04 15:07:00) [14]

> Так это лишние провода :(

Зато надёжно!.

Германн (2007-01-04 14:08:00) [15]

> А почему бы CTS/RTS не использовать? Стандартный механизм
> RS232C?
Так это лишние провода :(
>
> Обычно для контроля хватает и просто посылки, длину из знакомых
> устройств никто не посылал. И время ожидания не -4 мс, а
> 200 мс. Окончание посылки можно и байтом посылать, и CRC
> для точночти добавить.

200 мс во многих случаях слишком большой и неоправданный простой. Спецбайт как окончание посылки не годится, если в посылке могут быть байты с любым значением. Ну а CRC - это просто хороший тон, но к сабжу не относящийся.

tesseract (2007-01-04 09:22:00) [16]

> Может тогда сменить идеологию? И сделать так, как делают
> многие. В первом байте ответа посылать длину вышеназванного.
> И при приёме её контролировать?

А почему бы CTS/RTS не использовать? Стандартный механизм RS232C?

Обычно для контроля хватает и просто посылки, длину из знакомых устройств никто не посылал. И время ожидания не -4 мс, а 200 мс. Окончание посылки можно и байтом посылать, и CRC для точночти добавить.

Германн (2007-01-04 01:22:00) [17]

> vertal © (03.01.07 19:57) [18]
>
>
> > Германн © (03.01.07 02:40) [9]
> > Готов обсудить! Гарантирую, моё буферное устройство, твои
> > запросы полностью удовлетворит!
>
> Да я верю. Мы и сами можем такое сделать. Вопрос в целесообразности.
> Эта программа для PC, которую я сейчас пишу, будет тестовой
> программой, позволяющей проверять работоспособность наших
> контроллеров. Поставлять вместе с ней еще какое-то дополнительное
> устройство - будет слишком жирно.

Не понял???
Проверка работоспособности, имхо, обязанность ОТК производителя!

> Признаком конца сообщения-ответа служит отсутствие прибытия
> нового символа после предыдущего в течение более 4 милисекунд.
> Максимальная длина ответа - 256 символов.

Может тогда сменить идеологию? И сделать так, как делают многие. В первом байте ответа посылать длину вышеназванного. И при приёме её контролировать?

tesseract (2007-01-03 21:39:00) [18]

> шутка? в винде у мну всегда работало)

Зависит от загрузки проца. В нормальных микроядерных/RTOS нет такого параметра.

Только драйвер имеет право захряпать под себя нужные ресурсы, и то он ограничен очередью IRP.

kaZaNoVa (2007-01-03 21:36:00) [19]
tesseract © (03.01.07 21:34) [22]
Выставь любому процессу TIME_CRITICAL и получи BSOD!!!!
шутка? в винде у мну всегда работало)

про линукс не знаю

tesseract (2007-01-03 21:34:00) [20]

> kaZaNoVa © (03.01.07 21:32) [21]

Соломон тебя прибьёт.

Новогоднее предложение !!!!! Выставь любому процессу TIME_CRITICAL и получи BSOD!!!!

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »