Подскажите пожалуйста, про многозадачность. Опции

[_Алекс]

Есть несколько задач (программ) которые должны выполнятся с минимальным временем, можно организовать как линейный список функций, которые последовательно вызываются из главной функции main() при условии что время выполнения каждой функции ограничено т.е. внутри функции нет кода который задерживает выполнения (ожидает чего либо).
Например одна функция обрабатывает принятый массив с USARTа. другая расшифровывает принятую команду и выполняет ее, подготавливает ответ к отправке (квитирование).
Еще пару функций, которые что-то делают (обслуживают клавиатуру, исполнительные устройства). Получается все запутанно, если делать все функции в виде конечных автоматов с минимальным временем работы каждой. Хорошо было бы, если каждая функция выполнялась в виде задачи, ожидает, данные с параллельного потока пускай ждет, получила что хотела, выполняет. Есть задержка в функции скажем, на 20 секунд, пускай ждет, в это время выполняются другие функции. С операционными системами как-то все сложно, может планировщик задач да и все. Какие есть решение не сложные? Механизм взаимодействия функций друг с другом.

[Сергей Б]

Ну для этого и придуманы прерывания, например для UARTа.

-->Получается все запутанно, если делать все функции в виде конечных автоматов с минимальным временем работы каждой. Хорошо было бы, если каждая функция выполнялась в виде задачи, ожидает, данные с параллельного потока пускай ждет, получила что хотела, выполняет. Есть задержка в функции скажем, на 20 секунд, пускай ждет, в это время выполняются другие функции.

Сильно смахивает на параллельность операций. В контроллере врятли получиться.

[_Алекс]

Ну для этого и придуманы прерывания, например для UARTа.

-->Получается все запутанно, если делать все функции в виде конечных автоматов с минимальным временем работы каждой. Хорошо было бы, если каждая функция выполнялась в виде задачи, ожидает, данные с параллельного потока пускай ждет, получила что хотела, выполняет. Есть задержка в функции скажем, на 20 секунд, пускай ждет, в это время выполняются другие функции.

Сильно смахивает на параллельность операций. В контроллере врятли получиться.

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

[Сергей Б]

Ну так ясное дело в прерывании, например для юарта забираете посылку, а в функции уже разбираете ее.

[GinRider]

Получается все запутанно, если делать все функции в виде конечных автоматов с минимальным временем работы каждой.

А других вариантов-то и нет. Единственное, если есть функции с наивысшим приоритетом (например, приём/передача данных по интерфейсу на максимальной скорости в большом объёме), их придётся целиком запихивать в прерывания. Можно ещё в некоторых режимах блокировать ненужные функции. Главное - не запутаться в системе флагов.

[Сергей Б]

Получается все запутанно, если делать все функции в виде конечных автоматов с минимальным временем работы каждой.

А других вариантов-то и нет. Единственное, если есть функции с наивысшим приоритетом (например, приём/передача данных по интерфейсу на максимальной скорости в большом объёме), их придётся целиком запихивать в прерывания. Можно ещё в некоторых режимах блокировать ненужные функции. Главное - не запутаться в системе флагов.

Да флагов рожлается огромное количество на сыром коде, но после оптимизации половина выкидывается. Главное, при расположении большого кода в прерывании не забывать об их приоритетах.

[rezident]

Можно и без вложенных прерываний в одном прерывании все обслуживать, если наименьший период вызова других прерываний не превышает времени работы в данном прерывании. Например, на скорости 9600 прерывания от UART будут не чаще чем через 1 мс. Дребезг клавиатуры за это время конечно не устранишь, а вот разобрать пакет и подготовить ответ вполне можно при достаточной производительности МК. Да и клаву тоже можно обслужить, если вызывать процедуру один раз через 9 (при дребезге клавиш не более 10мс). По крайней мере у меня на MSP430 при работе UARTа на 115200 в 10мс прерывании и клавиатура обслуживается и транспортная процедура (прием/передача/подсчет CRC/выдача ответа "занят", без разбора самого пакета) RTU-ного протокола крутится.

[GetSmart]

В винде вот красиво сделано. Там есть обработчики событий. Вся прога при этом пишется из обработчиков, которые сами себя вызывают друг за другом. Конечно, там ещё и разделение во времени чтобы тупые обработчики не завешивали систему. Вобщем есть три механизма:
1. Прерывания
2. Обработчики событий
3. Разделение во времени
Хотя может чего ещё и забыл.

[IgorKossak]

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

[GinRider]

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

Если используется какой-нибудь высокоуровневый протокол, то да. А если там требуется прочитать клавиатуру да выкинуть что-либо на LCD-дисплей, то получится только напрасная трата ресурсов.

[µµC]

Если используется какой-нибудь высокоуровневый протокол, то да. А если там требуется прочитать клавиатуру да выкинуть что-либо на LCD-дисплей, то получится только напрасная трата ресурсов.

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

[SasaVitebsk]

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

Если используется какой-нибудь высокоуровневый протокол, то да. А если там требуется прочитать клавиатуру да выкинуть что-либо на LCD-дисплей, то получится только напрасная трата ресурсов.

Насколько я понимаю это в любом случае RTOS. Просто в одном случае реализованная своими силами и сильно упрощённая, ну а в другом написанная сторонними производителями, и, возможно сильно усложнённая.

Если свой упрощённый вариант, то я пишу так как не рекомендует писать уважаемый 'IgorKossak'.
То есть ввожу флаги состояний, задачи замыкаю на себя, данные напрямую не передаю, общаюсь только ч/з флаги и ОЗУ. (то есть вых. данные одной проги - входные другой). Блоки пишу таким образом, что их перестановка местами м/у собой не влияет на работоспособность программы.

[_Алекс]

Есть функции, есть планировщик задач. Функции зациклены. Выход из функции невозможен. Функция сама передает процессорное время по команде планировщику, планировщик отдает процессорное время другой функции по приоритету. Возникает вопрос как (для AVR IAR) вернутся в прерванную функцию по адресу где функция отдала управление и как в IAR сохранить рабочие регистры и какие нужно сохранять.

[GinRider]

Если свой упрощённый вариант, то я пишу так как не рекомендует писать уважаемый 'IgorKossak'.
То есть ввожу флаги состояний, задачи замыкаю на себя, данные напрямую не передаю, общаюсь только ч/з флаги и ОЗУ. (то есть вых. данные одной проги - входные другой). Блоки пишу таким образом, что их перестановка местами м/у собой не влияет на работоспособность программы.

Программа должна выглядеть так:

do{
ReadKeys();
UpdateDisplay();
}while(true);

Всё остальное - дело флагов, указателей и счётчиков.
Главное - в ассемблерном листинге это выглядит точно так же.

[defunct]

Есть задержка в функции скажем, на 20 секунд, пускай ждет, в это время выполняются другие функции. С операционными системами как-то все сложно, может планировщик задач да и все. Какие есть решение не сложные? Механизм взаимодействия функций друг с другом.

