@Jin X

Приветствую вас!

При появлении запроса на прерывание (IRQ) в регистре запросов прерывания IRR контроллера 8259A устанавливается бит, соответствующий этому прерыванию. Если бит регистра обслуживаемых запросов ISR того же прерывания (и всех более приоритетных) сброшен и прерывание незамаскировано (в IMR или через cli), процессор подтверждает прерывание и соответствующий бит в IRR сбрасывается, а в ISR устанавливается. После отправки команды EOI сбрасывается и бит регистра ISR, разрешая процессору снова прерывать выполнение кода вызовом обработчика того же прерывания (и менее приоритетных). Соответственно, поскольку после подтверждения прерывания процессором бит в IRR сбрасывается, он в любом момент может быть установлен снова, а значит, если мы ещё не завершили обработку прерывания, по после отправки EOI и выполнения iret/sti обработчик будет вызван снова.

Мне необходимо предотвратить эту ситуацию и сбросить соответствующий бит регистра IRR перед выходом из обработчика прерывания (iret), ну или перед отправкой EOI. Вопрос: как это сделать?
Регистр IRR можно без проблем прочитать, интерфейс для этого есть, а вот с записью проблема...

Вот тут написано:
Значит, стало быть, каким-то образом IRQ может быть снято? Как это сделать, как сбросить бит регистра IRR?

Добавлено через 1 минуту
Вариант инициализации контроллера прошу не предлагать

0

@Ethereal

Имеется ввиду внешним устройством снимается. Программно и прямо никак. IRQ - это сигнал на шине от внешнего устройства. И внешнее устройство хочет, этот сигнал выставляет, не хочет не выставляет. На выставление этого сигнала внешним устройством можно влиять только косвенно, при обработке прерывания как-то его ублажив.

По моему в том абзаце, что ты процитировал, тот кто его писал сам не понимал, что писал.
Если выставление сигнала IRQ защелкивается в каком-то триггере внутри 8259A, то после размаскирования прерывание должно произойти, неважно выставлен ли сигнал IRQ к этому моменту или уже был снят. А если выставление сигнала IRQ не защелкивается, то какой тогда смысл писать Когда возникает запрос на прерывание, который замаскирован разрядом в IMR, он не теряется когда при снятии сигнала IRQ он именно-что теряется.

В общем надо найти более вменяемое описание.

Добавлено через 11 минут
З.Ы. У Искры-1030.11 был не RS-232, а Стык-С2. Когда-то я самодельную схему нарисовал, мой друг развел плату RS-232 для Искры и спаял и мы подключали по ночам Искру через модем к Униксовому серверу на моей работе. Так вот когда мы это делали, я так и не понял как по уму прерывания должны работать. Наша плата идеально работала в режиме опроса готовности и фидошным софтом мы почту принимали и терминалом telnet-ом на серверок заходили. Но стоило попробовать любой софт, что работал с RS-232 по прерываниям, как стоило только одному прерыванию произойти, тут они и начинали валить бесконечно. Масла в огонь подливало то, что у Искры была совсем другая шина, чем у ПК и спецификации на Искровскую шину мы не имели. Только схему самой Искры и по ней только догадывались как должно работать. У ПК-то шина синхронная, а у Искры была асинхронная. Так вот тогда я так и не понял как работает сигнал IRQ - фронтом или уровнем. Получалось по факту, что уровнем и в результает выходила полная херь с бесконечными прерываниями. Но вот как оно должно было работать на самом деле и как мне переделать схему я так и не понял. И вот у тебя теперь похожая фигня. Есть какие-то описания, но тот кто их писал, делал это явно в невменяемом состоянии. Ну или смотрел на это дело как программист, который как оно работает электрически просто не задумывается. И в итоге от этих описаний все равно остается непонятка.

Добавлено через 2 минуты
З.З.Ы. Во чего нашел
Помимо собственно инициализации контроллеров, необходимо указать, какие линии IRQ будут обслуживаться по уровню сигнала, а какие — по его фронту. Это осуществляется записью нужных значений в регистры ELCR (порты 4D0h и 4D1h для ведущего и ведомого контроллеров соответственно). Пять линий — IRQ0, IRQ1, IRQ2, IRQ8 и IRQ13 — всегда программируются на реакцию по фронту сигнала; соответствующие им биты регистров ELCR должны быть равны нулю. Остальные линии могут программироваться на реакцию как по фронту, так и по уровню.
Видимо на этом я когда-то и накололся. Хотя нет, а откуда на Искре порты > 3FFh ?
Ну так в любом случае тебе надо выставить обработку IRQ по фронту. Тогда тем-же уровнем IRQ никакой бит IRR заново выставляться не будет. А вот если внешнее устройство быстренько пошлет два фронта подряд, вот этого ты уже никак не победишь. Раз запросы на прерывание были, так будь добр обработать.

Добавлено через 6 минут
Или в обработчике прерывания маскируй прерывания и через некоторое время эту маску снимай. В любом случае ты не объяснил зачем собираешься нарушить логику работы прерываний ? Ведь ты собираешься некоторые запросы на прерывание тупо пропускать. Зачем делать криво, если было прямо ?

1

@Kukuxumushu

Ethereal, более понятно объясняю:
1) всё, что приходит в 8259, защёлкивается в IRR, всегда, аппаратно, вне зависимости от состояния IMR
2) как только возникает возможность обработать прерывание, этот бит из IRR кочует в ISR, что означает "прерывание в процессе"
3) Jin X обрабатывает прерывания довольно долго и существует риск, что в это время в IRR асинхронно ещё чего-нибудь защёлкнется, и сразу же по выходу из обработчика опять уйдёт на вот это прерывание, которое было "в очереди", но "просрочилось" и уже не нужно
4) ему надо каким-либо образом отменить пункт 2, сбросив IRR перед выходом из первого прерывания, чтобы второе сразу же не возникло
5) документация по этому вопросу очень слабая, не очень внятно описан даже алгоритм отклонения запросов контроллером 8259, про возможность сброса IRR не написано вообще ничего, кроме одной фразы одного чувака с WASM, что якобы определённая комбинация бит в одной из управляющих команд позволяет это сделать (не знаю, проверял ли этот способ Jin X).

1

@Ethereal

Ты бы вместо того чтобы объяснять вопрос одного человека другому человеку, на сам вопрос-бы ответил. Добровольный помошник, блин. Ну так я-же сказал перевести контроллер прерываний для данной линии IRQ в режим работы по фронту. Тогда в IRR ничего не защелкнется асинхронно.

1

@Kukuxumushu

Он ловит IRQ 0 от таймера, который и так уже в режиме прерывания по фронту.
Интересно вот, что будет, если его наоборот перевести в режим прерывания по уровню???

1

@Ethereal

Блин, сорри, вспылил. Но уж в очень неудачной форме был твой пост.

Добавлено через 9 минут
Блин. Ну вот можно было бы об этом и сразу сказать. Значится хочет ловить прерывания от таймера и хочет задержаться в нем подольше и наверное всякие видеоэффекты рисовать. А тем временем таймер может еще раз тикнуть и еще раз. И надо защелкнутый запрос на прерывание помножить на ноль. Ну не видать нигде в описаниях этой чипы даже намека, что так программно можно сделать. Недокументированная возмозмость такого может быть, конечно. Но тут придется контроллер прерываний всеми возможными сочетаниями бит в управляющих командах высношать, пока это найти.

Добавлено через 6 минут
В том-то и дело. В своем длинном посту в самом верху я написал одну неправильную вещь, глянул в PDF и неправильность стала ясна. Но недоумение-то все равно осталось. Я не понимаю как контроллер прерываний может работать по уровню. Или выставление этого уровня должно быть минимально короткое - длиной в один такт на шине или неизбежен обвал повторных прерываний, ну прям как тогда у меня на Искре.
Вот от уровня IRQ выставился бит в IRR. Вот пошло прерывание. Бит в IRR сбросился, выставился в ISR. Но если идет работа по уровню и IRQ все еще стоит, то IRR тут-же снова выставится и повторное прерывание сразу после обработки первого неизбежно. Если IRQ продолжает стоять, то будет и третье прерывание и четвертое.
IRQ 0 небось работает по фронту именно потому, что на эту линию наверно тупо поступает частота кварца 14.3 Mhz деленная на 12, а не кратчайшие импульсы.

Добавлено через 44 минуты
Идея :
А вообще, почему бы у таймера в начале обработчика прерывания не изменить значение самого старшего бита старшего байта так, чтобы до конца работы обработчика таймер не переполнился, а перед выходом из обработчика откорректировать бит обратно. Тогда регистр IRR во время работы обработчика выставляться не будет. Переполнение таймера ведь при полном диапазоне 0..FFFF 18.2 Гц, а частота кадровой развертки изображения более чем в 3 раза больше. Т.е самый старший бит переворачивать можно безболезненно.
Я так понимаю, что если происходит прерывание по переполнению таймера, то на входе в обработчик до момента инкремента старшего байта еще далеко и можно не глядя корректировать. Надо подумать как не нарваться корректировкой на момент инкремента старшего байта на выходе из обработчика. Ну чтобы случайно не потерять 256 тиков.

1

@Jin X

Эта тема относится к Номер текущей строки CRT-луча
Там да, как раз IRQ 0. И его перенести на "уровень" нельзя, он всегда работает по фронту (хотя я, честно говоря, не совсем понимаю разницы).
IRQ 0 может обрабатываться долго только в начале кадра (я даже уверен, что он пару IRQ-запросов "проглотит"). В общем-то, я придумал, как эту проблему решить. Там счётчик программно настраивается, так вот можно в самом начале этой "долгой обработки" выставить счётчик на максимум (0=65536), 55 мс хватит с лихвой (там и 1 мс хватит, но изначально таймер настроен на ≈ 30 кГц... да, да, вот такие скорости).

Эта комбинация (если она, конечно, работает) сбрасывает все биты. Т.е. если я, к примеру, нажму какую-то клавишу во время обработки прерывания, она просто можно не сработать.

Добавлено через 2 минуты
Опередил
Да, я примерно так и хочу сделать
Только там нельзя отдельный бит выставить, там сразу всё число записывается, так что пишем 0 и всё. Всё равно таймер каждый раз перенастраиваться (перезапускаться) будет.

1

@Ethereal

Одновременно написали

1

@Jin X

Кстати, раз уж речь об этом зашла. Если мы пишем не 2 байта в счётчик, а один (старший или младший), что происходит со вторым байтом? Т.е. было, скажем, 1234h. Если мы изменили 12h на 21h, то 34h не изменится или сбросится в 0? Ну и наоборот: если поменяли 34h на 56h, что будет с 12h? Надо бы протестить...

1

@Ethereal

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

1

@Jin X

И я так понимаю, тактовый генератор 1.19 МГц работает всегда в своём темпе, без перезапуска? Т.е. если я записал в счётчик какие-то число, он же (генератор) не перезапускается в этот момент, а продолжает работать (перезаписывается только значение счётчика).

Схематично (1 строка с частотой 1.19*4 МГц) значения счётчика:
100
100
100
100
99
99
99
99
98
98
тут я записал в счётчик 200, далее будет:
199
199
198
198
а не:
199
199
199
199
198
198
...
???

Добавлено через 4 часа 18 минут
Потестил. Очень забавно всё работает. Во-первых, при любом раскладе, если записываем 1 байт (только младший или старший), то изначально в счётчик заносится 2 одинаковых байта (на ноуте при записи в младший байт в старший заносится значение на 4 меньше, чем в младший, в DOSBox или при записи в старший такого нет).
Далее...
Если пишем только младший байт, счётчик уменьшается по 101h на каждый тик:

Если пишем только старший байт, счётчик уменьшается тоже по 101h, но не на каждый тик, а раз в... (101h тиков?)

Причём, забавный факт (если вы заметили в спойлерах): на первый раз значение иногда больше на 1, чем в последующий (в DOSBox такого нет).
Это всё для режима 2. Для режима 3 числа меняются в 2 раза быстрее (что, в общем-то, неудивительно) и разница не 4, а 8.

И ещё прикол: делаю последовательное чтение в цикле в буфер с включенным cli (прога под DOS на паскале). Запускаю на ноуте, получаю значение раз в 5 циклов (почти ровно).

Почему так медленно, кто-нибудь знает???

1

ФедосеевПавел

0

@Ethereal

Ты не понял. В моем случае в Искру была воткнута моей разработки плата и в ней стояла вполне себе i8250 совместимая микросхема. Кажется 16C450, но уже не помню точно. Я только тогда неудачно прикрутил к шине Искры прерывания от этой микросхемы. Не в этом дело. Каждое изменение таймера происходит в момент прихода фронта клока, который получается делением частоты кварца на 12. На этот клок ты не можешь повлиять и сделать так, чтобы его фронты подстроились под моменты записи тобой в таймер новых значений.
В общем это не таймер не перезапускается, это клок, идущий на таймер не перезапускается, клочит и клочит сам по себе. Не обращая внимание на то, что ты в таймер в данный момент пишешь новое значение.

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

Добавлено через 9 минут
Не знаю в этом ли дело, но давным давно я обнаружил такую вещь. Не знаю справедливо ли это для современных ПК. Но тогда давно обнаружил такое - комп может быть иметь сколько угодно быстрый проц, но вот команды in и out насрамши на проц всегда будут исполняться около микросекунды. Поэтому я маленькие и стабильные задержки именно командами in и out делал. Может это было справедливо только для материнских плат с шиной ISA, не знаю, но может оказаться, что это и всегда так - in и out исполняются медленно, по времянкам шины, а не по тактовой частоте проца.

2

@Jin X

Я и подумал, что скорее всего так и будет. Но всё же решил спросить, мало ли...

Жесть, конечно. Ну вообще, я заметил, что и in из порта 3DAh тоже не так часто читает. Надо ещё не стационарном попробовать (то ноут был).

0