возврат параметров из прерывания, как передать измененные переменные из прерывания в программу Опции

[robix]

Всем привет!
заметил странную особенность в программировании NIOSII. При вызове обработчика прерывания передаю ему контекст в виде переменной, похоже он передается по значению, поэтому переменная не меняется при возврате в программу. Ну это еще ладно, я изменяю значение глобальной переменной в обработчике прерывания, по возврату из прерывания ее значение не меняется. И самый прикол, такое ощущение, что при обращении к глобальной переменной в обработчике создается постоянная переменная, которая видна только в обработчике прерывания. Кто нибудь может прокомментировать такое поведение? Как мне вернуть переменную из обработчика прерывания?

#include "system.h"
#include "alt_types.h"
#include "altera_avalon_pio_regs.h"
#include "sys/alt_irq.h"

alt_u8 led = 0x0;
volatile int i,j;

static void timer_0_isr (void* context){
led++;
IOWR_ALTERA_AVALON_PIO_DATA(LED_BASE, led);
IOWR_16DIRECT(TIMER_0_BASE, 0, 0);
}

int main(void)
{
IOWR_ALTERA_AVALON_PIO_IRQ_MASK(SW_BASE, 0xf);
alt_ic_isr_register(TIMER_0_IRQ_INTERRUPT_CONTROLLER_ID, TIMER_0_IRQ, timer_0_isr, led, 0);

while(1){
for(i = 0; i < 5000000; i++);
led = 0;
IOWR_ALTERA_AVALON_PIO_DATA(LED_BASE, led);
}
return 0;
}

Сообщение отредактировал robix - Mar 1 2011, 17:30

[sergeeff]

Что-то мутное у вас многое в программе.

1. Функция обработчика прераваний не может иметь параметров. В функцию параметр передается через регистр или стек, в зависимости от процессора и/или компилятора, и делает это вызывающий контекст. Посему

Код

static void timer_0_isr (void);

2. Вас интересует переменная led. Ну и объявите ее

Код

volatile int led = 0x0;

и будет вам счастье.

[vadimuzzz]

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

почему это не может? еще как может:

alt_ic_isr_register()
...
Prototype:
int alt_ic_isr_register (alt_u32 ic_id, alt_u32 irq, alt_isr_func isr, void* isr_context, void* flags)
...
The function arguments are as follows:
■ ic_id is the interrupt controller ID as defined in system.h, identifying the external interrupt
controller in the daisy chain. This argument is ignored if the external interrupt controller
interface is not implemented.
■ irq is the IRQ number, as defined in system.h, identifying the interrupt to register.
■ isr is the function that is called when the interrupt is accepted.
■ isr_context is the input argument to isr. isr_context points to a data structure associated with the device driver instance.
■ flags is reserved.
The ISR function prototype is defined as follows:
typedef void (*alt_isr_func) (void* isr_context);

собственно, предполагается, что все переменные, который необходимы внутри обработчика прерывания, передаются через структуру context

[sergeeff]

Да уж, NIOS II это круто.

В функции

Код

extern int alt_ic_isr_register(alt_u32 ic_id,
alt_u32 irq,
alt_isr_func isr,
void *isr_context,
void *flags);

4-ый параметр - это указатель на ваш контекст, нe правда ли?

Тогда вы должны вызывать у себя в таком виде:

Код

alt_ic_isr_register(TIMER_0_IRQ_INTERRUPT_CONTROLLER_ID, TIMER_0_IRQ, timer_0_isr, &led, NULL);

а в обработчике, что-то типа:

Код

