Есть два кварцевых генератора, частота 28мГц, с точностью/стабильностью 50ррм.
Процессор STM32F103 должен определить у какого генератора частота выше.
Абсолютное значение не интересует.
Я пока ничего умнее не придумал, чем подать на два счетчика, запустить их одновременно, через какое-то время остановить и посмотреть на разницу в показаниях.
Какое достаточное время для измерения?
Или может есть другой способ?

Можно из одного сигнала сделать некий интервал, скажем, 1-2с, и за это время посчитать другой сигнал. Должно быть точнее.

Почему?

Имея точность +-50ppm, предположив худший случай, что частоты разошлись в разные стороны, можно определить, за сколько периодов частоты разбегутся на целый такт. Если же нужно найти более тонкое различие, время придется увеличить. Опять же, легко считается.

Можно период измерять, заполнив чем-то высокочастотным. Не один период, а кучу. Побыстрее будет, чем частоту считать.

Если допустимо добавление компонентов, тогда наверное лучше будет измерять фазу.

Добавлять не хотелось бы (как сделать все это на расссыпухе я знаю).

Можно посчитать длительность миллиона периодов каждого сигнала, но не вижу как это сделать одновременно, чтобы не вносить погрешностью.
Считать количество импульсов за определенное время наверное проще и нет проблем точно одновременно запускать и останавливать счет.

Если нужна только долговременная разница, то это "Велосипед". Зависит только от возможности проца.
Необходимая точность определяет время замера...
Ну а если надо и кратковременную мерить, то это метод скорее всего не подойдёт. ИМХО.

Во 1-х, нужна долговременная.
во 2-х - сама разность вообще не нужна, нужен толко ее знак.

Всё страньше и страньше... Какая-то загадочная задача. Вам не кажется, что первое другому противоречит? Если частоты достаточно близки, то возможны биения, где знак будет меняться. В какой-то момент можно будет определить какой-то знак. Но это совершенно не говорит о том, каким он (знак) будет в момент следующий. Тем более в долговременной перспективе.
ИМХО, кроме знака обязательна разность, чтобы быть уверенным (или хотя бы с достаточной вероятностью утверждать), что знак этот сейчас же не изменится.
Ну, а Вам видней, конечно.

Без абсолютного не обойтись, если интересует точность. А так, вполне нормальное решение, непонятно чем вам не нравится ? Проведите, скажем 5-10 измерений длительностью в одну секунду, найдите статистическую погрешность и радуйтесь.
"Зачем просто, если можно сложно"

Можно просто запустить счётчики, периодически считывать, не сбрасывая.
А дальше делай с ними что хочешь!

Нет, на кажется - мне не нужно знать разность частот на основании анализа одного периода, да это и невозможно.


Да, биения конечно возможны, если частоты плавают относительно друг-друга.
Можно даже посчитать частоту этих биений, зная что тастота сигналов 28МГц а их разность в худшем случае 100ррм.

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





Если он "когда-то там" изменится - это не страшно, главно в первый момент определить какой кварц быстрее.

Да, достаточно пустить от двух источников, как угодно неодновременно, два счётчика, а затем одним и тем же фрагментом программы, т.е. тоже неодновременно, периодически считывать их значения и смотреть на разность.

С чего бы ему меняться ? Вообще непонятно с какого вдруг зашел разговор о знаке ? Все вдруг резко забыли как работает таймер от внешнего источника ? Или про необходимость формирователя для измерительного подключения кварца ? Тут главный вопрос - в обеспечении синхронности старта или вычислении набегающей разницы за счет несинхронного старта\считывания показаний таймеров.

Ну мало ли, все-таки надпись "100ррм" на кварце это не только его точность, но еще и стабильность.
К счастью, в моем случае в процессе работы оба сигнала получаются в одинаковых и практически неизменных условиях (питание, температура).



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



Так напомните.



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




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

Если разница большая, то засечь её можно быстро.
А если маленькая, то ждать придётся относительно долго.
Обязательно нужно засечь разницу или нет?
Зачем вообще всё это надо?

Там время есть, в разумных пределах.



Полностью долго рассказывать, а если кратко - есть две системы, тактируемые от своих генераторов. С одной системы данные поступают пачками на другую, через процессор, в котором некоторая обработка и FIFO.
В начале каждой пачки есть почти секунда на тестирование сигналов, ну а дальше - допустимая длина пачки зависит от размера
FIFO (и макс. возможной разности частот).
Сейчас в начале пачки заполняется половина FIFO, а его размер выбран так, чтобы при максимальной разности частот не происходило переполнения. Т.е. начальная разница между указателями равна половине буфера, при Fread>Fwrite указатель чтения будет догонять указатель записи, Fread<Fwrite - отставать.
Идея состоит в том, что если заранее знать условие, например Fread>Fwrite, то дождавшись полного заполнения буфера, можно указатель чтения ставить на на пол буфера позже указателя записи, а сразу пере ним. Если Fr<Fw, то указатель чтения сразу после указателя записи. Таким образом, начальная разница указателей будет равна не половине размера буфера а целому, и при то-же влеличине буфера мжоно длину пачки увеличить почти вдвое, или наоборот - почти вдвое уменьшить величину буфера при неизменной пачке.
Разумеется, при условии что за время пакета разность частот не меняет знак. (если это и произойдет, то не страшно, если оно будет детектировано - пакет будет отброшен).

Для чего это нужно, всё равно не понятно, "Секретная информация", ну да ладно, дело хозяйское.
Похоже тока что разница нужна обязательно. Тогда если она маленькая, может понадобиться
много времени. А если в течении разумного предела, разница так и не будет определена?

Я вроде обьяснил для чего.



Тогда как и раньше - на середину буфера, если разница маленькая, проблем не будет.

Не надо изобретать велосипед, поставьте кольцевой буфер с указателями на запись и чтение.

Не очень понял этой реплики - какие "изобретения"? Именно кольцевой буфер с двумя указателями и используется.

Ну, если вы всё знаете, зачем спрашиваете?

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

1) Читаю я всегда внимательно, скажу больше, даже внимательнее, чем вы пишете.
2) Кольцевой буфер не так работает, как вы описываете.
3) Постановка вами задачи и ваши комментарии, мягко говоря, вызывают сомнения в том, что вы в теме.
4) [Чтобы развеять ваши встречные сомнения, скажу, что ваши 28МГц я могу измерить с погрешностью порядка 200 Гц за ОДНУ миллисекунду]

Удалил повторное сообщение

Очень рад. Тогда вы несомненно можете дать массу полезных советов.



В моем представлении, есть буфер, есть два указателя - один на запись, другой на чтение, после каждого чтения идет инкремент указателя чтения, по каждой записи - инкремент указателя записи. (В моем случае это происходит по прерываниям, но это неважно).
Инкременты разумеется, по модулю размера буфера (поскольку он кольцевой).
В чем я не прав?



Я и спрашивал совета как лучше это сделать.
За 1мс пройдет 28000 импульсов одного генератора.
Чтобы засечь минимальную разницу, надо чтобы со второго пришло или 27999 или 28001 импульс. Итого разница составит 1кГц.
Если вы знаете секрет как поймать за 1мс 200гц имеющимися в распоряжении средствами - расскажите, думаю всем начинающим будет интересно.

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

Это понятно. Тут другое - поскольку частота записи и частота чтения чуть-чуть отличаются, через некоторое количество "оборотов" кольцевого буфера один указатель догонит другой.
Повторю еще раз:
Сейчас начальные условия - чтение начинается после заполнения половины буфера, расстояние между указателями и равно этой половине.
Зная макс. допустимую разность частот и размер буфера можно посчитать через склько оборотов произойдет "наезд" и таким образом посчитать максимульную длину передачи без переполнения.
Идея состоит в том, что если знать в какую сторону побежит указатель чтения относительно указателя записи - будет догонять или отставать (т.е. от знака разности частот), можно действовать по другому:
- если частота чтения ниже частоты записи, то не надо ждать заполнения буфера, ставим указатель чтения сразу за указателем записи.
- если частота чтения выше, то дожидаемся заполнения всего буфера, и ставим указатель чтения перед указателем записи.
Таким образом, по сравнению с имеющимся вариантом, виртуальный размер буфера как бы вдвое увеличится, при том-же его физическом размере, поскольку начальная разница между указателями будет равна не половине буфера а целому.
Т.е. можно или увеличить вдвое длину передачи, или при той-де длине уменьшить вдвое буфер.
Не знаю, может я как-то сумбурно обьясняю, но вроде должно быть понятно.
Если я в чем-то не прав - обьясните пожалуйста.
К тому же, мне крайне любопытно как за 1мс поймать разность частот, меньшую одного импульса, как утверждалось выше.

