Переключение задач на STM32f10x в Keil Опции

[Omnicake]

Здравствуйте, пытаюсь сделать простейший переключатель задач на миксе ассемблера и си, используя микропроцессор STM32f10x и среду Keil uVision 5, но постоянно натыкаюсь на непонятные моменты. У меня есть основная функция main, из которой инициализируется процессор и включается таймер systick, по прерыванию таймера запускается диспетчер, в котором я хочу сохранить состояние регистров и при выходе выйти уже не на main а на задачу.
Задачи оформлены в виде c-файлов task1.c task2.c и.т.д., к каждой задаче прикреплена структура(массив из 8 чисел) в который заносятся данные о статусе программы, ее длительности и значения SP и PC-регистров, а также зарезервирована величина стэка командой int Stack_task1[512];. Под все это дело организован еще один массив с указателем на массивы каждой из задач. В теории, при инициализации я должен загрузить в массив для каждой задачи значения SP и PC регистров, чтобы после сохранения/восстановления регистров загрузить в регистры SP и PC числа из массива и командой BX выйти на задачу, до следующего срабатывания таймера.
Однако здесь у меня возник вопрос: как мне узнать значения регистров SP и PC для каждой задачи, если она нигде не запускается? То есть она просто прикреплена к проекту, на нее ссылается массив но при выполнении программы она не выполняется нигде. ТАкже мне известно, что у STM32 два SP регистра, один из которых работает в прерывании, а другой в главной программе. Получается если я перед самым выходом из прерывания изменю значение SP, мне это не поможет, потому что после выхода оно все равно сбросится на то значение, которое было до входа в прерывание? В общем, возможно, вопросы глупые, но сам до додуматься до решения пока не могуЮ потому прошу совета. Заранее спасибо.

[Golikov A.]

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

Правда оговорюсь, я пока только теоретически подкован, ручками этого не делал....

[Forger]

Здравствуйте, пытаюсь сделать простейший переключатель задач на миксе ассемблера и си...

ЗАЧЕМ???
Ведь есть готовые OS в исходниках под это камень и среду в т.ч, где все УЖЕ СДЕЛАНО как нужно и где все отлажено и работает как надо!

[jcxz]

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

В реале - не совсем так.
Переключатель контекста (задач) это собсно - ISR. Для Cortex - конкретно PendSV. И должен быть самым низкоприоритетным из всех прерываний.
В нём переключается контекст (стек) задачи Thread-режима. Все задачи выполняются в Thread-режиме, обработчики (и PendSV) - в Handler-режиме.
Выход из Handler - возврат к выполнению задачи (возможно новой, если было переключение в PendSV).
Для переключения задачи из Thread-режима необходимо программно возбудить прерывание PendSV.
PendSV собсно и создано для операционок.
Это вкратце.

Ведь есть готовые OS в исходниках под это камень и среду в т.ч, где все УЖЕ СДЕЛАНО как нужно и где все отлажено и работает как надо!

