Как стать автором
Обновить

Комментарии 45

И тут я сохраняю контекст задачи 1, и говорю ей: "пришло твое время поработать"

А как она поработает если вы ее из процессора в стек выгрузили?

Должно ж быть "я восстанавливаю контекст" и уже восстановленный запустить в работу, не?

Переключение контекста

Это действие, при котором сохраняется контекст последней выполняющейся задачи, выбирается следующая задача, и восстанавливается контекст текущей выбранной задачи

"последняя", "следующая" - это понятно, а зачем тут "текущая" непонятно. Более понятно восстановление контекста выбранной не предыдущем этапе т.е. "следующей задачи", а не понятно откуда взявшейся (явно не проговоренной) "текущей".

Та я уже уставший был когда публиковал, и картинку на скорую руку сделал, тольк опотом сообразил)

Отредактировать не мог, пока статью не опубликовали. Вот, опубликовали - сейчас и исправлю)

И спойлеры подправлю, т.к. в них нет названий...

"последняя", "следующая" - это понятно, а зачем тут "текущая" непонятно

Последнюю мы вытеснили, выбираем следующую, и она становится текущей)

Все понятно)

Памяти всего 1 килобайт, переключаем, вытесняем, обрабатываем... А работать когда?

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

Памяти всего 1 килобайт, переключаем, вытесняем, обрабатываем... А работать когда?

Я не понял в чем суть замечания.

Работаем во время кванта времени, который длится 1 мс, если хотите - меняете период прерывания таймера, и задаёте свой квант времени, вот и работаете. До 100 мкс ядро, 1000 мкс рантайм (можете задать 10 мс, тогда рантайм будет 10 000 мкс).

Памяти всего 1 килобайт

Каждая задача требует 35 байт для стека, значит, если у нас целых четыре задачи, то:

35 * 4 = 140 байта1024 - 140 = 884 байта

Целых 884 байта остается!

Даже если каждый таск будет вызывать 4 вложенных функции, это еще плюс 32 байта.

Ну тогда будет 852 байта.

Этого недостаточно для чего?

По-моему для всего за глаза...

GitHub это полезно и бесплатно. 

Целью для меня была именно статья, а не проект. Если буду выкладывать эту ОС как релиз - заведу гит.

Для такого мелкого контроллера лучше сделать вытесняющую ОС с run to completion задачами, в таком случае, не нужен будет отдельный стек для задач, и вообще не надо будет заморачиваться с сохранением контекста задач, все автоматом будет делаться компилятором, ну и конечно переключение контекста будет в разы быстрее.

Еще вопрос, а зачем для микронтроллера не ОСРВ вытесняющая операционка? Ну т.е основное преимущество ОС для микронтроллеров, это как раз возможность по событию быстро переключиться на высоко-приоритную задачу, чтобы обеспечить "мгновенную реакцию", т.е послал я из прерывания по таймеру событие задаче измерение, тут же ее вызвал. Не совсем уловил этот момент у вас. У вас получается как в Винде, пока 1мс не пройдет, никакой реакции, верно я понял?

лучше сделать вытесняющую ОС с run to completion

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

  1. Их, с аппаратной точки зрения, я знаю лучше других архитектур, а значит я буду сконцентрирован только на ОС, а не изучении архитектуры;

  2. Хотел сделать максимально простую вытесняющую ОС, которая поедет даже на AVR, т.к. если делать сразу под ARM - многие моменты по поводу оптимизации могут ускользнуть, т.к. там ресурсов хоть жеппой жуй. Такой себе челендж для меня;

  3. Опять же, я уже отвечал на другие комментарии, цель этой ОС, в первую очередь - обучение.

Первым требованием к моей ОС была возможность вызывать в задачах тупые задержки "while", т.к. делать это в кооперативных ОС нельзя, и в "run to completion", если я правильно понимаю что это, тоже нельзя.

Ожидать что-то через сервисы ОС не всегда удобно. Как опытный пользователь кооперативной RTOS - я просто уже за*бался что-то ждать без "while", если нет требований к быстродействию.

Без "while" код начинает выглядеть ненаглядно, и не далеко уходит от использования конечного автомата в "main()" без использования ОС в принципе.

