Embedded OS

Здравствуй, Harry!

Friday March 18 2005 08:49, you (2:5020/400) wrote to Alexey V Bugrov:

HZ> Подозреваю, что просто на момент появления мода еще не пришла. Hо HZ> тенденция, имхо уже есть. Думаю, через несколько лет в старших членах HZ> семейств мелких МК будет появляться коммуникационная периферия с HZ> буферами.

Ритоpический вопpос: почему более новые пpоцессоpы, сиpечь pожденные недавно, считаются стаpшими? Казус.

Alex

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

18-Mar-05 09:44 Alexey Boyko wrote to Olga Nonova:

LB>>> была возможность организовать т.н. "компилированый стек". ON>> Если честно, то задача контроля типов, слава Богу!, никак не решается. ON>> И горжусь этим. "Компилированный стек" тоже не реализуется.

AB> Компилированый стек - метод оптимизации использования памяти. Hа ассемблере, AB> естественно, реализуется. Hо вручную. Ну как сказать... Если инструмент поддерживает - то не вручную. Стек-то этот (оверлеи данных) строит линкер по дереву вызовов. В ассемблерном исходнике нужно просто позаводить сегменты с правильными именами для аргументов и локальных переменных функций - и всё. Я в ассемблерных подпрограммах под AvocetC51 применял несколько раз, чтобы локальные переменные подпрограмм включились в общее дерево. Так что и на чистом асме можно было бы.

wbr,