Вопросы по scmRTOS Опции

[koluna]

Здравствуйте!

scmRTOS v3 AVR/GCC.
Компилятор - WinAVR 20080610.
IDE - Code::Blocks 8.02.
Простую тестовую программу буду пробовать на ATmega88.

Приступил к изучению.
Читаю scmRTOS_v2.pdf, смотрю исходники примеров релиза.

Возникло несколько вопросов. Прошу помочь разобраться.
Буду очень благодарен за какие-нибудь шаблоны программ (без лишнего кода), практические рекомендации и ссылки!

Первые два вопроса - функции main примеров.
1. В примерах T0 - системный таймер. Почему инициализация и запуск системного таймера производится не средствами ОС (допустим, в Run), а пользователем ОС вручную?
2. Почему при использовании передачи управления на основе программного прерывания инициализация компаратора производится не средствами ОС, а пользователем ОС вручную?
3. Один тик системного таймера - одно его переполнение?
4. Рекомендуемое значение системного тика 1-10 мс. Т. е., мы должны настраивать системный таймер, на переполнение его в пределах этого времени?
5. Каковы будут дополнительные опции компилятора для моей связки ОС + компилятор + IDE?

Благодарю заранее!

[koluna]

Вот и ещё вопросы подоспели

8. Для чего функция процесса Exec() - статическая?
9. Почему функции WakeUpProcess() и ForceWakeUpProcess() следует использовать с осторожностью? В каких случаях?
10. Какую оптимизацию задавать при компиляции?

У нас на форуме уже рассказывалось, как можно ввести контроль за объемом стека в scmRTOS. Методика простая. Выделяем поболее, смотрим за реальной работой процессора, анализируем сколько было использовано. Есть возможность - ужимаем, оставив еще немного про запас.

Я читал
Но мне как новичку пока сложновато это...

TOGGLE(LED_R);

Что это?

[dxp]

8. Для чего функция процесса Exec() - статическая?

А как иначе? Эта функция должна быть в единственном экземпляре всегда. Кроме того, хотя эта функция и объявлена, как функция процесса, на самом деле к ресурсам процесса она отношения не имеет и служит исключительно для нужд пользовательского кода. Поэтому делать ее нестатической - это передача ненужного this, а учитывая, что эта фукнция нормально не вызывается, то и this нее передать невозможно. Вот такие логические и технические посылы.

9. Почему функции WakeUpProcess() и ForceWakeUpProcess() следует использовать с осторожностью? В каких случаях?

Потому, что их использование нарушает обычную логику работы программы. Например, какой-то процесс ожидает события, а тут его в другом месте выдергивают - это как бы нештатная ситуация. Поэтому тут надо действовать внимательно. К слову сказать, функции эти сделаны там скорее на всякий случай, лично я уже и не помню, когда их применял (и применял ли вообще). При правильно организованной программе необходимость в их использовании стемится к нулю. Это как с оператором goto.

[koluna]

А как иначе? Эта функция должна быть в единственном экземпляре всегда.

Каждый процесс - объект типа полученного с помощью шаблона process, наследник TBaseProcess.
Каждый процесс существует в единственном экземпляре.
Значит функция будет и так в единственном экземпляре...
Или я не понимаю что такое статическая функция

Потому, что их использование нарушает обычную логику работы программы. Например, какой-то процесс ожидает события, а тут его в другом месте выдергивают - это как бы нештатная ситуация. Поэтому тут надо действовать внимательно. К слову сказать, функции эти сделаны там скорее на всякий случай, лично я уже и не помню, когда их применял (и применял ли вообще). При правильно организованной программе необходимость в их использовании стемится к нулю. Это как с оператором goto.

А что может произойти? Система "упадёт"?

[dxp]

Каждый процесс - объект типа полученного с помощью шаблона process, наследник TBaseProcess.
Каждый процесс существует в единственном экземпляре.
Значит функция будет и так в единственном экземпляре...
Или я не понимаю что такое статическая функция

Никто не мешает завести больше одного объекта-процесса. Хотя это, конечно, неправильно. Я же ясно, вроде, пояснил, что:

1. хотя эта функция и объявлена, как функция процесса, на самом деле к ресурсам процесса она отношения не имеет и служит исключительно для нужд пользовательского кода. Это логический довод.
2. делать ее нестатической - это передача ненужного this, а учитывая, что эта фукнция нормально не вызывается, то и this нее передать невозможно. Это технический довод.

Как бы вы передали в нее указатель this? А без этого она может работать некорректно, и там можно получить очень хорошие грабли.

А что может произойти? Система "упадёт"?

Можно получить неожиданное поведение. И удивляться. 

[ReAl]

Как бы вы передали в нее указатель this?

Если постараться - можно.
В конструкторе TBaseProcess после Kernel.RegisterProcess(this), там, где формируется начальный стековый кадр, затолкать этот же this в такое место, чтобы после восстановления контекста он оказался в нужных регистрах. Только, насколько я понимаю, тип параметра exec у конструктора для этого должен быть другой - указатель на функцию-член.

Топикстартеру:

Таким же образом можно было бы передать в функцию процесса указатель на некую структуру/класс, с которыми процесс должен работать, но для этого надо конструктору добавить соответствующий аргумент. Но это имело бы смысл при одновремённом переводе Exec() в нестатическую - чтобы создавать два экземпляра процесса (с разными приоритетами, но это в конечном счёте не важно), работающие одинаковым образом с разными однотипными сущностями и разделяющими код.

Но это же делается просто созданием двух процессов, из Exec() которых вызывается одна и та же функция с разными указателями на рабочий объект. Несколько накладнее, пожалуй. И не так красиво.
Но у меня пока такие желания не возникали - ну пусть два UART - ну всё равно у них разное назначение в системе и они обрабатываются по разному.
А ради просто красоты до/пере-делывать структуру ОС особого смысла не вижу.

Очень хотелось бы сделать так, чтобы первый объявленный процесс получал высший приоритет, следующий процесс - приоритет на 1 ниже и т.д.
Тогда, объявив в самой ОС число возможных процессов по максимуму всю ОС оформить в виде отдельной библиотеки и пользователям в своей организации раздать, чтобы они "грязными ногами" в ее "чистом теле" не натоптали. Сколько не думал, пока ничего не придумалось. Может есть какие соображения на сей счет?

Чтобы процессов было "по максимуму" их и задать бы надо. Ну там размер таблиц вырастет, это ладно, но между низшим по приоритету из созданных и Idle заполнено всё должно быть, она же их вызывать попытается.
Можно наоборот - с низшего начинать. Ну, если выйдет, так как я тоже чисто языковыми средствами не могу придумать как это сделать - в разных файлах, независимо. Но тогда начинаться непонятно с чего выполнение будет - до наивысшего таблицы пусты.

Главное - "а зачем"?
Удобство "объектных", а не "исходниковых" библиотек в embeded обсуждалось неоднократно и практически для всего, кроме стандартной библиотеки языка оно для меня сомнительно. А уж scmRTOS, в которой ещё некоторые вещи конфигурируются попроектно - не только число процессов, и компилируется потом с inline-подстановками оптимально под проект - так и подавно.

Так то, что должно решаться административными методами, ими и решайте.
Пусть проверка результата работы производится компиляцией со свежевыдернутыми из недоступного по правам записи хранилища, а кто в рабочей копии наменял что-то - сам себе враг. Или ещё что-то придумайте.

[dxp]

Если постараться - можно.
В конструкторе TBaseProcess после Kernel.RegisterProcess(this), там, где формируется начальный стековый кадр, затолкать этот же this в такое место, чтобы после восстановления контекста он оказался в нужных регистрах. Только, насколько я понимаю, тип параметра exec у конструктора для этого должен быть другой - указатель на функцию-член.

Да, согласен, если постараться, то можно. Раз уж готовим сами стековый кадр, то и внедрить туда this тоже можно. Только зачем? Я ни одной приличной причины не знаю. По своей сути функция exec - это функция пользователя. Ей от самого объекта-процесса ничего не надо. Т.е. это отдельная фукнция, просто помещенная в пространство имен процесса. С таким же успехом можно было бы создавать произвольные глобальные функции и подсовывать их в конструктор процесса. Ну, как сделано, так сделано. В духе ++.