В одном из своих проектов я решил подобный вопрос с помощью нехитрого планировщика , который занимался тем, что запускал функции "задачи" по расписанию.
Ввел три типа задач:
TASK_PERIODIC - запускать постоянно через определенный интервал
TASK_SINGLECALL - запустить однократно через определенный интервал
TASK_KERNEL - запускать в отдельном _idle_ цикле постоянно (к этому типу относятся всевозможные Dispatcher'ы)

Задачи помещаются в отдельные очереди и при вызове могут добавлять/удалять в/из очереди любые другие задачи. Если потребуется выполнение довольно длительной задержки (у меня таки потребовалось) внутри "задачи", то задача обязана вызывать _idle_ цикл, чтобы отрабатывали все "системные" задачи типа TASK_KERNEL (обслуживание времени, I/O и т.п.).

От флагов такой подход полностью не избавляет, но все-таки минимизирует чуть-чуть, и экономит ПП. Для сравнения этот планировщик отнимает всего ~500 байт ПП и может занимать меньше, ну а кол-во занимаемого RAM'а регулируется взависимости от потребностей проекта. (по 16 задач каждого типа займет 10*16*3 байт ОЗУ).

[Сергей Борщ]

Есть функции, есть планировщик задач. Функции зациклены. Выход из функции невозможен. Функция сама передает процессорное время по команде планировщику, планировщик отдает процессорное время другой функции по приоритету. Возникает вопрос как (для AVR IAR) вернутся в прерванную функцию по адресу где функция отдала управление и как в IAR сохранить рабочие регистры и какие нужно сохранять.

www.scmRTOS.narod.ru - очень подробное описание как это все делать.

[µµC]

Программа должна выглядеть так:

do{
ReadKeys();
UpdateDisplay();
}while(true);

Всё остальное - дело флагов, указателей и счётчиков.
Главное - в ассемблерном листинге это выглядит точно так же.

Программа _может_ так выглядеть, но вовсе не должна. Суперлуп наиболее примитивный вариант реализации многозадачности, что данный код и демонстрирует - 100% ресурсов занято там, где хватило бы долей %.

От флагов такой подход полностью не избавляет, но все-таки минимизирует чуть-чуть, и экономит ПП. Для сравнения этот планировщик отнимает всего ~500 байт ПП и может занимать меньше, ну а кол-во занимаемого RAM'а регулируется взависимости от потребностей проекта. (по 16 задач каждого типа займет 10*16*3 байт ОЗУ).

Получается 10*3 байт на задачу, только на "системные" издержки? Как-то многовато. Для невытесняющей оси нужно в 4 - 5 раз меньше.

[gormih]

Скромная попытка объяснить необъятное двумя словами :

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

Если не хочется ждать окончания какого либо процесса - можно вообще поступить таким образом (в свое время реализовал это на z80 ПК Zx-Spectrum):

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

Сообщение отредактировал Михаил Горюнов - Oct 18 2006, 13:23

[defunct]

Получается 10*3 байт на задачу, только на "системные" издержки? Как-то многовато. Для невытесняющей оси нужно в 4 - 5 раз меньше.

10 байт на задачу, 3 разных очереди. Вот такая вот структурка:

Код

typedef struct _TTask
{
  U32  ExecuteWithin;  // время в тиках ядра
  U32  ReloadInterval; // интервал перезапуска
  _task_function *Task;
} TTask, *PTask;

[Alexander Storm]

Попробуй всеж чуток с операционками разобраться, пока не с вытесняющими, кооперирующими, очень простая jacos. Если пишешь только на С, все очень просто, толково описана и примеры есть. Фриварная, с исходниками, автор баги быстро исправляет.
Как для меня оказалась проще чем я ожидал, это первая с которой столкнулся, может есть и лучше, не спорю, но реально простая и удобная, ресурсы минимально жрет, только когда на асеме вставки лупишь - лучше в дебагере детально просмотреть АСМ объекта, как всегда для сюхи

[_Алекс]

Почитал по операционнкам, попроще получается кооперативная с приоритетным планировщиком, но: есть три задачи с приоритетом 1,2,3. Приоритеты присваиваются при создании задачи. Каждая задача сама отдает процессорное время. Планировщик должен запустить следующую задачу готовую к выполнению с наивысшим приоритетом. Тогда задача с 1 приоритетом вообще никогда не получит управление, ведь у ней самый маленький приоритет, когда есть задача 2, 3. Каким образом планировщик с приоритетным планированием запускает задачу с наименьшим приоритетом или вообще до нее очередь никогда не доходит.

[Dog Pawlowa]

Осень. Пора, как все, лететь к RTOS.

Но я пока делаю по старинке.

Самые быстродействующие или просто привязанные к времени процессы распихиваю в прерывания по таймеру (причем несколько - от 500 мкс до 1 с).
Прочие процессы - в вызовы функций в цикле по индексу состояния процесса.

for(;;)
{
//process 1
event=GetKeyEvent();
if (!event) event=GetTimerEvent();
if (!event) event=GetExternalKeyboardEvent();
process1[status1]();
//process 2
event=GetIrdaEvent();
if (!event) event=GetModemEvent();
process2[status2]();
}

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

Есть RTOS, нет ее, на этапе начала проектирования ресурсы контроллера и частота появления внешних событий должны быть просчитаны. А если все просчитано и понятно, зачем RTOS?

[Hz!]

Почитал по операционнкам, попроще получается кооперативная с приоритетным планировщиком, но: есть три задачи с приоритетом 1,2,3. Приоритеты присваиваются при создании задачи. Каждая задача сама отдает процессорное время. Планировщик должен запустить следующую задачу готовую к выполнению с наивысшим приоритетом. Тогда задача с 1 приоритетом вообще никогда не получит управление, ведь у ней самый маленький приоритет, когда есть задача 2, 3. Каким образом планировщик с приоритетным планированием запускает задачу с наименьшим приоритетом или вообще до нее очередь никогда не доходит.

до нее дохдит очередь, когда задачи с приоритетами 2 и 3 неактивны.
А вот случится ли это (если должно) - вопрос к разработчику

[_Алекс]

Осень. Пора, как все, лететь к RTOS.

Но я пока делаю по старинке.

Самые быстродействующие или просто привязанные к времени процессы распихиваю в прерывания по таймеру (причем несколько - от 500 мкс до 1 с).
Прочие процессы - в вызовы функций в цикле по индексу состояния процесса.

for(;;)
{
//process 1
event=GetKeyEvent();
if (!event) event=GetTimerEvent();
if (!event) event=GetExternalKeyboardEvent();
process1[status1]();
//process 2
event=GetIrdaEvent();
if (!event) event=GetModemEvent();
process2[status2]();
}

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

Есть RTOS, нет ее, на этапе начала проектирования ресурсы контроллера и частота появления внешних событий должны быть просчитаны. А если все просчитано и понятно, зачем RTOS?

Поясните, пожалуйста,
У вас функции вызываются из цикла по индексу, можете пояснить механизм. Функция вызвана, как из нее происходит выход, когда выполнится весь код в функции или принудительно, механизм сообщений, если, например одна функция ждет события от другой

Почитал по операционнкам, попроще получается кооперативная с приоритетным планировщиком, но: есть три задачи с приоритетом 1,2,3. Приоритеты присваиваются при создании задачи. Каждая задача сама отдает процессорное время. Планировщик должен запустить следующую задачу готовую к выполнению с наивысшим приоритетом. Тогда задача с 1 приоритетом вообще никогда не получит управление, ведь у ней самый маленький приоритет, когда есть задача 2, 3. Каким образом планировщик с приоритетным планированием запускает задачу с наименьшим приоритетом или вообще до нее очередь никогда не доходит.

до нее дохдит очередь, когда задачи с приоритетами 2 и 3 неактивны.
А вот случится ли это (если должно) - вопрос к разработчику ;)

