Как писать хороший код Опции

[amaora]

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

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

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

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

[_pv]

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

[amaora]

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

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

[_pv]

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

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

[amaora]

что в пределах одной функции? стэк чего?
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

[=AK=]

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

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