Наткнулся на одну неприятную особенность таймеров STR912.

Таймеры тактируются от PCLK. Частота PCLK 48 МГц. Надо организовать прерывание таймера через 1мкс. Значения регистра совпадения и предделителя рассчитаны правильно, но прерывание возникает с периодом больше чем 1 мкс.

В поисках по форуму, наткнулся на пост уважаемого AlexandrY:



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

Тогда вопрос, изза чего таймер тикает медленее?

Попытка подключить источник тактового сигнала Fmstr вместо PCLK не увенчалась успехом.

Я бы всё-таки ещё раз проверил, что регистры инициализируются правильными значениями. Например, надо помнить, что в этом хитромудром таймере счётчик начинает считать не с нуля, а со значения 0xFFFC.
К тому же, как проверяется значение периода прерывания? 1 мкс - это довольно мало, так что если не спешить, то можно поймать не все прерывания. Я бы начал с бОльшего периода, убедился, что всё работает верно, а потом стал бы уменьшать период.

То, что таймер считает не с нуля а с 0xFFFC знаю.
Ради интереса выставил сделал счетчик, который каждую секунду должен зажигать светодиод.

Но период не 1 сек, а примерно 1,3-1,5.

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

бит TI23SEL в регистре SCU_CLKSNTR сброшен, то есть EXTCLK настроено на fMSTR.
таймер тоже настроен
TIM2->CR1 |= 1;

А в каком месте написано что так можно сделать? По пдфке,как я понял, работа или от PCLK или с внешней ноги. на внешнюю ногу я настраивал, и подавал туда 32 килогерца. все работает.

В Reference manual, на странице 49 есть картинка с всеми тактовыми сигналами и там видно, что EXTCLK имеет два источника, первый fMSTR через 16-ти битный предделитель, а второй сигнал от ноги.
На странице 125 видно, что к таймеру можно подключить либо EXTCLK(от внешней ноги или от fMSTR, в зависимости от настройки регистра SCU->CLKCNTR, по умолчанию подключено fMSTR) либо PCLK.
Но проблема в том, что при настройке соответствующих регистров, ничего не меняется.
Таймер тикать не хочет.

http://www.st.com/mcu/devicedocs-STR912FAW44-101.html
http://www.st.com/stonline/products/literature/rm/13742.pdf

не нашел. или не там ищу??


http://www.st.com/mcu/devicedocs-STR912FAW44-101.html
http://www.st.com/stonline/products/literature/rm/13742.pdf

не нашел. или не там ищу??

Опа. Походу у меня референс мануал старый.
Внизу скрин с него.

Думаю, что эту тему надо перенести в раздел для начинающих ))

Не спешите. Я тоже столкнулся с проблемой тактирования периферии в STR91xx от внутренней частоты PCLK. Причем два раза для разных устройств- для UART- ов и для таймеров. На таймере запрограммировал PWM, генерирующий меандр с частотой 100 Гц. Получил 100, 5 Гц. Задающий кварц 25МГц- идеальный, проверял. Пришлось тупо корректировать загрузку кэпчур-регистра, чтобы убрать ошибку частоты в 0,5%. С UART получилась похожая история- при загрузке генератора скорости стандартными значениями из мануала, фактическая скорость следования битов оказалась на 2% ниже требуемой. Только на 57600 оказалась точной, а для других- всегда с занижением. Чем это объяснить- нет никаких мыслей. Пришлось также тупо корректировать загрузки генератора скорости, чтобы получить стандартные частоты. Проблема так и осталась нерешенной. Боюсь выплывет какой-нибудь неприятностью чуть позже.

Чушь какая-то.
Два-три года назад реализовывал проект на STR911, таймера использовал для генерации нескольких частот (использовались аналоговой частью прибора - как сигналы возбуждения, синхронными детекторами и т.п.). Никаких таких проблем не было. Если бы у меня частота отличалась хоть на 1%, просто ничего бы не работало.

У STR91 есть особенность работы, поищите в мануале Special interrupt mode control. Я плохо помню подробности, но смысл там в том, что при его использовании при выполнении программы RCLKDIV устанавливается в какое-то значение, а в прерываниях он кажись становится 1. Ну а вся пакость в том, что переключается не только тактовая ядра, но и все частоты, которые получаются из RCLK. Выход - отказаться от использования Special interrupt mode control

<br /><br /><br />

Это называется Special Interrupt mode IRQ(есть также для FIQ).
Этот режим выключен.



Как я понял из перевода и диаграмм тактовых сигналов, если включен этот режим, то CPU тактируется от fMSTR, а обработчик прерывания от RCLK.

Кроме того, если бы происходило произвольное изменение PCLKDIV, то изменения частот таймеров и UART были бы в РАЗЫ, а наблюдаются всего проценты. Я тоже грешил на делитель для PCLK, но по здравому размышлению отказался. Больше похоже на PLL. Может ведь так быть, что присваивая настройки PLL для генерации 96МГц, на самом деле эта PLL генерит на несколько процентов меньше? Проверить это можно только частотомером с выхода, например, таймеров. Других способов я не вижу.

Я тоже так думаю. У меня появился осциллограф, правда древний, как унты чукчи, но меряет частоту до 20 MHz. Надо попробовать измерить частоту например ШИМ.

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

К слову, не PCLKDIV, а RCLKDIV