Надо одну частоту подать на вертикальный вход осциллографа, а вторую частоту - на горизонтальный. А потом посмотреть на фигуру Лиссажу.

Вы случайно не в Майкрософте работаете?

http://ru.wikipedia.org/wiki/%D0%9B%D0%B8%...%83%D0%B0%D0%BD

Не видно фигуры - скрыта каким-то лапсердаком

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

По поводу измерения частоты на голой авр методом захвата посмотрите здесь http://electronix.ru/forum/index.php?showt...29796&st=15. Можно читать с начала, а можно сразу с моего поста #23. На арме я такую задачу не делал, но схемы захвата там есть, принцип работы тот же самый, должно работать. По моей оценке, при тактовой частоте проца 72 МГц, можно измерить 28 МГц за 4 мс с погрешностью 100 Гц.


Увы, это ноу-хау, кстати, ваш земляк сделал примерно то же самое, он точно измеряет 1 МГц за 1 мс. Он сделал прибор на этой основе и успешно его продаёт. А я долгое время разрабатывал приборы дистанционного измерения момента вращения, давления и температуры. Радиоимпульс с частотой заполнения 450 МГц длительностью 17 мкс я измеряю за 50 мкс с точностью 1 Гц. Правда, там другая схемотехника, заказной эйсик и тексасовский дсп.

Разумеется. Но вы согласны, что при конечной величине буфера, и неограниченной длине передачи, переполнение рано или поздо произойдет?
Вот задача и состоит в том. чтобы выбрать макс. длину передачи, при заданном размере буфера. А оно зависит не только от размера буфера и разности частот, но и от алгоритма работы с буфером.



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

Буфер - какой есть, он его размера и алгоритма (а о алгоритме-то я в веду речь) зависит максимальная выбираемая длина передачи.
Поймите еще раз - размер буфера жестко задан, а вот длина передачи - как раз и выбирается так, чтобы небыло "наезда".
Но что плохого в том, чтобы изменением алгоритма, при том же размере буфера увеличить допустимую длину передачи почти вдвое?



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

Но вот откуда беруться ваши конкретные цифры - совершенно непонятно.
К примеру - вы можете сказать откуда взялись 200гц за 1мс в моем примере (частоты равны 28Мгц +-50ррм)? Тактовая частота процессора неважна, хоть 20, хоть 200мгц, она в процессе счета не участвует.



Измеряется что, длительность радиоимпульса или частота заполнения?
И какое соотношение точностей измеряемой частоты и тактовой частоты измерительного устройства?
В моем варианте, измерительное устройство НЕ обладает тактовым генератором более точным, чем измеряемые частоты.



Тоесть совершенно ничего общего с данной задачей.

1) Ну тут одно из двух, или я неправильно понял условия задачи (видимо, и все остальные тоже), или у вас неправильная постановка задачи.
2) Не постигли вы суть той темы, тактовая частота проца именно важна.
3) Погрешность 200 Гц - это моя оценка измерения за 1 мс моим методом, просто для примера, никто же не говорил про минимальное время измерения.
4) Измеряется частота заполнения 450 МГц с погрешностью ± 1 Гц.
5) Что значит "совершенно ничего общего с данной задачей"? Задача была одна - измерить две частоты и сравнить их между собой. Эта задача может быть решена данным способом.

Видимо да, неправильно поняли или я плохо обьясняю.
Постановка задачи не может быть "неправильной" - она какая есть Я ее себе не ставил, я лишь реализую.



В ТОЙ - да, поскольку одна из частот у вас - тактовая проца.


