Странности таймеров в STR912 Опции

[artur_off]

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

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

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

Кстати, обнаружил, что програмный такт у STR в 1.4 раза длинее чем у LPC при выполнении из RAM.
Т.е. если симулятор для LPC покажет 60 000 000 тактов при выполнении процедуры, а потом измерить это время при выполнении на мекете с частотой ядра 60 Мгц то получим ровно 1 сек. Для STR91 получим 1.4 сек при выполнении из области DTCM RAM, а из области мапированной на AHB RAM еще длинее.

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

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

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

Сообщение отредактировал artur_off - Jan 18 2010, 16:04

[artur_off]

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

[Aprox]

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

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

[artur_off]

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

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

[koyodza]

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

Ради интереса выставил сделал счетчик, который каждую секунду должен зажигать светодиод.
Но период не 1 сек, а примерно 1,3-1,5.

... в UART скорость была на 2% ниже ...

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

[Aprox]

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

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

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

[artur_off]

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

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

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

[Aprox]

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

Она в свободном доступе на сайте 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-ов, то этот момент еще с новой библиотекой не проверялся.