Таймер с разрешением 0.8383 микросекунды

mause
на С под Атмел тоже можно кодить то же самое программирование, только под рукой куча удобных инструментов, которых в PC либо нет из-за другой области применения, либо они труднодоступны из-за многозадачности, может даже и все управление на него перевести сможешь.
А юзать АЦП вместо форимирователя импульсов это ты конечно перебор

 

1. Странно, что никто даже не упомянул GetPerformanceCounter() и GetPerformanceFrequency().

2. Если установить для процесса/потока приоритеты TIME_CRITICAL и REALTIME_PRIORITY, то у цикла будет по крайней мере секунд 5 непрерывной работы, без прерывания от других задач. Вполне достаточно для измерения частоты.

 

iamlamer

Это не интересно. =)

Не знал. Если 5 секунд то сделаю =)

 

ConstZ,Y_Mur, АЦП есть, а компаратора нет(кстати надо поискать что это)
по 2му пункту, бала такая идея, ага, НО, с уменьшением времени измерения мы получаем ухудшение точности вычисления частоты, была такая идея, но не прижилась как раз потому что идет переодическое измерение частоты врашения. И точность которая нам нужна не получаеться на том диапазоне измерений который нам нужен. А вот с этим все получилось на "ура" но теперь встала другая проблема.
И да, скажите ключевые слова для поиска по Атмела и RC цепочки, я не понял это выражает, смысл уловил, а путь реализаци нет. И насколько я понял с этим способом мы получаем не поток импульсов(прерываний), а некий аналоговый сигнал, к примеру напряжение, который строго пропорционален кол-ву приходящих импульсов, так?

Плат у нас великое множество, а вот использовать их на полную не получается Есть ацп, цап, блок реле, и мультиплата цап-ацп. Вообше у нас токарный станок, 2 датчика на поперечной и продольной подаче, а один меряет частоту врашения шпинделя, и вот как раз для этого нам и нужен таймер, для подач нам это не нужно, т.к. можем получить перемешение очень точно и без дополнительного вычисления частоты врашения.
И еще, пишите попроще пожалуйста, я все таки студент, не програмиссткой направлености, и чтобы понять что вы пишете приходится долго искать

 

mause
Для общего представления на русском, подробности на английском, среда разработки. Считывать цифровые импульсы с фотодиода через АЦП это типа забивать микроскопом гвозди там достаточно одного-двух транзисторов, или можно аналоговым компаратором (например, LM339 все три датчика обслужит). Хотя ещё вопрос что за фотодатчик? - там может уже формирователь с ТТЛ выходом есть .
Если специальность и хобби не программирование и не электроника, то имхо лучше привлечь соответсвующего специалиста, в принципе и толкового студента достаточно

 

iamlamer
Если установить REALTIME_PRIORITY для потока, то он не будет прерван другим потоком.
Но это не значит, что он не будет прерван каким нибудь прерыванием - таймером, мышью и т.д.
И откуда 5 секунд - простно интересно.

 

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

Но раз в 4-5 секунд в винде запускается "стратегический" перепланировщик, который обнаруживает, что один поток слишком долго занимает проц, а у остальных в это время "priority starvation" - голодают, бедняжки. Тогда включается "priority boosting", т.е. из хвоста очереди берутся давно не работающие потоки и им (вроде бы, на 2 кванта) дается максимально возможный приоритет. Т.е., выглядит это примерно так: текущий поток 4-5 сек работает непрерывно, а потом его грубо прерывают, и надолго - например, на полсекунды, а в это время работают низкоприоритетные потоки. Потом опять все повторяется.

Кстати, реалтаймом лучше не злоупотреблять. Померял быстренько, вернись в нормал_приорити, дай Винде отдышаться. А то у нее глюки начнутся.

Откуда взял? Из собственного опыта. Еще отсюда: http://www.intuit.ru/department/os/osmswin/6/2.html . Еще читал (а сейчас потерял) какую-то буржуинскую доку, в которой сравнивались методы priority boosting для разных Виндов. Якобы в NT потоки из хвоста выбираются случайным образом, а в win9x заюзан какой-то хитрожопый алгос... И якобы эффективность примерно одинаковая, но рандом проще реализуется, поэтому во всех последних версиях виндов, видимо, рандом.

Это все навскидку и, ессно, имхо.

 

iamlamer
Это чисто гипотеза, которая с реальностью никак не совподает.

Знай что пока поток имеет DPL = 3 приоритет практически не имеет значения. Установка в реалтайме лишь незначительно ускорит исполнение задачи.

Имхо всё сказанное может и имеет смысл для неё, но никак для версий выше 5.0.

 

iamlamer
Первый раз слышу про priority boosting на NT. ИМХО, это что-то из мира UNIX/LINUX

 

Partner это чтото из мира выньдовс тоже...

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

 

