Linux Forum — Обработчик прерывания по IRQ 0, 8

Re: Обработчик прерывания по IRQ 0, 8

2015-01-17T08:36:59Z

Спасибо, в будущем, думаю, стоит обратить внимание - цена, действительно, доступная.

Re: Обработчик прерывания по IRQ 0, 8

2015-01-17T01:21:36Z

Aether пишет:

Пишечка - это PIC? Если да, то это тема ближайшего рассмотрения, точнее начинаю изучать PIC16F1454. Вопросы тоже имеются, нужна консультация

не... raspberry Pi... pic'и для линукса маловаты...

Re: Обработчик прерывания по IRQ 0, 8

2015-01-16T14:57:08Z

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

Пишечка - это PIC? Если да, то это тема ближайшего рассмотрения, точнее начинаю изучать PIC16F1454. Вопросы тоже имеются, нужна консультация.

Re: Обработчик прерывания по IRQ 0, 8

2015-01-16T09:40:36Z

Aether пишет:

тати, обратил внимание - используя таймер на малых интервалах (1-2мс) наблюдается отклонение времени исполнения фактического от запрошенного

hrtimer'ы пробовал?

Aether пишет:

Есть предложение использовать другую платформу?

как вариант arm, можно даже пишечку — на ней можно с прерываниями по GPIO поиграться...

Re: Обработчик прерывания по IRQ 0, 8

2015-01-16T08:38:04Z

IRQF_DISABLED, да, понял, похоже, не верно.

Fat-Zer пишет:

это всем хотелось бы, только вот сил на разработку собственного девайса под x86 ни у кого не хватает....

Есть предложение использовать другую платформу?

Кстати, обратил внимание - используя таймер на малых интервалах (1-2мс) наблюдается отклонение времени исполнения фактического от запрошенного, и оно растёт, если систему нагрузить, то есть фактически, без использования механизма прерываний невозможно обеспечить высокую чёткость работы. Конечно, это не всегда требуется, но, когда, например, производишь измерения, то, опоздав на пару мс, можно упустить актуальный результат.(

Re: Обработчик прерывания по IRQ 0, 8

2015-01-15T22:20:20Z

Aether пишет:

Так вот, я разложил 00015a20, и оказалось, что стандартный обработчик IRQ0 - timer содержит флаг IRQF_DISABLED, то есть по сути он выполняет роль заглушки

не правильно понимаешь: IRQF_DISABLED — это «запретить прерывания при входе в обработчик»... если верить этому, то сейчас это делается для всех обработчиков, а флаг оставлен для совместимости...

Aether пишет:

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

это всем хотелось бы, только вот сил на разработку собственного девайса под x86 ни у кого не хватает....

Re: Обработчик прерывания по IRQ 0, 8

2015-01-15T18:31:15Z

Недостатки постараюсь учесть)

Да, покопался и вот, что выяснил:

Консоль:

genirq: Flags mismatch irq 0. 00014200 (My_IRQ0) vs. 00015a20 (timer)

перед скобками и стоят, собственно, флаги IRQF, определённые в файле linux/interrupt.h.
Так вот, я разложил 00015a20, и оказалось, что стандартный обработчик IRQ0 - timer содержит флаг IRQF_DISABLED, то есть по сути он выполняет роль заглушки. Отсюда, также и следствие - счёт не идёт. Я проверил на стареньком Celeron 233 /proc/interrupts, там таймер скачет десятками тысяч.
Покопался далее, выяснил, что за системный счёт теперь отвечает APIC, и его тики подсчитываются, как у Вас и написано, в LOC (local timer).

В итоге, решил задачу, посредством включения timer.h, задав функцией setup_timer таймер и его обработчик. Тем не менее, хотел бы научиться, как можно использовать тики APIC более прямым образом? Мда, одни вопросы решаются, другие появляются.)

Re: Обработчик прерывания по IRQ 0, 8

2015-01-15T15:21:30Z

Aether пишет:

1) На IRQ0 или 8 - невозможно впринципе написать обработчик из-за монопольного использования линии текущим обработчиком?

да, по идее раздельное использование прерываний для разных устройств на x86 возможно только в рамках pci...

Aether пишет:

2) Если написать возможно, то, наверное, нужны другие IRQF флаги?

FYI: arch/x86/kernel/time.c

  static struct irqaction irq0  = {
      .handler = timer_interrupt,
      .flags = IRQF_DISABLED | IRQF_NOBALANCING | IRQF_IRQPOLL | IRQF_TIMER,
      .name = "timer"
  };

а если глянуть /proc/interrupts

Консоль:

CPU0 CPU1 CPU2 CPU3
0: 19 0 0 0 IO-APIC-edge timer
...
8: 4 1 0 0 IO-APIC-edge rtc0
...
LOC: 751701606 790091571 867486481 745563970 Local timer interrupts
...

то этих прерываний окажется как-то мало... не уверен до конца, что же ядро на самом деле использует для найминга... по идее должен использоваться hpet, он должен был бы эмулировать rtc и старый таймер и слать прерывания через них или занять отдельное прерывание... а ни того ни другого не видно... есть ещё внутренние прерывания APIC'а — вот их похоже и используют...

Обработчик прерывания по IRQ 0, 8

2015-01-12T14:21:34Z

Доброго дня.)

Занялся изучением вопроса установки собственных обработчиков прерываний. Написал простенькую программу. В ней всё работает, но, когда я пытаюсь выполнить:
insmod Mod_1.ko // в которой:

   N_irq = 0; //или 8; 0 - timer, 8 - rtc
   if (request_irq (N_irq, My_interrupt,
   IRQF_SHARED|IRQF_TIMER, "My_IRQ0", &D_irq)) return -1;

То на консоли вижу:

insmod: ERROR: could not insert module Mod_1.ko: Operation not permitted
dmesg показывает:
genirq: Flags mismatch irq 0. 00014200 (My_IRQ0) vs. 00015a20 (timer)

Как я понял, мне отказывают в регистрации обработчика из-за несоответствия флагов, отсюда вопросы:
1) На IRQ0 или 8 - невозможно впринципе написать обработчик из-за монопольного использования линии текущим обработчиком?
2) Если написать возможно, то, наверное, нужны другие IRQF флаги?

Пользование тегами code/console крайне желательно