Цитата(Alex03 @ Nov 28 2006, 11:31)
У меня нет желания спорить с Вами.
Постараюсь тоже не спорить, но смолчать как-то не хочется. Вот такая проблема :-)
По "статистике прерываний" - замну для ясности, хотя понятно, что делать абстракную статистику всех
прерываний правильнее в "узком месте", непонятно только зачем "всех". Точнее отсылка была явная
- если система большая и универсальная - пусть и это фиксирует, вдруг кто спросит.
Цитата
И где по Вашему этим система разбирается?
1. Исполняется юзер-процесс
2. Происходит прерывание
3. Исполняется Ваш обработчик, который выводит из спячки высокоприоритетный процесс.
4. Возврат из прерывания
5. ??? Опять юзер-процесс ??? Где переключение контекста на высокоприоритетный процесс?
В пункте '3' когда обработчик "выводит из спячки высокоприоритетный процесс" по крайней мере
у меня так :-) - после перепланирования очереди задач планировщик возвращает признак наличия
более приоритетного процесса. При наличии более приоритетного дальнейшее поведение может быть
двояким;
- Ну есть и есть - проигнорировали и тогда в пункте 5 - все по Вашему - вернулись в прерванный процесс. И потом уже при ближайшем таймерном система перекючит.
- Вызвали переключатель контекста и тогда из обработчика возвратились уже в высокоприоритетный процесс.
По любому - статистикой системы занимаются вставки в системных вызовах а не универсальная прокладка перед обработчиками прерываний.
Цитата
Рядом с упомянутыми массивами nIntCounts[N], pIntFn[N] положите ещё массив с флагами для каждого прерывания, такими как возможность разрешения вложенности, флаг реентерабельности (повторного вхождения) и т.д.
Мысль понятна, реализация универсальна, но громоздка.
Цитата
и приходится ОС (точнее её универсальному обработчику прерывания) вызывать по очереди все зерегистрированные для данной линии обработчики, а уже конкретный обработчик первым делом проверяет своё железо на факт наличия прерывания,
Упустил, "про свои 16" - это однотипные девайсы про которые все знает их обработчик. Других, о которых он не знает - нет. Если мы на одно прерывание вешаем разнотипные железяки, то тогда, естественно некий супервизор необходим.
Цитата
Про обязательность везде и всего я не говорил.
Это радует :-) Будем считать, что я про НЕ обязательность везде не говорил :-)
Однако в Ваших примерах просматривается жесткий перекос в большие системы, а я как-то ожидал, даже при упоминании слова "система" говорить о более приземленных материях.
Цитата
Во первых я сам в LPC пользую
ldr pc,[pc,#-0xFF0]
При этом я не пользую ОС.
А я пользую и то и другое. Причем, даже после вышеприведенного не буду менять концепцию :-)
Цитата
Ну и как пример оправданности оверхеда с тем же VICVectAddr:
В в системе эта проблема может решаться разными способами, например окончанием обработчика прерывания "системным вызовом", в вырожденном случае заменяющимся макросом с
"с тем же VICVectAddr". Ну и обертку делать тоже никто не запрещает. Это мне много ближе, нежели включение в систему абстрактно написанного драйвера, вызываемого из абстрактного кода. При таком подходе тот-же помянутый оверхед становится далеко не единственным :-(
Проблема LPC2214 UART+T0 IRQ
Nov 28 2006, 13:38