Ясно, а кто задачи с приоритетами 2 и 3 делает активными - планировщик? по событиям? или планировщик, видя что все задачи не октивны, сам запускает с наивысшим приоритетом

[Dog Pawlowa]

Поясните, пожалуйста,
У вас функции вызываются из цикла по индексу, можете пояснить механизм. Функция вызвана, как из нее происходит выход, когда выполнится весь код в функции или принудительно, механизм сообщений, если, например одна функция ждет события от другой

1. Вызов по индексу - организуется массив функций и вызывается функция из этого массива. Все просто и наглядно.

2) Раз я говорю, что RTOS не использую, значит функция завершается так же естественно, как пиво в бутылке

3) А механизм передачи сообщений прост.
- Каждый процесс имеет status. Это уже достаточно информативно для того, чтобы другие процессы могли узнать, что делается в этом. Например, состояние ошибки. Жду, курю бамбук, жду событий.
- Каждый процесс генерирует события при вызове функции GetProcessNEvent().
типа if (beer_level==0) return(evBeerOver);

Это событие обрабатывается примитивно просто :
switch (event)
{ case evBeerOver: OpenBottleWithVodka();
case evVodkaOver: GoToShop();
}

[Hz!]

Ясно, а кто задачи с приоритетами 2 и 3 делает активными - планировщик? по событиям? или планировщик, видя что все задачи не октивны, сам запускает с наивысшим приоритетом

Может и событие и приложение.
Это происходит при помощи различных сервисов, таких как семафоры сообщения и т.д.
Найдите мануал на какую-ть ось (я с JjacOS разбирался), там все подробно должно быть расписано.

[osnwt]

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

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

А что, исходники jacos уже появились? До сих пор, насколько я знаю, было множество библиотек под разные процессоры и варианты компиляции?

Да и насчет ответов автора - да, год-два назад так и было, подтверждаю. Но сейчас человек, который тоже использовал jacos, сообщил, что автор на его письма отвечать перестал. И разработки переехали под scmRTOS, которая реально имеет открытый исходный текст, в т.ч. для коммерческого использования.

[AVR]

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

А что, исходники jacos уже появились? До сих пор, насколько я знаю, было множество библиотек под разные процессоры и варианты компиляции?

+1
Посмотрел на сайте автора, так там нет никаких исходников... Можно ссылочку?
ЗЫ
Страшно нравится jacos, вот только что известно на счет багов?

[Alex B._]

Автор jacOS высылает исходники по запросу, напишите ему письмо, должен ответить.

[_Алекс]

Посмотрел ОС scmRTOS, jacOS, Salvo. многозадачность нужна в AVR а все операционки со своей поддержкой много МК самых разных, поддержка разных компиляторов, условная компиляция, комментарии в исходнике не поймешь, да и исходник сам не найти, компоновка в среде, закрытые подключаемые библиотеки… Можно конечно по примерам, по рекомендациям интеграции в определенную среду разработки но так до конца не поняв внутреннею работу ОС, разбираться, что где не работает, почему когда работает когда нет. Понравилась Salvo но где исходник! В моем проекте задач 6. Причем некоторые требуют жесткой временной привязки и активно используют таймеры, порты ввода вывода, ШИМ, SPI, USART. Остальные задачи, включить выключить, считать дискретный вход. Мне кажется, нужен хороший кооперативный приоритетный планировщик как, например в Salvo (вот бы его исходник) ни какой глобализации объять не объятное, только то что нужно. Осталось написать кооперативный планировщик, скажем задач 10 максимум. Может есть у кого исходник.

Прикрепленные файлы

 salvo_user_manual_ch4_russian.pdf ( 329.63 килобайт ) Кол-во скачиваний: 177

 

[osnwt]

Посмотрел ОС scmRTOS, jacOS, Salvo. многозадачность нужна в AVR а все операционки со своей поддержкой много МК самых разных, поддержка разных компиляторов, условная компиляция, комментарии в исходнике не поймешь, да и исходник сам не найти, компоновка в среде, закрытые подключаемые библиотеки…

scmRTOS: есть поддержка AVR, один компилятор IAR, условная компиляция - и это правильно, комментарии отличные, русская документация с фрагментами исходников OS для понимания, исходники открыты для любого использования, в т.ч. коммерческого, пример использования в комплекте - собирается командной строкой (что не мешает использовать IDE), библиотек нет - только исходники. Автор оперативно отвечает.

Вот пример отладки в среде Proteus программы с использованием scmRTOS на AVR. Видно, как можно шагать по исходному коду системы.

Понравилась Salvo но где исходник!

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

В моем проекте задач 6. Причем некоторые требуют жесткой временной привязки и активно используют таймеры, порты ввода вывода, ШИМ, SPI, USART.

Такие вещи надо стараться делать по прерываниям.

Остальные задачи, включить выключить, считать дискретный вход. Мне кажется, нужен хороший кооперативный приоритетный планировщик как, например в Salvo (вот бы его исходник) ни какой глобализации объять не объятное, только то что нужно. Осталось написать кооперативный планировщик, скажем задач 10 максимум. Может есть у кого исходник.

Jacos более чем подходит этому описанию, а условная компиляция позволяет отсеять то, что не используется. Один минус: отсутствие исходников и поддержки на данный момент (по известной мне информации, может, она ошибочна).

[µµC]

Посмотрел ОС scmRTOS, jacOS, Salvo. многозадачность нужна в AVR а все операционки со своей поддержкой много МК самых разных, поддержка разных компиляторов, условная компиляция, комментарии в исходнике не поймешь, да и исходник сам не найти, компоновка в среде, закрытые подключаемые библиотеки…

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