Товарищ изобретает велосипед.
Изобретать будет долго и получится он с квадратными колёсами, так как читать доки не хочет (ибо - писатель, а не читатель и изучать существующие ОС тоже не хочет.
Если-бы хоть что-то прочитал про режимы Cortex, его регистры, обработку прерываний/исключений, то глупых вопросов не задавал-бы.
Ибо начинать надо всегда с глубокого изучения вопроса и читать-читать долго и долго, и только когда всё прояснится, тогда и только тогда можно начинать что-то писать.
А если начинает с писания, то ничего путнего никогда не получится....

[RabidRabbit]

Однако здесь у меня возник вопрос: как мне узнать значения регистров SP и PC для каждой задачи, если она нигде не запускается? То есть она просто прикреплена к проекту, на нее ссылается массив но при выполнении программы она не выполняется нигде. ТАкже мне известно, что у STM32 два SP регистра, один из которых работает в прерывании, а другой в главной программе. Получается если я перед самым выходом из прерывания изменю значение SP, мне это не поможет, потому что после выхода оно все равно сбросится на то значение, которое было до входа в прерывание?

Про то, как и что сохраняется в стеке - смотрите ARMv7-M Architecture Reference Manual, главу "Exception entry behavior". Далее, если специально не заморачиваться, считайте, что у Вас один регистр SP. Второй задействуется только если Вы специально захотели использовать исполнение кода в "непривелегированном" режиме.
В стеке для каждой задачи перед первым их запуском необходимо проинициализировать "сохранённые регистры", что-то вроде
xPSR, ReturnAddress(), LR (R14), R12, R3, R2, R1, and R0. PC (ReturnAddress()) устанавливается равным адресу функции задачи (task1() или task2() у Вас). xPSR - читайте руководство, что там должно быть. Остальные регистры - по вкусу. При возврате из прерывания SP должен содержать адрес xPSR той задачи, на которую осуществляется переключение.
Как-то так. И ещё раз - читайте мануалы и разглядывайте исходники портов RTOS для STM32, очень поможет в понимании.

[adnega]

Я бы посоветовал почитать "Джозеф Ю. Ядро Cortex-M3 компании ARM".

[Golikov A.]

В реале - не совсем так.

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

Код

Товарищ изобретает велосипед.

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

[jcxz]

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

В реальности любое переключение контекста - это выход из прерывания.
Т.е. - исполняется ваша задача (в thread-mode) ===>>
происходит прерывание (либо PendSV (вызванное программно из этой-же самой задачи) либо любое другое аппаратное или исключение) ===>>
контекст прерванной задачи сохраняется частично аппаратно (механизм Stacking: R0-R3, R12, SP, PC, PSR) частично программно (остальные регистры на входе в ISR) на стеке ===>>
в этот момент, так как находимся внутри ISR, то активным является MSP, а на прерванный контекст указывает PSP (это если прерван thread-mode, а не handler-mode) ===>>
если это обработчик PendSV, то он проверяет необходимость переключения задачи, если нужно переключать -
просто сохраняет указатель из PSP в текущий указатель стека в дескрипторе данных прерванной задачи, а в PSP загружает значение текущего указателя стека из
дескриптора данных новой задачи (которая теперь будет исполняться) ===>>
дальше - просто выходит из прерывания, а так как PSP теперь указывает на новую задачу, то после выхода будет продолжено выполнение уже её, как будто прерыванием
была прервана она, а не старая задача. Вот и всё.

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

Так как PendSV имеет низший приоритет, то соответственно он не может прервать другой ISR, и не нужно в нём делать проверку случая прерывания другого ISR
(и соответственно прерванным всегда будет PSP). Такой метод переключения задач хорошо совместим и с механизмом вложенных прерываний Cortex и с механизмом tail-chaining.
Не требует много телодвижений для переключения (как например было в ARM7/ARM9 - там ужас какие выкрутасы приходилось делать с множественными переключениями режимов и копированиями контекстов).
Исходники самого переключателя контекстов у Cortex и у ARM7/9 отличаются по объёму в разы.

Естественно - перед стартом ОС, стеки всех задач должны быть проинициализированы правильно (так как будто эта задача была прервана прерыванием), а в дескрипторах задач должны быть указатели на верхушки стеков.

[Omnicake]

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

[jcxz]

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

[Omnicake]

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

[Forger]

Если честно, разработка диспетчера (то самое изобретение велосипеда) это студенческая работа, которая по определенным обстоятельствам мне досталась и относится

Скачивайте исходники любой ОС, имеющией "порт" под cortex-m3.
Например: freertos, tnkernel, ucos.
Там же в доке будет расписан механизм работы переключателя контекста задач.

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

[jcxz]

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

какое ограничение по времени?
В прерывании таймера обычно ставится только запрос PendSV. Это чтобы всё переключение делалось в одном месте и не нужны были блокировки.
И PendSV должно иметь низший приоритет, ниже любого другого ISR, в том числе таймера, чтобы не мешать работе аппаратных прерываний (не мешать "реальному времени").
Я уже писал об этом выше.
А если вы сделаете в таймере, то как раз это будет хуже с точки зрения реалтаймовости, так как переключение будет на уровне приоритета аппаратного прерывания таймера.

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

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

[Omnicake]

Я скачал исходники FreeRTOS и первое на что обратил внимание - это то, что он написан на C, а я видимо забыл упомянуть, что диспетчер я делаю на ассемблере.

[RabidRabbit]

В прерывании таймера обычно ставится только запрос PendSV. Это чтобы всё переключение делалось в одном месте и не нужны были блокировки.

Небольшой хинт: для того, чтобы выставить запрос на PendSV, нужно установить бит PENDSVSET в регистре процессора "Interrupt Control State Register (ICSR)". После этого, когда обстановка позволит, процессор выполнит обработчик PendSV и переключит задачу (если надо).

По поводу исходников на Си - скомпилируйте без оптимизации и посмотрите на ассемблерный листинг

[jcxz]

Я скачал исходники FreeRTOS и первое на что обратил внимание - это то, что он написан на C, а я видимо забыл упомянуть, что диспетчер я делаю на ассемблере.

Скачайте порт Cortex-M для uCOS. Там всё на асм. И очень лаконично.

[Forger]

Я скачал исходники FreeRTOS и первое на что обратил внимание - это то, что он написан на C, а я видимо забыл упомянуть, что диспетчер я делаю на ассемблере.

Не все там на С, переключатели контекста (порты) написаны на ассемблере. Так организована практически любая ОС.

[Golikov A.]

С Си на Асм перейти правда 5 копеек задача, компильнул и смотри листинг, обратно муторно, а впрямую то нет проблем.

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

Единственный момент, мне казалось что переключение задач запускает все же таймер, время отведенное на задачу определяет приоритет потока, так? То есть по выходу интервала таймера он ставит флаг PendSV, и уже тот вызвавшись все делает, так?

[_Артём_]

Единственный момент, мне казалось что переключение задач запускает все же таймер,

Нет. Не должен таймер, но может. Задача может сама впасть в ожидание и переключить поток исполнения.

время отведенное на задачу определяет приоритет потока, так?

Хотелось бы, но чему равно это время - вопрос. От схемы зависит и т.д.
И прерывания могут длится не известно сколько...

То есть по выходу интервала таймера он ставит флаг PendSV

Если надо, то ставит, если не надо, то не ставит.

PendSV

PendSV переключает, если вызовут...

[Omnicake]

Прочитал в книге "Джозеф Ю. Ядро Cortex-M3 компании ARM" (спасибо кстати тому, кто посоветовал) по поводу прерывания PendSV, и меня смутило что он ждет завершения обработки других прерываний, хотя по идее в ОС реального времени они бывают иногда запрещены. В то время systick делает на мой взгляд то, что нужно: запускается программа -> выполняет несколько шагов -> приходит исключение от systick -> сохраняется контекст -> запускается диспетчер, который определяет переключать или не переключать задачу -> задача переключается/не переключается -> контекст восстанавливается.
В итоге в голове у меня сложилась такая схема того, что мне нужно сделать:
1) В начале инициализации главной подпрограммы main в дескрипторы каждой из задача должны быть загружены значения sp для каждой свой, и значения pc - которое нужно брать от метки каждой из задач.
2) При срабатывании исключения от таймера systick я должен дополнительно сохранить те регистры, которые автоматически не сохраняются и запустить алгоритм, определяющий текущий статус выполнения программы. Который при этом будет опираться на указатель первой задачи в списке дескрипторов.
3) В случае переключения я должен изменить указатель дескрипторов на следующую задачу, сместив его на 32 бита.
4) По окончанию всех операций в диспетчере восстановить состояние регистров, которые не восстанавливаются, выгрузить из дескриптора значения PC и SP и прыгнуть по адресу в PC регистре (то есть на задачу).
Однако не получится ли так, что несмотря на то, что я выгрузил значения SP для задачи а потом, выйдя из прерывания, SP снова переписалось на то значение, которое было до прерывания? И получится что указатель стэка не изменился.

