А как же setjmp/longjmp ?

Переключатель задач по таймеру прерывает процесс. Участие в этом действии со стороны процесса - не требуется.
Это определение вытесняющей многозадачности.

Хотя процесс и имеет возможность прервать сам себя... И это не противоречит вытесняющей многозадачности.

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

---
Что такое setjump узнал только сейчас. (Я Си специально не изучал никогда).
Может и можно. Но по-моему быстрее скопипастить два десятка ассемблерных строк переключателя, чем разбираться в том, что именно на самом деле делают упоминаемые функции Си.
--
В том плане, что к примеру для АРМ там надо ж сохранять контекст в режиме работы процесса...Т.е. setjump должен из режима прерывания сохранить контекст другого режима (режима задачи).
Что-то сомневаюсь, что он это делает. Ибо такая функция будучи универсальной должна как-то разбираться в конкретных режима процессора... Что все сильно усложняет...
А меня, лично, сложное всегда сильно пугает.

Сообщение отредактировал DpInRock - Nov 30 2011, 02:54

система должна принимать данные от АЦП, обробатывать их блоками, передавать по UART (по 3-м сразу и независимо), весли лог работы на SD-карту, работать с часами реального времени....
вобщем пример класический)

Всё работает на "суперлупе" по прерываниям и циклическим опросам флагов.
Когда (и какая) может возникнуть ситуация, что нужно будет задуматься о применении вытесняющией многозадачности (без ОС и пусть такая программа сама по себе нечто вроде ОС)?

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

Мда... На каком контроллере? Есть конкретные результаты сравнения? Можно ли с ними ознакомиться?

Вполне тянет на минимум кандидатскую диссертацию. Ваши интересы не затрону?

буду краток:
ось, планировщики (и т.д.) нафик не нужно в МК. Это Вы ребята подсознательно хотите как у "больших" типа. зачем тягаться в той весовой категории где МК вообще все плюсы сольёт. Чем будет отличаться то? тем что на борту у него есть аппаратная реализация то, что у "больших" на матери? всё?

по мне: единственный плюс разработки с юзаньем оси - командная разработка (типа просче дробить, тестировать, изолировать и т.п.), и скорость в счёт качества(подсобрать всякую тучу кривых библиотек и сапотить энным кол-вом работников). всё.

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

удачи вам
(круглый)

похоже это то что я ищу, но пока не понимаю как конкретно в контексте "С" выглядят конструкции:
- установка и обработка приоритета для события,
- сам процесс переключения событий и "прерывание" низкоприоритетных событий высокоприоритетными, при сохранении состояния первых

а вообще вы нечто вроде этого имели ввиду?:

Сообщение отредактировал Zelepuk - Nov 30 2011, 08:48

1. зависит от контроллера прерываний. Например, в MSP430 приоритеты заданы железно и поменять их не удастся.
2. не ваша забота. Компилятор сам все сохранит. Главное, чтобы были разрешены вложенные прерывания (то есть возможность прерывания текущего прерывания более приоритетным)

спасибо.
говоря о приоритетах прерываний в MSP430 вы скорее всего имели ввиду аппаратные прерывания, но как быть, если мне нужно отреагировать на программное событие (накопился блок данных АЦП например). С "суперлупой" это организуется циклическим опросом флагов.

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

Или все отладку хотят выдать через уарт.... Ну и так далее.

Вот мне дяденька добрй дал задание. Сделай, говорит, маленькую радиостанцию, каналы, то, се. (Вроде как задачка для авр...). А заодно, говорит, присобачь для комплекта ФМ-радио, МР3 плеер, фоторамку. И чтоб цветно было и 3D. И вот громоздить суперпупер лупы - даже предположить опасаюсь...

а я в очередь ставлю через шаг. 1 3 5 7. и у меня 3 приоритета.

0- это реального времени, при возникновении прерывания задача полностью отрабатывается. (ком по пдп набил буфер, и по прерыванию его сразу обработала задача)
1- это быстрое, задача ставится в очередь, в ближайший свободный шаг. если выполняется задача 5, то ставится в очередь на 6 место. (ком по пдп набил буфер, и по прерыванию, поставил задачу на обработку буфера в очередь)
3 - обычные задачи. задача ставится в хвост очереди. на 9 место

Сообщение отредактировал Warlockwolf - Nov 30 2011, 10:07

Катит только для архитектур с одним SP. Для ARM7, например, требует внешних костылей для сохранения User SP. Для CM3 - только в режиме с одним стеком.

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

Сообщение отредактировал Zelepuk - Nov 30 2011, 13:32

Да вы сначала реализуйте просто по очереди.
Тут все просто как в зоопарке.

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

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

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

хидер



соурсе




Коментарии я почти не пишу. так что разбирайтесь как есть.
InDNA()- в очередь в конец.
InDNA_rapid()-в очередь в пустое место, если 16 ближайших заняты, тогда в конец.



Сообщение отредактировал Warlockwolf - Nov 30 2011, 17:48