Ну и конечно же сделать вытесняющую ОС общего назначения мне банально было интереснее.

Можно сказать - мечта детства, сделать свой мини-компьютер на AVR, подключить дисплей, внешнюю память и т.п. Вот для этого мне и нужна была вытесняющая ОС общего назначения. Конечно, это не эффективно, если сравнивать с Ryzen 2600 и материнкой на X570. Но это просто домашний проект, ничего важного для посторонних людей. Это просто для души)

а зачем для микронтроллера не ОСРВ вытесняющая операционка?

А я в статье не написал что она "не ОСРВ". Правда и не написал, что она "ОСРВ"...

  1. Потому что побоялся холиваров;

  2. Я не смог найти четкого определения ОСРВ, чтобы мог уверенно ее так назвать.

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

Вот когда доделаю - измерю время реакции, и, наверное, назову ее ОСРВ)))

У вас получается как в Винде, пока 1мс не пройдет, никакой реакции, верно я понял?

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

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

Я имею ввиду, вот к примеру, пришло внешнее прерывание от АЦП и нужно тут же посчитать что-то. Понятно, что в прерывании считать не надо, иначе заблокируем все, надо передать событие задаче. Обычно так и делается, прерывание просто генерит событие, тут же вызывается планировщик и запускается нужная задача для обработки события, а как это у вас будет происходить? Насколько я понял, пока не пройдет квант времени, ничего не произойдёт. Т.е. придется эту 1 мс ждать в худшем случае, верно?

run to completion", если я правильно понимаю что это, тоже нельзя.

В run to completion они(задержки) не нужны :). Задача вызывается только тогда, когда она нужна. Это кстати еще хорошо с точки зрения потребления, и не надо каждый раз 1мс долбить таймер в 90% в пустую. Но придется задействовать много таймеров, ну либо также можно сделать на одном таймере, но тогда долбежка тоже будет.

В run to completion они(задержки) не нужны :). Задача вызывается только тогда, когда она нужна.

Это получается таблица событий. Это не то, что мне нужно.

Я имею ввиду, вот к примеру, пришло внешнее прерывание от АЦП и нужно тут же посчитать что-то. Понятно, что в прерывании считать не надо, иначе заблокируем все, надо передать событие задаче. Обычно так и делается, прерывание просто генерит событие, тут же вызывается планировщик и запускается нужная задача для обработки события, а как это у вас будет происходить?

Если задача 1 ждет семафор, а задача 2 выполняется, то пока квант времени задачи 2 не закончится - задача 1 не получит управление, даже если семафор установлен.

Смена контекста из прерывания еще не реализована. Но она будет.

Ох... Человече... Будьте моим Гуру)))

Вообще то локальные переменные обычно хранятся на стеке. и уже оттуда помещаются в регистры, по мере необходимости их использования. В конце концов локальных переменных то же может быть много ( ну кто знает, сколько вы их объявите внутри функции, хоть 50 штук) Где на них столько регистров наберешься???? По моему по договору (для армов) первые три регистра используются для хранения локальных, а вот все остальное (будь те любезны) на стек.

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

Локальные переменные не хранятся в стеке просто так. Либо я не понял что имеется ввиду)

Да, они могут попасть в стек в ходе выполнения функции, например, если нужно что-то сохранить, и выполнить другие манипуляции и этими же регистрами, но это зависит от компилятора.

И это хорошее замечание, которого я не учел, спасибо!

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

В регистры вы можете поместить столько локальных переменных, сколько у вас регистров. Все остальные будут храниться на стеке и при необходимости перемещаться в регистр. Когда происходит выход из функции, SP выставляется в адрес, на котором он был в начале функции.

Под "naked" функцией возможно имело смысл поискать по ключевому слову "inline" функция? Как помню для старых 8 битных avr все функции по умолчанию инлайнились компилятором.

Под "naked" функцией возможно имело смысл поискать по ключевому слову "inline" функция?

Я не уловил смысл. Где поискать и зачем?

Как помню для старых 8 битных avr все функции по умолчанию инлайнились компилятором

