Интересно сравнить, где "красивше" будет реализация такой нехитрой задачи:
прерывание вызывается раз в 1мс, после десяти прерываний необходимо вызвать функцию, после десяти вызовов функции вызвать другую функцию.

с while(1), все понятно: заводим 2 глобальных счетчика и вперед щелкать инкременты в прерывании.
С RTOS нешто проще как-то?

Как вы собираетесь вызывать через 10 прерываний функцию? Если без ОСРВ то при вызове функции из прерывания вы будет находиться так же в прерывании, если не придумаете другой механизм вызова этой функции. Если с ОСРВ то будет то же самое (только вне прерывания) после 10 инкрементов в прерывании будет передано (например сообщение для вашей функции которая уже будет называться задачей и ожидать это сообщение) сообщение и если приоритет этой задачи (вашей функции) будет главным то по выходу из прерывания, планировщик переключит выполнение программы на эту функцию.
Но вся эта магия приобретает интерес когда у вас будет несколько параллельных задач, например обработка АЦП в реальном времени (цифровая фильтрация), передача параметров по modbus и вывод значений на экран.

Зачем в прерывании вызывать функцию? обычно в прерывании дергаем флаг, а в цикле while(1) опрашиваем его.

Сообщение отредактировал Zelepuk - Apr 4 2017, 06:35

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

А вот при наличии вытесняющей RTOS можно гибко настраивать приоритеты задач и время до обработки вашего "флага" будет более определенным.

Добавлю к словам Baser'a

Что бы реакция МК была приближена к "мгновенной реакции", в ОСРВ это называется время реакции системы.
А так можно все делать и без ОСРВ только это будет тяжелей поддерживать и координировать взаимосвязь и время работы "функций" в вашей программе.

Тут стоит соблюдать баланс - какие-то обработки можно и в прерывании делать, а что-то передать в основной цикл. Вопрос приоритетности подзадач обрабатывающих поступающие и отдаваемые данные.

Вы предлагаете прерывании обрабатывать данные или что?
Мгновенная реакция - это конечно здорово, если нужно, например битик выставить в регистр, но FFT вы тоже считать в прерывании будете?

Да, именно в прерывании очень удобно делать FFT.
Поскольку длительность всех прерываний автоматически логится SWO трассером и ведется статитстика.
В системах жесткого реального времени самое важное - это профайлинг, а не RTOS, прерывания или что-то еще.
А тут вы профайлинг получаете не пошевелив даже пальцем .

У любого ARM-а есть туча свободных векторов прерываний и есть достаточное количество приоритетов у прерываний.
Так что делать FFT в прерываниях я бы даже рекомендовал.

Под RTOS типа Micrium OS такая концепция отлично ложится.
Они кстати сегодня разослали предложение скачать триальную версию на 45 дней с Micrium Platform Builder.

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

Решил не создавать новую тему, а здесь спросить:

Никогда не пользовался setjmp/longjmp для сохранения под Cortex M3,4 контекста - возможно ли сделать так же красиво, как по ссылке:
setjmp/longjmp AVR
Хотелось, если можно с примером кода (различие AVR/ARM).
Или как в простой AVR-ской CoOS (файл в приложении) использование setjmp/longjmp:
Какие компиляторы под ARM Cortex M3,4, GNU GCC, IAR... переваривают такое?

Сохранение/восстановление контекста делают все вытесняющие ОС. Возьмите Cortex-порт от любой и посмотрите.

Спасибо! За смотрите туда, не знаю куда... Я конкретно спросил про использование/помощь здесь, а не рыться в исходниках Осов, тосов, ртосов. Что я уже делал.

Из Вашего обработчика вызовите свободное прерывание с нужным приоритетом.

(1) организуйте для глобальных данных одну структуру. Если не хотите уходить от "глобализации"
Работать со всеми глоб. данными можно через один указатель на нее.
(2) "красиво" можно сделать и без ОС. Зависит от сложности задачи и целесообразности использования ОС.
Многие ОС для МК имеют "порты" под PC/x86
(3) Проект для контроллера надо изначально писать с расчетом на "переносимость" -
на уровне компиляторов для MK и PC. В PC прокт компилировать-запускать в своем "эмуляторе".
(например вывод на SPI заменить на вывод в файл или консоль)
(4) Если "главный цикл" в основе Вас устраиевает - посмотрите на
оболочку protothread Dunkless. ОНО работает-компилируется и на MK, и на PC (проверено).
По-сути это оболочка для цикла.

Вопрос об использовании setjmp/longjmp в контексте использования простой ос подобной или самой CooS, но вместо AVR для Cortex M3/4, например STM32F0.