Вот и совершенно непонятно, даже вашим методом, откуда взялись эти цифры? Вас не затруднит показать арифметику?



Нет, не так. Вы ИЗМЕРЯЕТЕ обе частоты и сравниваете друг с другом. У меня нем задачи ИЗМЕРИТЬ, мне не важно их абсолютное значение, для описанного (уже не один раз) выше алгоритма - важно только какая частота больше, какая меньше, чтобы выбрать соответствующие начальные значения указателей.

Кажется, на пустом месте тема. Если Вы данные на ходу не обрабатываете, то куда и зачем читаете? Неужели весь этот сыр-бор только лишь для банального подсчёта контрольной суммы?

Если данные всё же обрабатываете на ходу, то всего лишь, что надо, чтобы средняя скорость чтения была больше средней скорости записи. И никакие супербуферы не нужны. Например, писать байт, читать/обрабатывать слово, и т.п.

Причем тут вообще контрольная сумма и где у меня написано, что данные не обрабатываются? Я сказал что в данном случае мы обсуждаем не обработку, а не зачем нужен этот буфер. Примите это как данность.



Не только обрабатываются, но еще и дальше передаются.
Но процесс обработки мы не обсуждаем, поскольку на работу с буфером он не влияет.



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

Просто дочитайте до конца, что цитируете — если пишется по байту, читать надо по 2 байта, и т.п.

Да нет, это вы дочитайте до конца условия задачи. Ну прочитал я 2 байта, обработал как хотел, результат у меня - те-же 2 байта. Дальше что мне с ними делать?

Видимо, абстрактрые примеры не очень доходят, все пытаются порассуждать о чем-то постороннем, почему бы и мне, как топикстартеру. не сделать тоже самое?

Забудет об изначальном вопросе про сравнение частот, более конкретный пример (толко пример, с реальной моей задачей есть масса отличий):

У вас процессор, неважно какой.
Два SPI порта.
1-й - режим слейв-приемник, получает данные извне.
2-й - режим слейв-передатчик, оправляет данные куда-то наружу.

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

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

Ваше решение?

Например, можно их выбросить — вот соответствующий пункт ТЗ:



Читаю, и говорю мастеру "взял".
Кладу, и говорю мастеру "положил".

Это должно быть все-же достаточно редким явлением.

А если мастер не готов принять из-за того что он медленнее?

Продолжаете заблуждаться. Те два навязанных Вам своенравных генератора ничего не дожны, и их поведение описывается точной формулой, а именно худшим случаем.

Поймите, Вы этим топором "выбрасывание пакетов" просто уменьшаете скорость записи, т.е. соблюдаете всё то же условие о соотношении скоростей — Ваш источник с самого начала мог прекрасно передавать данные с меньшей скоростью, но Вы спроектировали систему неверно.


Его проблемы. Получит со следующим пакетом соответствующее уведомление — о том, что он тормоз.

Для худшего и считается - один генератор 28Мгц+50ррм, а второй 28МГц-50ррм.



Откуда вы взяли, что я собираюсь что-то выбрасывать? Для того и буфер, для того и согласование его размера, алгоритма и длины пакетов, чтообы ничего не выбрасывалось.
О выбрасывании я упомняул как о Форс-Мажорном случае, т.е. если "это" вдруг раз на Х пакетов и произойдет, то ничего страшного, никто не помрет. Но в общем случае, никакого выбрасывания быть не должно.



Я ее не проектировал, она была уже до меня, и уже довольно долго работает Я только пытаюсь ее улучшить.



И что? Он свою скорость изменить не может.

Нет, это по-прежнему всё то же снижение скорости записи.


Естественно. Виновен разработчик, который элементарно не посчитал скорости.

Нет никакого "снижения скорости записи".



Он их не считал - скорости одинаковые, и они заданы имеющимся (не нашим) оборудованием.

Так как на изначальный вопрос больше ответов нет, а разговор пошел совсем о другом, тему можно считать исчерпанной.
Если кто хочеть продолжить разговор "о другом" - можно открыть другую тему, а если кому есть что сказать по исходному вопросу- пожалуйста в ЛС.