Мне кажется, нужен хороший кооперативный приоритетный планировщик как, например в Salvo (вот бы его исходник) ни какой глобализации объять не объятное, только то что нужно. Осталось написать кооперативный планировщик, скажем задач 10 максимум. Может есть у кого исходник.

Исходники можно взять для jacos, и повторю, нужны они лишь при обновлении версий компиляторов. Раньше можно было немножко заплатить за поддержку, сейчас ее нет, но есть исходники.
Salvo только за деньги, за довольно приличные. Можно слямзить исходники, но лямженный порт для AVR не встечал. Может есть у кого?

[_Алекс]

Исходники можно взять для jacos, и повторю, нужны они лишь при обновлении версий компиляторов. Раньше можно было немножко заплатить за поддержку, сейчас ее нет, но есть исходники.
Salvo только за деньги, за довольно приличные. Можно слямзить исходники, но лямженный порт для AVR не встечал. Может есть у кого?
[/quote]

А у вас нет исходника jacos.

[µµC]

А у вас нет исходника jacos.

Есть. Обращайтесь к автору и у вас будет текущая версия.

[Alex B._]

>> Один минус: отсутствие исходников
Это не минус. Если система активно развивается автором - не нужно ему мешать. Ну поправите вы что-то, добавите дополнительные сервисы, а автор выпустит новую версию. И ваши проекты уже не будут совместимы с родной библиотекой. В случае с jacOS - уже вряд-ли - обновлений давно нет и не придвидится, но в общем случае править что-то в ядре RTOS - нужно разбираться во всем коде. Иначе система будет работать но в один прекрасный момент вылетит. И хорошо если в момент тестирования, а не у клиента.

[osnwt]

>> Один минус: отсутствие исходников
Это не минус. Если система активно развивается автором - не нужно ему мешать. Ну поправите вы что-то, добавите дополнительные сервисы, а автор выпустит новую версию.

И все же это минус. Наличие исходников позволяет лучше понять то, как реализована та или иная функциональность, особенно в случае неких проблем. То, что для этого придется разобраться в коде - да, и не все на это готовы. Но кто готов - ему это пригодится. Если исходники хорошо прокомментированы, то все "подводные камни" там должны быть описаны, а не оставаться в голове автора (который их обязательно забудет через пару лет сам).

Что касается правки, то есть и другая модель внесения изменений: пишется письмо автору, где предлагается некая функциональность и патчи примера ее внесения. Если автор считает, что это заслуживает внесения в официальный порт - он это сделает в очередном релизе. Если нет - то нет. Я такую модель обкатал на AVR-USB драйвере - она очень хорошо работает. Все, что мне было нужно, автор дописал в оригинале, сохранив совместимость с исходной версией. В итоге я просто перешел на новую версию, выкинув свои патчи, а драйвер стал более функциональным. При этом диалог был конструктивным: не "а нельзя ли добавить вот это?", а "хочется вот такое, я сделал так - прошу посмотреть и реализовать, если одобрямс".

[Alex B._]

Согласен на полминуса.
Для того чтобы лучше понять - есть документация. Если она убогая - вообще нужно отказаться от этого продукта, альтернатив всегда хватает.
Опять же, что мешает задать вопрос в техподдержку (если либа или РТОС платная) - ведь деньги платятся не только за архив с исходниками. А если бесплатное - автор, как правило сам охотно идет на контакт.
Дальше. Поставка в скомпилированных либах или объектниках - некая защита интеллектуальной собственности. Можно купить софт гораздо (в разы) дешевле.
И еще. Поставляя библиотеку, ядро РТОС в объектниках производитель может гарантировать клиенту ее работоспособность. С исходниками сложнее - в 99% указывается на то, что автор не несет ответсвенности за ошибки в ПО, если исходники каким-то образом изменены.

В общем тут перетирать эту тему очень долго можно. ИМХО начинающему исходники абсолютно не нужны и даже вредны

[osnwt]

Поддержка - или платить постоянно за нее, или автору надоело, или самому влезать. Впрочем, тут возможны варианты, не о чем спорить.

Защита собственности - да, хотя многие отличные продукты вроде scmRTOS или AVR-USB драйвера открыты. Если это критично, то можно выбирать из таких, в том числе.

А ответственности за ПО никто не несет вообще - даже Microsoft :-) Так что все это условно.

[haker_fox]

Есть несколько задач (программ) которые должны выполнятся с минимальным временем, можно организовать как линейный список функций, которые последовательно вызываются из главной функции main() при условии что время выполнения каждой функции ограничено т.е. внутри функции нет кода который задерживает выполнения (ожидает чего либо).
Например одна функция обрабатывает принятый массив с USARTа. другая расшифровывает принятую команду и выполняет ее, подготавливает ответ к отправке (квитирование).
Еще пару функций, которые что-то делают (обслуживают клавиатуру, исполнительные устройства). Получается все запутанно, если делать все функции в виде конечных автоматов с минимальным временем работы каждой. Хорошо было бы, если каждая функция выполнялась в виде задачи, ожидает, данные с параллельного потока пускай ждет, получила что хотела, выполняет. Есть задержка в функции скажем, на 20 секунд, пускай ждет, в это время выполняются другие функции. С операционными системами как-то все сложно, может планировщик задач да и все. Какие есть решение не сложные? Механизм взаимодействия функций друг с другом.

Недавно запустил scmRTOS на микроконтроллере ATmega16. Версия ОС 1.10, компилятор GCC. Никаких сложностей не встретил. Пример, приложенный к ОС, собрался сразу и без проблем. Потом написал свою, с нуля, тестовую программу. Сборка также прошла отлично. Рекомендую обратить внимание на эту ОС: есть исходники, есть хорошо написанный мануал.т Есть отзывы о ее надежной работе.

[yod]

У многих "универсальных" ОС основная проблема - неоптимизированное ядро. Там бы все ручками...
А так их реакция не радует. Монопольный режим ядра, да и долгое время переключения задач.
Прикрепляю архив с "в последний лохматый раз" переделаной "переключалкой контекстов".
Описывать неохота если кому интересны подробности - спрашивайте.
Сие работает на давайсах с мега48, другой на 16.
Написано на асме и для асма (но очень хочется сами задачи на С писать, сейчас "вопрос прорабатывается").
Если кто-нибудь что-нибудь предложит по оптимизации ядра, будет хорошо.
интересны:
Функция проверки истечения таймаута;
Функция проверки говых по событию задач;
время переключения задач:
с одной на ту же около 150 тактов (примерно)
с одной на другую от 200 тактов (примерно).
прерывания рабоают в монопольном режиме.
планировщик в общем режиме.
//--------------------------------
щаз там уарт на 115200 зашит и прием зациклен на передачу через буферную систему.
При старте выдает тестовую строчку. Работоспособность проверял только что.
С уважением, yod

Прикрепленные файлы

 AVRasmOS.zip ( 36.65 килобайт ) Кол-во скачиваний: 69

 

[Turion]