[jcxz]

Единственный момент, мне казалось что переключение задач запускает все же таймер, время отведенное на задачу определяет приоритет потока, так? То есть по выходу интервала таймера он ставит флаг PendSV, и уже тот вызвавшись все делает, так?

Я не рассматривал операционок, где ведётся контроль времени на активную задачу. Очевидно что такое может делаться только в ОС, допускающих задачи с равным приоритетом.
Я использую uCOS, а в ней не допускается двух задач с одинаковым приоритетом. Соответственно - всё время CPU всегда получает задача с наивысшим приоритетом, и
менее приоритетная задача может получить время только если все более приоритетные уйдут в ожидание. Это более простая организация ОС, мне её хватает.
Когда Вы говорите про таймер, Вы путаете два разных действия ОС - решедулинг (выбор новой задачи верхнего уровня, которой и будет теперь отдаваться время CPU)
и собственно - переключение контекста (передача управления с переключением стека и рабочих переменных ОС).

Так вот решедулинг выполняется
во-первых:
при выполнении любой операции ОС с объектами синхронизации ОС (семафорами, мьютексами и пр.). Т.е. - при вызове функций ОС ЗанятьСемафор(), ОсвободитьСемафор(), и т.п.
во-вторых:
в функции таймера, который отсчитывает счётчики времени приостановки задач (OSTimeDelay(N_тактов_таймера)) вызванные задачами для создания паузы в выполнении задач.

