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

По поводу измерения частоты на голой авр методом захвата посмотрите здесь 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ррм.



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



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



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

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


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

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



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

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