А ничего, что на сайте scmRTOS висит версия 2.04a-beta от 28.04.2006. Как у нее со стабильностью,как никак бета-версия. Можно ее применить в серьезном проекте.

[Сергей Борщ]

А ничего, что на сайте scmRTOS висит версия 2.04a-beta от 28.04.2006. Как у нее со стабильностью,как никак бета-версия. Можно ее применить в серьезном проекте.

Думаю, что можно. Для MSP430 применял именно эту бету, работает. Из нее же делал порт для ARM.

[µµC]

Функция проверки истечения таймаута;
Функция проверки говых по событию задач;
время переключения задач:
с одной на ту же около 150 тактов (примерно)
с одной на другую от 200 тактов (примерно).
прерывания рабоают в монопольном режиме.
планировщик в общем режиме.

Ну jacOS, например:
Функция проверки истечения таймаута - ok;
Функция проверки говых по событию задач - ok;
время переключения задач:
с одной на ту же - 55 тактов (mega16, IAR 420A, prim2)
с одной на другую - от 55 тактов (OS_Cooperate(), скажем, OS_Delay() - 146 тактов).
прерывания рабоают в монопольном режиме - ? Не понял что имеется в виду.
планировщик в общем режиме - ok.

[yod]

jacOS - это круто, потому что FSM (Finite State Machine)
и соотвественно в расчет не идет - не сравнима.

[µµC]

потому что FSM (Finite State Machine)

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

и соотвественно в расчет не идет - не сравнима.

Обычная невытесняющая ось. С чем не сравнима? На мой взгляд, невытесняющие оси, по природе своей, на порядок (двоичный, троичный) более подходят для AVR , чем вытесняющие. Но, до пьедестала несравнимых (несравненных) сама концепция их не вытягивает.

[yod]

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

"Задача остается текущей столько времени, сколько захочет, а управление ядру передает исключительно добровольно. " это из манаула.
Я не знаю чего тут еще пояснять. Довольно прозрачно.
Т.е. существует конечный ряд состояний всего ПО, для каждого состояния можно определить набор состояний(из общего множества состояний ПО), следующих за ним, и условия перехода (в д.с. события, приоритеты). Это и есть FSM.

Обычная невытесняющая ось. С чем не сравнима? На мой взгляд, невытесняющие оси, по природе своей, на порядок (двоичный, троичный) более подходят для AVR , чем вытесняющие. Но, до пьедестала несравнимых (несравненных) сама концепция их не вытягивает.

Ну jacOS, например:
время переключения задач:
с одной на ту же - 55 тактов (mega16, IAR 420A, prim2)
с одной на другую - от 55 тактов (OS_Cooperate(), скажем, OS_Delay() - 146 тактов).

А как их сравнивать-то - разная идеология ("архитектура")?
в вытесняющей - сохранение контекста, вытеснение задачей задачи, там одни "такты".
в FSM - упорное выполнение "состояния", переход между состояниями - там другие такты.
Хотя критерий есть: для "RTOS в системе", не важно какая она, основной критерий - гарантированное, детерминированное время отклика на событие. Для кооперативной это считается много легче, чем для вытесняющей(если не сказать более категорично).

Если хочется сравнить "на пальцах": то за какое количество тактов провериться событие на "истечение таймаута"? за какое количество тактов провериться 10 событий на "истечение таймаута"?
в посте:

Функция проверки истечения таймаута;
Функция проверки говых по событию задач;

Функция проверки истечения таймаута - ok;
Функция проверки говых по событию задач - ok;

я спрашивал не "какая ОС это умеет делать", а "кто знает как эту ПиПиСку сделать "круче""?
scmRTOS ИМХО отличная ось, но эта ПиПиСка там для АВР не оптимизирована, мне очень жаль дарить бесценные "ядрёны" такты компилятору. Для "ядра" это "одна из" долгоиграющих функций (кто не понял - void OS::TKernel::SystemTimer())
//----------------------------------------------------------------------
На самом деле из-за своей детерминестической природы FSM
выглядит очень даже привлекательно. Ну а с позиций 8-ми биток, так вообще "шоколадно", это я с Вами, уважаемый, согласен.
из мануала:
"На самом деле, проблема не в том, что для кооперативной ОС нельзя добиться времени отклика сопоставимого с тем, что есть у вытесняющих. Это как раз достижимо ценой частых переключений задач. Проблема в том, что обеспечить такое переключение не всегда будет легко. " - масло масленное конечно, но верно.
Дело за малым - выработать методологию "превращения" каждой задачи в набор состояний
С этих позиций много проще прерывать задачи, сохранять и восстанавливать контекст.
//-----------------------------------------------------------------------
Я постараюсь конкретизировать:
Мне не нравиться, когда ключевые моменты ОС, "отданы в распоряжение" копмилятора С и посему
мне интересно, у кого есть оптимизированные "ядра" на АСМе или может есть какие-то концептуальные идеи реализации? я просто предложил свой вариант.
С уважением, yod

[dxp]

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

"Задача остается текущей столько времени, сколько захочет, а управление ядру передает исключительно добровольно. " это из манаула.
Я не знаю чего тут еще пояснять. Довольно прозрачно.

Это просто кооперативная ОСь. Ничего FSM'ного отсюда не следует.

Т.е. существует конечный ряд состояний всего ПО, для каждого состояния можно определить набор состояний(из общего множества состояний ПО), следующих за ним, и условия перехода (в д.с. события, приоритеты). Это и есть FSM.

Нет. Эдак любую программу можно к FSM'у притянуть - в любой программе всегда есть состояния.

ОС FSM'ного типа - это кооперативная ОС, в которой каждая задача организована как АВТОМАТ СОСТОЯНИЙ. Делается это для того, чтобы процессор не проводил много времени в задаче - зашел, выполнил кусок, вывалился. В следующий раз зашел и сделал другой кусок (следующую порцию общей работы). Вот так и прыгает по задаче. Латентность тут будет определеяться временем выполнения куска. А само "прыгание" по частям всего кода задачи организовывается как автомат состояний. Salvo и jacOS - обычные кооперативные ОСи, в них вы можете зайти в задачу и сидеть там по посинения, а все остальное (ну, кроме прерываний) будет стоять колом. Поэтому никто так не делает, а всегда сами руками разбивают задачу на куски, между которыми отдают управление. FSM ОС предоставляет формализованный путь сделать это. Примером именно такой ОС - nesos от товарища Нильсена.

[Dog Pawlowa]

А само "прыгание" по частям всего кода задачи организовывается как автомат состояний. Salvo и jacOS - обычные кооперативные ОСи, в них вы можете зайти в задачу и сидеть там по посинения, а все остальное (ну, кроме прерываний) будет стоять колом. Поэтому никто так не делает, а всегда сами руками разбивают задачу на куски, между которыми отдают управление.

