Стек для прерываний, и недостаток таймеров Опции

[amaora]

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

Код

handler:
sts stack-0, r16
sts stack-1, r17
in    r16, __SP_L_
in    r17, __SP_H_
sts stack-2, r16
sts stack-3, r17
ldi r16, lo8(stack-4)
ldi r17, hi8(stack-4)
out    __SP_L__, r16
out    __SP_H__, r17
//здесь код обработчика прерывания
// востановление писать лень ) тут все понятно
reti_

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

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

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

[amaora]

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

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

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

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

[defunct]

А надо вот ещё опрашивать небольшую клавиатуру с частотой от 60..120 Гц. Что можно сделать? сменить MCU не вариант.

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

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

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

[Zlumd]

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

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

[defunct]

А разве в кооперативной ОС один стек на все задачи?

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

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

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

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

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

[Zlumd]

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

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

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

Так это не несколько паралельно выполняющихся задач. Это одна задача. Каждая задача подразумевает сохранение всех локальных переменных, которые лежат в стеке, при переключении с задачи на задачу.

[defunct]

Так это не несколько паралельно выполняющихся задач. Это одна задача.

Как не крути а процессор один, и для него любая программа будет одной задачей.
Вопрос в абстрагировании. Ниже приведено две реализации одного и того же:

1)

Код

task()
{
   while( true)
   {
       wait_sema( sema_x);
       do_stuff();
   }
}

2)

Код

task()
{
   if ( sema_x)
      do_stuff();
}

Пусть памяти всего 1KB, и есть 3 таска. Во втором варианте каждый таск может запросто взять и пользовать например 512 байт под временный буфер, в первом же 3x512B > 1KB и приехали.

Каждая задача подразумевает сохранение всех локальных переменных, которые лежат в стеке, при переключении с задачи на задачу

Дайте каждой задаче static контекст с которым она работает, оформите как обычную функцию, массивные временные переменные/буферы выделяйте в стеке, и вызывайте их все поочереди(и/или по условию) и получите много задач, "параллельно" выполняющихся (находящихся в разной стадии исполнения), плюс оптимальное распределение памяти.

[Zlumd]

Как не крути а процессор один, и для него любая программа будет одной задачей.
Вопрос в абстрагировании. Ниже приведено две реализации одного и того же:
1)

Код

task()
{
   while( true)
   {
       wait_sema( sema_x);
       do_stuff();
   }
}

2)

Код

task()
{
   if ( sema_x)
      do_stuff();
}

Пусть памяти всего 1KB, и есть 3 таска. Во втором варианте каждый таск может запросто взять и пользовать например 512 байт под временный буфер, в первом же 3x512B > 1KB и приехали.

Так очень неудобно код писать. Что делать если хочется посидеть в do_stuff() примерно минуту ?

Дайте каждой задаче static контекст с которым она работает, оформите как обычную функцию, массивные временные переменные/буферы выделяйте в стеке, и вызывайте их все поочереди(и/или по условию) и получите много задач, "параллельно" выполняющихся (находящихся в разной стадии исполнения), плюс оптимальное распределение памяти.

Static - это необоснованный расход памяти.
Вот пример:

Код

Thread1()
{
func1();
func2();
func3();
func4();
func5();
func6();
func7();
func8();
}

Пусть в каждой фунции func1...func8 есть локальные переменные по 100 байт в каждой. Если все staticами объявить, то Thread1 800 байт памяти отъест, если auto - то всего 100 байт.

Может быть у нас терминология не совпадает? Я так понимаю, что задачи в вытесняющей ОС - это эквивалент Thread в программировании под Windows. А задачи в кооперативной ОС - это эквивалент Fiber. Я правильно понимаю?

[defunct]

Так очень неудобно код писать. Что делать если хочется посидеть в do_stuff() примерно минуту ?

Например сделать свою реализацию ks_wait() / ks_yeild() - которая будет запускать оставшиеся задачи прямо из текущей.
Есть конечно и другой вариант, - разбить do_stuff() на две части, и запускать вторую часть через минуту после первой.

Static - это необоснованный расход памяти.

Именно. А Вы же собрались стек статически распределить. Плюс вероятно еще и контекст регистров каждого таска хранить, статически.
В Вашем случае потерь памяти будет куда больше, чем если просто выделить ровно столько памяти сколько нужно для полезных данных.

Пусть в каждой фунции func1...func8 есть локальные переменные по 100 байт в каждой. Если все staticами объявить, то Thread1 800 байт памяти отъест, если auto - то всего 100 байт.

Не нужно бездумно объявлять все статиками. Делайте статиком только, то что должно быть статиком.

Например задача обработки принятого пакета данных - вырождается в
1. вынуть пакет из очереди,
2. обработать
3. засунуть в другую очередь.
4. Гото 1.
Сколько же нужно данных хранить статически для этой задачи? Помоему очевидно, если обеспечить непрерывное выполнение с п.1. до п.3. то статически хранить потребуется всего лишь два указателя на входную и выходную очереди.

Может быть у нас терминология не совпадает? Я так понимаю, что задачи в вытесняющей ОС - это эквивалент Thread в программировании под Windows. А задачи в кооперативной ОС - это эквивалент Fiber. Я правильно понимаю?

И да и нет. Насчет первого утверждения - сравнение Thread с таском вытесняющей ОС подходящее.

Что же касается сравнения с Fiber в кооперативной ОС, ну не совсем оно то, хотя близко:

1. Никто не заставляет App управлять процессом, процессом запуска (schedule'ом) может заниматься ядро ОС, задача лишь обязана вернуть управление этому ядру -
либо нативно - выход из функции, либо непосредственным вызовом соответствующей системной функции.
2. Никто не заставляет наделять задачу в кооперативной ОС своим стеком. В связи с тем, что задача сама отдает управление ОС когда ей удобно, - все задачи могут ужиться с одним общим стеком.

Во первых если задаче надо так много памяти то очень вероятно, что она долго не будет возвращать управление системе.

Почему же, вот примеры где может потребоваться большой буфер, но не нужно много времени:

- банальный ping
- чтение/запись внешней флешки
- обработка модбас пакета

и т.д. все где имеет место запрос-ответ.

Во вторых если в системе много ввода/вывода, то что регулярно делать if (data_ready) do_stuff() ? не лучше ли wait_for_event() который блокирует задачу (выводит из планирования), а потом в прерывании она снова ставится в очередь. Так и код проще выглядит.

Бесспорно так лучше, абсолютно согласен.
Но это же концепции не меняет, соответвующий if просто уйдет "в недра" планировщика, а задача будет состоять из одного только do_stuff().

ks_run( do_stuff, &do_stuff_context, <event_id>, <timeout> );