Что необходимо знать, чтобы написать свою Embedded RTOS (часть 1)

Предположим Ваша динамически слинкованая программа ожидает, что динамически заргуженная библиотека будет находиться в блоке памяти, начиная с адреса X. Пусть для простоты этот блок включает в себя и исполняемый код и данные, которые библиотека для себя харниит в памяти. Однако на целевом процессоре у Вас эта библиотека загружена по адресу Y.

Если Вы попытаетесь загрузить ее и "слинковать" вручную, то Вам каким-то образом нужно будет перехватить все запросы к адресам в блоке Х и подменить адреса так, чтобы они ушли в блок Y с корректными смещениями. Если у Вас есть MMU, то это тривиально. Вы просто подставляете в таблице виртуальных адресов адресам для диапазона X корректные физические адреса, на которых загружена библоитека.

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

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

И это все равно будет работать только до тех пор, пока Ваша библиотека thread-safe. Если только нет, то ее разделение между тасками потребует кучу дополнительных оверхедов для менеджмента синхронизации. В случае с MMU этой проблемы нет, потому что когда нужно, страница в которую поток попытается что-то записать будет просто скопирована и станет уникальной для этого потока.

Вот здесь немного о том, как можно делать shared библиотеки без MMU http://xflat.sourceforge.net/NoMMUSharedLibs.html

Фрагментация памяти, ее малое кол-во, хранение списка [название функции : адрес функции] для прилинковки функций из ядра к приложению и поиск функции в этом списке на этапе загрузки (в достаточно больших ОС это вполне могут быть сотни килобайт данных).

Правильно ли я понял, что у вас функция void PendSV_Handler(void) да еще с вызовом планировщика выполнится в худшем случае за 1 мкс?

Да вообще, ну смотрите, если в РанТокоплишен, переключение делается примерно вот так:

while (nextTaskId < activeTaskId)
      {
        activeTaskId = nextTaskId;
        CallTask(nextTaskId); // вызываем задачу и сбрасываем установленное событие
        nextTaskId = GetFirstActiveTaskId(); // вдруг есть еще активные задачи
      }

Т.е. по факту, просто вызываем функцию высокопритетной задачи прямо на этом же стеке.

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

Я вот тут, ну совсем примитивный способ переключения описывал https://habr.com/ru/post/506414/

Нам же нужен номер высыкоприоритетной задачи в массиве задач? Вот он как раз вернёт индекс задачи, дальше только вызвать её остаётся по этому индексу.

А вот как на Ваш взгляд - RISC-V проектировался чтобы удобно было писать RTOS? Хотелось бы чтобы Вы продолжили свою тему, т.к. Вы рассмотрели пока только простые вещи, а вот интересно как раз посмотреть реализацию чего-то более сложного.

В тех проектах где я работал(аю), данная проблема не проявлялась. Но и в целом я не сторонник большого количества задач в системе, где возникает необходимость мьютексов и такие запутанные случаи с ними. Последнее время я предпочитаю сбалансированный подход, стараясь внутри задачи организовать Event Driven архитектуру и минимизируя тем самым количество задач.

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