Что-то я потерял нить...
Если все задачи реализованы как АВТОМАТ СОСТОЯНИЙ, то зачем тогда ОС? Точнее, можно ли этот способ выполнения задач назвать OC, если каждая задача гарантированно выйдет из обработки своего состояния? :
for (;;)
{
Task1();
Task2();
Task3();
}
Сам так делаю, но наглости назвать это ОС не хватает
ОС и нужна для того, чтобы не самостоятельно "врукопашную" бить каждую задачу на состояния, а чтобы планировщик автоматически предоставлял время каждой задаче. Предоставлял и отбирал, поэтому задача не может сидеть там до посинения. Иначе это не RTOS. Это Windows :-)
Ссылочку посмотрю, конечно...

[osnwt]

Если все задачи реализованы как АВТОМАТ СОСТОЯНИЙ, то зачем тогда ОС? Точнее, можно ли этот способ выполнения задач назвать OC, если каждая задача гарантированно выйдет из обработки своего состояния? :
for (;;)
{
Task1();
Task2();
Task3();
}
Сам так делаю, но наглости назвать это ОС не хватает

Не совсем такая структура - см. ссылку на jacOS. Нечто подобное должно быть внутри каждой задачи, только там Task2() в приведенном примере - это, например, OS_Cooperate() вызов для передачи управления, а 1 и 3 - это что-то полезное, что делается в задаче.

ОС и нужна для того, чтобы не самостоятельно "врукопашную" бить каждую задачу на состояния, а чтобы планировщик автоматически предоставлял время каждой задаче. Предоставлял и отбирал, поэтому задача не может сидеть там до посинения. Иначе это не RTOS. Это Windows :-)

То, что Вы хотите - это преемптивная OS (с разделением времени и принудительным переключением). А то, что обсуждается - кооперативная. Как уже говорилось, в последней гораздо проще оценить временные характеристики, поскольку все под контролем автора кода.

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

[µµC]

"Задача остается текущей столько времени, сколько захочет, а управление ядру передает исключительно добровольно. " это из манаула.
Я не знаю чего тут еще пояснять. Довольно прозрачно.
Т.е. существует конечный ряд состояний всего ПО, для каждого состояния можно определить набор состояний(из общего множества состояний ПО), следующих за ним, и условия перехода (в д.с. события, приоритеты). Это и есть FSM.

С формальной тз невытесняющие (НВОС) и вытесняющие (ВОС) оси отличаются тем, что задача у НВОС во время работы имеет наивысший приоритет. НВОС и ВОС теряют управление в "конечном ряде" своих "состояний", что само по себе не превращает систему в FSM - вообще не принципиально сколько у задачи есть "точек перехода" 10 или 500. Задачи в системе могут быть вполне автономны и асинхронны. И для системы нет того, о чем вы пишите: "для каждого состояния можно определить набор состояний (из общего множества состояний ПО), следующих за ним,". Все наоборот, из "состояния" одной задачи никак не следует "состояние" другой. Если совсем коротко: обычно задача совсем не знает о существовании других задач (исключения - сервисы создающие / перезапускающие задачи). Межзадачный обмен не рассматриваю по двум причинам: 1) в НВОС и ВОС он сделан одинаково, 2) его может и вовсе не быть.

А как их сравнивать-то - разная идеология ("архитектура")?

Вот интересно, а как их не сравнивать-то, раз делают одно дело в одинаковых условиях? Просто беру разные оси и сравниваю, по удобству, достаточности и тп. Мой выбор для AVR - невытесняющая ось для С, причем в самых простых конфигурациях.

[bodja74]

2vod

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

Код

____INIT_THREAD_CONTEXT:
    std    Y+CONST_THREAD_CONTEXT_SIZE+3,r24;save SPL
    std    Y+CONST_THREAD_CONTEXT_SIZE+2,r25;save SPH
    std    Y+CONST_THREAD_CONTEXT_SIZE+1,REG_OS_TEMP;save SREG
    std    Z+CONST_THREAD_AMOUNT,Yh    
    st    Z+,Yl    
    adiw    Y,CONST_THREAD_MEM_SIZE
    RET
;------------------------------------------------

Для этого есть такая рееедко применяемая ,но всетаки существующая команда косвенного перехода на подпрограмму по Z icall .

Скажу чесно,оси никогда не цеплял,так как считаю что асм потеряет свои преимущества перед другими языками при ее применении.
Но своебразную многозадачность реализовывал.Сами знаете ,частенько на асме проги небольшие выходят .Вот и захотельсь мне зделать многофункциональный девайс ,тоесть впихнуть несколько программ (которые были уже написаны) в один контроллер.
Я не навязываю свой способ ,но я думаю будет интересен.Раскажу вкратце.

1 Заместь векторов в таблице указываем вызов планировщика
Например заместь
rjmp PROG
rjmp INT0
rjmp INT1
.....

Пишем
rcall PLAN_START
rcall PLAN
rcall PLAN
.....

Я думаю догадались для чего заместь rjmp стоит rcall Чтобы планировчик по стеку смог определить какой адресс вектора был у прерывания .

2 К этому адрессу плюсуем адрес начала векторов прерываний одной из программ который выбрал планировщик ,подвигаем стек,и переходим на вектор,ну а дальше как обычно.

3 Естественно в PLAN_START обнуляем память до RAMEND-1 ,последняя ячейка у нас для выбора программы,ну и т.д.

Вот такие извращения.

Что нам это дает?
Можно просто тупо соединять несколько программ,с сохранением абсолютно ВСЕХ прерываний для каждой программы без каких либо переделок,все что нужно если хотим программно перепрыгивать из одной программы в другую - дописать в нужном месте номер проги в последнюю ячейку и call PLAN_START

[yod]

to bodja74

хотя конечно вот это необязательно было делать

Код

____INIT_THREAD_CONTEXT:

Этим вызовом я инициализирую
1. в стек задчи сохраняю адрес возврата (в д.с. стартовый адрес)
2. инициализирую соотв. ячейку в таблице указателей задач текущим указателем стека задачи
после всей инициализации молча прыгаю в планировщик. там пусть сам выбирает
[offtopic]

Для этого есть такая рееедко применяемая ,но всетаки существующая команда косвенного перехода на подпрограмму по Z icall .

Я пока "не догнал", как там "матеро" можно его использовать, но будем думать. Там еще проблема.
Я регистр Z оставил для пользования прерываниям - такая специфика - надо каждые __256 тактов__ _гарантировано_ обновить ШИМ-регистр таймера. А все значения в таблице прописаны во флэш.
таблица 1кб

Скажу чесно,оси никогда не цеплял,так как считаю что асм потеряет свои преимущества перед другими языками при ее применении.

ИМХО напрасно, если писать что-то тяжелее "эха" на уарте.

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

Ну то что Вы копали, спасибо кстати, это и есть "реализация своеобразной многозадачности".
про проги небольшие молчу - свою "ОС" пользую когда прога занимает от 1кб.
[/offtopic]

