[Storejet 0]

У меня AT32uc3b0256. К нему по SPI должно быть подключено АЦП. Проблема в следующем: контроллер должен начинать считывать данные из АЦП по отрицательному фронту сигнала DRDY от АЦП. Для обнаружения этого фронта я собирался использовать прерывание. АЦП у меня пока не запаяно, поэтому имитирую сигнал DRDY c частотой 48 кГц спомощью GenericClock. Сгенерированный сигнал подаю на вход контроллера внешних прерываний. В обработчике прерывания пишу формирование небольшого импульса на другой произвольной линии GPIO, короче дергаю ножкой. Все это дело завел на осциллограф и вижу что прерывание приходит с запазданием гдето в 3 мкс!! Частота тактирования процессора и переферии 48 мГц. Проблема в том что я не буду успевать считать все данные с АЦП. Поднять частоту SPI тоже нет возможности. Не понимаю почему такая задержка???

[Dopler 0]

Какой менеджер прерываний вы используете? Если из framework, то он далеко не оптимальный по скорости. Вообще в вашем случае лучше использовать SSP с кадрами вместо SPI.

[Storejet 0]

Механизм считывания данных с АЦП определялся не мной, да и поздно уже его менять. Пользуюсь функциями из framework. Если честно, то я новичок...поясните как можно по-другому сделать обработку прерывания

[Dopler 0]

Вот, почитайте.

http://www.utasker.com/forum/index.php?topic=679.0

 

Все же рассмотрите вариант переговорить с тем, кто определяет "Механизм считывания данных с АЦП". Может быть он согласится переключить 3 линии на SSP. Это очень сильно облегчит вам жизнь.

[Storejet 0]

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

[Infernomen 0]

Какой менеджер прерываний вы используете? Если из framework, то он далеко не оптимальный по скорости.

Столкнулся почти с такой же задачей, как и автор тоста, и у меня так же возникает задержка 2-3 мкс при входе в обработчик прерываний, при использовании менеджера прерываний из framework'a.

 

В менеджере прерываний из framework таблица векторов в RAM лежит, так же как и в приведенном Вами варианте по ссылке её в RAM переносят, в чем тогда выгода?, а если код функций-обработчиков прерываний в RAM перенести получим еще большую скорость обработки прерываний? Только как это в коде на языке С реализовать?

 

Вообще в вашем случае лучше использовать SSP с кадрами вместо SPI.

В AVR32 это SSC контроллер?

[Dopler 0]

Столкнулся почти с такой же задачей, как и автор тоста, и у меня так же возникает задержка 2-3 мкс при входе в обработчик прерываний, при использовании менеджера прерываний из framework'a.

 

В менеджере прерываний из framework таблица векторов в RAM лежит, так же как и в приведенном Вами варианте по ссылке её в RAM переносят, в чем тогда выгода?, а если код функций-обработчиков прерываний в RAM перенести получим еще большую скорость обработки прерываний? Только как это в коде на языке С реализовать?

Посмотрел код примера из Framework и с ходу ни асилил. Понятно только, что во Framework еще анализируют ситуацию, когда на одну группу приходится несколько прерываний. Код в ссылке значительно более понятен.

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

 

В AVR32 это SSC контроллер?

Да SSC, SSP - это я просто описался.

[Infernomen 0]

Посмотрел код примера из Framework и с ходу ни асилил. Понятно только, что во Framework еще анализируют ситуацию, когда на одну группу приходится несколько прерываний. Код в ссылке значительно более понятен.

 

В приведенном примере мне вот только не понятно какой адрес кроется под INTC_BLOCK в строчке:

 

unsigned long *ptrIntPriority = (unsigned long *)INTC_BLOCK;

 

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

 

Приведенный пример не подходит, менеджер прерываний от IAR'a тоже только один обработчик на группу определяет....

 

Внутри обработчика определять источник прерывания что ли? - долго ведь будет...

[skyvmicro 0]

Привет.

Пару слов по поводу времени входа в обработчик прерывания.

Взял пример с таймером для AT32UC3A0512 и посмотрел в

отладчике (AVR STUDIO5) задержку от момента возникновения прерывания

(сравнение с содержимым С) и до первого оператора обработчика

таймера. Получилось всего "ничего" - 104 цикла (1.76 мкс при частоте 14.74*4МГц).

Думал AVR32 шустрее в этом деле.