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

Сейчас пытаюсь делать всю работу требующую немедленного реагирования в прерываниях, без дополнительных слоев абстракции. Но есть одна медленная задача, это интерфейс командной строки. Эта задача выполняется в главном цикле, в единственном контексте который может вызывать блокирующие функции т.к. вытесняющего планировщика и множества нитей нет. Пока единственная блокирующая функция это отправка символа в USART через несколько буферов. Блокировка выполняется в виде цикла ожидания в котором вызывается "планировщик". Последний может выполнять еще какие-то задачи или перевести МК в режим простоя. Еще какие-то задачи это переброс данных между USART и FIFO структурами с которыми удобно работать задаче интерфейса командной строки. То есть если выполнилась какая-то команда которая вызвала printf с очень длинным текстом который забил весь буфер, то putc вызванный внутри printf встанет на цикле ожидания и будет вызывать задачи которые могут вычистить выходной буфер. Для этого соответственно, те задачи работающие с FIFO не должны и не могут ни на чем блокироваться, что создает некоторые неприятности в их реализации.

Дальше возникают вопросы эффективности такого метода, сейчас все задачи запускаются по каждому поводу. То есть по каждому выходу из режима простоя, который происходит на каждом прерывании. Можно обложить все задачи флагами которые выставлять в тех местах где образуется работа для соответствующей задачи. Или сделать динамическую очередь задач, чтобы не проверять кучу флагов. Несколько раз уже переписывать код по разному, обдумывал разные варианты. Но хорошего не приходит, всегда что-то не так. Например, очередь потребует нетривиальной реализации, чтобы можно было добавлять в нее задачи из прерываний. А запрета этих прерываний нужно избежать. Вопросы так же возникают по поводу того, что делать если понадобится вторая задача которая тоже захочет блокироваться.

Как сделать хорошо и без вытесняющего переключения задач?

Protothreads?
не то чтобы совсем хорошо, но зато без вытесняющего переключения

Это только в пределах одной функции? А если у меня такой стек shTask->shEval->shExactMatch->someCMD->printf->putc->shSend ? И на месте someCMD может быть одна из многих команд.

Стандартное решение для простых задач:
- Расчеты реального времени в прерываниях (ШИМ, модуляция, фильтрация и т.п.).
- В фоне "super loop" с асинхронными вызовами.
- Сведенный к минимуму функционал обслуживания асинхронных вызовов тоже в прерываниях.

что в пределах одной функции? стэк чего?
protothreads это, грубо говоря, тупо goto, очень красиво обёрнутные в макросы препроцессора С, которые позволяют писать код так, как будто это почти настоящие независимые потоки
http://dunkels.com/adam/pt/expansion.html
при этом когда у одного "потока", например shSend, который данные в буфер uartа складывает вдруг закончится буфер и ему надо ждать, в этом месте макрос незаметно сделает возврат из функции обратно в главный цикл, там поделается еще что-то следующее, а когда управление по циклу опять дойдёт до функции shSend, то он вернётся в то место где проверялась занятость буфера и продолжит как будто никуда и не отходил. вместо того чтобы тупо сидеть и ждать когда освободится буфер.

Сделать кооперативную ось. Благо она делается на чистом С (без ассемблера) и занимает шиш да кумыш места в памяти.

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

Мне видится, что лучше привести весь код задачи с блокировкой в автоматный вид, чем скрываться за макросами с неявными case/goto.



Имею привычку делать свою libc когда пишу код для МК, и у меня нет setjmp/longjmp. Никогда ими не пользовался и возможно неверно понимаю, что они должны делать. Почитаю еще, непонятно что будет если "прыгнуть" в то место из которого уже вышли и соответствующий фрейм стека уже освобожден и возможно затерт.

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

Сообщение отредактировал amaora - Dec 18 2014, 13:06

А почему не использовать разный приоритет для прерываний?
У меня прерывания работы с железом(обработка различных сигналов) имеют высокий приоритет, а так же есть терминалка которая срабатывает по прерыванию от UART - принимает по одному символу, последовательно анализирует и выполняет какие-то команды, что-то назад отправляет. Но так как приоритет прерывания UART самый низкий, он никому не мешает.

я вообще без оберток пишу либо

либо смешанные стейт машины, где переменная у switch(pc)
принимает не только безымянные значения с помощью __LINE__ и такой-то матери
но и предопределенные, и стейт машину можно без гемора переключить в другое состояние.
При этом, выполнение прерываний на стейт машинах это тоже часть задумки.
Красиво, безобразно и единообразно
В процессе эксплуатации прототред-лайк сопрограмм юзер-программист сталкивается с соблазном запилить
абсолютно все прототредами либо сильно извращаться на длинных вычислениях.
так я Вам скажу, делать этого абсолютно не нужно, если у Вас есть какая-то приоритетная часть - ее можно из прерывания по таймеру вызвать.
все решаемо, в общем. И у такой программно-аппаратной РТОС хорошие характеристики.

Кроме того, волшебные коллбеки повышают универсальность написанного.

Сообщение отредактировал _Pasha - Dec 18 2014, 18:13

Ну так именно для этого и используются библиотечные функции: setjmp сохраняет контекст и возвращает управление ядру, а longjmp восстанавливает контекст и прыгает в задачу, в то самое место, из которого задача возвращала управление ядру. А ядро в основном занято тем, что отсчитывает для каждой задачи задержки между моментом возврата в ядро и моментом, когда снова можно передавать управление задаче. При написании кода кажется, что каждая задача работает сама по себе, а команда DELAY(X) просто задает задержку X, на время которой задача останавливается.

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


решил такую проблему двухуровневыми прерываниями:
ISR1 - высший приоритет - не блокируется никогда, выполняет только самое необходимое, и затем вызывает ISR2
ISR2 - записывает данные в FIFO, и может блокироваться из main когда там идет чтение FIFO.

А можно пример вашей машины с применением callback функций?

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

Да там собственно и показывать нечего.
Предположим у нас есть грубо говоря - драйвер, он чего-то делает по SPI, но это "что-то" состоит из команды, статуса и блока данных
У нас есть одна и та же функция, protothread - like для того, чтобы:
1. Выбрать CS ведомого, пнуть spi, послав команду - выполняется из основного потока
2. Забрать статус - выполняется уже из прерывания. Тут же настраивается DMA на блок данных
3. Коллбэк из прерывания TCIF DMA - вызывает абсолютно ту же функцию, которая выставляет флаги готовности и выключает CS ведомого.

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

В итоге получается, что текст пестрит "командами" типа yield, sleep, wake - но читается как линейный код.


вот. а вызовы - разбросаны по всему тексту.
кроме того, там же есть и неблокирующий вариант - в зависимости от выставленного флага pending->block
единственно, усложнение - тогда, когда в жесткую стейт-машину возможны вклинивания "сторонних сил"
там нужно предусмотреть чтобы вызов шел с конкретным указателем.

Мне очень понравился ваш подход к написанию кода, но из вырванного куска кода из контекста, с моим уровнем знаний сложно разобраться - Решил вернуться к вашему примеру - pls можно более подробнее описание вашей псевдооперационки с объявления и описанием переменных, функций, прототипов.

Если не трудно, хотя бы на коротком примере?

Сообщение отредактировал Herz - Sep 22 2016, 09:06