Я не навязываю свой способ ,но я думаю будет интересен.Раскажу вкратце.
...

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

Код

MODULATOR_INT:
    ____OCR_REG_WRITE MOD_PWM;1
    lds    Zh,ADR_MOD_TABLE_HIGH;2
    mov    Zl,MOD_ADR    ;1
    lpm    MOD_PWM,Z+    ;3     с инкрементом
    mov    MOD_ADR,Zl    ;1
    cpse     MOD_PWM,Zh    ;1/2     хитрость
    RETI            ;4  - 13 тактов SREG не портится, Z_reg портиться
далее код перезагрузки указателей на следующий сигнал

В реализиции "AVRasmOS.zip" на любой евент может быть назначена любая комбинация задач.
ну а в прерывании ____EVENT_SET и в путь
просто лишний переход RCALL (как у Вас) и последющие вычисления требует (ИМХО навскидку) многовато тактов и не способствуют универсализиции, той что не потребует много накладных расходов.

[bodja74]

Я пока "не догнал", как там "матеро" можно его использовать, но будем думать. Там еще проблема.
Я регистр Z оставил для пользования прерываниям - такая специфика - надо каждые __256 тактов__ _гарантировано_ обновить ШИМ-регистр таймера. А все значения в таблице прописаны во флэш.
таблица 1кб

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

ИМХО напрасно, если писать что-то тяжелее "эха" на уарте.

Я про реалтайм,тяжко будет поцепить на такую ось допустим генератор тестового видеосигнала,где потребуется прервание через каждые 64 микросекунды с наивысшим приоритетом.

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

Код

MODULATOR_INT:
    ____OCR_REG_WRITE MOD_PWM;1
    lds    Zh,ADR_MOD_TABLE_HIGH;2
    mov    Zl,MOD_ADR;1
    lpm    MOD_PWM,Z+;3     с инкрементом
    mov    MOD_ADR,Zl;1
    cpse     MOD_PWM,Zh;1/2     хитрость
    RETI        ;4  - 13 тактов SREG не портится, Z_reg портиться
далее код перезагрузки указателей на следующий сигнал

В реализиции "AVRasmOS.zip" на любой евент может быть назначена любая комбинация задач.
ну а в прерывании ____EVENT_SET и в путь
просто лишний переход RCALL (как у Вас) и последющие вычисления требует (ИМХО навскидку) многовато тактов и не способствуют универсализиции, той что не потребует много накладных расходов.

Хе,ну я уже говорил,я легко вцепил к своему осцилу генератор видео,без лишних телодвижений.
Вот "скоростной" вариант планировщика прерываний

Код

PLAN:
   pop R16            ;Сдвигаем стек ,старший адресс вектора прерывания нам не нужен ,все равно 00
   pop R16            ;Сдвигаем стек и заносим младший в Р16
   in  R2,SREG       ;Сохраням СРЕГ в регистре
   lds ZH,(ramend-1);Заносим адресс начала выбранной проги
   lds ZL,(ramend)
   adc ZL,R16         ;Складываем адресс программы и адресс вектора
   brcc (PC+2)       ;если у нас флаг переноса значит ZH+1
   inc  ZH
   out SREG,R2      ;востанавливаем СРЕГ
   icall                   ;переходим на вектор прерывания

Переход на подпрограмму фиксировано увеличивается на 16 тактов для любого прерывания и любой программы
Кто придумает короче поставлю пиво!!!
В основной программе и подрограммах не используются R2,R16,Z в прерывания можно использовать в качестве промежуточных. В (ramend-1) и ,(ramend) заносится адресс выбранной программы,естественно при иницилизации стека (ramend-2)

ЗЫ В принципе подобные подходы вравнивать ,тоже самое что сравнивать топор с колесом,но думаю кто интересуется многозадачностью будет из чего выбрать

[trofim]

.def Zero = rxx ;любой регистр

clr Zero ; в инициализации нулевая константа часто используется


;adc ZL,R16 ;Складываем адресс программы и адресс вектора
; brcc (PC+2) ;если у нас флаг переноса значит ZH+1
; inc ZH

;в первой строке ошибка !!!

add zl,r16
adc zh,Zero

Кто придумает короче поставлю пиво!!!

[bodja74]

Кто придумает короче поставлю пиво!!!

, ,

Заместь adc нужно add

В этом коде ,есть еще одна ошибка ,исправив ее,ускорим выполнение еще на 1такт.

[=GM=]

Кто придумает короче поставлю пиво!!!

, ,
Вместо adc нужно add
В этом коде ,есть еще одна ошибка ,исправив ее,ускорим выполнение еще на 1такт.

Стек уже подправлен, поэтому надо вместо icall поставить ijmp. Выигрыш 1 такт.
Короче, с вас пиво, вас за язык никто не тянул(:-).

[bodja74]

Кто придумает короче поставлю пиво!!!

, ,
Вместо adc нужно add
В этом коде ,есть еще одна ошибка ,исправив ее,ускорим выполнение еще на 1такт.

Стек уже подправлен, поэтому надо вместо icall поставить ijmp. Выигрыш 1 такт.
Короче, с вас пиво, вас за язык никто не тянул(:-).

Абсолютно верно,ДВА ПИВА!!!
, , ,

[=GM=]

Абсолютно верно,ДВА ПИВА!!! , , ,

Ну ладно, при случае(:-). А вы где территориально?

Кстати, почему изначально 16 тактов было, должно вроде быть 17(:-).

Вот еще подумал, используются три регистра, не гуд. А мы знаем, что первый pop r16 заносит гарантированный ноль. Если написать так

Код

[font=Courier New]
PLANi: pop  r2            ;старший байт адреса вектора не нужен
       pop  r2            ;сдвигаем стек и заносим младший
       lds  ZH,(ramend-1) ;адрес начала выбранной проги
       lds  ZL,(ramend)
       in   r2,SREG       ;cохраням SREG
       sbiw zl,-vector(i) ;реальный адрес вектора
       out SREG,R2        ;востанавливаем SREG
       ijmp
[/font=Courier New]

то будет использоваться всего один регистр r2. Но, конечно, под каждое i-ое прерывание должна быть своя подрограмма PLANi и своя константа vector(i) (1, 2, 3, …)

[bodja74]

Ну ладно, при случае(:-). А вы где территориально?

Украина,Бердичев

Кстати, почему изначально 16 тактов было, должно вроде быть 17(:-).

Команда brcc (PC+2) выполняется за 1 такт если условие не выполняется ,и за 2 если перепрыгивает.
хотя если учесть, что заменяется в векторах jmp(rjmp) на call(rcall) тогда +1

Вот еще подумал, используются три регистра, не гуд. А мы знаем, что первый pop r16 заносит гарантированный ноль. Если написать так

Код

