@OVY-srok

/* репозиторий */
/* https://bitbucket.org/OVY-srok/rtos-cortex-m3-gcc */

Ос потоковая, это означает что все активные на данный момент задачи выполняются в порядке очереди, без приоритетов.
Аналог приоритета - процент выделенного времени , есно в процентах от 100% до 1% - от номинального значения, которое есно задаётся при старте.
Старт ос в любом месте майна, но при этом оптимизация есно должна стоять os. После старта есть две задачи: майн и нулевая - которая отдаёт время если кто-то ещё активен.
Задача может: быть активной, уснуть, быть зависимой (ожидание), запускать уникальные задачи, запускать задачи под своим именем, может уступить время (актуально для короткого циклического кода), может убиться и удалиться в любом участке кода спец командой, может автоматически стереться в случае отсутствия бесконечного цикла, может разбудить зависимую задачу.

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

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

На данный момент вся ос это два файла, работает исключительно под Sortix-M3 GCC. И главное - модификаций кода не требуется, ось сама достаёт всё необходимое и перемещает стеки на рабочее место.

Прочитаю любые предложения, даже безумные.

0

@OVY-srok

Обновление.
Служебная структура malloc теперь занимает 8 байт минимум, 4 байта под имя/размер и минимум 4 байта данных. Размер выделяемой памяти от байта до 32М. Память растёт снизу - на встречу стеку, всё в общую кашу. При удалении задачи - занимаемая память очищается. Новый кусок выделяется из первого подходящего пустого места. Стек работает аналогично - но сверху.
Собственно в этом разница между остальными свободными ос, где необходимо снашаться с каждой задачей по отдельности - по долгу подбирая необходимый размер выделяемой памяти.

Новые функции:
sTask_memory_donate - Отдать память другой нитке ( & link_memory, "task_func_name") (функция подтверждения)
sTask_memory_have - Получить память от другой нитки ("task_func_name") (функция подтверждения)
sTask_resource_ask - Запрос ресурса, бесконечный цикл - пока не освободится
sTask_resource_free - Освободить ресурс
Homdler_zize - Проверка границы стека прерываний, функция применяется любом прерывании приоритета 1 , результат в общей структуре.

Функции общения отдельных задач без подтверждения - нативны до безумия, это банально структура с распределённым доступом чтение/запись. Для каждого уникального условия создаётся собственная структура с уникальными параметрами. Структура может быть статической или создаваться в отдельной задаче из выделенной памяти - вариантов море. По сему давать пример, или описывать стандарт - нет смысла.

Ради прикола запустил минимальный проект с рисованием гифки на экранчике и малость математики - на разных ос.
Максимальные тормоза - чибиос. Как не странно - наличие готовых пустых проектов облегчает холодный старт. Просто добавь своё -и оно работает, хотя и тормозит.
Чуть быстрее - FriiRTOS. Очень сложно заставить работать с холодного старта - необходимо бешеное количество нигических слов, в основном матерных.
Segger - максимальное быстродействие, быстрее даже чем у меня. Но шаг влево/право - и карточный домик падает. У них подробная ерата - куда низя ходить. И типа настоящий джедай должен эту карту помнить постоянно. А у меня память плохая...

Моя ос, по сравнению с первыми двумя - добавление задачи с математикой не вызывает заметного снижения скорости отрисовки графики. Точнее - можно удивить при тотальном подсчёте от рисованных кадров за минуту. Где-то минус 1-2 кадра.
Для первых дух ос в вытесняющем режиме - скорость отрисовки падала более чем в два раза...

0

@MrYurom

Что-то мне кажется, что простейшая ОС для СМ3 и вообще ARM должна представлять из себя конфигуратор NVIC

0

@OVY-srok

Под м3 простых указаний адресов стека - мало. Потому как нет аппаратной поддержки шрейдера задач как в старших процах. Посему приходится ручками собирать стартовый образ стека для каждой новой задачи.
Есть два способа решения этой проблемы:

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

Второй вариант - задачи динамически распределяют свободное пространство. Перепроцессором такое просчитать просто невозможно, посему юзается алгоритм поиска свободного места.
Ситуация: памяти всего 8к, а нужно переписать один байт в памяти 25q64, для этого требуется кеш сектора в 4к + кеш в 512 байт для операции записи. В этом случае временно удаляем всё не нужное из памяти, запускаем жирную задачу, и ожидаем её завершения.

0