"naked" точно убирает prolog и epilog, т.к. этот атрибут именно для этого и нужен.

А вот "inline" - я не уверен что все компиляторы делают все одинаково с ним, так что его я для этих целей использовать не рекомендую.

Только что проверил в этом же проекте - компилятор мне ничего не заинлайнил. Ему вообще все пофигу. Либо моя 8-битная avr-ка недостаточно старая)

все функции по умолчанию инлайнились

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

Разве что речь о старых AVR, в которых не было стека, но я о таких не слышал)

INLINE

Нет, не все. Где то надо перед объявлением функции явно указывать ключевое слово "inline". А для наиболее простых мк (частный пример 8 бит авр, в авр студио), по умолчанию инлайнил функции, которые допускали возможность прямого выполнения в коде, как вы выразились без "пролога и эпилога".

inline именно про встраивание функции в тело другой функции и ключевым словом является только в С++, оно не имеет никакого отношения к удалению пролога и эпилога. Тут нужен именно naked.

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

Спорить не буду. Пишу на "Си". Если перед Си функцией объявляю ключевое слово "inline" GCC не ругается. Будет использоваться стек компилятором в этом случае, не проверял. Но предполагаю, что для уменьшения накладных расходов, большинство функций можно сделать встроенными в тело главной функции.

Но предполагаю, что для уменьшения накладных расходов, большинство функций можно сделать встроенными в тело главной функции.
Какие именно накладные расходы Вы имеете в виду?

Расходы на вызов, возврат, перекладывание данных в нужные регистры, через которые передаются параметры в функцию, прочие манипуляции, описанные в ABI.

Но все эти накладные расходы не важны, когда прошивка не помещается в МК, не зря inline на -Os не включается, и вообще компилятор сам решает, встраивать функцию или нет. Заставить его можно через forceinline, только скорее всего это плохая идея.

И для того, что описано в стаье inline не подходит, т.к. он именно встраивает функцию по месту вызова, и если встраивание не удалось (например, куда встраивать обработчик прерывания?), то пролог и эпилог никуда не денутся.

И тут возникает вопрос: а зачем? Вы уж извините, но в данном контроллере каждый байт на счету, как в памяти так и во флеше. Отладка Операционной Системы и тестирование на данном микроконтроллере у Вас займет столько времени, что Вы никогда не окупите проект даже если будете работать за свой счет 95 % времени. А почему пишу - мой КБ (конструкторское бюро) мне выдал PIC16 для 30К $ девайса. Все было сделано на ассемблере за 2 года, плюс 1 год потрачено на новую функциональность из-за нехватки памяти. А потом на новом 32 bit контроллере с 256 Flash и 256 RAM я сделал похожее устройство (правда, прототип) без всех ограничений (а они были, уж поверьте) за 3 месяца удаленно. И тут дело не только в опыте.
И Ваш проект звучит - мне скучно и нечем заняться, но не рекомендуйте его пожалуйта :) Нужна OS for Embedded - ThreadX лежат исходники например, Linux тоже не закрыт.

Никак не хочу оскорбить - просто Ваша статья может ввести в заблуждение

И тут возникает вопрос: а зачем?

Чтобы разобраться!

Это удивительно, и может показаться не очевидным, но разбираться, делая с нуля, шаг за шагом - полезнее, и в некотором смысле проще, чем разбирать код уже готовой ОС. Т.к. там:

  1. Много ненужных фич, которые будут отвлекать;

  2. Много оптимизаций, которые могут запутать;

  3. Не понятная структура для того, кто еще не делал такого ни разу. Вот и я, не делал такого ни разу, поэтому решил сделать свое, чтобы разобраться.

Я так понимаю, вы сторонник идеи "зачем делать свое, если все сделано до нас".

Вот мне как раз таки становится грустно из-за этой идеи...

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

"Подключаете библиотеку, копируете мой код - и у ваш веб-сервер и дата центр готов."