[font=Courier New]
PLANi: pop  r2        ;старший байт адреса вектора не нужен
       pop  r2        ;сдвигаем стек и заносим младший
       lds  ZH,(ramend-1);адрес начала выбранной проги
       lds  ZL,(ramend)
       in   r2,SREG      ;cохраням SREG
       sbiw zl,-vector(i);реальный адрес вектора
       out SREG,R2    ;востанавливаем SREG
       ijmp
[/font=Courier New]

то будет использоваться всего один регистр r2. Но, конечно, под каждое i-ое прерывание должна быть своя подрограмма PLANi и своя константа vector(i) (1, 2, 3, …)

Ну раз такая жара ,тогда в векторах ставим
.org 0
jmp(rjmp) PLAN_START
jmp(rjmp) PLAN1
jmp(rjmp) PLAN2
....

и сносим pop R2
в результате

Код

PLANi:
       lds  ZH,(ramend-1);адрес начала выбранной проги
       lds  ZL,(ramend)
       in   r2,SREG      ;cохраням SREG
       adiw zl,vector(i);реальный адрес вектора
       out SREG,R2    ;востанавливаем SREG
       ijmp

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

[=GM=]

GM Ну ладно, при случае(:-). А вы где территориально?

bodja74 Украина,Бердичев

Ясенько, вам пора музей контрабандистов открывать(:-). Еще вроде там венчание Бальзака было, в костеле...А Никольская церковь стоит?

bodja74 Ну раз такая жара, тогда в векторах ставим
.org 0
jmp(rjmp) PLAN_START
jmp(rjmp) PLAN1
jmp(rjmp) PLAN2
....
и сносим pop R2
в результате

Код

PLANi:  lds  ZH,(ramend-1) ;адрес начала выбранной проги
        lds  ZL,(ramend)
        in   r2,SREG       ;cохраням SREG
        adiw zl,vector(i)  ;реальный адрес вектора
        out  SREG,R2       ;востанавливаем SREG
        ijmp

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

Ну раз пошла такая пьянка... Если хранить адрес проги не в памяти, а в регистрах (r5-r4), то получим суперсверхскоростной код(:-)

Код

PLANi:  in   r2,SREG       ;cохраням SREG
        movw r30,r4        ;current program address
        adiw zl,vector(i)  ;реальный адрес вектора
        out  SREG,R2       ;востанавливаем SREG
        ijmp

Ужоснах, если сравнивать с исходным кодом(:-). Всего 5 слов кода на прерывание, не так уж и много для вставки. Зато скорость удвоилась: 10 тактов по сравнению с 20 исходными! Это ж скока пива! Не, я стока не выпью(:-)

[bodja74]

GM Ну ладно, при случае(:-). А вы где территориально?

bodja74 Украина,Бердичев

Ясенько, вам пора музей контрабандистов открывать(:-). Еще вроде там венчание Бальзака было, в костеле...А Никольская церковь стоит?

Ааа,бывали в наших краях,будете проезжать ,свистните,пивка попьем

Ну раз пошла такая пьянка... Если хранить адрес проги не в памяти, а в регистрах (r5-r4), то получим суперсверхскоростной код(:-)

Код

PLANi:  in   r2,SREG      ;cохраням SREG
        movw r30,r4    ;current program address
        adiw zl,vector(i) ;реальный адрес вектора
        out  SREG,R2      ;востанавливаем SREG
        ijmp

Ужоснах, если сравнивать с исходным кодом(:-). Всего 5 слов кода на прерывание, не так уж и много для вставки. Зато скорость удвоилась: 10 тактов по сравнению с 20 исходными! Это ж скока пива! Не, я стока не выпью(:-)

ПЬЕМ ПИВО ДАЛЬШЕ!!!
Как вам такой вариант?

Код

.org 0
jmp PLAN_START
ldi R16,$04
rjmp PLAN
ldi R16,$08
rjmp PLAN
....

clr R17

....

PLAN:  in   r2,SREG        ;cохраням SREG
    movw zl,r4 ;current program address
                add zl,r16
                adc zh,r17
    out  SREG,R2      ;востанавливаем SREG
    ijmp

Очередной изврат заключается в подмене в векторах одной команды jmp (4байта) на ldi и rjmp (по 2 байта) ,правда такой номер не пройдет для 8 и 8535 мег,но это не смертельно учитывая ,что у них не так немного памяти для размещение нескольких программ.
Естественно планировщик в первых 2кило кода ,скорость таже,но зато не нужно дублировать PLAN для каждого прерывания

ЗЫ ГЫ,неслабая ось получилась

[=GM=]

[quote name='bodja74' date='Nov 1 2006, 16:41' post='171352']
Ааа,бывали в наших краях,будете проезжать ,свистните,пивка попьем
[/quote]
Замётано(:-)

Ну раз пошла такая пьянка... Если хранить адрес проги не в памяти, а в регистрах (r5-r4), то получим суперсверхскоростной код(:-)

Код

PLANi:  in   r2,SREG     ;cохраняем SREG
        movw r30,r4;current program address
        adiw zl,vector(i);реальный адрес вектора
        out  SREG,R2     ;востанавливаем SREG
        ijmp

Ужоснах, если сравнивать с исходным кодом(:-). Всего 5 слов кода на прерывание, не так уж и много для вставки. Зато скорость удвоилась: 10 тактов по сравнению с 20 исходными! Это ж скока пива! Не, я стока не выпью(:-)
[/quote]

ПЬЕМ ПИВО ДАЛЬШЕ!!!
Как вам такой вариант?

Код

.org 0
jmp PLAN_START
ldi R16,$04
rjmp PLAN
ldi R16,$08
rjmp PLAN
....

clr R17

....

PLAN:  in   r2,SREG    ;cохраням SREG
    movw zl,r4;current program address
                add zl,r16
                adc zh,r17
    out  SREG,R2     ;востанавливаем SREG
    ijmp

Очередной изврат заключается в подмене в векторах одной команды jmp (4байта) на ldi и rjmp (по 2 байта) ,правда такой номер не пройдет для 8 и 8535 мег,но это не смертельно учитывая ,что у них не так немного памяти для размещение нескольких программ.
Естественно планировщик в первых 2кило кода ,скорость таже,но зато не нужно дублировать PLAN для каждого прерывания

ЗЫ ГЫ,неслабая ось получилась
[/quote]

Тогда уж так, лишние регистры не помешают

Код

        ldi  r30,0x04
        rjmp PLAN

PLANi:  in   r2,SREG    ;cохраняем SREG
        clr  r31        ;current program address
        add  zl,r4      ;реальный адрес вектора
        adc  zh,r5
        out  SREG,R2    ;востанавливаем SREG
        ijmp

Почему бы и не попить(:-)

[=GM=]

ЗЫ ГЫ,неслабая ось получилась

To bodja74

Довёл до 8 тактов с незначительными ограничениями.

Или уже неинтересно(:-(?