Hi Harry, hope you are having a nice day!
18 Мар 05, Harry Zhurov wrote to Alexey V Bugrov:
AV>> Hикак. Ядро (таскманагер) писать с нуля. Все остальное может быть AV>> и на С написано, легко перенесется. HZ> Похоже, у нас несколько разное восприятие понятия "ядро". Вот ISR, HZ> где возможно перепланирование - это ядро?
В твоих терминах не знаю. В моих терминах перепланирование в пользовательском ISR невозможно, из него только посылаются сигналы ядру, которое перхватывает вызов пользовательской ISR и по окончании его работы производит перепланирование при необходимости. Интересно, сколько раз я уже написал этот тезис за время нашей дискуссии?
Т.е. у меня ISR - это не ядро, оно может быть писано на чем угодно, только вот его вызов перехватывается ядром, которое делает всю черную работу. У меня _внутри_ пользовательского ISR никакое перпланирование невозможно.
HZ>>> дают некую свободу в конкретном случае, но решение получается HZ>>> частным со всеми вытекающими. AV>> Даже для uC/OS Лябрус вполне прозрачно написал, что если AV>> интересует результат, а не процесс, то самая главная часть ОС, в AV>> том числе планировщик, должна быть написана на асме. Обвеска на C AV>> - сколько угодно. HZ> Hо сам-то он все на С делает.
Note that OSSched() could be written entirely in assembly language to reduce scheduling time. OSSched() was written in C for readability, portability and also to minimize assembly language.
Вот если последнее не требуется (ты же не занимаешься написанием ос на продажу и каждый день с платформы на платформу не прыгаешь) то писание на асме полностью оправдано.
HZ> Hа асме только низкоуровневый код HZ> вроде переключения контекстов. И тут я с ним целиком и полностью HZ> согласен, и делаю именно так. Hо функции переключения контекстов - HZ> очень небольшая часть от всего остального. А все остальное прекрасно HZ> пишется на С и оверхеда почти не создает.
А я о чем говорил? Все тоже самое + планировщик и другая концепция работы с прерываниями.
AV>> Да. Обработчик прерывания - это функция. Какая разница кто ее AV>> вызовет: внешнее событие или другой код? Единственная проблема - AV>> это reti вместо ret на выходе. Hо это можно обойти.
HZ> А вектора прерываний ты сам руками вставляешь?
;=============================================================== OS_ISRV_SECT CODE 0x0018 ; адрес вектора прерывания. Сюда ядро прибито гвоздями. ;--------------------------------------------------------------- ; save minimal context ; [skip, ибо не существенно] ; btfsc OS_CtxSwPending ; check OS request, переключение контекста запрошено вне прывания. bra _skip_user_isr ;--------------------------------------------------------------- ; proceed user interrupts ; incf OS_bIntLevel,F,ACCESS ; increment interrupt nest level incf OS_bLockCount,F,ACCESS ; we are inside interrupt, so increment locker ; call OS_ISR ; call user ISR (это тот самый обработчик, который сгенерил компилятор) ; decf OS_bLockCount,F,ACCESS decfsz OS_bIntLevel,F,ACCESS ; decrement interrupt nest level bra _os_exit ; if not zero skip task scheduler ; _skip_user_isr: ;--------------------------------------------------------------- ; тута смотрим надо ли запускать планировщик и т.д.
HZ> Поясню, что имеется HZ> в виду: в IAR'е, например, есть волшебное слово __interrupt, которое HZ> придает функции особый статус - в частности, компилятор сохраняет все HZ> используемые регистры, а не только local.
Hу и что? Это даже замечательно. От этого сгенерированный код перестал быть функцией, которая может быть вызвана коммандой call?
HZ> И еще там же предназначена к HZ> использованию волшебная прагма: #pragma vector=..., где указываешь HZ> адрес ISR.
Хинт: в этой прагме указываешь не адрес вектора, а некий произвольный адрес вне таблицы векторов. Или вообще не указываешь эту прагму, пусть функция будет там где она есть, а вектор останется не тронутым. В таблице векторов располагаешь врапер на асме, который делает описанную мной работу и вызывает этот самый обработчик (OS_ISR), расположенный по адресу, указанному в прагме.
HZ> Таким образом, компилятор делает всю остальную работу - HZ> помещение адреса ISR в таблицу векторов прерываний, реализует HZ> поведение внутри ISR как это полагается делать (все же HZ> обработчик прерываний - непростая функция).
Единственное отличие - это reti в конце вместо ret. Все остальное несущественно.
HZ> Если отказываться от этого сервиса, то придется кое-что делать HZ> руками, что не есть удобно и вдобавок граблечревато.
Если концепция одна и она не меняется, то грабли надо еще умудриться найти.
AV>> Ой. Эти десять строчек надо на асме писать. HZ> Понятно. Т.е. в сухом остатке: надо, чтобы ISR был обычной HZ> функцией, где часть кода написана на асме. Больше вопросов не имею.
Как вариант. Hо можно и более детально исследовать вопрос со штатными возможностями компилятора.
[skip]
HZ> Если будет требоваться скорость (либо какие-то другие причины HZ> вынудят), то так и делаем. Что выбрать - второй вопрос. Hо пока по HZ> скорости устраивает, можно и не дергаться, а решить все в лоб.
Это вопрос для отдельной дискуссии, но все-таки я надеюсь, что обсуждаем разные способы реализации планировщика и пытаемся взвесить их плюсы и минусы. Для моего варианта я вижу пока минус только один: меньшая (не очень значительно) переносимость кода и чуть-чуть большие накладные расходы на вход/выход из обработчика. Зато мы получаем прозрачность написания пользовательских прерываний (не делим их на осевые и неосевые), не стесняясь использовать функции ОС по прямому назначению (т.е фукции сигнализации в прерываниях) и увеличение скорости обработки прерываний, т.к. переключение контекста происходит только тогда, когда оно затребовано сигналом.
HZ>>> чтобы он вообще к этому не касался. Тогда пишем на входе свой код HZ>>> сохранения, на выходе свой код восстановления.
AV>> Hа асме?
HZ> Естественно. Пишется макрос, который состоит из ассемблерных HZ> вставок. Один на входе (сохранение), другой на выходе HZ> (восстановление).
Если это допустимо, то и вставить перед выходом из функции прерывания, сгенерированной компилятором, _asm(ret) труда не составит (это чтобы подменить reti компилятора). Значит мой вариант реализуем на 100%. Hикаких макросов для сохранения/восстановления контекста в ISR не потребуется.
WBR, AVB