В своей предыдущей статье я вскользь упомянул, что использую в проекте операционную систему реального времени собственной разработки vsrtos, которая по внешнему API похожа на FreeRTOS. Так зачем же нужно было ее разрабатывать, и когда стоит сделать выбор в ее пользу вместо FreeRTOS?
В этой статье будут разобраны плюсы и минусы использования vsrtos и FreeRTOS для определенного ряда задач, ради которых vsrtos и была разработана.
Предпосылки к созданию
В один из своих домашних проектов (о нем планирую рассказать в одной из следующих статей), после тщательной оценки требований к аппаратным ресурсам, я заложил микроконтроллер stm32l010k8 (Cortex-M0, 64 KB Flash, 8 KB RAM). По моим расчетам, я мог не задумываясь решить задачу, даже используя десяток потоков FreeRTOS. Собственно, так оно и получилось. Прототип работал хорошо и стабильно, а у меня оставалось 3 килобайта неиспользованной RAM. Далее мне захотелось расширить функционал устройства. Однако в проекте имеется LCD экран на базе контроллера ST7920 с разрешением 128 на 64 пикселя, подключенный по SPI. Для прошлой задачи скорость его обновления была достаточной, но для решения этой уже требовались доработки.
Несколько слов о работе с экранами на основе контроллера ST7920 по SPI
При работе с монохромным экраном на основе контроллера ST7920 по SPI, отправка данных или команд происходит по пакетам. Один пакет - 3 байта. То есть для того, чтобы установить координаты X/Y (обязательно устанавливаются парами), требуется отправить 6 байт (по 3 байта на установку каждой координаты). Устанавливать X/Y необходимо для каждой сдвоенной строки (внутри контроллера на самом деле экран 256x32, которой разорван посередине по оси X на два экрана 128x32, а правая часть находится под левой. Картинка отсюда).
После установки координат на начало сдвоенной строки, необходимо отправить ее содержимое - данные о 256 пикселях. При отправке данных пакетами, последовательно от самого левого пикселя до самого правого сдвоенной строки, они начнут отображаться от начала выставленной строки до конца выбранной строки + 32 (из-за организации экрана, описанной выше). В каждом пакете из трех байт данных содержится 8 бит полезных данных.
Изначально в проекте был выделен буфер под изображение на экране, размером один килобайт (128 * 64 / 8). И буфер под двойную строку (256 * 3) в формате пакетов, пригодных для отправки в экран по DMA. Данные из буфера изображения экрана построчно копировались в буфер для отправки, преобразовывалась на ходу в формат пакетов SPI для ST7920.
В итоге, для обновления экрана требовалось:
Выставить координаты X/Y для каждой двойной строки
Преобразовать строку изображения к формату для отправки
Произвести отправку.
Установка X/Y происходила отправкой независимых пакетов по 3 байта, отправка двойной строки цельным куском. И команды и данные передавались по DMA.
При таком подходе было заметно, как перерисовывается изображение. К тому же, максимальная частота SPI у данного экрана 500 кГц, что еще больше осложняло дело. Поразмыслив над тем, что у меня осталось от решения задачи на прошлом этапе, я решил изменить принцип работы с экраном и его изображением следующим образом:
Хранить изображение не в удобном для рисования формате, а в пригодном для отправки по SPI. Из-за этого объем RAM, требуемый для хранения изображения вырос в 3 раза (на 1 байт полезных данных 3 для отправки).
Держать команды позиционирования курсора на экране вместе с изображением. Это также увеличило потребления RAM.
Отправлять данные не кусками, а цельным блоком. И команды и данные вперемешку.
При таком подходе:
Значительно выросло потребление RAM
Пришлось переписать библиотеку рисования примитивов, чтобы она рисовала сразу в пригодном для отправки формате и игнорировала заголовочные команды в начале каждой сдвоенной строки.
Но, так или иначе, цель была достигнута. Отрисовка начала происходить очень быстро и начала удовлетворять требуемой для расширенной задачи скорости.
Однако, возник нюанс. На решение новой задачи уже не хватало RAM… По моим прикидкам, около 700 байт. Потоки FreeRTOS падали один за другим или происходили зависания в разных частях кода. И, больше всего выводило из себя то, что FreeRTOS не давала толком понять, где именно не хватало памяти. Я начал копаться в ее недрах и понял, что есть множество причин, которые могут не позволить программной защите памяти указать мне, что у задачи закончилось место под стек. В этом случае у меня было два варианта:
Вернуть все как было и сделать конвертацию в формат SPI для ST7920 “на лету”, производя отправку в прерываниях от SPI.
Как-то снизить потребление RAM сервисными функциями.
Переделывать все на работу по прерываниям мне не хотелось. DMA не для того изобретали, чтобы я 20% процессора тратил на конечный автомат в прерывании. А вот идея снизить потребление RAM показалась здравой.
После оценки потребления по map файлу (во FreeRTOS использовалась только статическое выделение памяти, в heap в проекте ни в каком виде не использовался. Даже sbrk), я пришел к выводу, что объекты FreeRTOS занимают примерно 25% проекта (сюда входят как используемые семафоры/мьютексы/очереди, так и внутренние данные самой FreeRTOS, необходимой ей для работы). Остальное же было занято стеками задач и новоиспеченным буфером почти в 3.2 килобайта. Выделенные стеки задач мне также казались сильно большими, но и их не хватало (об этом ниже).
Решив, что примерно 35% RAM - это сильно много, а предупреждения об отказах ОС “только если повезет”, меня не устраивают, я решил разработать свою ОС, лишенную этих недостатков. Но почему они вообще есть в такой популярной операционной системе?
Сравнение операционных систем
Недостатки FreeRTOS выходят из ее достоинств:
Достоинства |
Недостатки |
Портирована под множество архитектур |
Лишние уровни абстракции, которые потребляют стек при использовании под конкретную архитектуру |
Структуры базовых компонентов универсальны (очереди, мьютексы, семафоры) |
Большее потребление RAM |
Большое количество возможностей, которые покрывают широкий спектр задач |
Много неиспользуемого кода, который усложняет восприятие при чтении |
Можно создавать задачи как статически, так и динамически |
Код сложнее читать из-за двух разных видов инициализации (хотя внутри все сводится к одному механизму). К тому же, связывание между задачами происходит в момент регистрации задачи в процессе выполнения программы. Это ведет к более сложному анализу происходящего при падениях в HardFault |
Все компоненты инициализируются по ходу выполнения программы |
Невозможность без выполнения оценить всю связанность в проекте |
Поскольку в 95% случаев мне приходится работать с микроконтроллерами на основе Cortex-M (которые во всей линейке обратно совместимы, за исключением конкретных дополнительных возможностей в каждый более новой линейке), то было принято решение написать ОС, которая была бы максимально оптимизированной и простой для чтения только под одной архитектурой. Однако, реализуя эти принципы, она автоматически лишается описанных выше достоинств FreeRTOS.
Возможности, преимущества, недостатки
Возможности и преимущества:
-
Реализован API, покрывающий основные потребности в RTOS, совместимый с FreeRTOS:
Запуск планировщика
Вход в критическую секцию/выход из критической секции (только в потоке).
Принудительное переключение задачи (можно вызвать как из потока, так и из прерывания)
Получение времени (из потока или из прерывания), ожидание до метки времени/ожидание в течении заданного периода (только из потока)
Блокировка/разблокировка мьютекса (только из потока)
Получение семафора (только из потока), выдача семафора (из потока и из прерывания)
Получение данных из очереди (только из потока), отправка данных в очередь (из потока и из прерывания)
Инициализация всех потоков происходит в одном месте и описывается пользователем в виде массива константных структур. Это гарантирует, что никакое повреждение стека не сломает конфигурацию задач.
Проверка переполнения стека происходит на этапе каждого переключения контекста относительно данных из неизменной конфигурации задачи. Таким образом, в 100% случаев переполнение будет определено (если только не посыпалась flash, но тогда у меня вообще плохие новости…).
Недостатки
Менее гибкая, чем FreeRTOS.
Приходится вручную задавать все связи между объектами.
Работает на момент написания статьи только с Cortex-M0 (в дальнейшем планирую увеличить список до всей линейки Cortex-M. Там минимальные отличия).
Примеры использования
В качестве примера использования может служить программа из предыдущей статьи. В дальнейшем я планирую дополнять документацию перечнем проектов, в которых данная операционная система была использована.
Выводы: когда стоит сделать выбор в пользу vsrtos вместо FreeRTOS?
Повлиять на решение в пользу vsrtos могут следующие причины:
У вашего микроконтроллера мало памяти, а ОС все же требуется
Вам не очень нравится падать в hardfault по непонятным причинам, с последующим выяснением того, что ваш поток перезаписал часть системных данных ОС, а потом вы упали совершенно в другом месте при попытке воспользоваться этими данными
Вам требуется надежное связывание объектов на этапе компиляции для повышения надежности
Комментарии (40)
predator86
31.07.2021 14:19Значит в M0 эксклюзивного доступа к памяти нет. Почему бы вам не использовать М3, М4 или М7. В М0 есть что то особенное?
Vadimatorikda Автор
31.07.2021 14:23Значит в M0 эксклюзивного доступа к памяти нет.
Просто он простой) И для большинства задач его хватает.
Почему бы вам не использовать М3, М4 или М7.
Со временем и их добавлю. Просто не было проектов пока домашних, где было бы необходимо что-то выше M0. Но в планах есть M7. Благо понадобится добавить совсем немного.
В М0 есть что то особенное?
Просто нравится максимальная простота) Ясное дело, что выбирать надо под задачу. В прошлом проекте вот (по ссылке в начале статьи), чтобы байтики копировать туда-сюда без математики почти - больше и не нужно. А вот будущий проект планируется с кучей математики внутри, там M7 рассматриваю с double аппаратным.
predator86
31.07.2021 14:27Так может для М0 ОС (тем более своя) — это избыточно, а для М3, М4, М7 и FreeRTOS'а уже хватит?
Vadimatorikda Автор
31.07.2021 14:29+2Все зависит от задачи и подхода. Я тут готовлю интересную статью. Там я одну и ту же задачу решаю 5-ю разными способами. Чисто чтобы показать разницу в ресурсах и производительности.
Vadimatorikda Автор
31.07.2021 14:30А про M3 и выше. У них я бы добровольно-принудительно при наличии в чипе MPU бы еще использовал) Тоже дополню, как руки дойдут.
predator86
31.07.2021 14:33Так глядишь и полноценная ОС для Cortex M не за горами, с нормальными приложениями, динамическими библиотеками и защищённой памятью.
Vadimatorikda Автор
31.07.2021 14:35Не. Это уже Embox. Они и сами с этим неплохо справляются. У меня цель "дешево и сердито". Дать минимально нужный от RTOS функционал, стараясь потреблять памяти по-минимуму.
predator86
31.07.2021 14:38Ну тогда очень жаль, что идеальной ОС для МК нам не видать.
Vadimatorikda Автор
31.07.2021 14:52Не тему "крупных" ОС много чего интересного есть. Та же ChibiOS. Так что те, кто хотел, уже нашел. Да и если много flash и хочется крупного, то embox хороший выбор. У них поддержка классная и примеры есть. Я как-то игрался, но меня больше привлекают мелкие микроконтроллеры. Так что тут увы.
predator86
31.07.2021 14:56Та я уже понял что это сложно и времени много надо, но придется делать как в пословице: «Если хочешь чтобы было хорошо, то ...», ну в общем вы поняли.
Vadimatorikda Автор
31.07.2021 15:03Почему же? Просто цели такой не стояло перед этой разработкой. Вот и все. А чем не устраивают предложенные варианты? Они вроде как раз содержат все что вам нужно. Динамические библиотеки, консоль... По сути, почти Linux)
predator86
31.07.2021 15:10Да запросы у меня «небольшие»: приложения (без перекомпиляции) для любого МК (конечно одной архитектуры типа М3, М4, М7), и работали чтобы независимо и защищены от взаимного доступа к памяти, и вызывались как EXE файлы, и чтоб библиотеки для них были именно динамические, и т.д. и т.п. Ну в общем полноценная во всех смыслах ОС.
Vadimatorikda Автор
31.07.2021 15:26Так можно сделать во FreeRTOS. Вам нужно для этого собрать ваши задачи с флагом "-pie". При том, под Cortex-M0. Как самый младший обратно совместимый. А далее в начало полученного bin файла нужно положить информацию о том, где функция вызова. После этого можно создавать динамически task и ему скармливать функцию из вашего bin. Если нужны внешние зависимости, то можно в экосистеме сделать статическую секцию с указателями на различные функции. И из всех приложений использовать ее.
Если нет желания все это делать самому, то в EMBOX все это есть уже из коробки. Ради этого она и создавалась)
predator86
31.07.2021 15:31Я так понимаю в EMBOX это недавно добавили, потому что буквально месяц назад я терзал их по этому вопросу и они сказали что теоретически это возможно, но ни о каких вызовах сторонних приложений даже и не шло речи.
Vadimatorikda Автор
31.07.2021 15:37Спрашивал раньше, мне говорили что раньше был запуск с флешки. И если сейчас не работает, то надо просто допилить немного. Далее уже вам к ним) Я чате телеграмма спрашивал.
predator86
31.07.2021 15:45+1Мне они заявили что архитектура МК не позволяет им это сделать, наверное просто парится не стали. А по поводу доработки FreeRTOS, то там всё плохо, надо позиционно независимые инструкции и глобальную память для каждого приложения, но приложения таки смогут навредить друг другу даже если использовать MPU т.к. глобальная память самой ОС для них общая. Всё равно проще написать ОС заново с учётом всех моментов.
Vadimatorikda Автор
31.07.2021 15:48Просто надо понять, надо ли это делать. Сейчас есть одноплатники примерно за 500 рублей. И там все из коробки. Стоит ли оно того?
Vadimatorikda Автор
31.07.2021 16:35Но вот не знаю, правда. Тут нет MMU, значит динамику априори не закладывали. У нас на подобном на новой работе автопилот работает. Там куча матана крутится с приличной частотой. Проблем с производительностью нет, но это пока что) А вообще чипы огонь. Но они все же реального времени. Там даже классные секции есть мелкие чтобы мелкие ОС туда класть. Они без задержек в этом случае работают.
abondarev
01.08.2021 14:39+1Немного поясню ситуацию.
Начнем с простого, Вы пишите что хотите чтобы код M0,..4,7 запускался, но например M0 это архитектура ARMv6-M а другие это ARMv7-M. Даже набор инструкций другой. Если одна архитектура то могут быть разные реализации плавающей точки (https://habr.com/ru/company/embox/blog/418295/) разные наборы инструкций и так далее.
Теперь о внешних приложениях. Embox можно сконфигурировать как полноценную ОС с изолированными линейными адресными пространствами, но только при наличии MMU. Более того, это направление не особо востребованно, поскольку ниша Embox специализированные устройства, а там известна тредуемая функциональность на помент проектирования. Получается возможность запуска произовльного приложения - просто дыра в безопасности.
На микроконтроллерах, в принципе мы запускаем Qt (и другие приложения) когда приложение и библиотека Qt лежат во внешней памяти а сам Embox во внутренней. То есть при доработке можно сделать вариант, когда одно или несколько приложений будут собраны для конкретной конфигурации Embox, положены во внешний носитель, и могут быть вызвано любое из них.
Если говорить о динамических библиотеках и приложениях, без MMU то тут не много вариантов. Компилируем без линковки и в загрузчик приложений добавляем линкер, который из PIC делает что то конкретное. Ну или добавляем таблицу внешних символов и модифицируем компилятор, чтобы он специальным образом вызывал эти символы. Все варианты, ну скажем имеют свои недостатки и главное особых запросов нет. Я бы в этом случае предложил ucLinux поковырять.
Если говорить о реальных запросах от пользователей то в последнее время спрашивают о возможности перезаписи образа, то есть есть системный загрузчик, который вызвает основной Embox. Ну и было пару запросов, о запуске единственного внешнего приложения.
predator86
01.08.2021 15:09Начнем с простого, Вы пишите что хотите чтобы код M0,..4,7
приложения (без перекомпиляции) для любого МК (конечно одной архитектуры типа М3, М4, М7)
имелась ввиду именно одной архитектуры, с разными без перекомпиляции и так понятно что не возможно.Если одна архитектура то могут быть разные реализации плавающей точки
Приложение должно проверить наличия сопроцессоров и спец. инструкций, как в х86 архитектуре.Получается возможность запуска произвольного приложения — просто дыра в безопасности.
Ну это из серии не баг, а фитчя. Дайте возможность выбора, а там пользователь уже решит как ему будет лучше(безопаснее).модифицируем компилятор
то есть текущие компиляторы не позволяют решить эту задачу?
abondarev
01.08.2021 20:27Приложение должно проверить наличия сопроцессоров и спец. инструкций, как в х86 архитектуре.
Кому должно? И где вы видели чтобы оно проверяло? Приложение может это делать, например проверить что есть SSE инструкции и установить соотвествующие реализации вызовов, но это в сильно крутых приложениях. Обычно просто компилируют с минимальными требованиями. Благо SSE сейчас есть на всех современных процах.
Ну это из серии не баг, а фитчя. Дайте возможность выбора, а там пользователь уже решит как ему будет лучше(безопаснее).
Я и говорю, пользователи понимали что это дыра в безопасности. Ну или им намекали, что если они могут загружать любой код, то и другие смогут это сделать.
то есть текущие компиляторы не позволяют решить эту задачу?
Прочитайте пожалуйста мой комментарий.
И главное, поймите пожалуйста, ничего бесплатно не бывает. Если Вам кажется что реализовать это легко, реализуйте, я лишь говорил, что это возможно но трудно требует сущетсвенных затрат и лично я не вижу оснований чтобы этим заниматься, поскольку запросов таких нет, ну или за это не готовы платить.
predator86
01.08.2021 21:04это возможно но трудно требует существенных затрат
запросов таких нет
Значит это возможно, но никому не нужно кроме меня. Правильно я вас понял?
abondarev
01.08.2021 21:12Нет не правильно.
Это возможно, но очень сложно. Настолько сложно, что одного желания, чтобы этим заниматься, недостаточно.
С другой стороны, Embox открытый и свободный проект, если Вам интересно причем настолько, что Вы готовы этим заниматься, мы всегда рады оказать посильную поддержку.
predator86
01.08.2021 21:26если Вам интересно причем настолько
Неужели Вам не интересно? Представьте что есть такая ОС которая запускается мгновенно и полностью разделяет программную и аппаратную составляющие, при этом программы независимы и защищены друг от друга, и общение между ними и аппаратурой осуществляется только по правилам ОС через её API. Это как ардуино, только в её лучшем виде. Неужели это ни кому не нужно?
Vadimatorikda Автор
01.08.2021 21:50+1Чем круче ос, тем больше она жрет и нужно более мощное железо, чтобы это сгладить. Моя текущая ОС может дать фору в производительности FreeRTOS-у, но лишь потому, что проще. ОС, что вы опишете, не факт, что будет сильно быстрее целого Linux ядра. А последнее можно настроить с минимальными надстройками и запустить на чипе дешевле, чем многие "мощные" микроконтроллеры. Так же не стоит забывать, что сейчас есть много SoC, внутри которых есть нормальный процессор Cortex-A, а так же куча периферии и памяти внутри. И формально, у вас 1 кристалл (хоть и довольно крупный), на котором сразу все есть. И памяти мегабайт 128, и ram, мегебайт 32. Все есть. И Linux стартует сразу из коробки. И тут уже отпадает всякое желание натягивать сову на глобус.
Все же напомню главное в разработке. Для каждого проекта свое решение. Пихать одно решение всюду (как Arduino), далеко не всегда оправдано. А иногда и вредно.
predator86
01.08.2021 22:04Все же напомню главное в разработке. Для каждого проекта свое решение.
Для меня главное в разработке это затраченное время и средства, а если есть возможность сэкономить не потеряв качество, то это оправдано.
abondarev
02.08.2021 10:31Если я правильно Вас понял, то Вы предлагаете другим потретить время и средства, чтобы Вы смогли съэкономить?
К тому же вам уже много раз сказали, что универсальное решение, уступает специализированным.И универсальное решение уже есть ucLinux. Дорабатывайте если необходимо.
Вот у автора получился интересный результат для совсем маленьких систем. Причем попутно предложено пара решений для проблем с которыми мы сталкиваемсяь. и даже рассматриваем аналогичные решения время от времени.
Приведенный вами ардуино не буду критиковать, но отмечу что у них нельзя запускать произвольный код, даже скомпиленный под аржуино. Нужно для задачи перекомпилировать.
predator86
02.08.2021 13:02я просто пытаюсь понять, нужна ли полноценная «идеальная» ОС для МК, хоть кому-нибудь и идёт ли кто-нибудь из разработчиков в этом направлении.
универсальное решение, уступает специализированным
не спорю, но возможно цена универсальности окупится меньшим затраченным временем, доп. возможностями и можно оказаться в значительном выигрыше.у автора получился интересный результат
Да, даже интересно в каком направлении будет дальнейшее развитие.ардуино не буду критиковать, но отмечу что у них нельзя запускать произвольный код
Вы меня не так поняли, под ардуино имелось в виду простота и доступность для большой аудитории. По сути у начинающих просто нет другой альтернативы, которая не напугала бы их своей сложностью.
belav
31.07.2021 15:33+2А чем не понравилась, scmRTOS?
Vadimatorikda Автор
31.07.2021 15:43-1Честно, даже не знал о ней. Сейчас почитал документацию, посмотрел код. В принципе, если описание не врет, то интересная ОС. Но увидев ее все равно бы писал свою, потому что:
На C++.
Несколько слоев абстракции. Тяжелее читать. Часть будут убраны компилятором, а вот часть нет.
А если бы писал проект на C++, то для интереса бы глянул.
sim2q
31.07.2021 17:45Ух, ассемблера внутри... страшно)
Заглянул в надежде увидеть сразу терминал внутри, почему то подумалось что он там сразу встроен будет.Vadimatorikda Автор
31.07.2021 17:49Терминал - это вам к Embox) Тут у нас борьба за каждый байт. Сейчас ОС уже прошла испытания временем (месяц устройство на ней проработало стабильно). Далее есть рад замечаний, что будут влиты по окончании тестов. По текущему раскладу удастся высвободит около 300 байт flash на Os, что не мало.
Vadimatorikda Автор
31.07.2021 17:50Ну и ассемблера там минимум. И то, только потому, что нет тега, говорящего GCC не трогать push при входе в функцию.
lis82
01.08.2021 18:58__attribute__((naked))должен помочь, правда он кроме push/pop ещё и ret выкинет - нужно будет явноBX LRв конец функции дописывать.
abondarev
01.08.2021 13:28+1Спасибо за статью! Интересные результаты!
А не думали применить подход Embox, то есть компилировать только нужные части из FreeRTOS? Я имею в виду, у Вас получилось интересное и эффективное решение для определенного класса задач, и на мой взгляд главный недостаток не в меньшей гибкости, а в меньшей отлаженности и протестированности решения. Вы же не просто так сохранили совместимость по API, и если я правильно понял задумку то в идеале вам следует переиспользовать планировщик (может быть аддаптированный) и добавить свои фичи, типа статической инициализации задач.
Кстати, на счет последного и проверки переполнения, правильно ли я понимаю, что за счет статичекой инициализации вы и легко проверяете выход за границы стека. То есть в прерывании вы смотрите на текущую задачу и проверяете что указатель стека находится в ее границах?Vadimatorikda Автор
01.08.2021 14:25+1А не думали применить подход Embox, то есть компилировать только нужные части из FreeRTOS?
Оставил только ядро, статические методы для регистрации объектов, мутексы и семафоры. Все остальное, что не использовалось, отключил.
а в меньшей отлаженности и протестированности решения
Само собой пока что не могу гарантировать что в ОС нет ошибок. На данный момент ее наработка в проектах безотказно только около 3 дней без остановки. Нужен куда более долгий срок анализа. Также сам код еще нуждается в улучшениях. Сейчас работаю над ними в нерелизной ветви.
Вы же не просто так сохранили совместимость по API, и если я правильно понял задумку то в идеале вам следует переиспользовать планировщик (может быть аддаптированный) и добавить свои фичи, типа статической инициализации задач.
Оставил для того, чтобы можно было легче переходить с одной на другую. Я не позиционирую свою, как заметили в личных сообщениях, "всрат-ос" (название оставлю, будет как PIDORA, запоминающимся) как замена FreeRTOS. Это скорее выход из положения, когда осознаешь, что не влез, а партия на руках.
А теперь насчет расширения ядра... Честно, FreeRTOS страшный. Я много лет смотрю на него. И это обилие ifdef убивает. Я пару раз делал его порты под мало кому известные архитектуры. Местами просто под давно уже мертвые... И достаточно насмотрелся на ее код. Но это не отменяет ее главного достойнства. FreeRTOS - работает. Если конечно настроена верна.
Кстати, на счет последного и проверки переполнения, правильно ли я понимаю, что за счет статичекой инициализации вы и легко проверяете выход за границы стека. То есть в прерывании вы смотрите на текущую задачу и проверяете что указатель стека находится в ее границах?
Да. Именно так. И, забыл написать в статье. Напишу тут. Есть киллер фича. Вы можете разместить основную структуру ОС в RTC регистрах у микроконтроллера. Тогда ее 100% никто не перепишет и если упадете, то 100% будете знать, где именно. Не обязательно RTC регистры. Куда угодно, где есть 4 32-х битных слова быстро изменяемой памяти.
predator86
При синхронизации отключаются ли на время все прерывания?
Vadimatorikda Автор
Т.к. речь про Cortex-M0, то да. Иначе надежно не сделать.