Круто, конечно, оно работает, но мне от этого грустно(

И Ваш проект звучит - мне скучно и нечем заняться

Скучно и нечем заняться - это запускать Скайрим на тесте на беременность, что, кстати, уже было.

"разобраться, как это сделать" != "нечем заняться"

А если я портирую проект на PIC24 или ARM - что-то изменится? Вашу претензию удовлетворю, т.к. там памяти больше. А что еще хорошего будет?

У моего проекта было три цели:

  1. Разобраться, как сделать вытесняющую ОС;

  2. Сделать вытесняющую ОС для AVR;

  3. Определить, насколько это целесообразно, использовать вытесняющую ОС на AVR, т.к. их действительно мало, но они есть.

Так вот:

  1. Первый пункт выполнен;

  2. Второй пункт выполнен, хоть, она еще и не доделана;

  3. Третий пункт выполнен, считаю, что это весьма целесообразно.

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

И я в статье нигде не писал, что создаю конкурента FreeRTOS, ThreadX, или буду ее рекомендовать для Automotive-разработчиков или Илону Маску. А как раз таки, указал, что это ради обучения и примера. Я ни в коем случае не рекламирую свой проект, я его приложил как доказательство, что все работает, и чтобы те, кому интересно, могли поиграться, если не нашли всех ответов в статье.

А по поводу:

мой КБ (конструкторское бюро) мне выдал PIC16 для 30К $ девайса. Все было сделано на ассемблере за 2 года, плюс 1 год потрачено на новую функциональность из-за нехватки памяти.

И я не понял, у чему это было упомянуто, но, думаю, ваше КБ делает что-то не так, если приняло такое решение.

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

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

ОС вносит очень большой overhead.

Я не пишу под Ardino или Rasberry, чтобы с гордостью рассказывать, какой я Embedded разработчик - просто в моих проектах микросекунды играют роль.

Например если глянуть, как генерируется код для портов в нынешних IDE, то чтобы pin перещелкнуть - это одна команда без OC - и страница кода если требуется поддержка OC.

Ну иногда требуется

А вообще, проект, проекту рознь. Иногда возьмешь микроконтроллер побольше и начинаешь шашкой махать, а потом оказывается, что выбранный контроллер на 50 центов дороже, того, в который ты мог влезть. И ты теряешь 50 000 долларов в год из за этого.

Насчет ОС для такого мелкого микроконтроллера, я там выше написал, можно было бы run to completion сделать, проще, меньше, быстрее.

Но в общем с ОС разрабатывать софт приятнее.

Спасибо. У вас талант объяснять, все листинги по делу, не часто такое встретишь. На пикабушечке такого не хватает, факт :-)

OS – это программная прослойка,

Вот простите меня пожалуйста. Вы же сами посмеиваетесь над своим поспешным подходом. Но любой человек (да и не человек тоже), который собирается писать ОС, должен сначала понимать что это такое.
Есть фундаментальный труд, на котором выросли писатели ВСЕХ современных ОС: "Операционные системы" Э. Таненбаума. После прочтения этой книги в голове будет порядок и работать будет проще. Заодно можно узнать о существовании целого ряда готовых RTOS для MK.

OS – это программная прослойка, позволяющая реализовать псевдо многопоточность

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

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

Я думаю, было бы полезнее, если бы была конкретная претензия ко мне, что я сделал не так. Вместо того, чтобы цепляться за мое определение, лучше укажите на то, где я допустил ошибку в проекте, что реализовал не так. Я буду рад если будет такое замечание.

сначала понимать что это такое

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

Если я прочту этот фундаментальный труд, и изменю слова в определении - что-то изменится?

Если два человека знают как работает что-либо, и они объясняют это своими словами - в этом нет ничего плохого.

Заодно можно узнать о существовании целого ряда готовых RTOS для MK.

Я знаю ряд готовых RTOS для МК. Это не отвернуло меня от создания своей.

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

Тоже делал подобную штуку в свое время. Правда, дошел только до переключения задач, поскольку не смог придумать как продемонстрировать его работу неспециалисту. В частности как одна задача будет запускать другую, как они будут работать с памятью и т.д. Просто архитектура AVR для этого не очень-то предназначена: и всей оперативки мало, и инструкций косвенного доступа не хватает. Так что полноценную ОС на ней не написать.
А вот на ARM было бы интереснее. Там и работа относительно базового адреса имеется, и даже выполнение из оперативки, так что задачи можно вообще на лету подгружать.

