![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Отсчеты с шагом 1 мс
SergeyG © (2008-02-05 11:16:00)Для тестирования программы нужно посылать в СОМ порт пакеты (32 байта) с периодом от 45 до 65 мс, шаг изменения периода 1 мс.
Пакеты посылаю через TMSA32. Период задаю и изменяю в Edit.
Timer здесь не подходит, т.к. его тик составляет 55 мс (приходится работать в W98). Пробовал после посылки делать задержку с помощью sleep, у которого параметром является значение в Edit. А также "замерять" время с помощью GetTickCount. В обоих случаях стабильный период (смотрю осциллографом) получается с шагом 5 мс, т.е. с периодом 45, 50, 55, 60 и т.д. мс. На промежуточных значениях - дергание.
Внутри цикла стоит Application.ProcessMessages - может он чего портит?
Рамиль (2008-02-05 17:44:00) [1]
> Это недолго.
Смотря на каком компьютере:)
Ins (2008-02-05 17:36:00) [2]
> я вообщето по "фишку" Sleep-а, засыпание процесса и отдание
> времени другим не делается за 1 мс.
Вполне. Даже быстрее. Там действий выполнить немного нужно, пометить поток как непланируемый, выбрать из очереди следующий поток и передать ему квант. Это недолго.
Ins (2008-02-05 17:33:00) [3]
> я вообщето по "фишку" Sleep-а
Ну да. И я о том же. После вызова timeBeginPeriod(1) планировщик получает управление не через каждые 10 мс, а через каждые 1 мс. Таким образом, можно уменьшить дискретность отсчета временных отрезков, Sleep, мультимедийные, ожидаемые и даже user-таймеры будут лучше выдерживать малые интервалы.
sniknik (2008-02-05 17:30:00) [4]> Так в этом и фишка timeBeginPeriod
я вообщето по "фишку" Sleep-а, засыпание процесса и отдание времени другим не делается за 1 мс. и неважно какой там таймер будет использоваться (имхо, ибо не проверял.)
Ins (2008-02-05 17:23:00) [5]
> и этим добавить время гораздо больше чем указанная 1 мс.
Так в этом и фишка timeBeginPeriod. Она изменяет тик системного таймера, тем самым влияя на то, через какие промежутки времени управление получает планировщик потоков. Нормальные для NT 10 мс можно уменьшить до 1 мс. Побочный эффект - влияет на величину кванта, выделяемую потокам. Но только работает это как-то нестабильно, на некоторых системах мне с ее помощью удавалось user-таймер заставить держать если не 1, то 2 мс стабильно (при небольшой нагрузке на процессор), а на некоторых - не удавалось. В чем тут дело - глубоко не копал. Но мультимедийные таймеры вроде 1 мс держат хорошо.
sniknik (2008-02-05 17:15:00) [6]> в отдельный поток можно добавить Sleep(1)
и этим добавить время гораздо больше чем указанная 1 мс. (даже Sleep(0) будет больше времени выполняться. проверь если хочеш.)
Sapersky (2008-02-05 16:58:00) [7]Говорят (пишут), что через timeBeginPeriod можно установить квант 1 мс:
http://www.dtf.ru/articles/read.php?id=39888&page=2
(см. "Поверье четвертое").
Тоже, конечно, ненадёжно - но хотя бы процессор не будет грузиться по "не могу" (в отдельный поток можно добавить Sleep(1)).
ketmar (2008-02-05 12:52:00) [8]+много. не издевайся над виндой. «купи себе хотя бы пистолет — и будешь человеком». в смысле — QNX, RTLinux, etc, etc. оси, где прописано, что они real-time.
можешь, конечно, извратнуться с запуском отдельного потока, которому дашь «realtime» приоритет в винде, а паузы делать через rdtsc, но это загрузит процессор по самое немогу, и всё равно ненадёжно.
хам (2008-02-05 11:31:00) [9]> [3] SergeyG © (05.02.08 11:27)
Сетуп.эхе
SergeyG (2008-02-05 11:27:00) [10]:((
А как ДОС причипить?
Рамиль (2008-02-05 11:20:00) [11]Возьми систему реального времени, не мучай себя и Windows.
Минимальный квант времени, если неошибаюсь 10-15мс. Даже если бы он был 1 мс, все равно неполучится.
DOS вполне подойдет.
хам (2008-02-05 11:18:00) [12]> [0] SergeyG © (05.02.08 11:16)
> Timer здесь не подходит, т.к. его тик составляет 55 мс (приходится
> работать в W98).
Забудь об этом. В Windows, а тем более 98