Начнем с того, что он не будет ничем хорош. Программный справляется точно так же, плюс имеем бонусы в виде свободного назначения ног, легкой переносимости кода и т.д., обо всем этом я уже писал. Есть случаи, когда аппаратное решение весьма желательно, например, при реализации 1-Wire, там критичны времена. Но тот же 1-Wire реализуется в STM32 через одно место, возмущает, что при столь развитой периферии не нашлось места нескольким аппаратным портам 1-Wire.
Все эти плюсы актуальны лишь для приверженцев софтового ногодрыга и ЛУТ. Касательно 1wire это вообще смех. Вам предоставлена мощнейшая периферия , своего рода конструктор - соберите из этих элементов 1wire. Озвучу сразу - оно есть и работает (аппаратный 1wire) :
Если использовать DMA для чтения состояния счетчика
Я не очень понял Вашу идею. Она выглядит как успеть прочитать захваченное состояние до того как пришел следующий импульс входного сигнала? По моему основные копья здесь связаны не с успеть прочитать, а сформировать нужным образом сигнал захвата. Не слишком рано, что бы прошел хотя бы 1 период входной частоты от предыдущего, и не поздно, что бы не слишком вылезти из интервала измерения и не потерять информацию, которую можно было бы померять. Время захвата рассчитывается исходя из входной частоты, которая может меняться в широких пределах. А расчитывать может только процессор например в прерывании.
Леонид Иванович писал(а):
Было бы заманчиво построить частотомер на STM32 с аналоговым интерполятором
По моему неразрешимых проблем нет. Единственно использовать его можно будет до Fref/2. Могут возникнуть задачи синхронизации внутренних счетчиков и интерполятора. Но по моему они разрешимы. Если есть желание - можно пообсуждать. Я еще пока не очень хорошо сформулировал как это должно работать для себя.
Леонид Иванович писал(а):
Девиация Аллана - это всего лишь мера нестабильности частоты
Да похоже что действительно так. Я так закопался что бы узнать что это такое, что забыл зачем оно было нужно в статье. Оказывается только что бы показать что их частотомер ее измеряет.
Вам предоставлена мощнейшая периферия , своего рода конструктор - соберите из этих элементов 1wire.
Я не могу собрать - не получается. Поэтому это плохая периферия, раз собрать из нее что-то могут лишь редкие люди. Для реализации 1-Wire использую UART, но их мало, если понадобится несколько портов - труба. Можно немного улучшить положение, использовав remap, но не сильно. Да и реализация на UART не такая простая. Хотелось бы проще - записал байт в регистр - он улетел по 1-Wire.
Спойлер
Код:
//----------
//Модуль поддержки термометра DS18B20, заголовочный файл
#define BR_RESET 10417 //скорость порта для формирования RESET #define BR_TSLOT 166667 //скорость порта для формирования TIME SLOT #define CONVERT_TM 800 //время преобразования температуры, мс
Компания MEAN WELL пополнила ассортимент своей широкой линейки светодиодных драйверов новым семейством XLC для внутреннего освещения. Главное отличие – поддержка широкого спектра проводных и беспроводных технологий диммирования. Новинки представлены в MEANWELL.market моделями с мощностями 25 Вт, 40 Вт и 60 Вт. В линейке есть модели, работающие как в режиме стабилизации тока (СС), так и в режиме стабилизации напряжения (CV) значением 12, 24 и 48 В.
Я не очень понял Вашу идею. Она выглядит как успеть прочитать захваченное состояние до того как пришел следующий импульс входного сигнала?
Если я правильно понял, то можно настроить DMA на срабатывание по событию таймера. В данном случае входной фронт измеряемого сигнала вызывает захват в счетчике, работающем на тактовой частоте (72 МГц) и очень хочется по возможности одновременно захватить значение счетчика входных импульсов. Прерывание - долго. Ждать в цикле - тоже. А DMA вроде за 6 тактов справится. Так что до 10 МГц проблем нет.
А чем плохо внутри асинхронно предварительно поделить входной сигнал, скажем на 4? Вроде точности не уменьшит?
А зачем вообще рассуждать, если HHIMERA все придумал? Интелектуальное упражнение. И для лучшего понимания переферии STM32.
Если я правильно понял, то можно настроить DMA на срабатывание по событию таймера. В данном случае входной фронт измеряемого сигнала вызывает захват в счетчике, работающем на тактовой частоте (72 МГц) и очень хочется по возможности одновременно захватить значение счетчика входных импульсов.
Одновременно никак не получится...
Цитата:
А DMA вроде за 6 тактов справится.
Не уверен... даже сильно... надо мерять...
Цитата:
А чем плохо внутри асинхронно предварительно поделить входной сигнал, скажем на 4? Вроде точности не уменьшит?
В 4 раза и уменьшит...
Цитата:
А зачем вообще рассуждать, если HHIMERA все придумал?
Рассуждайте... не отвлекайтесь...
_________________ "Я не даю готовых решений, я заставляю думать!"(С)
To что совсем одновременно не выйдет - понятно. Вопрос как минимизировать задержку, вернее успеть до следующего фронта. Про 6 тактов - так понял appnote. Не проверял.
Поясните подробнее, почему делитель на 4 уменьшит точность в 4 раза? Если прямой счет, то естественно так. А если мы измеряем время между N фронтов, частота входного сигнала не влияет на случайную погрешность. Мы отслеживаем не каждый фронт, а каждый четвертый. И что?
А разве можно делать захват с асинхронным предделением?
Похоже нет. Не посмотрел внимательно. Ну да ладно, снаружи 74LV161A Практического смысла по сравнению с CPLD не много конечно, но чисто умозрительно по моему делитель не ухудшит разрешения. Или я ошибаюсь?
А вот если мы имеем таймер, тактируемый внешним сигналом допустим 1 герц. Один из каналов CC настроен на захват фронта (с формированием прерывания с переключением светодиода для наглядности). На вход захвата кнопкой подаем импульс(ы). Вопрос такой, будут ли синхронизированы включения светодиода с фронтами тактирующего сигнала или с фронтами кнопки? То есть захват будет происходить по фронту тактирующего внешнего сигнала, или внутреннего?
Если захват будет синхронизирован с внешним тактированием, то есть появляться только по фронту внешнего тактирующего синала счетчика, то частотомер сделать очень просто. Таймер Fref (Tref) осуществляет захват по триггеру от таймера входного сигнала (Tin). Tin тактируется измеряемым сигналом. Один из его каналов CC настроен на захват. На этот вывод подаем фронт. Таймер Tin осуществляет захват не сразу, а по фронту тактирования (это то и надо проверить), то есть входного сигнала. По этому сигналу он генерирует сигнал триггера (011: Compare Pulse - The trigger output send a positive pulse when the CC1IF flag is to be set (even if it was already high), as soon as a capture or a compare match occurred.). Номер входного периода в регистре захвата TIn. Номер выходного периода в регистре захвата Tref. Второй импульс на вход захвата - есть вторая точка. Но что то мне кажется, что это не будет работать. Слишком просто.
Вопрос такой, будут ли синхронизированы включения светодиода с фронтами тактирующего сигнала или с фронтами кнопки? То есть захват будет происходить по фронту тактирующего внешнего сигнала, или внутреннего?
От внутреннего... Все таймеры в STM32 синхронные... Отсюда и ограничения до половины тактирующей... Асинхронные есть у Микрочипа... да и то не везде... и унылые до не хочу...
_________________ "Я не даю готовых решений, я заставляю думать!"(С)
В Вашем случае формирование интервала зависимо от входного сигнала. Я не говорю про урезание интервала измерения до целого количества входных периодов - это другое. При Вашем алгоритме могут быть грубые ошибки формирования измерительного интервала. На входе может быть все, что угодно. За первую половину интервала в TIM2->CNT может насчитаться одно, а за другую половину - другое, если частота на входе меняется. Частотомер должен показать среднюю частоту, но за фиксированный интервал, а не за какое-то неопределенное время.
Посмотрел у себя что и как творится... Вот так мы плаваем...
Я имел в виду немного не то. При входном сигнале постоянной частоты нет сомнений в правильности работы алгоритма. Но сигнал на входе частотомера имеет право быть каким угодно. Скажем, пачки импульсов. Частотомер должен показать среднее значение частоты за измерительный интервал. И вот тут предложенный алгоритм может сформировать совсем неправильный измерительный интервал. Но эти проблемы встанут только при попытке допиливания алгоритма до уровня измерительного прибора.
Если я правильно понял, вместо того чтобы смотреть сколько импульсов набрали за 0.5 сек, можно посмотреть через 1 сек и в качестве конца счета использовать это N плуюс скажем 2. Тогда даже при сильно неравномерной входной частоте будет интервал близкий с 1 сек, если, конечно, частота хотя бы 10 Гц.
в качестве конца счета использовать это N плуюс скажем 2
Это если ограничить частоту сверху что бы таймер не успел прощелкнуть эти 2 такта пока производятся расчеты. Поэтому лучше все таки оценивать текущую частоту (кол-во импульсов) и на ее основе принимать решение о задержке. Задержка должна обеспечивать гарантированную настройку таймера за это время процессором.
Естественно в зависимости от грубо определенной частоты. Я написал "скажем 2" а не 1 именно чтобы не проскочить. Если большая частота, то хоть 100. Единственная разница с "классическим методом HHIMERA" в том, что определать ме по 1/2 интервала, а по почти полному.
захват будет происходить по фронту тактирующего внешнего сигнала, или внутреннего?
В микроконтроллере все внешние сигналы проходят через синхронизаторы. За редким исключением, типа сигналов счетных входов, где есть асинхронные прескалеры. В частотомере на ПЛИС у меня есть два разных клок-домена, один - опорная частота, второй - входная. При этом я не имею возможности прочитать счетчик входных импульсов "на лету", он в другом домене. Сигнал GATE должен поступать на счетчики обоих доменов, его нужно пропускать через синхронизаторы. Но, к сожалению, входная частота является нерегулярной, ее может совсем не быть, или она может быть очень низкой, полноценный двухтактовый синхронизатор мы здесь себе позволить не можем. Поэтому остается риск метастабильности. Можно было, конечно, перейти полностью в домен опорной частоты, но тогда бы наложилось ограничение для входной частоты в Fref/2, как и для микроконтроллера.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 8
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения