так инициализируется таймер в uCOS-II:

Да, именно. НЕ СНИМАЕТСЯ ЕСЛИ НЕ ЧИТАТЬ PIVR. Я вот удивляюсь - а документацию кто читать должен? Уже на gaw.ru и перевод сделали для тех, кому лень выучить необходимые для пониманий 90% текста 50 слов и сочетаний по-английски.

1) Уменьшить MCLK
2) Организовать в прерывании этого таймера хоть 128-битный программный счетчик.

Для формирования периодических прерываний с постоянным интервалом. Например системный таймер RTOS, который обычно генерит прерывания с частотой 100-1000Гц.

Я вобщем не спрашивал как организовать счетчик. Просто я так понял что больший интервал аппаратных прерываний чем записывается в PIVR получить нельзя.


Не понял. При чем здесь счетчик переполнений? Он же сбрасывается при считывании PIVR?

Что касается документации то да, признаю, я часто бываю невнимателен.

Да, нельзя. Тогда я не понял вопроса. А какой таймер позволяет делать больший чем разрядность таймера?

Извиняюсь, я тоже бываю невнимателен. Почему-то показалось, что вопрос был про PIT вообще. Видимо чтобы узнать сколько прерываний было потеряно если это прерывание было запрещено надолго и потом программно вызвать обработчик нужное количество раз:

Ну вообще-то полная разрядность таймера PIT 20 + 12 Хотя если подумать для чего сделан данный таймер то вобщем достаточно и 20 разрядов. Жаль только частота фиксированная.

А поясните, пожалуйста, почему этот таймер не так прост и не рекомендуется использовать прерывания? Тоже только недано начал ковырять АРМ на AT91SAMx256 борде. И тоже попробовал поднять RTT. Поллинг работает, а прерывание стартует только в режиме LEVEL, но почему-то рабоает нормально без запрета прерывания в прерывании и последующем его разрешении в основном цикле. Если меняю режим на EDGE то прерывание просто не запускается. Вообще.

Если кому не напряжно глянуть в мои каракули, может подскажете где грабли?

Вопрос в том, действительно ли прерывание RTT нормально работает в режиме LEVEL. Как я уже писал раньше, оно снимается через 2 цикла SCLK, то есть обработчик может вызываться несколько раз подряд, пока линия прерывания остается активной. А если количество вызовов будет нечетным, то на внешнем поведении светодиодов это не отразится


Режим EDGE для системного прерывания использовать не совсем корректно, так как у него может быть несколько источников, объединенных через логическое ИЛИ. То есть, если при выходе из обработчика останется активным хотя бы один из источников, дальнейшая работа будет заблокирована, что Вы, возможно, и наблюдаете.

Согласен полностью



Почему системное прерывание не желательно использовать по фронту понятно, но я больше никакие системные прерывания кроме RTT не разрешаю. Конечно они могут быть у какой-либо периферии разрешены после старта (я конечно весь DS пока не прочитал), но здравый смысл подсказывает, что после старта вся периферия должна быть выключена.

Выяснились новые подробности. Если перед основным циклом прочесть RTTC_RTSR то все работает как часы, из чего я делаю вывод, что иногда при старте прерывание от RTT уже активно! Сбросить его некому, т.к. у меня чтение его производится только из прерывания. Отсюда вопрос: а почему оно может быть активно после старта? Я же делаю ему (RTT) резет! Может я что-то не так инициализирую?
В принципе, глюк ясен и понятен. Как бороться тоже ясно и вопрос почти снят, но хочется узнать где же были грабли....

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



- а когда сброс выполнялся отдельно, то возникали проблемы.

Имеет смысл посмотреть свежую errat'у - там, кажется, упоминался RTT.

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

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

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

Нет, JTAG'а нет вообще. А сброс непричем, т.к. я же в начале программы даю резет для RTT.

Тогда не представляю :-(

Сообщение отредактировал Сергей Борщ - Dec 6 2006, 00:04

Итак, подводим итоги. Может быть кому-нибудь пригодится. Вообще-то я пришел к выводу, что RTT в sam'ах кривоват. И кривой он из-за своей природы, т.к. тактируется от RC-цепочки, котороая по-определению нестабильна в той или иной степени. Поэтому использовать его как средство для отсчета равных точных промежутков времени (как обычно используют таймеры) не получается. А раз так, то и прерывания от него особо не нужны... Но мне все-таки было интересно из принципа доковырять этот девайс до максимальной ясности.
При использовании прерываний по уровню все работает (см. посты от aaarrr). С прерываниями по фронту есть проблема, но ее решать смысла нет, т.к. (опять же см. aaarrr) системные прерывания по фронту включать крайне нежелательно. А проблема в том, что сброс RTT, а именно бит RTTRST, не сбрасывает бит RTTINC в регистре RTSR. Поэтому после сброса ядра процессора бит RTTINC может оказаться в активном состоянии, следовательно, фронта никогда не произойдет, поэтому и прерывание не стработает, а тогда не будет чтения из регистра RTSR и бит RTTINC не сбросится. Выход - после сброса RTT читать RTSR один раз чтобы принудительно сбросить флаг инкремента.
Спасибо всем за помощь в изучении проблемы