Отсчеты с шагом 1 мс

← →
SergeyG © (2008-02-05 11:16) [0]

Для тестирования программы нужно посылать в СОМ порт пакеты (32 байта) с периодом от 45 до 65 мс, шаг изменения периода 1 мс.
Пакеты посылаю через TMSA32. Период задаю и изменяю в Edit.
Timer здесь не подходит, т.к. его тик составляет 55 мс (приходится работать в W98). Пробовал после посылки делать задержку с помощью sleep, у которого параметром является значение в Edit. А также "замерять" время с помощью GetTickCount. В обоих случаях стабильный период (смотрю осциллографом) получается с шагом 5 мс, т.е. с периодом 45, 50, 55, 60 и т.д. мс. На промежуточных значениях - дергание.
Внутри цикла стоит Application.ProcessMessages - может он чего портит?

← →
хам (2008-02-05 11:18) [1]

> [0] SergeyG © (05.02.08 11:16)
> Timer здесь не подходит, т.к. его тик составляет 55 мс (приходится
> работать в W98).

Забудь об этом. В Windows, а тем более 98

← →
Рамиль © (2008-02-05 11:20) [2]

Возьми систему реального времени, не мучай себя и Windows.

Минимальный квант времени, если неошибаюсь 10-15мс. Даже если бы он был 1 мс, все равно неполучится.

DOS вполне подойдет.

← →
SergeyG © (2008-02-05 11:27) [3]

:((

А как ДОС причипить?

← →
хам (2008-02-05 11:31) [4]

> [3] SergeyG © (05.02.08 11:27)

Сетуп.эхе

← →
ketmar © (2008-02-05 12:52) [5]

+много. не издевайся над виндой. «купи себе хотя бы пистолет — и будешь человеком». в смысле — QNX, RTLinux, etc, etc. оси, где прописано, что они real-time.

можешь, конечно, извратнуться с запуском отдельного потока, которому дашь «realtime» приоритет в винде, а паузы делать через rdtsc, но это загрузит процессор по самое немогу, и всё равно ненадёжно.

← →
Sapersky (2008-02-05 16:58) [6]

Говорят (пишут), что через timeBeginPeriod можно установить квант 1 мс:
http://www.dtf.ru/articles/read.php?id=39888&page=2
(см. "Поверье четвертое").
Тоже, конечно, ненадёжно - но хотя бы процессор не будет грузиться по "не могу" (в отдельный поток можно добавить Sleep(1)).

← →
sniknik © (2008-02-05 17:15) [7]

> в отдельный поток можно добавить Sleep(1)
и этим добавить время гораздо больше чем указанная 1 мс. (даже Sleep(0) будет больше времени выполняться. проверь если хочеш.)

← →
Ins © (2008-02-05 17:23) [8]

> и этим добавить время гораздо больше чем указанная 1 мс.

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

> Так в этом и фишка timeBeginPeriod
я вообщето по "фишку" Sleep-а, засыпание процесса и отдание времени другим не делается за 1 мс. и неважно какой там таймер будет использоваться (имхо, ибо не проверял.)

> я вообщето по "фишку" Sleep-а

Ну да. И я о том же. После вызова timeBeginPeriod(1) планировщик получает управление не через каждые 10 мс, а через каждые 1 мс. Таким образом, можно уменьшить дискретность отсчета временных отрезков, Sleep, мультимедийные, ожидаемые и даже user-таймеры будут лучше выдерживать малые интервалы.

> я вообщето по "фишку" Sleep-а, засыпание процесса и отдание
> времени другим не делается за 1 мс.

Вполне. Даже быстрее. Там действий выполнить немного нужно, пометить поток как непланируемый, выбрать из очереди следующий поток и передать ему квант. Это недолго.

> Это недолго.

Смотря на каком компьютере:)

Отсчеты с шагом 1 мс Найти похожие ветки