Счетчик частоты на SAM7S64 Опции

[abit]

Здравствуйте.
Мне нужно было собрать измеритель частоты (от 1 до 4МГц) на SAM7S64 и передавать по usb в компьютер эту частоту... программирую в IAR...
встретился с проблемой - хотя там пишут про частоты в 47МГц...
реально например написана такая программа:

Код

do {counter++;} while (dataready!=0)

и стоит счетчик c прерыванием ровно на 1 секунду, который выставляет dataready...
программа успевает насчитать в counter до порядка 2 800 000... а мне ведь еще частоту в 4 000 000 мерить, а не просто счетчик пускать...
это можно как-то ускорить? может я неправильно что-то тактирую...
я просто впервые столкнулся с подобного рода программированием, подскажите пожалуйста в чем проблема...

[abit]

aaarrr
Компилятор IARа с оптимизацией почему-то так и сделал...
более того инструкции

Код

while (dataready!=0) {counter++;}

и

Код

for (dataready=1;dataready!=0;)  {counter++;}

впадают в вечный цикл, хотя

Код

do {counter++;} while (dataready!=0)

работает... я видел много всего из области фантастики с циклом for, но с while впервые...

Нельзя так ловить оба фронта, таймер работает только по одному. Да и зачем это нужно?

Почему нельзя? вроде в книжке говорится что можно по переднему, заднему и по обоим фронтам...
мне это нужно... смысл такой зачем это нужно:
исходная частота - порядка 1ГГц проходит через микросхему (назовем ее A), в которой есть предварительный 8-битный счетчик, от неё в МК я загоняю только старший бит (как раз порядка 4МГц) и по сигналу строба допустим раз в секунду сбрасываю из счетчика в регистр внутри A, а он вешает это число на ножки МК... далее я читаю состояние входов и одновременно должен убедиться что состояние старшего бита в прочитанном регистре совпадает с состоянием фронта той 4МГц частоты... если совпал - значит МК успел, если не совпал - значит нужно увеличить значение подсчитанной 4МГц частоты... ибо попался такой момент, что пока я читал регистр, там сменился фронт...
в общем путано, но как смог объяснил свою затею

и еще раз для ясности... просто сперва вы мне говорили

Используйте аппаратный таймер-счетчик в режиме Capture:
"Capture Mode allows the TC channel to perform measurements such as pulse timing, frequency, period, duty cycle and phase on TIOA and TIOB signals which are considered as inputs" (это из даташита на данный МК).

Capture - это режим захвата насколько я помню английский...
а теперь говорите забудь про захват, используй режим счета...
хотя в книжке говорят о двух режимах: захвата и формирования....

Заранее благодарю за ответы!
Вы мне уже очень помогли.

Сообщение отредактировал abit - Jul 27 2011, 07:52

[aaarrr]

работает... я видел много всего из области фантастики с циклом for, но с while впервые...

Не бывает чудес ни с for'ом, ни с while. Как объявлены counter и dataready?

Почему нельзя? вроде в книжке говорится что можно по переднему, заднему и по обоим фронтам...

Захват можно сделать по любому фронту, считать таймер умеет только по одному.

мне это нужно... смысл такой зачем это нужно:
...ибо попался такой момент, что пока я читал регистр, там сменился фронт...

Казалось бы, на одну четырехмиллионную можно смело плюнуть, нет?

и еще раз для ясности... просто сперва вы мне говорили

ОК, еще раз: таймер может работать в режимах capture и waveform. Первый предназначен для измерения параметров сигнала, поданного на TIOA (частота, длительность и т.п.), второй - для формирования выходных сигналов на TIOA/B.
Сигнал у вас высокочастотный, поэтому измерять длительность его периода средствами capture бесполезно, т.к. получается слишком низкая разрешающая способность. Поэтому и нужно подать сигнал на TCLK, чтобы тактировать таймер непосредственно от измеряемого сигнала.
Такое подключение допускают оба режима - и capture, и waveform. Затем можно или каскадировать таймеры (тогда первый должен быть в режиме waveform, чтобы можно было сформировать перенос следующему), или сделать инкремент старшей половины счетчика программно, по прерыванию переполнения.

[abit]

Не бывает чудес ни с for'ом, ни с while. Как объявлены counter и dataready?

Я подобные "чудеса" много где встречал, каждый раз разные источники беды... я конечно МК не программировал, но программировал много чего другого...

ну если брать этот пример :
counter объявлен локально в main() во первых строках... как unsigned int counter;
dataready сразу после инклудов, глобально как unsigned char dataready;
чуть ниже этого объявления сразу идет функция обработчика прерывания, где код dataready=0; непосредственно перед выходом из прерывания...

почему while и for впадают в вечный цикл - ума не приложу... более того я внутрь этого цикла засунул выдачу содержимого dataready в usb - оно сперва вываливало 1, потом спутя секунду вываливает 0, т.е. значение явно сменилось... а цикл не завершался... в то время как do...while работает чудесно...

Захват можно сделать по любому фронту, считать таймер умеет только по одному.

Спасибо, я разобрался... там в книжке речь шла о синхронизации по обоим фронтам на триггере...

Казалось бы, на одну четырехмиллионную можно смело плюнуть, нет?