Решедулинг определяет - изменилась-ли текущая high-priority task? И, если изменилась, ставит запрос PendSV.
Например - задача вызвала ОжиданиеСемафора() который в настоящий момент занят. Тогда она будет переведена в состояние Wait (с опциональной привязкой дескриптора задачи к
семафору). Соответственно - нужно найти новую текущую high-priority task. Решедулинг просматривает список задач находящихся в активном состоянии (хотя-бы одна должна быть,
всегда имеется фоновая Idle-задача ОС, на самом низшем приоритете, которая никогда не должна уходить в Wait (не должна вызывать никаких функций ожидания ОС)), выбирает
имеющую высший приоритет и ставит запрос PendSV. То же самое происходит в любом другом вызове функций ОсвободитьСемафор() или Занять/ОсвободитьМьютекс() или
ПриостановитьЗадачуНаNТиков() и т.п.

Само переключение контекста делается всегда в одном месте - в ISR PendSV. Это избавляет от необходимости запрета прерываний на время работы функции переключения контекста -
она может быть прервана любым ISR и соответственно - совсем не мешает аппаратным прерываниям.

Единственное, что делается в системном таймере (относительно переключения задач ОС) - это декремент счётчиков задержек выполнения задач (если задача вызвала
ожидание функцией OSTimeDelay(N_тактов_таймера) и если какой-то из этих счётчиков обнулился, соответствующая задача переходит из состояния DELAYED в состояние ACTIVE и
вызывается Решедулинг().

[Omnicake]

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

[jcxz]

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

Я думаю - Вы немного путаете. Вам наверное нужна обычная вытесняющая многозадачность, но с возможностью существования равноприоритетных задач.
И только если задача с равным приоритетом не отдаёт сама время CPU (вызывая одну из функций ожидания объекта синхронизации ОС), она может быть
переключена на следующую с таким-же приоритетом.
Приоритеты по-любому должны быть. Хотя-бы у фонового IDLE-процесса должен быть приоритет ниже, чем у любого другого процесса.

Или вам нужна корпоративная многозадачность?

[Omnicake]

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

[Golikov A.]

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

[jcxz]

таймер - это ограничение сверху, чтобы если задача не отдает процессор, его у нее отберут принудительно, спасибо за пояснения!

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

И всегда есть самый низкоприоритетный IDLE-процесс, аккумулирующий все неиспользованные такты CPU в инструкциях WFE/WFI или в цикле вычисления загрузки CPU.

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

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

PS: Вообще тема неверно озаглавлена. Ибо имеет отношение к STM ровно такое-же, как к любому другому Cortex-M, а к Keil - вообще никакого...