Две таблицы векторов в одном софте, xmega Опции

[xelax]

Привет всем!

Тут некоторых коллег посетила нездоровая идея иметь два вектора прерывания на одну периферию (NVM eeprom и flash).
Одна таблица в application другая в bootloader секции. И всё это должно жить в одной программе. В возможности иметь две таблице векторов прерывания для xmegа я не вижу никаких технических препятствий, то как это реализовать в одном софте средствами компилятора и линкера пока не понимаю. Не могу же я иметь две функции

Код

ISR(NVM_EE_vect)

Пока не вижу другого способа кроме как для application секции формировать таблицу посредством макросов ISR, а для bootloader формировать её в рукопашную, размещая jmp на обработчики по фиксированным адресам из bootloader и добавляя в функции обработки рукописные прологи и эпилоги.

Но уж очень этот вариант на камасутру похож. Может кто-то знает более красивые варианты решения?

[xelax]

Так камни с ядром avr имеют гарвардскую архитектуру и умеют исполнять код только из FLASH области, к сожалению это не cortex .

[defunct]

Так камни с ядром avr имеют гарвардскую архитектуру и умеют исполнять код только из FLASH области, к сожалению это не cortex .

И что с того?
В ОЗУ для каждого вектора пусть лежит адрес обработчика, а по реальному вектору прерывания во флеш пусть лежит буквально следующий код:

Код

lds zh, high( vector_i )
lds zl, low( vector_i)
ijmp

Где vector_i - переменная в ОЗУ.

Если с асмом туго, переместите все вектора в область бутлоадера, и состряпайте Сишные wrapper'ы:

Код

ISR( vect_xxx)
{
     if (handlers[ vect_xxx ])
         handlers[ vect_xxx ]();
}

где "handlers" массив в ОЗУ, где каждый элемент - адрес обработчика.

Но не думаю, что IAR C умеет ее использовать для целей, потребных топикстартеру.
Все-таки 2 отдельных проекта реальнее, чем так извращаться на Си

Toolchain от IAR включает еще и транслятор Asm'а. Создаете .s файл, пишете в нем код таблицы векторов, и линкером кладете в секцию таблицы векторов вот и всего делов.

__interrupt __raw void irqUSART0_RXC (void)
{
interrupt_entry ();
(* Ufunc_ptr)();
interrupt_exit ();
}

Не вижу смысла в ручных entry / exit.
Надо просто тупо вызвать функцию.

[vvppvv]

Не вижу смысла в ручных entry / exit.
Надо просто тупо вызвать функцию.

Тупо можно на этапе изучения контроллера, системы команд и написания первых "Hello, World". Дальше "тупо" - не надо. У меня перед объявлением программ прерываний стоИт __raw. Это совсем не просто так. Оптимизатор IAR спотыкается о косвенный взов, и начинает, как Вы говорите, "тупо" сохранять все регистры. Поэтому были составлены специальные inline-функции interrupt_entry (); и interrupt_exit (); Просто я выдрал пример из конкретного проекта, и немного его "не очистил" от лишнего, не относящегося к теме )

[defunct]

У меня перед объявлением программ прерываний стоИт __raw.

Как тут на форуме кто-то сказал - "в японии проходит ежегодный конкурс на самое сложное решение простой задачи, может быть вам стоит отправить туда и свое решение?" )
Особый интерес наверняка проявят к программке-доработке компилятора, для анализа используемых регистров в подменяемых функциях. )

как Вы говорите, "тупо" сохранять все регистры.

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

У меня перед объявлением программ прерываний стоИт __raw. Поэтому были составлены специальные inline-функции interrupt_entry (); и interrupt_exit ();

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

Тупо можно на этапе изучения контроллера, системы команд и написания первых "Hello, World". Дальше "тупо" - не надо.

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

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