опубликован 03-10-2001 20:20 MSK        

Для тестирования я использовал такой код (модифицированный код, который дал Kosha)
программа 100000 раз в секунду добавляет к переменной nTimerInMicroSec по 1 и если значение переменной >100000 то прекращает эту процедуру. До и после вызова этого таймера засекаю системное время, чтобы подсчитать врямя работы программы.

int nTimerInMicroSec;
SYSTEMTIME sTime,sTimeLast;

UINT ThreadProc(LPVOID pParam)
{
CCriticalSection criticalsection;
CSingleLock singlelock(&criticalsection);

LARGE_INTEGER PerformanceCounterLast;
LARGE_INTEGER PerformanceCounterCurrent;
LARGE_INTEGER PerformanceFrequency;
LARGE_INTEGER PerformanceDelta;
float SecondsPassed=0;

PerformanceCounterLast.QuadPart=0;
PerformanceCounterCurrent.QuadPart=0;
PerformanceFrequency.QuadPart=0;
PerformanceDelta.QuadPart=0;

QueryPerformanceFrequency(&PerformanceFrequency);
QueryPerformanceCounter(&PerformanceCounterCurrent);

GetLocalTime(&sTime);

while (nTimerInMicroSec<100000)
{
QueryPerformanceCounter(&PerformanceCounterCurrent);

PerformanceDelta.QuadPart=PerformanceCounterCurrent.QuadPart-PerformanceCounterLast.QuadPart;
if ((PerformanceDelta.QuadPart)>50)
{
SecondsPassed=( (float)PerformanceDelta.QuadPart)/( (float)PerformanceFrequency.QuadPart);

if (SecondsPassed>=0.00001)
{
PerformanceCounterLast=PerformanceCounterCurrent;
singlelock.Lock();

nTimerInMicroSec++;

singlelock.Unlock();
}

опубликован 04-10-2001 12:21 MSK            

SetPriorityClass(...Real time)
SetThreadPriority(time critical)

опубликован 04-10-2001 01:21 MSK            

Этот код не претендует на точность. Просто он дает разрешение немного выше, чем мультимедиа-таймер, а также позволяет эту погрешность (будь она неладна!) посчитать. Но опять же, с некоторой точностью, т.к. сам код рассчета погрешности тоже времени требует.

Дык вот: В принципе, эта байда меряет чего-то-там-пока-время-не-вышло.
Но есть несколько траблов, а именно:
Если в точное "время-вышло" ресурсы проца не у твоей программы, мастдаю по х.ру, вышло оно или не вышло. Как заблокить задачи - ставь приоритет Time Critical. Но это решит всего лишь 50% проблем. Хоть Time Critical, если я ничего не путаю, тормозит ВСЕ, кроме твоей проги, я в этом не уверен. По крайней мере такие баги не убираются.

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

опубликован 10-10-2001 01:14 MSK            

Можно сделать такую фичу: например тебе надо подождать сотую миллисекунды:
замеряешь, сколько в проце выполняется, например, ADD, смотришь, сколько их тебе выполнить надо для этого интервала и выполняешь...
Тока это считать надо на этапе компилирования ;-)

Получается привязка к машине и всю идею загубят кэши...

Но даже эта идея - под голый ДОС.

опубликован 15-10-2001 12:53 MSK            

причем TSC насрать на многозадачность - он ведь просто считает такты и всё...

опубликован 06-12-2001 04:16 MSK            

Господа, я работал с железом еще с 198х года.
Так вот что я вам могу сказать. Давайте вспомним,
кто первый сказал: "55 мс". И откуда взялась эта
странная цифра.

Давнам давно, Когда Гейтс был молодой и
(относительно) бедный, знаменитый Голубой Гигант
создал уникальную (в смысле -- бездарную) IBM PC,
которую вскоре переделали в IBM PC/XT. PC-ишка
создавалась в жуткой спешке и не очень продвинутыми
специалистами (иначе бы мы сейчас не маялись с
нехваткой прерываний и др. прелестями, доставшимися
нам в наследство).

Итак, В PC-шке была одна мелкосхема -- таймер i8253.
Он имел три канала:
нулевой -- вырабатывал тики для часов,
первый -- отвечал за регенерацию памяти,
второй -- противно пищал в динамик.

Все три канала таймера были запитаны от единственного
генератора. Кварцевый генератор работал на частоте
14,31818 Мгц.

Затем эту частоту делили на три (= 4.77 МГц) и
подавали на тактовый вход микропроцессора (i8088).
Потом ее еще раз делили на 4 (= 1.19318 МГц) и
подавали на входы всех трех таймеров.

Таймер устроен очень просто. Можно считать, что это
три независимых 16-разрядных регистра (порта). В них
записывается коэффициент деления. Таким образом,
в нулевой канал записывали число 0х0000, в первый --
0х0012, во второй -- 0х0528.

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

Не трудно догадаться, что нулевой канал вырабатывал
импульсы с частотой равной

1.19318 МГц / 65536 = 19.5 Гц или каждые 55 мс.

А вот у первого канала на выходе стоял еще один счетный
триггер, который делил частоту на два. Таким образом,
получались почти 15 микросекундные импульсы.
(Я не привожу расчеты.)

Так вот, изюминка состоит в том, что программы могут не
только инициализировать эти каналы, но и считывать их
текущее состояние. Другими словами, если мы читаем из
нулевого канала его состояние, потом произведем
некоторые "действия", а затем еще раз считаем состояние
канала, то вычислив разницу можно легко посчитать
длительность этих "действий" -- частоту декремента канала
мы ведь знаем -- 1.19 МГц. Здесь надо оговориться, что
длительность измеряемых "действий" не должна превышать
55 мс.

Все было бы хорошо, если б не прогресс. На современных
компьютерах ставятся совершенно другие таймеры, которые
работают с совершенно другими частотами. Но к счастью,
в С++ нет необходимости лазить по портам, каналам таймера
и прочим бестиям. За нас это делают библиотеки.

Я советую Вам, милейший, посмотреть функции

QueryPerformanceFrequency
QueryPerformanceCounter

, которые как раз и работают с нулевым каналом таймера.

И последнее. Мой предыдущий опыт говорит о том, что если
Вы хотите использовать компьютер в качестве машины для
управления оборудованием и обработки данных, то это
можно делать и на Виндах. Но как только Вы попытаетесь
применять его в качестве прецезионного инструмента, то
лучше работать из-под ДОС, а еще лучше из-под UNIX.
Можно рассмотреть и другой вариант -- в Вашем случае
LPT не _генерирует_ частоту, а _управляет_ частотой
внешнего генератора. Это самый лучший вариант, не смотря
на то, что требует внешнего оборудования. Винды -- это не
коттедж с тремя туалетами для двоих. Винды -- это
коммуналка, где "на 38 комнаток всего одна уборная".
Проблематично какому-то конкретному человечку
периодически справлять свои нужды строго по времени.
Не для таких задач Билл Гейтс создавал "Окна", Вы
онемного шиблись в выборе инструмента для решения своих
задач.

опубликован 07-12-2001 03:50 MSK            

теперь подробнее по теме:
пусть проц 500МГц,выходная частота 200кгц
т.е допустимое число тактов на переключение 2000
ежели кто интересовался ядром NT то знает что на задачу там отведено 5-20 мс (т.е если задача в течение этого времени не отдаст управление то оно все равно переключится)
причем процесс с более высоким приоритетом в 9х получит управление СРАЗУ а NT только по истечении интервала

поэтому в NT можно нормально ботать только нахрен убив механизм переключиния задач

в 9х нам непосредственно доступна на запись IDT что делает все легким и удобным

а делаем мы следующее:
1.создаем свой обработчик прерываний от таймера
2.вписываем его дескриптор на место стандартного от маздая

что он должен делать:
I.инициализация:
1.определить с какой скоростью работает сейчас таймер
2.перепрограмировать его на нужную скорость
3.определить частоту проца
II.непосредственная работа
1.сделать что нужно с LPT
2.вызывать стандартный обработчик выравнивая задержками через RDTSC

что следует иметь ввиду:
1.таймер как и LPT железяка внешняя и ее частота вряд-ли больше 4 МГц
2.чипсет тоже дурной=он любит кэшировать запросы и работает в асинхронном режиме

P.S:я бы посоветовал приобрести микроконтроллер вроте ATMEL ATtiny (<1$)
у него 8 ног есть флешка,таймер=короче идеальный генератор=и управлять им с компа

опубликован 07-12-2001 04:06 MSK            

сорри не заметил ляпу

может в далеком 95 году на заре форточкостроения так и БЫЛО=но сейчас 2001 год кончается и используется RDTSC =который ДАВНО СТАЛ ИНДУСТРИАЛЬНЫМ СТАНДАРТОМ и которого нет только в первых пнях