полноценную ОС на ней не написать

Для начала нужно определиться что такое полноценная ОС, чтобы понимать до каких требований нужно дотянуться, собственно это и есть ТЗ. Конечно, если брать FreeRTOS как полноценную, то она просто не влезет, т.к. занимает килобайты. Но там много фич, от которых можно отказаться.

и инструкций косвенного доступа не хватает

Ну так регистровые пары XYZ есть, по памяти ходить можем, мне хватает)

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

на ARM было бы интереснее

Как раз таки на AVR интереснее, т.к. там ничего нет. Хотя, у каждого свои интересы...

Сделал бы ОС для ARM - вместо вопросов "а зачем тебе ОС на AVR?" были бы "а зачем тебе такая слабая ОС на ARM"?

Для начала нужно определиться что такое полноценная ОС
Ну, моя цель была навелосипедить ОС, аналогичную десктопным, то есть чтобы и процессы на лету запускать, и подгружать откуда-то, и разграничение доступа обеспечить. И потом похвастаться «компьютером» на контроллере.
Ну так регистровые пары XYZ есть
Вроде команда ldd r, Y+2 не везде поддерживается, а без нее любой доступ к локальным переменным превращается в издевательство над адресным регистром.
А вообще на AVR невозможно сделать полноценную ОС только из-за того, что нет ничего для проверки переполнения стека.
Лучше сказать более общо — нет механизма защиты памяти.
Как раз таки на AVR интереснее, т.к. там ничего нет.
Некоторые аппаратные вещи все-таки необходимы. Ну, скажем, без прерываний не реализовать планировщик. Без выполнения кода из ОЗУ не реализовать по-человечески загрузку с внешнего носителя.
Сделал бы ОС для ARM — вместо вопросов «а зачем тебе ОС на AVR?» были бы «а зачем тебе такая слабая ОС на ARM»?
Пф-ф-ф, тем, кто не понимает зачем вообще нужно велосипедостроение, вряд ли можно это объяснить.

Своя ось может быть чревата серьезными последствиями.
Если вы как разработчик поступательно будете осваивать все более сложные и перспективные платформы, то от своей оси придется отказаться.
Но отказаться будет трудно, жалко же потраченных сил.
Это приведет к фрустрации и конфликтам с заказчиками.

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

В сети масса исходников заточенных под mbed, uCOS-II , Azure RTOS, Zephyr RTOS, MQX ...
Своя ось исключает их из вашего круга интересов. Вернее вы будете их рассматривать только для того чтобы объяснить себе почему они вам не подходят. Это психологическая ловушка.

На самом деле любая из перечисленных может быть запущена на Cortex-M0. Любая из них справиться с тем же что и собственная. У них разница только в глубине и охвате поддержки.

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



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

Я нигде не писал, что я буду использовать ее в своей работе. Это домашний проект для изучения темы. Не более.

И вот вместо изучения всего этого богатства вы пилите свою ось.

И вот вместо того, чтобы писать на пайтоне, люди пишут на Си.

Я пилю свою ось, т.к. это моя профессия, и в то же время хобби.

Да и все известные сейчас ОС начинались с таких шагов. Разве нет?

Согласен с тезисом о том что эффективным путем освоения архитектуры ОС является разработка ОС. Но с другой стороны можно взять готовую ОС например тот же Minix, и модифицируя ее понять как она работает. Кроме того вы смешиваете конкретный микроконтроллер и архитектуру ОС. Вот у нас есть статья про планировщик https://habr.com/ru/company/embox/blog/219431/ да там есть некоторая привязка к нашему проекту, но сделано это только для того чтобы любой смог сразу воспроизвести все примеры описанные в статье. А привязываться к конкретной архитетуре при изучении принципов планирования, это не очень хорошо. Это отдельная тема вот например по поводу особенностей для ARM Cortex-m https://habr.com/ru/company/embox/blog/330236/

Но с другой стороны можно взять готовую ОС например тот же Minix, и модифицируя ее понять как она работает.

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

Кроме того вы смешиваете конкретный микроконтроллер и архитектуру ОС.

