Здравствуйте.
Суть проблемы в том что я уже три недели не могу получить картину подтверждающую тот факт что АЦП этого контроллера способно выполнить преобразование за 1мкс.
Лучший из результатов который я получал был таков: между запуском АЦП и заходом в прерывание FIQ проходило 1,9мкс (500ksps).

Контроллер настроен на тактовую частоту 42,7МГц, АЦП настроен на максимальное быстродействие, обработчик прерывания размещен в RAM. Запуск АЦП по таймеру.

Хотелось бы спросить ваших рекомендаций на что можно еще обратить внимание, т.к. я первый раз работаю ARM и с 32-х разрядным контроллером вообще.

p.s. Еще один странный факт, если в главном цикле делаю мигание леда, через GP4CLR и GP4SET на выходе вижу максимум 10МГц... судя по полученному из кейла ассемблеру там 2 инструкции... на каждую по 2 такта? и где обещанные 40MIPS на 40МГц?

Заранее благодарен.

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

Посоветуйте способы улучшения быстродействия выполнения кода на ARM. (Пишу на С, компилятор Keil)

Заранее благодарен.

"Ужасное" время обработки имеет какое-нибудь количественное выражение?
Способы улучшения быстродайствия напрямую зависят от задачи; Signal Processing - мягко говоря,
не самая сильная сторона ARM

Скажем так, время сохранения результата и перезапуска АЦП превышает время преобразования в 1,5-2,5 раза даже при размещении обработчиков в RAM... смысл измерять с 1мспс, если я даже сохранять результат так быстро не могу?

Сообщение отредактировал UserXP - Oct 26 2006, 13:13

К сожалению апноты по АДуКам ниже плинтуса. Код в студию. Вместе и подумаем.

Cначала было так:
#define LED_ON GP4CLR = 0x00040000
#define LED_OFF GP4SET = 0x00040000

void My_funk_ram (void) __ram
{
ADCCON |= BIT0|BIT1|BIT7; //запуск конверсии
ADCCON &= ~BIT7;

while (1)
{
while (!ADCSTA){}
LED_OFF;
ADCResult = (unsigned short)(ADCDAT>>16);
ADCCON |= BIT0|BIT1|BIT7; //запуск конверсии
ADCCON &= ~BIT7; //защита от случайного запуска по пину
LED_ON;
}
}
функция запускается из мейна, т.к. как загнать сам мейн в RAM я так и не понял

Потом сделал
#define MY_ADCDAT (*(volatile unsigned short *) 0XFFFF0512)
и заменил
ADCResult = (unsigned short)(ADCDAT>>16);
на
ADCResult = MY_ADCDAT;
судя по ассемблеру минус три инструкции MOV

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

Сообщение отредактировал UserXP - Oct 27 2006, 07:46

А какова конечная цель работы АЦП? А то в этом примере результат работы как видно неважен :-). Потому что обычно кучу времени съедает раскладка полученных данных в буфер и проверка окончания цикла.
А как сконфигурен ADCCON? Там же все зависит от настройки клоков в битах 10-12 и 9-8. Кстати, гнаться за минимальным ADC acquisition time нестоит-тогда нужен мощнай драйвер входа АЦП и ошибки становяться слишком большие. Намного лучше чем в референсном дизайне несделать ftp://ftp.analog.com/pub/www/technology/d...source_code.zip
Можно только выиграть на раскладке данных в пямять при многоканальном сборе данных.
А дерганье ЛЕДа вообще все тормозит. К сожалению АД не приводит данных по конкретной реализации внутренностей портов ИО, но все помнять проблемы филипса с "дрыгоножеством", когда пришлось вводить дополнительную периферию фастио. Поэтому для измерений лучше выпустить наружу сигнал ADCBUSY и использовать его для контроля быстродействия.

АЦП имеет быстродействие 1MSPS, а процессор - 40MSPS.
Таким образом за время одного преобразования реально выполнить
около 10 простых С операторов.

Кстати, по поводу быстродействия.
Читайте на странице №33 даташита:
41Mips - в режиме Thumb,
20Mips - в режиме ARM.
Это связано с тем, что flash имеет ширину 16 бит и для выборки 32-битной команды в режиме ARM требуется 2 такта.


При работе АЦП на максимальной скорости не пользуйтесь прерываниями.

Да, я привел пример на котором я увидел что конверсия длиться меньше 1мкс, и запись и перезапуск длятся чуть больше 1 мкс..
Если я обмеряю два канала и рассовываю все по разным массивам то время обработки вырастает в разы...

По поводу acquisition time... я тестил разные значения и не заметил ухудшения при установке 2 клоков... ухудшения точности измерений происходят при снижении vref'а ниже 1 вольта
А ADC clock speed = 000 т.е. делитель частоты = 1;



У меня другой даташит но именно поэтому функии засунуты в оперативку...

Чтобы не быть голословным сейчас у меня такой код
while (1) //Главный цикл
{
if (ArrIn[0]!=0) Common(); //Если пришла посылка по уарту - обработать


if (fADC==2) // если запущен АЦП висим тут
{
while (!ADCSTA)
{} //Ждем завершения преобразования
LED_OFF;
if (ADCCP==1)
{
ADCResult[ADCCount/2] = MY_ADCDAT; //Сохраняем результат
ADCCP = 0x02;
}
else
{
ADCResult[48+ADCCount/2] = MY_ADCDAT; //Сохраняем результат
ADCCP = 0x01;
}

ADCCount++;
T0CON |= BIT7;

if (ADCCount>95) //если набрали 96 байт
{
T0CON &= ~BIT7; // останавливаем запускающий таймер
fADC = 0; //снимаем флаг
ADCCount = 0; //обнуляем счетчик
}
}
}

Теперь можно сделать вывод, что работа процессора соответствует документации на него.

Сам на 26-м столкнулся и не поверил. Ситуация - один в один. А потом почитал про Interrupt Lattency и все стало ясно - до 50 циклов, что при частоте 41.78 дает 1.2 мкс. Ужас!