Решил добавить: От переполнения, так как произошло большое количество вложенных вызовов функций. Либо в функциях было слишком много локальных переменных. Вот от таких вещей защита в первую очередь работает.
Как прикидывать, не случится ли такое, «на глазок» — будет описано в следующей части, она отрезана от этой части, так как получалось слишком много PageDown-ов.
В целом — Вы правы. К счастью, у нас сейчас не могут запускаться сторонние приложения. Приложения собираются вместе с ОС, так что зловредный код, который пытается «просочиться» — отсутствует. Стек растёт в сторону меньших адресов, так что вылет за пределы массива — тоже выскочит за защищаемую область только если нечаянно произошло отрицательное смещение.
Итого: Задача защиты стека от случайного типового случая переполнения — всё равно выполняется. Случайное грубое переполнение (вылет за пределы массива в отрицательную область) и зловредные действия — Вы верно заметили, отслежены не будут. Пожалуй, я подниму этот вопрос на обсуждение с архитекторами и разработчиками в плане, не будет ли вопросов при сертификации. Возможно, это просто придётся отразить в документах, ведь такое возможно и на PC под Windows. По крайней мере, было возможно — точно, указателю всё равно, указывает он на стек, на кучу или вообще на проецируемые на память регистры аппаратуры.
Но чисто формально — всё равно, метод — самый совершенный. Так как все остальные методы — хуже.
В целом — согласен. Там так было — до написания этого документа, никто и не обращал внимания на данный факт. Потом разработчики ядра прочли и сказали: «А точно!». И задумались о том, как переделать. Но рутина засосала. Ведь на самом деле — этот третий режим используется настолько редко… А разработчиков — настолько мало (сколько бы ни было — всегда не хватает)… А более срочных задач — горы. Поэтому пока будет красной рамкой в документе.
Тем не менее, я разработчикам ссылку на этот комментарий сейчас перешлю.
Допустим, все потоки почему-то заснули с целью ожидания тех или иных ресурсов. Например, взводимых по прерыванию. И вот прерывание пришло, один из ресурсов освободился. Работающих потоков — нет, все ждут. Само собой, один из них начнёт выполняться.
Ну, во-первых, IAR и KEIL. Причём размер ядра такой, что даже в бесплатной версии, умеющей собирать только 32К можно попробовать (мы так автотесты проводим)
Eclipse+GCC — в демонстрационной версии, лежащей на сайте не поддерживается, но для внутренних работ — основной инструмент.
Согласование дополнения про лицензии «на верхах» прошло. Давайте я вставлю комментарий руководителя по поводу лицензий в виде прямой речи. Пересказывая, могу что-то утерять или исказить. Поэтому лучше прямую речь.
Текущая лицензия – лежит на сайте вместе с демкой. Бесплатно – только изучение.
Думаю можно озвучить, что мы планируем сделать ядро полностью бесплатным. Для начала – для некоммерческого использования, и это случится, по всей вероятности, уже до конца года. Также всерьез рассматриваем возможность сделать бесплатным и коммерческое применение. Не потому, что нет спроса – спрос уже сейчас гораздо выше ожидаемого. Но для более быстрого распространения. Платными же останутся отдельные модули (например, Mesh), сертифицированные дистрибутивы и т.п. То есть массовый пользователь не будет в чем-то ограничен, оплата потребуется только в случае применения в особо крупных и специализированных промышленных проектах.
Почему не сделали бесплатной сразу – чтобы быть в состоянии поддерживать наших клиентов. В случае взрывного роста популярности наша служба поддержки моментально бы захлебнулась. А так – постепенно наращиваем свои возможности, аккуратно регулируя величину спроса лицензионной политикой.
Начну издалека, но это важно. Давным-давно, в прошлом тысячелетии, сдавал я курсовик преподавательнице, которая осуществляла на нашей кафедре нормоконтроль дипломов. И поэтому в её требованиях к отчёту было, что всё должно соответствовать ЕСПД. А я, работая на заводе, имел личный томик ЕСПДшных ГОСТов и, так получилось, что выучил его почти наизусть.
Во время защиты, она пыталась доказать, что у меня ничего в отчёте не понятно, и что надо добваить то-то и то-то. А я – тут же открывал томик и показывал, что именно это — не допускается. Апофеозом был следующий диалог:
— Давайте выйдем в коридор, покажем десяти первым встречным Ваш отчёт и спросим, понятен ли он им?
— Хорошо, но ещё покажем ворох документов на ДВК и спросим, понятен ли им и этот ворох
— Думаете, это хорошо?
— Зато по ЕСПД
Тогда всё кончилось хорошо, мы сошлись на написании небольшого приложения в свободной форме…
Переходим к нашим дням. Я участвовал в проектировании идеологии ОС, я делал прототип. Затем – с ядром работала группа разработчиков, а я был отвлечён другими делами, и только иногда помогал идеологически. Шло время. Ядро обрело полную функциональность и массу детских болезней. Затем эти болезни оттуда изъяли, встал вопрос об опытной эксплуатации…
Но там такое дело. Для сертификации ОС, документация на неё должна соответствовать ЕСПД. И для большинства серьёзных Заказчиков – тоже. Поэтому… В общем, смотрите начало комментария. Итак. Передо мной лежат ЕСПД-шные документы, передо мной лежит ядро… И я задаю один простой вопрос: «Как это работает?». При том, что я знаю всю идеологию. И при том, что я – лицо заинтересованное в начале работы. При этом я ничего не понимаю. А если это будет сторонний человек, который просто обязан быть настроен скептически?
Собственно, тогда и родилась идея в дополнение к официальной документации, от которой не отвертеться, сделать художественное руководство. Эта задача легла на меня. Я изучил текущий вариант ОС, и попутно – описал её так, чтобы было понятно простому программисту, сделав акцент именно на отличия работы под нашей ОС от стандартных общепринятых подходов программирования под ту же Windows. Это руководство долго пылилось в запасниках, ни разу не попадая в открытый доступ… И вот, наконец, было решено его опубликовать здесь.
Правда, есть в команде и противоположное мнение, что ЕСПДшная документация вполне красива, и некоторые сторонние разработчики (именно программисты, а не бюрократы) её хвалили. И даже по ней начинали программировать под ОС. Но это никак не противоречит моей идеологии «Больше документов, хороших и разных». Кто лучше читает ЕСПД – прочтёт ту документацию, кто там ничего не поймёт (вроде меня) – тому лучше художественный текст. И при чтении художественного текста, всё равно точные прототипы следует смотреть в ЕСПДшном документе (или в заголовочных файлах, кому как нравится).
Теперь про доступность ОС. Скачать демо версию ядра можно хоть сейчас с нашего сайта. Там же, кстати, лежит документация ЕСПДшная. Но лицензия там – чисто для ознакомления. В коммерческих целях – надо покупать. Можно было бы написать, что программисты могут убедить руководство сделать это. Но понятно, что никто этим никогда заниматься не будет, чудес не бывает.
Тем не менее, среди наших Заказчиков есть производители отечественных микроконтроллеров. Так что может оказаться, что на стол простому программисту ляжет плата на базе микроконтроллера и предписание использовать именно нашу ОС. И та самая документация, полностью соответствующая ЕСПД… Надо бы противоикотное средство заранее закупить, так как боюсь, вспоминать нас будут многие непривычные к тому стилю, и делать это будут вдумчиво. А вот те, кто сейчас прочёл этот цикл статей – хмыкнут, скажут: «Где-то что-то я такое видел», отыщут его и найдут сначала сухое теоретическое описание (эти два поста), а также более практический следующий, и уже совсем практический, который будет через один. Ну, и более, более следующие. И поймут, что не так страшен чёрт, как его малюют.
P.S. про лицензию возможны обновления. Сейчас идёт согласование с высшим руководством, чтобы ничего лишнего не наобещать. Если всё будет утверждено — будет ещё один комментарий.
Это просто замечательно, что в наше время имеется возможность попробовать все варианты. Какой вариант окажется более удачным — покажет время. Вот когда направление развития задавал Госплан — там цена ошибки в выборе была высока.
Лет 5 назад, делая систему JTAG сканирования под C#, я нашёл парсер BSDL на чистых Сях. Обернуть его в объектную библиотеку заняло менее рабочего дня. Не проникая внутрь. Просто сначала собрал LIB файл, затем — уже вокруг него сделал плюсовую обёртку на C++ CLR. А это дело уже автоматически «засосалось» в любой .NET компилятор. Так что не так это страшно.
Часть библиотек сейчас разрабатывается сразу под Плюсы. Часть — проще написать заново, чем взять чужие.
В общем, оба варианта рассуждений имеют право на существование, а что окажется жизнеспособней — покажет время. Благо сейчас есть возможность рискнуть.
«ОСРВ МАКС» — Операционная Система Реального Времени для Мультиагентных Когерентных Систем.
Так что именно MAKS. Такая политика руководства применительно к данному конкретному продукту. Там даже комментарии все на русском. Тоже не от незнания английского.
Именно я нажимал кнопку «Создать проект», и именно я создавал несколько первых классов для прототипа. От них уже ничего не осталось, ребята постарались на славу, всё переделано неоднократно, но самые первые классы как были созданы мной, так и есть. Так что точно нами всё сделано. И, как я отмечал в комментариях выше, именно сделано, а не позаимствовано.
Исходно считалось, что мы попробуем, наберёмся опыта, а затем — создадим «боевой» проект. Посему не боялись закладывать в архитектуру не устоявшиеся у других варианты, а то, как оно нам виделось правильней (при том, что опыт работы с RTOS в качестве пользователей у нас был, так что виделось нам более-менее чётко). Но потом проект, выросший из прототипа оказался вполне жизнеспособным до сих пор.
Очень сложно ответить по пунктам и не запутаться. Поэтому скажу только, что MPU у нас используется, мы не смогли с его помощью изолировать процессы. Только — защитить ядро ОС и бороться с нулевыми указателями. Это же говорится и в описаниях на Cortex M, включая книги об этом процессоре. Буду рад, если подскажете, как это сделать, обещаю «продавить» на совещаниях реализацию, чтобы не пропало. Я вообще люблю «продавливать» нестандартные решения.
Очень здорово, что пока что фатальный недостаток не обнаружен (нами, кстати, тоже пока что). Надеюсь, он не вылезет до самого конца публикаций, так как дальше пойдёт описание функциональности. Но законов Мерфи никто не отменял, так что он вполне может объявиться.
Можно-то можно. Можно вообще много чего. Вопрос в том, какими силами это делается.
Почему-то вспоминается стек USB, прилагаемый к STM32. Там есть чётко выраженные слои, всё замечательно. Но связь — как раз на чистых Сях. И вот выяснилось, что система периодически виснет на больших объёмах передачи, если посылать данные в произвольный момент. Масса исследований, и вот ясно, что она не виснет, если начинать посылать в обработчике прерывания SOF. Осмотр кода показывает, что этот обработчик вполне себе может быть пропущен по слоям, но… Но чтобы протянуть его в готовый «класс» CDC, надо поправить кучу файлов, прописать кучу связей. И каждый раз во время выполнения там идёт проверка на ненулевой указатель — мелкая, но ненужная задержка…
В общем, работать-то оно работает. Но будь там не чистые Си, а Плюсы — при той же подготовительной работе, проделанной авторами стека, было бы достаточно перекрыть виртуальную функцию. И всё. Причём прототип достаточно было бы просто скопировать из родительского класса. Ну проще же было бы. И так — везде по мелочам, на чистых Сях всё достижимо, но усилия — больше.
Эти споры можно вести вечно. И обе стороны будут давать массу аргументов.
Текущая позиция, которую отстаиваю лично я — объектно-ориентированный код проще содержать в таком состоянии, что он хорошо понятен. Загадить можно любой код, но процедурный — чуточку проще. А объектный будет самоподдерживаться в читаемом виде.
Дальше, за счёт строгой типизации, ограничений области видимости и прочих подобных вещей, мы ставим себе на службу механизм IntelliSense, который упрощает разработку прикладному программисту. Его же бросают с проекта на проект, везде надо вспоминать, что к чему. И IntelliSense — быстрее введёт в курс дела, чем очередное копание в документации. Опять же… В тексте у меня есть хороший пример, как это помогает, но график выкладывания сюда утверждал не я. Поэтому пока просто предлагаю верить на слово, что есть. Опубликовано будет позже.
А «Этого же можно добиться и другими путями» — ну да, можно. Но там надо добиваться, а тут — оно само получается.
Итого: Заставлять всех переходить на ООП — глупо. Верить, что скоро все перейдут на ООП — наивно. Но по крайней мере, попробовать — достоинства от этого видятся неплохие. Была возможность. Попробовали. Понравилось. Не всё гладко, но не жалею, что попробовали. Продолжаем развивать.
Как потом оказалось (начинали мы давно), попробовали не только мы. И во всех случаях, тоже был успех. А либы — это дело наживное, были бы Заказчики (то есть, оплата работ).
В тексте рассказано про не менее «монолитные» ОС с процедурным подходом. Более мощные в тексте не рассматриваются. Правда, с момента начала разработки появился вполне себе объектный MBED. Ну, и Arduino, хоть это не ОС, а библиотека — но она тоже вполне себе объектная. Что только подтверждает, что для такого типа ОС не только мы на этом деле «повёрнуты», другие идут тем же путём.
Монолитность ОС была заложена, как основополагающий фактор. Исходно было принято решение, что мы попробуем, а не понравится — воспользуемся полученным багажом знаний и сделаем всё с нуля. Оказалось, что ниша для монолитных ОС — на сегодня вполне себе большая. А всё остальное — пока не выходит дальше споров на совещаниях, но иногда обсуждается.
В общем, Вы верно отмечаете, что всё это — следствие монолитности. Но монолитные системы — это же нормально для систем управления. А более широкое применение и не задумывалось пока.
Некоторые реальные Заказчики хотят пользоваться достаточно старомодными компиляторами. Поэтому конкретно Ваш пример сейчас решается через static функции, описанные в библиотеке mcucpp (библиотеку можно найти, мы её тоже нашли исходно). Но тоже неплохо решается. Там в дальнейшем тексте (который уже написан, но ещё не опубликован) показано, как он выглядит на плюсах и в ассемблере. Результаты тоже очень даже ничего. Но увы, увы, увы. Иногда желание применить самые свежие решения разбивается о то, что есть Заказчик, компилятор которого не готов к этим подвигам. А проект оплачивает — он, в том числе. Но вода камень точит, будем точить…
Что до структурированности и реального времени — давайте дождёмся глав с практическими примерами, тогда обсудим конкретные случаи.
Настоящий Mesh у нас в процессе разработки (который соответствует стандартам и прочее, прочее, прочее). А взаимодействие устройств будет описано в последней главе первого тома (текст-то написан давно, так что я знаю, где оно описано). Абсолютно ООПшная штука, но не на сетевом стеке сейчас сделана.
В целом — на самом деле, какая разница, что на чём базируется? Философия — не мой конёк. В конце концов, оно всё в ассемблер превращается. Интереснее, как это выглядит для прикладного программиста. И вот прикладному программисту всё подаётся в классовом виде. А что мы сами делаем с нуля — оно и от роду объектно-ориентированное. Но кое-что приходится и обернуть, так как всё и сразу сделать невозможно. Тем не менее, если можно стремиться к этому — почему бы не устремиться?
Что до IoT, то мы сейчас работаем с Cortex M, дешёвый IoT модуль на Cortex M3 — это RTL8710, он базируется на старом добром LwIP. А в конце концов, всё превратится в ассемблер. Но на пользовательском уровне — наша ОС, она объектная. Аналогия — объектная Arduino вокруг ESP8266 или того же RTL8710. Причём у неё в основе — ну разумеется, LwIP.
Подумал и решил добавить: Файловая система ещё не устаканилась, так что она ещё в будущем времени. Там исходно планировался именно объектно-ониентированный вариант а-ля Ардуино. Но потом победила точка зрения плюсовых потоков, так как они являются частью стандарта языка в наше время, а в той же Ардуине есть два вида файловых классов, которые очень похожи друг на друга, но не совместимы по синтаксису. Само собой, всё это будет обёрткой вокруг «избитой» процедурной файловой системы.
И не могу не отметить такой Ардуиновский проект, как Marlin — «прошивка» для 3D принтера. Когда я полтора года переносил этот код на ARM, выучил его почти наизусть. Тут недавно залез в самую последнюю версию — не узнал. Всё переделали на классы. Причём как и у нас, ради структурированности.
То есть, мир медленно, но к плюсам движется. Но медленно. Как в своё время транзисторы активно не внедрялись, пока не ушли на пенсию ламповики.
Поэтому RTOS-ы на С++ еще долго будут не востребованы.
Можно долго дискутировать на эту тему… Но тут такое дело. Когда я покупаю технику, мощнее нынешней, я не замечаю особой разницы. Но после нескольких месяцев работы, если приходится вернуться к старой — тут-то я и понимаю, что разница ой как была…
Раньше я использовал другие ОС для программирования под STM32. Потом, само собой разумеется, был вынужден делать на нашей. Ну иначе что это за ОС, которой сам не пользуешься? И теперь все иные подходы мне категорически не нравятся. Сложно рассказывать, пока не было статей про те же драйверы. Короче, может, я просто привык, а может — как раз тот случай, когда при переходе на лучшее особо не замечаешь, а при возврате к старому — сразу ощущается.
В общем, особо дискутировать будут или не будут востребованы — смысла нет. Кто привык работать в старом — ничто не заставит его добровольно перейти на новое. Или начальство заставит, тогда потом спросим (не раньше, чем через несколько месяцев), или студентов, не имеющих багажа обучим, а потом — посмотрим…
Arduino же многие пользуются. А там — как раз ООП. И поглядите, что там народ в коде творит. Дух захватывает. Я ради ESP8266 эту библиотеку изучил.
Эээээ. Вообще-то это не совсем законно, изучать для того, чтобы скопировать. Давайте скажем мягче, просто изучили, чтобы получить опыт…
Рассматривали FreeRTOS, CMSIS RTOS, uC OSII, Альтеровскую RTOS. Сейчас точно не вспомню, что ещё рассматривалось более поверхностно.
Из более высоких ОС была рассмотрена QNX, но часть её идей была выбрана, как цель для дальнейших устремлений.
Исходно было решено, что мы делаем ОС для низших контроллеров. Чтобы результат был реализуем, а не где-то на горизонте. Так что никакой изолированной памяти, ничего иного. Были выбраны Cortex M, их операционки и рассматривались. Потом — появились коммерческие задачи, список процессоров был расширен.
Чуть не забыл. Проекту не один год. И даже не два. Так что в те времена список имеющихся ОС был не очень богат.
Ну, а «что скопировали» — мы незаконными делами не занимаемся. Ничего не скопировали. Пропустили через себя и поняли, что нам требуется. Но перечень элементов ядра у всех ОС «для низших контроллеров» был един. В последующих главах это будет.
Как прикидывать, не случится ли такое, «на глазок» — будет описано в следующей части, она отрезана от этой части, так как получалось слишком много PageDown-ов.
Итого: Задача защиты стека от случайного типового случая переполнения — всё равно выполняется. Случайное грубое переполнение (вылет за пределы массива в отрицательную область) и зловредные действия — Вы верно заметили, отслежены не будут. Пожалуй, я подниму этот вопрос на обсуждение с архитекторами и разработчиками в плане, не будет ли вопросов при сертификации. Возможно, это просто придётся отразить в документах, ведь такое возможно и на PC под Windows. По крайней мере, было возможно — точно, указателю всё равно, указывает он на стек, на кучу или вообще на проецируемые на память регистры аппаратуры.
Но чисто формально — всё равно, метод — самый совершенный. Так как все остальные методы — хуже.
Тем не менее, я разработчикам ссылку на этот комментарий сейчас перешлю.
Eclipse+GCC — в демонстрационной версии, лежащей на сайте не поддерживается, но для внутренних работ — основной инструмент.
Во время защиты, она пыталась доказать, что у меня ничего в отчёте не понятно, и что надо добваить то-то и то-то. А я – тут же открывал томик и показывал, что именно это — не допускается. Апофеозом был следующий диалог:
— Давайте выйдем в коридор, покажем десяти первым встречным Ваш отчёт и спросим, понятен ли он им?
— Хорошо, но ещё покажем ворох документов на ДВК и спросим, понятен ли им и этот ворох
— Думаете, это хорошо?
— Зато по ЕСПД
Тогда всё кончилось хорошо, мы сошлись на написании небольшого приложения в свободной форме…
Переходим к нашим дням. Я участвовал в проектировании идеологии ОС, я делал прототип. Затем – с ядром работала группа разработчиков, а я был отвлечён другими делами, и только иногда помогал идеологически. Шло время. Ядро обрело полную функциональность и массу детских болезней. Затем эти болезни оттуда изъяли, встал вопрос об опытной эксплуатации…
Но там такое дело. Для сертификации ОС, документация на неё должна соответствовать ЕСПД. И для большинства серьёзных Заказчиков – тоже. Поэтому… В общем, смотрите начало комментария. Итак. Передо мной лежат ЕСПД-шные документы, передо мной лежит ядро… И я задаю один простой вопрос: «Как это работает?». При том, что я знаю всю идеологию. И при том, что я – лицо заинтересованное в начале работы. При этом я ничего не понимаю. А если это будет сторонний человек, который просто обязан быть настроен скептически?
Собственно, тогда и родилась идея в дополнение к официальной документации, от которой не отвертеться, сделать художественное руководство. Эта задача легла на меня. Я изучил текущий вариант ОС, и попутно – описал её так, чтобы было понятно простому программисту, сделав акцент именно на отличия работы под нашей ОС от стандартных общепринятых подходов программирования под ту же Windows. Это руководство долго пылилось в запасниках, ни разу не попадая в открытый доступ… И вот, наконец, было решено его опубликовать здесь.
Правда, есть в команде и противоположное мнение, что ЕСПДшная документация вполне красива, и некоторые сторонние разработчики (именно программисты, а не бюрократы) её хвалили. И даже по ней начинали программировать под ОС. Но это никак не противоречит моей идеологии «Больше документов, хороших и разных». Кто лучше читает ЕСПД – прочтёт ту документацию, кто там ничего не поймёт (вроде меня) – тому лучше художественный текст. И при чтении художественного текста, всё равно точные прототипы следует смотреть в ЕСПДшном документе (или в заголовочных файлах, кому как нравится).
Теперь про доступность ОС. Скачать демо версию ядра можно хоть сейчас с нашего сайта. Там же, кстати, лежит документация ЕСПДшная. Но лицензия там – чисто для ознакомления. В коммерческих целях – надо покупать. Можно было бы написать, что программисты могут убедить руководство сделать это. Но понятно, что никто этим никогда заниматься не будет, чудес не бывает.
Тем не менее, среди наших Заказчиков есть производители отечественных микроконтроллеров. Так что может оказаться, что на стол простому программисту ляжет плата на базе микроконтроллера и предписание использовать именно нашу ОС. И та самая документация, полностью соответствующая ЕСПД… Надо бы противоикотное средство заранее закупить, так как боюсь, вспоминать нас будут многие непривычные к тому стилю, и делать это будут вдумчиво. А вот те, кто сейчас прочёл этот цикл статей – хмыкнут, скажут: «Где-то что-то я такое видел», отыщут его и найдут сначала сухое теоретическое описание (эти два поста), а также более практический следующий, и уже совсем практический, который будет через один. Ну, и более, более следующие. И поймут, что не так страшен чёрт, как его малюют.
P.S. про лицензию возможны обновления. Сейчас идёт согласование с высшим руководством, чтобы ничего лишнего не наобещать. Если всё будет утверждено — будет ещё один комментарий.
Лет 5 назад, делая систему JTAG сканирования под C#, я нашёл парсер BSDL на чистых Сях. Обернуть его в объектную библиотеку заняло менее рабочего дня. Не проникая внутрь. Просто сначала собрал LIB файл, затем — уже вокруг него сделал плюсовую обёртку на C++ CLR. А это дело уже автоматически «засосалось» в любой .NET компилятор. Так что не так это страшно.
Часть библиотек сейчас разрабатывается сразу под Плюсы. Часть — проще написать заново, чем взять чужие.
В общем, оба варианта рассуждений имеют право на существование, а что окажется жизнеспособней — покажет время. Благо сейчас есть возможность рискнуть.
Так что именно MAKS. Такая политика руководства применительно к данному конкретному продукту. Там даже комментарии все на русском. Тоже не от незнания английского.
Именно я нажимал кнопку «Создать проект», и именно я создавал несколько первых классов для прототипа. От них уже ничего не осталось, ребята постарались на славу, всё переделано неоднократно, но самые первые классы как были созданы мной, так и есть. Так что точно нами всё сделано. И, как я отмечал в комментариях выше, именно сделано, а не позаимствовано.
Исходно считалось, что мы попробуем, наберёмся опыта, а затем — создадим «боевой» проект. Посему не боялись закладывать в архитектуру не устоявшиеся у других варианты, а то, как оно нам виделось правильней (при том, что опыт работы с RTOS в качестве пользователей у нас был, так что виделось нам более-менее чётко). Но потом проект, выросший из прототипа оказался вполне жизнеспособным до сих пор.
Так что за отсутствие этого недостатка я спокоен.
Очень здорово, что пока что фатальный недостаток не обнаружен (нами, кстати, тоже пока что). Надеюсь, он не вылезет до самого конца публикаций, так как дальше пойдёт описание функциональности. Но законов Мерфи никто не отменял, так что он вполне может объявиться.
Почему-то вспоминается стек USB, прилагаемый к STM32. Там есть чётко выраженные слои, всё замечательно. Но связь — как раз на чистых Сях. И вот выяснилось, что система периодически виснет на больших объёмах передачи, если посылать данные в произвольный момент. Масса исследований, и вот ясно, что она не виснет, если начинать посылать в обработчике прерывания SOF. Осмотр кода показывает, что этот обработчик вполне себе может быть пропущен по слоям, но… Но чтобы протянуть его в готовый «класс» CDC, надо поправить кучу файлов, прописать кучу связей. И каждый раз во время выполнения там идёт проверка на ненулевой указатель — мелкая, но ненужная задержка…
В общем, работать-то оно работает. Но будь там не чистые Си, а Плюсы — при той же подготовительной работе, проделанной авторами стека, было бы достаточно перекрыть виртуальную функцию. И всё. Причём прототип достаточно было бы просто скопировать из родительского класса. Ну проще же было бы. И так — везде по мелочам, на чистых Сях всё достижимо, но усилия — больше.
Текущая позиция, которую отстаиваю лично я — объектно-ориентированный код проще содержать в таком состоянии, что он хорошо понятен. Загадить можно любой код, но процедурный — чуточку проще. А объектный будет самоподдерживаться в читаемом виде.
Дальше, за счёт строгой типизации, ограничений области видимости и прочих подобных вещей, мы ставим себе на службу механизм IntelliSense, который упрощает разработку прикладному программисту. Его же бросают с проекта на проект, везде надо вспоминать, что к чему. И IntelliSense — быстрее введёт в курс дела, чем очередное копание в документации. Опять же… В тексте у меня есть хороший пример, как это помогает, но график выкладывания сюда утверждал не я. Поэтому пока просто предлагаю верить на слово, что есть. Опубликовано будет позже.
А «Этого же можно добиться и другими путями» — ну да, можно. Но там надо добиваться, а тут — оно само получается.
Итого: Заставлять всех переходить на ООП — глупо. Верить, что скоро все перейдут на ООП — наивно. Но по крайней мере, попробовать — достоинства от этого видятся неплохие. Была возможность. Попробовали. Понравилось. Не всё гладко, но не жалею, что попробовали. Продолжаем развивать.
Как потом оказалось (начинали мы давно), попробовали не только мы. И во всех случаях, тоже был успех. А либы — это дело наживное, были бы Заказчики (то есть, оплата работ).
Монолитность ОС была заложена, как основополагающий фактор. Исходно было принято решение, что мы попробуем, а не понравится — воспользуемся полученным багажом знаний и сделаем всё с нуля. Оказалось, что ниша для монолитных ОС — на сегодня вполне себе большая. А всё остальное — пока не выходит дальше споров на совещаниях, но иногда обсуждается.
В общем, Вы верно отмечаете, что всё это — следствие монолитности. Но монолитные системы — это же нормально для систем управления. А более широкое применение и не задумывалось пока.
Настоящий Mesh у нас в процессе разработки (который соответствует стандартам и прочее, прочее, прочее). А взаимодействие устройств будет описано в последней главе первого тома (текст-то написан давно, так что я знаю, где оно описано). Абсолютно ООПшная штука, но не на сетевом стеке сейчас сделана.
В целом — на самом деле, какая разница, что на чём базируется? Философия — не мой конёк. В конце концов, оно всё в ассемблер превращается. Интереснее, как это выглядит для прикладного программиста. И вот прикладному программисту всё подаётся в классовом виде. А что мы сами делаем с нуля — оно и от роду объектно-ориентированное. Но кое-что приходится и обернуть, так как всё и сразу сделать невозможно. Тем не менее, если можно стремиться к этому — почему бы не устремиться?
Что до IoT, то мы сейчас работаем с Cortex M, дешёвый IoT модуль на Cortex M3 — это RTL8710, он базируется на старом добром LwIP. А в конце концов, всё превратится в ассемблер. Но на пользовательском уровне — наша ОС, она объектная. Аналогия — объектная Arduino вокруг ESP8266 или того же RTL8710. Причём у неё в основе — ну разумеется, LwIP.
И не могу не отметить такой Ардуиновский проект, как Marlin — «прошивка» для 3D принтера. Когда я полтора года переносил этот код на ARM, выучил его почти наизусть. Тут недавно залез в самую последнюю версию — не узнал. Всё переделали на классы. Причём как и у нас, ради структурированности.
То есть, мир медленно, но к плюсам движется. Но медленно. Как в своё время транзисторы активно не внедрялись, пока не ушли на пенсию ламповики.
Можно долго дискутировать на эту тему… Но тут такое дело. Когда я покупаю технику, мощнее нынешней, я не замечаю особой разницы. Но после нескольких месяцев работы, если приходится вернуться к старой — тут-то я и понимаю, что разница ой как была…
Раньше я использовал другие ОС для программирования под STM32. Потом, само собой разумеется, был вынужден делать на нашей. Ну иначе что это за ОС, которой сам не пользуешься? И теперь все иные подходы мне категорически не нравятся. Сложно рассказывать, пока не было статей про те же драйверы. Короче, может, я просто привык, а может — как раз тот случай, когда при переходе на лучшее особо не замечаешь, а при возврате к старому — сразу ощущается.
В общем, особо дискутировать будут или не будут востребованы — смысла нет. Кто привык работать в старом — ничто не заставит его добровольно перейти на новое. Или начальство заставит, тогда потом спросим (не раньше, чем через несколько месяцев), или студентов, не имеющих багажа обучим, а потом — посмотрим…
Arduino же многие пользуются. А там — как раз ООП. И поглядите, что там народ в коде творит. Дух захватывает. Я ради ESP8266 эту библиотеку изучил.
Рассматривали FreeRTOS, CMSIS RTOS, uC OSII, Альтеровскую RTOS. Сейчас точно не вспомню, что ещё рассматривалось более поверхностно.
Из более высоких ОС была рассмотрена QNX, но часть её идей была выбрана, как цель для дальнейших устремлений.
Исходно было решено, что мы делаем ОС для низших контроллеров. Чтобы результат был реализуем, а не где-то на горизонте. Так что никакой изолированной памяти, ничего иного. Были выбраны Cortex M, их операционки и рассматривались. Потом — появились коммерческие задачи, список процессоров был расширен.
Чуть не забыл. Проекту не один год. И даже не два. Так что в те времена список имеющихся ОС был не очень богат.
Ну, а «что скопировали» — мы незаконными делами не занимаемся. Ничего не скопировали. Пропустили через себя и поняли, что нам требуется. Но перечень элементов ядра у всех ОС «для низших контроллеров» был един. В последующих главах это будет.