Как раз AVR не имеет ничего такого в своей архитектуре, чтобы ОС получилась исключительно для AVR. В них есть только стек и таймер, что есть во всех микроконтроллерах без исключения. А вот если писать сразу на ARM, то там и отдельный таймер для ОС есть, и аппаратные приблуды для стека, и т.д. Что и наложит свой отпечаток на ОС.

Портировать эту ОС на любую архитектуру - без проблем, а вот ОС для ARM обратно - уже будут проблемы.

Единственное влияние архитектуры, которое я здесь зацепил, это сохранение регистра "SREG" в контекст задачи. Содержимое контекста в принципе будет разным для каждой архитектуры. Банально количество регистров общего назначения будет отличаться.

А привязываться к конкретной архитетуре при изучении принципов планирования, это не очень хорошо.

Про планировщик это была скорее шутка, если привязка планировщика к архитектуре это: "не делать алгоритм планирования", то это не похоже на привязку XD

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

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

А вот если писать сразу на ARM

Ни в коем случае не предлагал писать под ARM или другую архитектуру. Посмотрите первую ссылку, там ни слово о регистрах. А у вас naked аттрибут не работает, ассемблер, а давайте первый раз выйдем из прерывания и так далее.

А у вас naked аттрибут не работает, ассемблер, а давайте первый раз выйдем из прерывания и так далее.

Я здесь не уловил мысль...

  1. Что значит "у вас naked не работает"?

  2. "Ассемблер" - а как переключить контекст без ассемблера?

  3. "а давайте первый раз выйдем из прерывания и так далее" - можно подробнее, чтобы я понял, как ответить на вопрос?

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

А в целом хорошая работа, продолжайте!

Не обязательно отвечать на вопросы.

Не обязательно, но желательно, чтобы расставить все точки. Если есть в комментариях замечания, вопросы и т.п. Или я вижу, что меня поняли не так, как я это планировал - я лучше отвечу.

первое переключение контекста отличается от последующих, но ведь чтобы этого избежать достаточно добавить понятие инициализация контекста

Согласен, не подумал вынести это в отдельный термин. Может позже исправлю.

Но в варианте, который я принял в итоге (решение 3) это и не требуется.

У Вас написано что Решение 3, одни плюсы, ну разве что не эстетично. На самом деле, объясните себе как вызвать перепланирование не из прерывания? Ну например поток в sleep ушел или ждет чего то?
Я уж не говорю, о том что функция contex_switch вообще то возвращается в тоже место, но только при возврате в этот же поток.

Я еще раз повторюсь Вы проделали хорошую работу и я не пытаюсь ее критиковать. Я просто обращаю внимание, что когда вы учитесь сразу на собственной ОС, вы сильно сужаете проблематику и не видете очень многих действительно важных моментов. И я предложил только начать с базовой теории в отрыве от конкретной задачи и процессора. Возможно сейчас с полученным опытом прочтение Таненбаума принисет очень хороший результат :)

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

Ну так можно же учиться про себя тихо и не пиариться.
А раз пиариться, то добро пожаловать в мир конкуренции.
Для себя ли или не для себя, но когда почувствуете холодок бесполезности своего труда, то будет некомфортно. Тут конкуренция в плюс, поскольку может вовремя дать сигнал остановиться.

Еще один минус самописаной оси - самобытная терминология.
Эт тож сильный барьер в приобщения к лучшим практикам.
К примеру что это - "текущая задача"? Есть термин "активная задача", но она может быть вовсе не текущей в смысле исполняемой в данный момент.

Да и речь не идет о том что автору выбрать, а о том как автору эффективней учиться.
И всего лишь.

Ну так можно же учиться про себя тихо и не пиариться.

При чем здесь пиар?

В самом начале статьи написано, для чего я ее опубликовал.

Я был бы рад увидеть такую статью, когда сам начал, но не нашел, и написал ее сам, чтобы такие как я могли ее прочитать.

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


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

Рефакторинг чужой ОС даст только ответ на вопрос "как это работает".

А между "знаю как работает" и "могу это сделать" огромная пропасть.

каждый программист должен написать свою ОС =)))
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории