[Mavric84 0]

Хотелось бы услышать мысли,

 

В моем устройстве не задествована команда (0000) - подтверждения прерывания, может ли причина заключаться в этом?

[Harbour 0]

Могу ошибаться - но эта команда до спины, нужна если не хочется делать логику подтверждения самому, а получать ее через стандартный интерфейс PCI. Т.е. хост все равно никак не узнает получил девайс эту команду или нет - обычно megacore ее должен тихо принимать, даже если девайс ее не поддерживает, обязана ли корка снимать запрос по ее приходу - это наверное отдельный вопрос. Вот на столе нормально работает девайс с отключенной командой подтверждения, проверялось на 2 chipset'ах - nforce mcp51 и какой-то embedded via в shared варианте и с отдельным apic interrup'том. В shared варианте почти вся периферия сидела на прерывании девайса (usb/sata/sound), правда ос - linux.

[yuri_d 0]

А как выполняется обработка прерывания? Особенно интересует заключительная часть.

 

Подозреваю, что проблема связана с неправильной работой с котролером прерываний (клон 8259A), установленном на системной плате. Этому контролеру требуется указать, прерывание обработано, для того, чтобы снова разрешить обработку данного вида прерываний. Обычно делается это записью команды "nonspecific EOI" (с кодом 0x20) в порт 0x20. Если PCI прерывание находится на старших векторах (от 8 до 15), то команду нужно посылать на оба PIC-а (второй расположен по адресу 0xA0).

[Mavric84 0]

А как выполняется обработка прерывания? Особенно интересует заключительная часть.

 

Подозреваю, что проблема связана с неправильной работой с котролером прерываний (клон 8259A), установленном на системной плате. Этому контролеру требуется указать, прерывание обработано, для того, чтобы снова разрешить обработку данного вида прерываний. Обычно делается это записью команды "nonspecific EOI" (с кодом 0x20) в порт 0x20. Если PCI прерывание находится на старших векторах (от 8 до 15), то команду нужно посылать на оба PIC-а (второй расположен по адресу 0xA0).

 

Да это уже мне подсказали, спасибо.

 

Но загвостка вся в том что, по словам программиста, записи по этим портам в 8259 производяться в ДОСе, а в МСВС это встроенно в систему (что исключает потребность производить данный операции с 8259)... но это мы еще проверим..

[gab 0]

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

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

 

Xilinx является мостом шина ввода\вывода to PCI )

 

Получается так. 1 прерывание проходит, 2 не проходит, 3 проходит 4 не проходит и.т.п. но если сделать вот так

 

1-е прерывание проходит,(пошевелил мышкой) 2-е проходит, 3-е проходит, пошевелил мышкой, 4-е проходит

Скорее всего проблемы с буферизируемостью чтения/записи регистров устройства. Под линуксом лечаться rmb(). wmb() в обработчике прерывания (принудительный сброс кэша в область памяти). Под виндами ищите аналог сами.

Ну и главный вопрос: как написан обработчик прерывания? Поддерживает-ли shared-прерывания?