|
|
|
|
|
Sergey_Samara: Вообще как производить обработку нескольких прерываний для PIC
В теле прерывания необходимо проверять флаги от разрешенных источников прерывания. Очередность выбирается програмистом
Например.
TMR0IF=1?Нет далее. Да выполняем процедуру прерывания, сбрасываем флаг и выход.
INTF=1?Нет далее. Да выполняем процедуру прерывания, сбрасываем флаг и выход.
RCIF=1?Нет выход, ошибка(прер не опознано)! Да выполняем процедуру прерывания, сбрасываем флаг и выход.
|
|
|
|
AlexAlcoa: Очередность выбирается програмистом 1. Судя по приведённому выше фрагменту кода, разбором прерываний занимается сам css. т.е. программист предоставляет ему только обработчик конкретного прерывания. плюсы подобного подхода - простота использования, и сокрытие аппаратных тонкостей. минусы - увеличивается время входа в прерывание. 2. В других компиляторах (например HITECH или C18) разбор действительно возложен на программиста. Но. делать так: AlexAlcoa:
TMR0IF=1?Нет далее. ...
INTF=1?Нет далее. ....
RCIF=1?Нет выход, несколько опрометчиво, т.к. наличие взведенного флага прерывания ещё ни о чем не говорит. Точнее говорит, конечно, что периферия жаждет внимания. Только вот периферия, взводя этот флаг, не интересуется, разрешены ли эти прерывания вообще.
И может сложиться такая ситуация, что неразрешенное прерывание INT взвело флаг INTF (переход по вектору при этом не произошел), а позже разрешенное RC взводит RCIF и переходит по вектору. И тогда, при проверке первого условия INTF=1 произойдёт обработка запрещенного прерывания, вместо ожидаемой обработки RCIF. Правильнее писать так:
if (INTF && INTIE) //Если пришло INTF и оно разрешено, обрабатываем его
{
INTF=0;
....
}; if (RCIF && RCIE) (....); //Аналогично для остальных сигналов Повторяю, конкретно в CSS это, может быть, делает сам компилятор. |
|
|
|
rfc: И может сложиться такая ситуация, что неразрешенное прерывание INT взвело флаг INTF (переход по вектору при этом не произошел), а позже разрешенное RC взводит RCIF и переходит по вектору. И тогда, при проверке первого условия INTF=1 произойдёт обработка запрещенного прерывания, вместо ожидаемой обработки RCIF.
Такой ситуации не должно быть т.к. пользователь должен проверять флаги только разрешенных прерываний, а не все подряд. Очередность опроса флагов задает приоритет прерывания. По такому алгоритму делал таймер на pic628 в программе было 2а источника прерываний от INT и UARTа разбор реализовывал именно по этому принципу сначала от INT(первостепенно) затем от UARTа(второстерпенно) все замечательно работало.
PS Вообще я в Си не силен "копаю совочком" возможно, такой подход на яву не корректен.
|
|
|
|
AlexAlcoa: Такой ситуации не должно быть т.к. пользователь должен проверять флаги только разрешенных прерываний, а не все подряд. Не совсем понял ход мыслей. Так работают 8 разрядные пики. приходит запрещённое прерывание - флаг взводится, приходит разрешенное, флаг взводится и переход на вектор происходит. А задача пользователя разобраться, как произошел переход. Для этого и ведется контроль по 2 битам IF и IE. AlexAlcoa: сначала от INT(первостепенно) затем от UARTа (второстерпенно)
А теперь представьте, что вам понадобилось в реальном времени обрабатывать UART и вы временно запретили INT. Тогда при прерывании по UART вы попадаете в общий обработчик, и проверяете что? Правильно флаг INTF, который запросто может быть установлен, т.к. в кнопочку, например, нетерпеливый юзер потыкал. И что мы обрабатываем? Этот самый INT, который заблокировали сами-же, чтобы не мешал. Это не относится ни к компилятору, ни к С. Это так процессоры эти сделаны. Просто у вас ситуации такой не сложилось. |
|
|
|
rfc: А теперь представьте, что вам понадобилось в реальном времени обрабатывать UART и вы временно запретили INT Эта задача однозначно заставляет контролировать разрешающий бит прерывания, согласен на 100%.
rfc: задача пользователя разобраться, как произошел переход. Для этого и ведется контроль по 2 битам IF и IE.Если программа не запрещает/разрешает прерывания в процессе работы, достаточно одного IF, а проверка IE уже лишняя трата памяти. |
|
|
|
AlexAlcoa: а проверка IE уже лишняя трата памяти.
Проверка IE - хорошая привычка, которая поэкономит время и нервы при доработке проекта или при написании более сложного. Одна команда btfsc - не так страшно, а если её некуда вместить, так это контроллер под задачу некорректно выбран В Си есть куда более прожорливые конструкции, которыми не глядя пользуются. |
|
|
|
rfc: Проверка IE - хорошая привычка+1
Привычки вырабатываются у каждого свои |
|
|
|
AlexAlcoa: Привычки вырабатываются у каждого свои
Каждая хорошая программистская привычка - это пара дней отладки, пара см² нервных клеток и несколько седых волос |
|
|
|
Не совсем удачное сравнение.
Ладно это уже офф. |
|
|
|
AlexAlcoa: Не совсем удачное сравнение
Пожалуй. Удалил. |
|
|
|
|