------------
Хм, посмотрел на блок-схему, освежил в памяти... Чего-то оно не очень освежилось...
Всё равно проверьте ещё раз насчёт настроек RCLKDIV и Special Interrupt Mode, если меня не подводит память - там какая-то засада была именно с таймерами, из-за чего я сразу отказался от использования этого режима

Да вроде как наладилось. Отказался от библиотек ST.

Измерил частоту ШИМ с помощью осца. Отклонение рассчитанных значений и измеренных составило меньше одного процента и если учитывать, что частота определялась на глаз и осц довольно древний, то с уверенностью можно сказать, что после отказа от библиотек ST таймеры затикали нормально.
За Special Interrupt mode спасибо. Буду иметь ввиду    .

Вот так и рождаются нездоровые сенсации...
А разобраться в чём дело значит не захотели. Библиотеки-то со всеми исходниками, можно ведь посмотреть и определить, кто и где был неправ

К сожалению нету времени в них копаться. Может как нибудь на досуге.
Один из примеров. Как только начинал с ним работать, не хотели прерывания генерироваться. Поднял на форуме тему, в одном из сообщений подсказали попробовать объявить обработчик прерывания таким образом __irq void ........ (void) (в библиотеках ST почему-то это дело написано без __irq).

Я залезал в исходники, ничего криминального не нашел. Более того, залез в реальный кристалл JTAG-отладчиком- смотрел коды в регистрах управления периферией и SCU- все правильно, точно по мануалу. Смотрел и бит в SCU, отвечающий за Special Interrupt Mode- этот бит стоит в нуле. А таймеры и скорость UART-ов все равно отличаются от ожидаемого на пару процентов.

Если вы говорите, что в UART скорость была на 2% ниже, то попробуйте в целях эксперимента немного повысить частоту PLL, AlexandrY говорил, что розганял STR912 до 133 MHz. (Попробовал бы у себя, но у меня UART тикает вроде нормально). Запишите значения например N=202, M=26, P=2(данные значения для кварца 25MHz) (частота PLL примерно 97.115MHz) и посмотрите, какая получается скорость передачи в UART. Если вдруг процессор не запустится, то лечится следующим образом, выпаиваете кварц и на его место запаиваете кварц на меньшую частоту, скажем 12 MHz, стираете прошивку и запаиваете старый.

Как обычно всё смешалось в одну кучу:



Это, как говорится, две большие разницы: в случае с уартом налицо проблема неправильной настройки делителей. В STR91 (как и во многих других МК уровнем чуть повыше 51 и АВР) делитель частоты уарта может иметь некое подобие дробного коэффициента, там используется Fractional baud rate generation. Многие противники использования библиотек от ST просто игнорируют этот момент, и получают свои % отличия.
В случае же с таймерами, описанным Вами в начале, отличие составляет десятки %. Чем оно может быть вызвано - одну из версий я уже выдвигал. Возможно, причина в чём-то другом, но однозначно это не их проблема, а Ваша. Ещё раз повторю: я реализовывал проект на данном МК, в котором недопустимо было отличие даже в сотые доли %, всё прекрасно работает.

У меня с UART была и другая проблема- он изредка двоил символами на прием в присутствии прерываний таймера. Полез на ST форум и обнаружил, что у многих такое наблюдается. Тогда полез в исходники ST библиотеки и обнаружил ошибку в IRQ-обработчике. Там было реализовано nested прерывания без обновления приоритета VIC1. Тогда полез в support от ST и нашел новую версию ST-библиотеки от 2009 года. В этой новой библиотеке уже нет ошибки пв прерываниях. Надеюсь, установку скорости UART и счет таймеров( или PLL?) тоже подправили. Теперь буду пробовать новую версию библиотеки. О результатах вскорости доложу.

Что же касается отличий в 2% от заданной скорости UART, то это похоже на ошибку округления до ближайшего целого при расчете fructional divider в старой версии ST библиотеки. Буду испытывать новую версию.

Поделитесь новой библиотекой)))

Она в свободном доступе на сайте STM по разделу support.
Уже кое-что попробовал. Действительно, обработчик прерываний в новой библиотеке стал работать предсказуемо за счет отказа от nested и правильного обновления приритетов при каскадировании VIC1 и VIC0. Понадобилось 2 года (с 2007 по 2009), чтобы устранить ошибки в ST библиотеке.

Что же касается ошибки в 2% при установке длительности периода PWM на таймерах, то я обнаружил причину. Она из серии хреновых мануалов. Оказывается, чтобы поделить PCLK на пределителе таймера в N раз, нужно грузить в пределитель число N-1. В разделе мануала, где даются формулы расчета периода PWM, ничего про это не говорится! И в руководстве библиотеки ST тоже молчок. А узнаешь про -1 только в разделе "описание регистров TIMx". Hо идеального совпадения периода PWM с расчетным все равно не получилось после исправления оплошности с N-1 пределителя. Завышение частоты составило в 5-ом знаке по отношению к частоте задающего кварца. Если при расчете значения OCR2 вычитать не -5, как в мануале, а -4, то совпадение получаем идеальным.

Что касается неточной установки скорости UART-ов, то этот момент еще с новой библиотекой не проверялся.

Ну так правильно, надо вычитать -4. Ведь при сбросе, значение счетного регистра устанавливается в значение 0xFFFC.

Если честно, не нашел библиотеки.

А фирменном мануале написано -5.
Ловите
Нажмите для просмотра прикрепленного файла

 

Благодарствую.