Y_Mur,так, стоп стоп, а куда мы будет подавать сигнал после обработки его аналоговым компаратором, сейчас точно что за датчики не скажу, но вроде не из простых...
и да, REALTIME_PRIORITY мы использовать не будем, нельзя, у нас там куча процессов, основных следует заметить, для которых и нужен данный таймер, а с этим выходит чтот таймер главней всего остального.

 

mause
Я бы всю первичную обработку сигналов (да и управление механикой если это ЧПУ) сделал на ATMega16, а связь с PC сделал: UART (в Mega16) -> RS485 -> преобразователь в RS232 -> com порт PC -> ReadFile/WriteFile (Win XP). Соответственно по этой цепочке передаются в PC уже обработанные и упорядочны отчёты, а из PC высокоуровневые команды типа: установить обороты ххх, сдвинуть суппорт на yyy, пройти по траектории заданной коэффициентами сплайна или Безье и т.п.
ЗЫ: Можно и через USB, но для станка RS485 лучше.
ЗЗЫ: Если пользуетесь готовыми платами ввода под слоты ISA, PCI, то они есть и с линейками цифровых входов и гораздо дешевле чем с АЦП входами только зачем этот геморой непонятно, тут недавно был топик про то, что современные PC даже под гольным ДОС не работают в реальном времени

 

int_13h
ОК, буду знать. Кстати нигде не сказано, может ли этот буст перебить реал тайм приоритет.

 

Partner экспериментально проверял - тока если у другого потока выставлен реал_тайм класс приоритета.

 

Y_Mur, увы начинал не я, и закупал все это не я, и в финансах мы ограничены, хотя эти платы стоят недешего,
ISAшные кстати, поэтому приходиться пользоваться тем что есть

 

int_13h
Ну тогда все логично.

 

Не совсем понятно: какая же точность нужна? Например в % к мгновенному значению числа оборотов. И как часто нужны данные о скорости вращения, т.е. как их "переваривает" управляющий цикл?

Ведь что получается: если измерять интервал между импульсами датчиков, то на максимальных оборотах молучите масимальную же ошибку, а также избыточное количество замеров скорости вращения. Если считать импульсы от датчиков за фиксированный интервал времени, соответствующий шагу управляющего цикла, то максимальная ошибка будет на низких оборотах. А если учесть, что там 2.5 тысячи импульсов на один оборот, - точность весьма приличная.

Вот и думайте, что лучше: ошибиться на больших оборотах, или на малых?

 

ConstZ
А я ведь наврал На шпинделе у нас 1000 импульсов на оборот, ошибаться нам нельзя скорей на высоких оборотах, и вообше похоже отпадает необходимость в этом таймере, раньше у нас было однопоточное приложение, теперь много, возможно обойдемся системным таймером, а точность падает из за уменьшения интервала времени измерения. т.к. за одну милисекунду получим 3 сигнала(200об/мин), измениться частота на 30% мы получим 4 сигнала, хорошая точность да? попробую считать число сигналов за полсекунды, может хватит.

 

Дык ничего же не мешает менять алгоритм подсчёта в зависимости от оборотов и иметь точность и там и там.

А если не секрет, как обрабатывать прерывание от ISA АЦП из user mode win XP ? или всё таки драйвер? или опрос? если user mode опрос то точность точно не гарантируется будут пропавшие импульсы, а то и целые блоки (ссылку я уже приводил).

Затраты на Mega16 + LPT программатор смехотворно малы, конечно еще нужны периферийные микросхемы RS485, RS232, но это тоже мелочь, особенно на фоне купленных "профессиональных" ISA плат, которые у вас используются мягко говоря не по назначению
Правда придётся ещё научиться с этим работать, но если проект серьёзный и предполагает дальнейшее использование накопленного опыта, то это обучение не будет потерянным временем

 

А вот и не секрет, драйверов нет, есть ДЛЛка inpout32.dll она очень замечательно мне помогает, есть код инициализаци АЦП(в доках был), после него на порту АЦП у нас есть некое число довольно большое тип longint и каждый следующий сигнал либо уменьшает нам это число либо увеличивает (против и по часовой стрелке вращение датчика соответсвенно) и таким образом мы имеем все необходимое для вычисления частоты врашения в определенный промежуток времени (секунда, полсекунды, четверть секунды, меньше уже лучше не делать). А для мгновенного измерения частоты вращения нам и нужен этот таймер, но хотя, такими темпами, он возможно и не понадобиться. Благодаря вам возможно найду лучшее решение.
Платы были куплены лет этак....... 10 назад наверно, ну может 8, и лежали мертвым грузом. Да я абсоютно согласен что это забивание гвоздей микроскопом. Повторюсь, я студент, и все это научная работа, а данный таймер небольшая частность На этой базе уже много было сделано, и получено множество эксперементальных значений. Пока, я сделал отельный поток который каждые четверть секунды выдает нам частоту вращения, хватит ли 4х значений в секунду или нет я не знаю.