Кто нибудь делал отдельный стек для прерываний? есть ли смысл? код думаю писать как то так,



Не слишком ли будет тяжеловесно? хотя это не главный вопрос, основная сложность с компилятором (GCC) как его заставить генерировать обработчтки в таком виде? можно __attribute__ ((__naked__)) но тогда надо как то следить за тем какие регистры были использованы, не сохранять же все. Похоже надо начинать смотреть исходники GCC.

Правка: push/pop и st/ld длятся все по 2 такта, можно просто заменить все push на sts с фиксированными адресами ... потерь в скорости не будет.

Сообщение отредактировал amaora - Jul 26 2009, 21:17

Вот на этот вопрос Вам и надо сначала найти ответ. Я лично не вижу ни малейшего смысла.

И вопрос второй, в atmega16 три таймера, а что если надо больше? нулевой занят планировщиком для прееключения задач, первый планирую для ШИМ, второй для часов с отдельным 32.768 кГц резонатором. А надо вот ещё опрашивать небольшую клавиатуру с частотой от 60..120 Гц. Что можно сделать? сменить MCU не вариант.


Не хочется держать на стеке каждой задачи пустое место размером ~20 байт. Пока сложно сказать хватит ли 1кб на все.

Сообщение отредактировал amaora - Jul 26 2009, 20:59

Можно сделать программный таймер, не обязательно же для каждого чиха иметь отдельный аппаратный.


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

А обойтись планировщиком, тот который задачи переключает, нельзя?



Возьмите за основу кооперативную ОС, - один общий стек на все задачи и прерывания.

Когда писАл на асме, оформлял задачи "для каждого чиха", в виде подпрограмм с переопределяемой точкой входа, простенький TCB содержал 8 байт (pc:2, sp:2, X:2,Z:2), за ним следовали локальные переменные (на них всегда указывает Y) и стек. Все задачи, ессно, могли быть реентерабельны. Принимая во внимание, что на мега16 нельзя создать андроида , рискну предположить, что глубина стека в этом случае будет байт 16. Но вот Сишные концепты - не влезают в эту схему. Грубое юзание стека не позволит.

Я бы три задачи (планировщик, часы реального времени, опрос клавиатуры) посадил на один таймер.

А разве в кооперативной ОС один стек на все задачи?
Насколько я понимаю, кооперативная ОС отличается от некооперативной тем, что в первом случае, задача сама решает, когда передать управление другой задаче, а во втором - ОС насильно прерывает одну задачу и передает управление другой. Или я ошибаюсь в терминологии?

Я бы тоже. Да ещё бы ввёл флаг-байт с временными метками... ну типа светодиодиком помигать с частотой 2Гц либо 1Гц и т.д.

Да. Иначе какой в ней смысл и преимущество над вытесняющей ОС?


В общем верно, если "передать управление другой задаче" заменить на "передать управление системе". Теперь, возьмем во внимание, - если задача сама решает когда передать управление системе, то что мешает ее построить в виде конечной функции, а планировщику периодически эту функцию вызывать?


Не проще на один таймер посадить только планировщик. Который бы вызывал остальные задачи ровно тогда когда их нужно вызывать?

Клавиатуру может быть и проще, но зачем системное время делать отдельной задачей если планировщик все равно пляшет от него?

Согласен, пусть планировщик и считает системное время.

Хорошо, с клавиатурой ясно, надо как то усложнить планировщик, сейчас он может только циклически переключать задачи (round-robin).

А вот генерацию пролога/эпилога прерываний придется похоже выполнять с помощью скриптов, т.к. в исходниках GCC все очень не просто.

По поводу кооперативной многозадачности, это же программная версия модели бесконечного цикла (ну или idle/sleep) и множества обработчиков прерываний? Для того что я делаю сейчас этого было бы достаточно, но не хочется этим ограничиваться.

Сообщение отредактировал amaora - Jul 27 2009, 15:57

Имхо, это шаг в сторону. Жизнеспособны в этом случае только варианты написания прерываний либо на чистом Си, либо на чистом асме. Остальное - полумеры, рано или поздно кривизна такого подхода себя обнаружит.

Например, так

ЗЫ: при невозможности разрулить приоритетами мютексы проще встраивать в саму задачу.

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