К сожалению это четырехмиллионная на самом деле в гигагерце превращается в 256Гц... что портит всю разрешающую способность и делает бессмысленным вообще тот регистр, которым я синхронизирую счетчик по стробам и читаю единицы герца.... так что фронт в момент строба иметь очень хотелось бы, чтобы мерить гигагерц до герца...

ОК, еще раз: таймер может работать в режимах capture и waveform. Первый предназначен для измерения параметров сигнала, поданного на TIOA (частота, длительность и т.п.), второй - для формирования выходных сигналов на TIOA/B.
Сигнал у вас высокочастотный, поэтому измерять длительность его периода средствами capture бесполезно, т.к. получается слишком низкая разрешающая способность. Поэтому и нужно подать сигнал на TCLK, чтобы тактировать таймер непосредственно от измеряемого сигнала.
Такое подключение допускают оба режима - и capture, и waveform. Затем можно или каскадировать таймеры (тогда первый должен быть в режиме waveform, чтобы можно было сформировать перенос следующему), или сделать инкремент старшей половины счетчика программно, по прерыванию переполнения.

Спасибо, сейчас буду пробывать по вашему рецепту...
не ясно только с тем загадочным триггером... вот внтуренний программный триггер можно использовать чтобы таймер времени и таймер счета T1связанный с T2 пустить одновременно / остановить одновременно по прерыванию от T0?

[aaarrr]

почему while и for впадают в вечный цикл - ума не приложу...

Потому что dataready должна быть volatile unsigned char dataready.

чтобы мерить гигагерц до герца...

Чтобы мерить гигагерц до герца, нужно прежде всего иметь опорный источник с сумасшедшей точностью и стабильностью. Он есть?

Спасибо, сейчас буду пробывать по вашему рецепту...
не ясно только с тем загадочным триггером... вот внтуренний программный триггер можно использовать чтобы таймер времени и таймер счета T1связанный с T2 пустить одновременно / остановить одновременно по прерыванию от T0?

Таймер счета не нужно останавливать вообще, смотрите разницу между предыдущим и текущим значениями. Можно, например, при помощи T0 формировать импульс длительностью 1с на TIOA0, а затем этим сигналом маскировать клок (BURST) для T1. Получается такой режим работы:
1. Считали и запомнили текущее значение T1
2. Запустили T0, дождались окончания секундного интервала
3. Считали значение T1, вычли из него предыдущее - получили частоту клока T1

[abit]

Потому что dataready должна быть volatile unsigned char dataready.


Чтобы мерить гигагерц до герца, нужно прежде всего иметь опорный источник с сумасшедшей точностью и стабильностью. Он есть?


Таймер счета не нужно останавливать вообще, смотрите разницу между предыдущим и текущим значениями. Можно, например, при помощи T0 формировать импульс длительностью 1с на TIOA0, а затем этим сигналом маскировать клок (BURST) для T1. Получается такой режим работы:
1. Считали и запомнили текущее значение T1
2. Запустили T0, дождались окончания секундного интервала
3. Считали значение T1, вычли из него предыдущее - получили частоту клока T1

огромное спасибо,
сейчас почти все удалось...
опорный источник (который будет формировать строб)) с сумасшедшей точностью будет когда-нибудь...
сейчас по факту вот что удалось:
TС0 - повесил на счет времени по MCK/1024, в T0.RC=46800 (чтобы секунда была) по переполнению - выроботка прерывания
TС1 - в режиме формирования импульсов с установкой TIOA1 на RC=32767, и cбросом TIOA1 на RA=0 (режим (13<<15)|7)), тактируется TCLK2 (PA29)
TС2 - в режиме захвата (0x7), тактируется от TIOA1

И на мое удивление все заработало. Фиг знает что без вас бы делал...
хотя есть одна странность - TС2 почему то если есть такты TIOA1 - сбрасывается, если нет - не сбрасывается по AT91C_BASE_TC2->TC_CCR = AT91C_TC_SWTRG;
поэтому если снять сигнал с PA29 - TC1 сбрасывается, а TC2 сохраняет свое значение с последнего цикла измерения и висит в таком состоянии пока не подать снова сигнал на PA29...

Все бы хорошо, однако все бултыхается...
Сейчас на время отойдем от этих счетчиков и вернется к примитивному циклу...

вот отдельно код:

Код

while (1) do
{
         dataready=0;
      AT91C_BASE_TC1->TC_CCR = AT91C_TC_SWTRG;
      AT91C_BASE_TC0->TC_CCR = AT91C_TC_SWTRG;
          AT91C_BASE_TC2->TC_CCR = AT91C_TC_SWTRG;
        
        do
          {
                  UpperCounter++;    
          } while (dataready==0);

      for (i=8; i!=0; i--)
      {
            digit=(UpperCounter%10);
            UpperCounter=UpperCounter/10;
            infdd[i-1]='0'+digit;
          }
          
      pCDC.Write(&pCDC, infdd,10);    
}

смотрю выход USB-порта (значение UpperCounter):

Код

02819021
02819063
02819016
02819050
02819045
02819016
02819033
02819027
02819060
02819061
02819053

почему он так веляет от цикла к циклу? Это временной промежуток между прерываниями CT0 меняется, время исполнения команд или опорная частота плавает или еще чего? Можно ли как то это синхронизировать и все таймеры для кучи одновременно сбрасывать?

Сообщение отредактировал abit - Jul 27 2011, 14:00