Коллеги, а подскажите, как сделать так, чтобы компонент формировал не одно, а несколько прерываний (avs_interrupt)?
На данный момент компонент является ММ-слейвом с одним avs_interrupt, но возникла острая потребность в еще одном прерывании.
Пока что как вариант - делать у компонента еще один ММ-слейв-интерфейс.
Не очень понимаю как можно выйти из этой ситуации.
Полная версия этой страницы: Несколько прерываний от одного компонента
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Системы на ПЛИС - System on a Programmable Chip (SoPC)
а чем не устраивает обычная схема, когда компонент генерирует прерывание по наступлении нескольких событий (ограничивается регистром типа interrupt_mask) и взводит соотв. флаг в статусном регистре, чтобы обработчик прерывания мог определить, какое событие вызвало прерывание?
Да, это простое и удобное решение, но:
Дело в том, что на этом прерывании сидит rtos-задача, которая читает из фифо данные. Данные должны быть вычитаны максимально быстро (то есть, в прерывании ничего больше быть не должно - любая проверка масок и прочие чтения регистров приведут к задержке, хоть и небольшой, но в моем случае это критично).
Поэтому и возникла мысль применить еще одно прерывание для остальных вещей.
Дело в том, что на этом прерывании сидит rtos-задача, которая читает из фифо данные. Данные должны быть вычитаны максимально быстро (то есть, в прерывании ничего больше быть не должно - любая проверка масок и прочие чтения регистров приведут к задержке, хоть и небольшой, но в моем случае это критично).
Поэтому и возникла мысль применить еще одно прерывание для остальных вещей.
Цитата(spectr @ May 12 2011, 15:35) 
Да, это простое и удобное решение, но:
Дело в том, что на этом прерывании сидит rtos-задача, которая читает из фифо данные. Данные должны быть вычитаны максимально быстро (то есть, в прерывании ничего больше быть не должно - любая проверка масок и прочие чтения регистров приведут к задержке, хоть и небольшой, но в моем случае это критично).
Поэтому и возникла мысль применить еще одно прерывание для остальных вещей.
Дело в том, что на этом прерывании сидит rtos-задача, которая читает из фифо данные. Данные должны быть вычитаны максимально быстро (то есть, в прерывании ничего больше быть не должно - любая проверка масок и прочие чтения регистров приведут к задержке, хоть и небольшой, но в моем случае это критично).
Поэтому и возникла мысль применить еще одно прерывание для остальных вещей.
а вы какой контроллер прерываний используете?
VIC не использую, значит обычный. Первой мыслью было применить VIC, но насколько я понял из описания, к VIC можно подключать только прерывания с авалоновских интерфейсов...
Цитата(spectr @ May 12 2011, 17:20)
VIC не использую, значит обычный. Первой мыслью было применить VIC, но насколько я понял из описания, к VIC можно подключать только прерывания с авалоновских интерфейсов...
так а у вас в первом сообщении и есть авалоновский интерфейс
Да, но мне нужно получить несколько прерываний с _одного_ интерфейса, а на VIC, насколько я понял, можно подключать N прерываний с N авалонов (по одному с каждого).
а кто мешает компоненту иметь несколько интерфейсов? хотя я бы сначала попробовал VIC с одним прерыванием и чтением контекстного регистра. больше того, я бы не стал доверять чтение из FIFO программе, коль скоро стоит задача вычитать максимально быстро. гораздо кошернее использовать для этого DMA с соотв. прерыванием
Цитата(spectr @ May 12 2011, 12:35)
Да, это простое и удобное решение, но:
Дело в том, что на этом прерывании сидит rtos-задача, которая читает из фифо данные. Данные должны быть вычитаны максимально быстро (то есть, в прерывании ничего больше быть не должно - любая проверка масок и прочие чтения регистров приведут к задержке, хоть и небольшой, но в моем случае это критично).
Дело в том, что на этом прерывании сидит rtos-задача, которая читает из фифо данные. Данные должны быть вычитаны максимально быстро (то есть, в прерывании ничего больше быть не должно - любая проверка масок и прочие чтения регистров приведут к задержке, хоть и небольшой, но в моем случае это критично).
Так у Вас ведь время реакции на прерывание много больше времени проверки бита в регистре. Бит-то проверить - 1 команда прочитать регистр, 1 команда лог. AND, 1 команда - условный переход. Если ниос и проц не самый простой - вроде как 3 такта займет (или около того) проверка бита. Это всяко десятки-сотни наносекунд, а реакция на прерывание если мне память не изменяет микросекунды. Стоит ли из-за наносекунд огород городить?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.