static void timer_0_isr (void* context){

  alt_u8 *pled = ((alt_u8 *)context;
  (*pled)++;
  IOWR_ALTERA_AVALON_PIO_DATA(LED_BASE, led);
  IOWR_16DIRECT(TIMER_0_BASE, 0, 0);
}

[ViKo]

С NIOS не знаком. Но, как и sergeeff, недоумеваю. Как в прерывание можно передать аргументы? Оно ж возникает в непредсказуемый момент. Кто ему что-то должен передать?

[robix]

Всем спасибо. Пока вышел из ситуации использованием объявления переменной с volatile.
Но, как я понял, эта проблема (c volatile) относится не только к прерываниям. Как понять когда его нужно использовать когда нет!?
У кого нить есть соображения по этому поводу? Пока, как я понимаю, его нужно пихать везде, где к одной и той же переменной нужно обращаться из разных областей видимости или может только для совместного использования с функциями оно нужно?

[vadimuzzz]

Как в прерывание можно передать аргументы? Оно ж возникает в непредсказуемый момент. Кто ему что-то должен передать?

ему передается структура, связанная с устройством (файл устройства, дескрипторы и прочая муть). передается при регистрации обработчика прерывания.

Но, как я понял, эта проблема (c volatile) относится не только к прерываниям. Как понять когда его нужно использовать когда нет!?

возьмите любой справочник по Си, там все расписано. это стандартная практика при работе в многопоточных окружениях. вот погодите, доберетесь до фокусов с data cache, там еще веселее

[robix]

С NIOS не знаком. Но, как и sergeeff, недоумеваю. Как в прерывание можно передать аргументы? Оно ж возникает в непредсказуемый момент. Кто ему что-то должен передать?

По поводу прерывания скажу, что в ниосе это очень полезная фишка, в смысле удобная, передавать в прерывание контекст обрабатываемого устройства, в общем мне нравится И вообще, мне вся эта схема разруливания прерываний в ниосе чем то напоминает менеджер задач. Интересно, учитывая наличие программных прерываний в ниосе, можно их использовать как независимые процессы!? кто нить пробовал?

[barabek]

Всем спасибо. Пока вышел из ситуации использованием объявления переменной с volatile.
Но, как я понял, эта проблема (c volatile) относится не только к прерываниям. Как понять когда его нужно использовать когда нет!?

Не совсем то, но в тему из NII software developers handbook

Код

For C programmers, note that declaring a pointer as volatile does not


cause accesses using that volatile pointer to bypass the data cache. The
volatile keyword only prevents the compiler from optimizing out
accesses using the pointer.


This volatile behavior is different from the methodology for
the first-generation Nios processor.

И, кажется, еще где-то видел (могу ошибаться), но как я понял слово volatile не всегда спасает от считывания старой (не актуальной) величины из кэша. Если ошибаюсь - поправьте, самому интересно.

[vadimuzzz]

И, кажется, еще где-то видел (могу ошибаться), но как я понял слово volatile не всегда спасает от считывания старой (не актуальной) величины из кэша. Если ошибаюсь - поправьте, самому интересно.

не спасает, за кэшем надо следить

[sergeeff]

не спасает, за кэшем надо следить

За кешем надо следить только, если не процессор пишет/читает данные, например DMA.

[vadimuzzz]

За кешем надо следить только, если не процессор пишет/читает данные, например DMA.

у меня все системы с DMA. и не с одним (неужели ниос кто-то без DMA применяет?)

[sergeeff]

у меня все системы с DMA. и не с одним (неужели ниос кто-то без DMA применяет?)

Никто не мешает буфера для DMA разместить в некешируемой области, к примеру.

[vadimuzzz]

Никто не мешает буфера для DMA разместить в некешируемой области, к примеру.

что-то не понял как, поясните

[alexPec]

что-то не понял как, поясните

А старший битик в адресе не означет некэшируемую область? По моему Вы мне про это и говорили летом...

[vadimuzzz]

А старший битик в адресе не означет некэшируемую область? По моему Вы мне про это и говорили летом...

это то, что я выше назвал "следить за кэшем". теперь представьте себе очередь пакетов для стека TCP, что делать с ней? целиком мимо кэша пробрасывать - просядет производительность. значит процессор должен работать с кэшированными пакетами, а при передаче управления контроллеру DMA сбрасывать их.