Нетрадиционная обработка прерываний

[masterspammer]

Есть желание обсудить такую обработку невложенных прерываний с настраиваемым приоритетом - пусть у нас есть до 7 включительно каналов прерываний; при возникновении очередного сигнала устанавливается соответствующий бит в каком-либо регистре. Сигнал INI формируется при наличии как минимум одного бита в этом регистре, при подтверждении прерывания значение устанавливается на шине данных, дополненное нулём в D0, а регистр сбрасывается.

В режиме прерывания 2 у нас оказывается 127 возможных сочетаний (нуль невозможен) и вместе с регистром I - 127 чётных адресов. Вектор полностью определяет все активные на момент его поступления сигналы, например (младший байт) 0x06 означает два самых младших бита в регистре из предыдущего абзаца. Соответственно, нужно выполнить два обработчика в порядке приоритета (причём приоритет не обязан быть транзитивным).

В нулевом режиме прерывания можно примерно так же формировать одну из 7 команд RST для обработки трёх источников.

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

[Alekcandr]

Сложно вот так сразу по исходным данным, что-то посоветовать. Хотя вот вспомнился простой приоритетный контроллер на 8 прерываний из Орион-Про (555ИВ1 + 555АП6).

[masterspammer]

Сложно вот так сразу по исходным данным, что-то посоветовать. Хотя вот вспомнился простой приоритетный контроллер на 8 прерываний из Орион-Про (555ИВ1 + 555АП6).

Посмотрел схему - кажется мне, там если придут вместе два сигнала, то будет обработан только один, а не оба в порядке важности.

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

[Alekcandr]

Посмотрел схему - кажется мне, там если придут вместе два сигнала, то будет обработан только один, а не оба в порядке важности.

Да схема отвечает только за приоритет и формирование вектора.

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

[masterspammer]

Да схема отвечает только за приоритет и формирование вектора.

Сдается мне за этим должен следить инициатор прерывания, что бы не было повторного прерывания, пропуска прерывания и прерывание гарантировано было обработано.

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

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

С таких рассуждений моя идея и началась. Так можно, кстати и несколько разных маскируемых сделать.

[Alekcandr]

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

Регистр это я громко сказал. Достаточно одного триггера и не сложного адресного дешифратора (лучше даже порт использовать). Взводить триггер по необходимости прерывания, а сбрасывать по заднему фронту адресного дешифратора. Вполне себе независимая "единица" источника прерывания получается. Ну а маскировать тогда программно, а то железка начнет разрастаться. Пока как-то так мне это ведется.

Так сказать зашел с другой стороны

p.s. Я еще тот схемотехник. Все эти мысли по мотивам MSX.

[masterspammer]

Регистр это я громко сказал. Достаточно одного триггера и не сложного адресного дешифратора (лучше даже порт использовать). Взводить триггер по необходимости прерывания, а сбрасывать по заднему фронту адресного дешифратора.

Но это на каждую линию, а можно общее на весь механизм. Регистр выставляется на шину данных и тут же сбрасывается; если по-моему (7 бит - вектор в IM2), то весь, если по-орионовски, то только один его бит (установить значение = регистр XOR дешифратор того, что на выводе шифратора).

И в Орионе-Про нет такого провода на разъёме прерываний, чтоб уведомлять, там HOLD зачем-то хотя можно и INTA притащить.

Вполне себе независимая "единица" источника прерывания получается. Ну а маскировать тогда программно, а то железка начнет разрастаться. Пока как-то так мне это ведется.

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

OOPS! Выше я ошибся - имел в виду "несколько разных НЕмаскируемых сделать"! Аппаратное-то одно, причину узнавать надо как-то иначе, например, через порт.

[Alekcandr]

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

1. Не трогаем схему Ориона. От нее только приоритет и вектор. Изменять приоритет нельзя.
2. Дешифратор адреса I/O узкое место. Согласен. Тут надо отталкиваться от дизайна. Возможна пред дешифрация, или общий дешифратор для источников прерывания.
3. Триггер(ы), которым(ы) удерживаем прерывание(я), до момента пока мы не подтвердим конкретное прерывание. Надо подумать. Микросхем с триггерами много. Задачи для него. Установка по прерыванию. Сброс по общему сбросу. Подтверждение прерывания - сброс по "фиктивному" чтению порта (порт с адресом из пункта 2), т.е. на шину данных мы ничего не выдаем.

Остается маска, если она нужна. Пусть пока будет программная. Это одна общая ячейка памяти, и одна проверка на конкретный бит в векторе прерывания.

если по-моему (7 бит - вектор в IM2), то весь, если по-орионовски, то только один его бит (установить значение = регистр XOR дешифратор того, что на выводе шифратора).

Допустим, используется схема Ориона.

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

P.S. Триггер из пункта 3 надо рассматривать совместно с источником прерывания, тогда схема вырисуется.

[masterspammer]

Допустим, используется схема Ориона.

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

Регистр это набор входных триггеров; убираем из него этот бит; если остаются другие, то они обработаются следующими входами в режим прерывание и так пока не кончатся.

P.S. Триггер из пункта 3 надо рассматривать совместно с источником прерывания, тогда схема вырисуется.

Именно это и смущает; источник хочется иметь готовый и возможно тупой - типа кнопки. Обработка - по перепаду.

[Alekcandr]

Регистр это набор входных триггеров; убираем из него этот бит; если остаются другие, то они обработаются следующими входами в режим прерывание и так пока не кончатся.

На уровне программы для микроконтроллера мысль понятна в первом приближение.

Со схемой – нет. Чем тактируется регистр? Выходы дешифратора подключаются через XOR ко входу регистра. Что на втором входе XOR? И т.д.

Если не затруднит, нарисуйте пожалуйста схему.

Именно это и смущает; источник хочется иметь готовый и возможно тупой - типа кнопки. Обработка - по перепаду.

Тогда ставим классику - TM2.

[masterspammer]

Регистр это набор входных триггеров; убираем из него этот бит; если остаются другие, то они обработаются следующими входами в режим прерывание и так пока не кончатся.

На уровне программы для микроконтроллера мысль понятна в первом приближение.

Со схемой – нет. Чем тактируется регистр? Выходы дешифратора подключаются через XOR ко входу регистра. Что на втором входе XOR? И т.д.

Если не затруднит, нарисуйте пожалуйста схему.

Затруднит - за компом бываю набегами, если будет время на схему, я скорее сяду паять. Поэтому только текстом - на втором входе XOR - выход регистра. XORим регистр сам с собой.

Тогда ставим классику - TM2.

Или сразу несколько штук одной штукой.

[masterspammer]

Со схемой – нет. Чем тактируется регистр? Выходы дешифратора подключаются через XOR ко входу регистра. Что на втором входе XOR? И т.д.

Если не затруднит, нарисуйте пожалуйста схему.

Затруднит - за компом бываю набегами, если будет время на схему, я скорее сяду паять. Поэтому только текстом - на втором входе XOR - выход регистра. XORим регистр сам с собой.

Тогда ставим классику - TM2.

Или сразу несколько штук одной штукой.

[Alekcandr]

Затруднит - за компом бываю набегами, если будет время на схему, я скорее сяду паять. Поэтому только текстом - на втором входе XOR - выход регистра. XORим регистр сам с собой.

Ок.

Постараюсь оформить свою писанину в схему. Может, кому пригодиться.

p.s. Ксорить регистр самим с собой чревато на первый взгляд, но я еще тот схемотехник. Может вся задумка сработает при неком тактировании регистра.

[masterspammer]

p.s. Ксорить регистр самим с собой чревато на первый взгляд, но я еще тот схемотехник. Может вся задумка сработает при неком тактировании регистра.

Кстати, да, можно ненароком выставить прерывание ещё раз; можно тактированием решить (но вдруг гонки возникнут), а можно взять другую функцию, например, при активном нулевом уровне сигнала прерывания и вывода дешифратора new=old OR NOT processed, если я ничего не перепутал...

[masterspammer]

Посмотрел ещё раз схемы по ссылкам, сформулировал такие проблемы и риски:
1. если делать сигнал прерывания, снимаемый работой обработчика с устройством (обработчик пишет в порт, устройство снимает сигнал), то получается очень хрупкая архитектура - достаточно не обработать любое одно прерывание любым способом и обработчик будет вызываться после каждой команды, причём отключить программно это одно прерывание будет невозможно.
2. если делать сигнал прерывания, снимаемый уведомлением, формируемым аппаратно (по выставлению вектора на шину данных), то в принципе для отключения обработки достаточно поставить RETI по вектору.
3. если обрабатывать прерывание не по уровню, а по фронту, то все проблемы с уведомлением становятся не важны, зато возникает ситуация появление двух запросов на одно прерывание за время ожидания и/или обработки (пока считаю, что это не самое страшное дело).
4. в любом случае недопустимо "проглатывание" прерываний - запрос был, но обработчик не был вызван ни разу; ситуация может возникнуть из-за гонок, из-за слишком короткого сигнала при работе по уровню, а не по фронту или ещё по какой-либо причине; если вдруг возможно, что прерывание может стать неактуально, устареть (не могу придумать примера), это какой-то особый случай, пусть его решает обработчик, когда будет вызван.
5. в любом случае недопустима экранировка низкого приоритета высоким - приоритет влияет только на очерёдность обработки. Если таймер пропускает такты из-за вывода на условный covox, это баг.

Пока склоняюсь к установке запроса не по уровню, а по фронту. Красивая схема что-то не вырисовывается, если не делать реально на отдельных триггерах Хочется использовать микросхемы-сборки из нескольких триггеров, лучше из восьми.

P.S. Для устройств - источников прерываний интерфейс хочется такой - вход для запроса и выход для подтверждения; в идеале - можно игнорировать подтверждение, а на запрос приделать просто кнопку, при нажатии на которую будет однократно вызываться прерывание.