AVR vs PIC

Привет!

Wed Jul 14 2004 01:47, Artem Kamburov wrote to Harry Zhurov:

...

AK> Э... Вложенные прерывания как?

Также как в AVR'е -- либо никак, либо разрешая прерывания в обработчике. Только толку от таких вложенных прерываний немного.

AK> Скорость реакции на события из-за кучи проверок флагов как?

На одну проверку уходит всего 2...3 цикла. Сделать в типичном случае 2...3 проверки не бог весть что.

AK> С ним не работал, но для ПИКа это несомненный прогресс - из AK> низкоприоритетного прерывания уже можно вызвать высокоприоритетное.

Можно, и время запуска обработчика при этом максимум 4 цикла (типично 3) и на выход 2 цикла. Итого накладных на реакцию 4, на обработчик в целом 6 циклов (если нужен переход -- 8). Сравни с AVR где реакция: до 3 (на завершение команды) + 4 (на прерывание) + 3 (на переход к обработчику) + 1 (на сохранение SREG) + 1 (на восстановление SREG) + 4 (на возврат). Итого накладных на реакцию 11, на обработчик в целом 16. Это без приоритета, с ним нужно добавить время реакции низкоприоритетного прерывания вплоть до снятия его обработчиком маски прерываний. Итого, в лучшем случае будет за 20 циклов.

AK> Только вот КАК прервать обработчика высокоприоритетного прерывания?

Так же как в AVR, разрешив прерывания. Вот только зачем?

...

AK> А реально в чем недостаток? Вложенные прерывания организуются свободно, AK> да и общий запрет прерываний на критическом учестке кода прерывания AK> никому еще не мешал... А при одновременных событиях разрешенных AK> прерываний приоритет вроде однозначный - по номеру, остальные ждут...

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

AK> Э... Вложенные прерывания как? Скорость реакции на события из-за кучи AK> проверок флагов как? Эхехе.... При входе в прерывание первым проверяем битик "самого важного", обрабатываем, потом идём по цепочке менее важных, между обработками каждого из них опять на всяк случай проверяем битик "самого важного"... Бррр....

AK> А реально в чем недостаток? Вложенные прерывания организуются свободно, Ну вот у меня на меге8 в одной плате в качестве таймера "системного времени" и динамической индикации взят TIMER2, так как для 1-го есть более важная работа, а у 0-го общий прескалер с первым (возможны всякие сбросы прескалеров, поэтому лучше им быть отдельно, а timebase отдельно). А у 2-го него самый выскоий приоритет в цепочке. Мне бы хотелось, чтобы все прерывания от таймера 1 обрабатывались с более высоким приоритетом, чем от таймера2. Но если я в самом начале обработчика SIG_OUTPUT_COMPARE2 разрешу прерывания (в смысле скажу, что он INTERRUPT, а не SIGNAL), то его смогут прерывать не только таймерные, а и UART, ADC и так далее. А вот этого я не хочу. Решением было бы поднять прерывания таймера1 уровнем выше, в другую цепочку.

AK> мешал... А при одновременных событиях разрешенных прерываний приоритет AK> вроде однозначный - по номеру, остальные ждут... Этот порядок часто хочется изменить. Наличие уровней прерываний -- это способ поменять порядок в цепочке :-)

AK> Не, два стека это такая фича для компилятора. С ними удобнее работать. AK> Причем AK> практически на любом чипе где такое возможно. GCC просто наследует AK> подход для х86-го. В общем да. В смысле gcc тоже не прав в некоторой мере, так как раздельные стеки данных и управления дают возможность делать некоторые вещи оптимальнее. Но "нормальный" указатель стека вызовов/возвратов тоже могли бы сделать у AVR, нашли на чём экономить в конце 20 века :-)

wbr,