Скажу прямо. Раздел про флэш перечитал много раз, не всё понял. Понял только, что на трёх вольтах и частотах ядра от 150 до 180 МГц, Latency должно быть равно пяти. У меня оно равно пяти.
Все аппаратные блоки работают внутри себя (это касается и упомянутого Вами блока для работы с ULPI). Ядро — если Вы научите меня считать точные цифры — я буду рад. Точно знаю, что все настройки выставлены верно, а точную цифру рассчитать пока не смог, на какой частоте всё это обязано работать.
Сейчас я вижу, что когда крутятся 4 команды — частота сигнала на выходе равна 21 МГц, когда три команды — 28 МГц. Это я вижу по приборам. И я никогда не доверял прямому управлению через GPIO в критичных к скорости вещах, предпочитая аппаратные блоки.
Проверил. На максимальном токе выходов заработало на частоте 28 МГц. С плохой скважностью. Начинаю думать, как бы это в текст вставить, чтобы не сильно его покрушить. NOP скважность хорошую обеспечивал. С одной стороны — он, с другой — переход. То на то и выходило. Сейчас буду думать, как и ляп в тексте убрать, и не сильно его менять.
Если что — с проверки настройки PLL я начал. Там всё по максимуму настроено (ну, по такому максимуму, на котором USB работает, разумеется, а так — можно и шустрее, я в курсе)
28 МГц — это именно частота выходного сигнала, то есть, порт шевелится быстрее, разумеется.
Четыре светодиода на STM32F4-Discovery. А на STM32F429-DISCO (которая с экранчиком)… Хм. Сейчас проверил — да, два есть. Но только два. Я почему-то всё время только один находил. И всё равно, на них то, что показано на осциллографе — не покажешь. Тем не менее, про число — уберу.
Насчёт частоты — похоже, не правы ни Вы, ни я в тексте. Возможно, надо будет переделать. Нашёл в даташите именно на 429-й чип:
3.37 General-purpose input/outputs (GPIOs)
Each of the GPIO pins can be configured by software as output (push-pull or open-drain,
with or without pull-up or pull-down), as input (floating, with or without pull-up or pull-down)
or as peripheral alternate function. Most of the GPIO pins are shared with digital or analog
alternate functions. All GPIOs are high-current-capable and have speed selection to better
manage internal noise, power consumption and electromagnetic emission.
The I/O configuration can be locked if needed by following a specific sequence in order to
avoid spurious writing to the I/Os registers.
Fast I/O handling allowing maximum I/O toggling up to 90 MHz.
Надо будет попробовать не NOPы добавлять, а выход переключить на самый быстрый. Проверю в ближайшее время.
По остальным вопросам — данная публикация является «художественным руководством» по работе с ОС. Серьёзные и занудные вещи, что-то доказывающие надо будет рассматривать в другой публикации. Всё в одном — не смешать.
Ну, там же оптимизатор всё неиспользуемое выкидывает, так что зависимостей бояться не стоит.
Эта книга писалась в ноябре прошлого года. Сейчас собрал проект именно этой мигалки, привязанный к ОС тех времён — получилось 18000 байт кода (я сам удивился столь круглому числу). Скорее всего, сегодня получилось бы меньше — за прошедший период был рефакторинг. Но именно этот пример именно с той версией ОС, для которой он был сделан — чуть меньше 18К занял.
И понятно, что мигалку ради мигалки лучше делать без ОС. Но демонстрировать практические опыты проще именно на мигалке.
Прикинул… Допустим, принимается блок по SPI с частотой 1 МГц (я специально взял малую частоту). В STM32 размер FIFO равен двум байтам, так что забрать данные надо уже через 16 мкс.
Допустим, прикладной программист запросил буфер на стороне, а потом — начал выделять под него память оператором new. Может успеть, может — не успеть к моменту переполнения буферного регистра. Зависит от того, как оператор отработает. И при отладке может всегда отработать, а уже у Заказчика — нет.
Вы скажете: «Кто ж так делает?». Вот я и отвечу, что я в тексте и написал, что так делать не стоит. Текст показывает основные отличия программирования под железо относительно общих принципов программирования. Считается, что читатель знаком с информатикой, но не очень глубоко знаком с аппаратурой.
Неопытные программисты под железо и не такое могут. Откуда им опыта набраться? Вот и написано. Опытные же могут скачать с нашего сайта документ, соответствующий всем требованиям ЕСПД и пользоваться им.
В книге заявлено: «Опасайтесь операций new. Если можно не использовать её при работе — не используйте».
Именно опасайтесь, и именно при возможности…
Вы попросили подтверждений, что всё это — не вчерашний день. Я их предоставил.
Если бы речь шла о том, что «мы сделали так, что операцию new нельзя использовать совсем, так что теперь никто никогда не сможет ею воспользоваться» — имело бы смысл опускаться до подтверждения всего, что Вы запросили. Пока же — просто добавлено подтверждение того, что рекомендация — не голословная. Дальше — каждый читатель самостоятельно решает, как ему поступить.
Но если вдруг из-за использования оператора new из стандартной библиотеки что-то случится — никто не скажет, что его не предупреждали. Возможные последствие должны быть задокументированы.
На этом предлагаю свернуть обсуждение данного раздела книги в рамках этой публикации.
По моей просьбе, разработчик, отвечающий за профилирование, провёл исследование. От себя добавлю, что на STM32 с частотой 168 МГц, на двух тысячах блоков среднее время составит 4.5 мкс. Хотя, максимальное — уже 10 мкс. Но есть и другие чипы. В частности, Миландровские. А ромбик военной приёмки — на них. И там пока частоты другие. А применительно к тому, Реальное Время у операционки или нет — лучше я дам прямую цитату от автора метрики:
Случайным образом захватывались и освобождались блоки памяти.
Профилировщик дал следующую картину:
Qty – количество блоков
Size – максимальный размер байтах (случайно, от 1 до Size)
Min – минимальное время new (здесь и далее такты процессора)
Max – максимальное время new
Dev – стандартное отклонение
Avg – среднее значение.
Итак, пока мы захватываем и освобождаем 1 байт – new стабильно занимает 459 тактов.
Для 20 блоков уже есть некоторый разброс.
По мере увеличения количества блоков (размер уменьшается, чтобы влезало в память) разброс растет.
Для 5000 блоков максимальное время увеличилось почти в 5 (!) раз.
Отдельно была искусственно создана довольно сильная фрагментация.
В таких условиях время выполнения new выросло в 8 (!) раз.
При этом никакой уверенности, что достигнут предел, быть не может.
Вывод: при отсутствии аналитического доказательства предельного времени отклика, динамическая память в стандартных библиотеках, идущих с компилятором, не удовлетворяет требованиям реального времени.
В комментариях к предыдущим публикациям, я уже отмечал, что отвечаю за «художественное» руководство по ней. И данная публикация — именно «художественное» описание. Не будем пытаться объять необъятное здесь.
Про new/delete в тексте сказано — за эти слова мне нужно отвечать, сейчас как раз уже будут метрики. А про такие серьёзные вещи — можете хоть сейчас на нашем сайте связаться с теми, кто за это дело отвечает. Ну, или когда мне поручат технический текст сделать — тогда я подготовлюсь и буду готов отвечать на такие вещи. Сейчас — не готов.
Моё личное мнение: Свои проекты для AVR я писал исключительно на ассемблере. Рука не поднималась писать даже на Сях. Сейчас я уже не делаю новых проектов на AVR. Есть Cortex M разных мощностей и цен.
Сегодняшние реальности по AVR: Arduino — вполне себе плюсовая библиотека. И, как ни странно, многие задачи прекрасно пашут. Если посмотрите статьи про библиотеку mcucpp, которая вообще использует подходы метапрограммирования, то увидите, что современные оптимизаторы делают код для AVR не хуже по оптимизации, чем ручная разработка на ассемблере. Я эту mcucpp для ARM использую, так что знаком с нею не только по статьям. Но исходно она явно делалась именно под AVR, на плюсах.
Так что сегодня для AVR многие пишут именно на плюсах. И это даже работает. У меня на столе стоит 3D принтер, в котором исходно была AtMega.
Но, как верно отмечено выше, эпоха 8 битной техники уходит в прошлое. Она уже ничем, кроме привычности для некоторых разработчиков, не выигрывает.
«Выигрываем в скорости — проигрываем в пути», закон физики. В этом примере я специально указал, что он «крутится» в системе с 50К свободной кучи. Там я больше боялся, что рано или поздно произойдёт фатальная фрагментация адресного пространства. Получили гарантированное отсутствие фрагментации, проиграли в производительности, которая для Web-сервера не настолько критична.
Если зайти совсем в разговоры о жизни, то пример относится к любительской разработке WiFi модуля для 3D принтера. ESP8266 постоянно вис. На скорую руку, я заменил этот кусочек. Был бы виноват он — сделал бы класс. Но выяснилось, что виновата работа в контексте прерывания, которая была сделана для устранения подвисаний… Короче, долгая история, описанная мною в блоге про 3D печать. А данный кусок был реабилитирован… Но в силу его показательности (соответствие старое-новое 1:1), пошёл в книжку про нашу ОС.
Надо будет подумать над другим примером, в дополнение к этому. Этот оставить для фрагментации, а другой — для скорости. Осталось придумать что-то красивое.
Классно вы переписали код с С++ на C-и при работе со строками.
А я ведь говорил, что скатитесь к C-и и никуда не денетесь.
По этому поводу, мне всегда вспоминается одно индийское видео. Там про программирование STM32. В куче частей. И вдруг к середине первой части автор начинает вместо рассказа про STM32 рассказывать про один приём программирования. И вся вторая часть посвящена ещё одному приёму программирования, никак не связанному с микроконтроллером. А надо-то про STM32 было! Видать, как и с индусским кодом, ему за хронометраж платят.
Тут мне надо было показать суть замены. Вместо динамики — статика. А про то, что это лучше обернуть в класс — написано ниже. Если бы я начал рассказывать про класс, показывать его тело — всё было бы уже не так. Здесь же можно наблюдать точное соответствие «старое-суть нового». А в класс — ну разумеется, упаковать. И об этом в тексте сказано.
Если бы сподобились измерить время выполнения malloc и free, то увидели бы что они в среднем всегда выполняется за 3 мкс.
Это Вы крючкотворцам расскажите, которые будут доказывать, что ОС при этом станет не реального времени, так как производительность уже не специфицирована. Посему об этом в документации предупредить — обязательно нужно.
Тем не менее, эта глава — всего лишь рекомендация. Операции new и delete как были, так и есть. Кто хочет ими пользоваться — может продолжать. Но пусть в уме держит возможные последствия. Мы предупредили, дальше — каждый сам решает.
Результаты тестов — я у ребят спрошу, проводили ли они. Тем не менее, возможную фрагментацию адресного пространства никто не отменял, независимо от результатов тестов быстродействия. А приведённый пример, который мы обсуждаем — это кусок найденного в сети http сервера для IoT. То есть, он крутится круглосуточно без перезапусков.
Чисто на всякий случай. Вдруг кто-то не прочтёт, что Вы не про нашу ОС. Поэтому я «прикрою» Ваш комментарий своим.
Мы несколько лет доводили ОС до минимально возможного ума. Мы прошли через ядро, которое работает, но делать на нём что-то страшно, так как то тут то там видны всякие мелкие утечки, а на имеющихся объёмах памяти это критично. Мы прошли через чистку этого ядра (полный рефакторинг внутренних механизмов с сохранением интерфейсов). Затем — пробная эксплуатация для внутренних задач. И уже потом — начали это дело как-то продвигать.
Не то, чтобы там уже больше нечего править. Команда всё время чем-то активно занята. Но продвигать мы начали уже не совершенно сырой продукт. Так редко, но бывает. И тут было именно так.
Аааа! Я понял, что Вы имели в виду. Надо читать сразу три предложения. «Философствовать про преимущества ООП и процедурного подхода можно долго, лично я считаю, что ООП — это преимущество, но философия — не мой конёк, поэтому я так считаю, а спорить не буду.». Имелось в виду это в тех трёх предложениях. «Преимущество» относилось к слову «ООП», а не «не мой конёк».
В общем, рассуждения о ненужности философии — это приблизительно то же, что рассуждения о ненужности физики от человека, не желающего знать физику.
Я просто хотел сказать, что меня в философских вопросах «завалить» — проще простого. Например, рассуждая о плюсах и минусах ООП применительно к ОС. В дебри же так просто сорваться.
Относительно этой ветки дискуссии — что такое ОС, а что — просто набор библиотек. Там можно долго спорить. И как людей в таком споре «уделывают» — я знаю. Вот и сразу сдаюсь :-).
Так что тут не нужность и ненужность философии, а просто философия — не мой конёк. Технические вопросы — ко мне. Философские — сразу сдаюсь, просто высказываю свои аргументы и всё. А жонглировать понятиями — не в состоянии.
Прочитал по Вашей ссылке про защиту от этого возвратно-ориентированного программирования. По-моему, тут ядро не должно никак участвовать. Скорее протоколы взаимодействия должны всё учитывать, вот их пусть на сертификации и проверяют.
А если у злодея есть личный доступ к аппаратуре, то он и через JTAG вломится. Наверняка же программист за собой не подчистит, и этот порт не заблокирует. Опять же, блокировка JTAG, взведение битов защиты и прочее — это уже не задача ядра (о котором речь в этой статье), это уже задачи прикладника, так как после отключения будет невозможна отладка. То есть, делаться всё должно на финальной стадии, если это вообще требуется.
А защита стека — она чисто от случайного переполнения. Пришёл новый сотрудник, добавил локальных переменных, стек и переполнился. Вот такие вещи отследить. Они побольше бед, чем злодеи, натворить могут. Вспомним хотя бы «муху цэцэ» у накопителей Seagate. Она возникала от переполнения файла с логом событий. А сколько дисков в кирпичи превращалось. Хорошо, что нашли выход…
Для систем, обрабатывающих важные данные, используются аппаратные системы другого уровня с другими типами ОС. ОСРВ МАКС в текущем исполнении должна обеспечивать работу оборудования (станков, бытовых приборов, иных аппаратов) на микроконтроллерах с не самым мощным набором встроенной аппаратуры. В частности, в большинстве из них, всё исполняется во флэшке. Поэтому там уровень защиты определяется скорее производителем контроллера.
В частности, у контроллеров Cypress FX2LP (51-е ядро, не поддерживается нашей ОС, но уж больно пример показательный) есть Vendor команда USB, которую нельзя перекрыть. Через неё память пишется и читается. Но это уже разработчику аппаратуры виднее, если он захочет поставить контроллер, у которого есть такая то ли особенность, то ли дыра… Зависит от случая.
В общем, сейчас считаем, что собирается ОС и приложение, это дело как-то «шьётся», после чего — старается работать с максимальной производительностью, обеспечивая работу «железа». Защититься от проникновения средствами контроллера, типа как я описал для FX2LP — ОС бессильна. И её задача — обеспечить хорошую, производительную работу системы.
Если появится Заказчик с иными задачами — будем их решать.
Как я уже говорил, философия — не мой конёк. Но тем не менее. Ядро — имеется. Управление потоками (тут они называются задачами) — имеется. Средства синхронизации задач — имеются. Драйверы — имеются.
Железку вполне можно оживить и без этого набора. Причём не будем доходить до фанатизма. Простые железки лично я без ядра оживляю, хотя драйверы — мне так нравятся, что я только через них работаю. Ядро нужно, когда система взаимодействий становится сложной.
Если посмотреть на большинство RTOS для низших контроллеров — у них у всех есть этот минимальный джентельменский набор, после которого у нас уже не набор библиотек, а ОС.
А что у нас круче, чем у других — будет ближе к концу цикла. Ну, и объектный подход. Хотя, в комментариях к первой части на эту тему много философии было, а философия — не мой конёк. Я считаю, что это — преимущество…
А текст я переформулирую в понедельник. Немного пообщаюсь с товарищем, который писал соответствующий код, и изменю формулировки глобально. Слово «любом» уберу, но лучше сразу добавлю подробностей, как можно настраивать защиту под ситуацию. А для этого — лучше сначала запытаю автора кода, чтобы отразить не только, что сам вижу в коде, но и все его задумки. Большое спасибо за то, что обратили внимание!
Все аппаратные блоки работают внутри себя (это касается и упомянутого Вами блока для работы с ULPI). Ядро — если Вы научите меня считать точные цифры — я буду рад. Точно знаю, что все настройки выставлены верно, а точную цифру рассчитать пока не смог, на какой частоте всё это обязано работать.
Сейчас я вижу, что когда крутятся 4 команды — частота сигнала на выходе равна 21 МГц, когда три команды — 28 МГц. Это я вижу по приборам. И я никогда не доверял прямому управлению через GPIO в критичных к скорости вещах, предпочитая аппаратные блоки.
Если что — с проверки настройки PLL я начал. Там всё по максимуму настроено (ну, по такому максимуму, на котором USB работает, разумеется, а так — можно и шустрее, я в курсе)
28 МГц — это именно частота выходного сигнала, то есть, порт шевелится быстрее, разумеется.
Насчёт частоты — похоже, не правы ни Вы, ни я в тексте. Возможно, надо будет переделать. Нашёл в даташите именно на 429-й чип:
Надо будет попробовать не NOPы добавлять, а выход переключить на самый быстрый. Проверю в ближайшее время.
По остальным вопросам — данная публикация является «художественным руководством» по работе с ОС. Серьёзные и занудные вещи, что-то доказывающие надо будет рассматривать в другой публикации. Всё в одном — не смешать.
Эта книга писалась в ноябре прошлого года. Сейчас собрал проект именно этой мигалки, привязанный к ОС тех времён — получилось 18000 байт кода (я сам удивился столь круглому числу). Скорее всего, сегодня получилось бы меньше — за прошедший период был рефакторинг. Но именно этот пример именно с той версией ОС, для которой он был сделан — чуть меньше 18К занял.
И понятно, что мигалку ради мигалки лучше делать без ОС. Но демонстрировать практические опыты проще именно на мигалке.
Допустим, прикладной программист запросил буфер на стороне, а потом — начал выделять под него память оператором new. Может успеть, может — не успеть к моменту переполнения буферного регистра. Зависит от того, как оператор отработает. И при отладке может всегда отработать, а уже у Заказчика — нет.
Вы скажете: «Кто ж так делает?». Вот я и отвечу, что я в тексте и написал, что так делать не стоит. Текст показывает основные отличия программирования под железо относительно общих принципов программирования. Считается, что читатель знаком с информатикой, но не очень глубоко знаком с аппаратурой.
Неопытные программисты под железо и не такое могут. Откуда им опыта набраться? Вот и написано. Опытные же могут скачать с нашего сайта документ, соответствующий всем требованиям ЕСПД и пользоваться им.
В книге заявлено: «Опасайтесь операций new. Если можно не использовать её при работе — не используйте».
Именно опасайтесь, и именно при возможности…
Вы попросили подтверждений, что всё это — не вчерашний день. Я их предоставил.
Если бы речь шла о том, что «мы сделали так, что операцию new нельзя использовать совсем, так что теперь никто никогда не сможет ею воспользоваться» — имело бы смысл опускаться до подтверждения всего, что Вы запросили. Пока же — просто добавлено подтверждение того, что рекомендация — не голословная. Дальше — каждый читатель самостоятельно решает, как ему поступить.
Но если вдруг из-за использования оператора new из стандартной библиотеки что-то случится — никто не скажет, что его не предупреждали. Возможные последствие должны быть задокументированы.
На этом предлагаю свернуть обсуждение данного раздела книги в рамках этой публикации.
Случайным образом захватывались и освобождались блоки памяти.
Профилировщик дал следующую картину:
Qty – количество блоков
Size – максимальный размер байтах (случайно, от 1 до Size)
Min – минимальное время new (здесь и далее такты процессора)
Max – максимальное время new
Dev – стандартное отклонение
Avg – среднее значение.
Итак, пока мы захватываем и освобождаем 1 байт – new стабильно занимает 459 тактов.
Для 20 блоков уже есть некоторый разброс.
По мере увеличения количества блоков (размер уменьшается, чтобы влезало в память) разброс растет.
Для 5000 блоков максимальное время увеличилось почти в 5 (!) раз.
Отдельно была искусственно создана довольно сильная фрагментация.
В таких условиях время выполнения new выросло в 8 (!) раз.
При этом никакой уверенности, что достигнут предел, быть не может.
Вывод: при отсутствии аналитического доказательства предельного времени отклика, динамическая память в стандартных библиотеках, идущих с компилятором, не удовлетворяет требованиям реального времени.
Про new/delete в тексте сказано — за эти слова мне нужно отвечать, сейчас как раз уже будут метрики. А про такие серьёзные вещи — можете хоть сейчас на нашем сайте связаться с теми, кто за это дело отвечает. Ну, или когда мне поручат технический текст сделать — тогда я подготовлюсь и буду готов отвечать на такие вещи. Сейчас — не готов.
Сегодняшние реальности по AVR: Arduino — вполне себе плюсовая библиотека. И, как ни странно, многие задачи прекрасно пашут. Если посмотрите статьи про библиотеку mcucpp, которая вообще использует подходы метапрограммирования, то увидите, что современные оптимизаторы делают код для AVR не хуже по оптимизации, чем ручная разработка на ассемблере. Я эту mcucpp для ARM использую, так что знаком с нею не только по статьям. Но исходно она явно делалась именно под AVR, на плюсах.
Так что сегодня для AVR многие пишут именно на плюсах. И это даже работает. У меня на столе стоит 3D принтер, в котором исходно была AtMega.
Но, как верно отмечено выше, эпоха 8 битной техники уходит в прошлое. Она уже ничем, кроме привычности для некоторых разработчиков, не выигрывает.
Если зайти совсем в разговоры о жизни, то пример относится к любительской разработке WiFi модуля для 3D принтера. ESP8266 постоянно вис. На скорую руку, я заменил этот кусочек. Был бы виноват он — сделал бы класс. Но выяснилось, что виновата работа в контексте прерывания, которая была сделана для устранения подвисаний… Короче, долгая история, описанная мною в блоге про 3D печать. А данный кусок был реабилитирован… Но в силу его показательности (соответствие старое-новое 1:1), пошёл в книжку про нашу ОС.
Надо будет подумать над другим примером, в дополнение к этому. Этот оставить для фрагментации, а другой — для скорости. Осталось придумать что-то красивое.
По этому поводу, мне всегда вспоминается одно индийское видео. Там про программирование STM32. В куче частей. И вдруг к середине первой части автор начинает вместо рассказа про STM32 рассказывать про один приём программирования. И вся вторая часть посвящена ещё одному приёму программирования, никак не связанному с микроконтроллером. А надо-то про STM32 было! Видать, как и с индусским кодом, ему за хронометраж платят.
Тут мне надо было показать суть замены. Вместо динамики — статика. А про то, что это лучше обернуть в класс — написано ниже. Если бы я начал рассказывать про класс, показывать его тело — всё было бы уже не так. Здесь же можно наблюдать точное соответствие «старое-суть нового». А в класс — ну разумеется, упаковать. И об этом в тексте сказано.
Это Вы крючкотворцам расскажите, которые будут доказывать, что ОС при этом станет не реального времени, так как производительность уже не специфицирована. Посему об этом в документации предупредить — обязательно нужно.
Тем не менее, эта глава — всего лишь рекомендация. Операции new и delete как были, так и есть. Кто хочет ими пользоваться — может продолжать. Но пусть в уме держит возможные последствия. Мы предупредили, дальше — каждый сам решает.
Результаты тестов — я у ребят спрошу, проводили ли они. Тем не менее, возможную фрагментацию адресного пространства никто не отменял, независимо от результатов тестов быстродействия. А приведённый пример, который мы обсуждаем — это кусок найденного в сети http сервера для IoT. То есть, он крутится круглосуточно без перезапусков.
Мы несколько лет доводили ОС до минимально возможного ума. Мы прошли через ядро, которое работает, но делать на нём что-то страшно, так как то тут то там видны всякие мелкие утечки, а на имеющихся объёмах памяти это критично. Мы прошли через чистку этого ядра (полный рефакторинг внутренних механизмов с сохранением интерфейсов). Затем — пробная эксплуатация для внутренних задач. И уже потом — начали это дело как-то продвигать.
Не то, чтобы там уже больше нечего править. Команда всё время чем-то активно занята. Но продвигать мы начали уже не совершенно сырой продукт. Так редко, но бывает. И тут было именно так.
Я просто хотел сказать, что меня в философских вопросах «завалить» — проще простого. Например, рассуждая о плюсах и минусах ООП применительно к ОС. В дебри же так просто сорваться.
Относительно этой ветки дискуссии — что такое ОС, а что — просто набор библиотек. Там можно долго спорить. И как людей в таком споре «уделывают» — я знаю. Вот и сразу сдаюсь :-).
Так что тут не нужность и ненужность философии, а просто философия — не мой конёк. Технические вопросы — ко мне. Философские — сразу сдаюсь, просто высказываю свои аргументы и всё. А жонглировать понятиями — не в состоянии.
А если у злодея есть личный доступ к аппаратуре, то он и через JTAG вломится. Наверняка же программист за собой не подчистит, и этот порт не заблокирует. Опять же, блокировка JTAG, взведение битов защиты и прочее — это уже не задача ядра (о котором речь в этой статье), это уже задачи прикладника, так как после отключения будет невозможна отладка. То есть, делаться всё должно на финальной стадии, если это вообще требуется.
А защита стека — она чисто от случайного переполнения. Пришёл новый сотрудник, добавил локальных переменных, стек и переполнился. Вот такие вещи отследить. Они побольше бед, чем злодеи, натворить могут. Вспомним хотя бы «муху цэцэ» у накопителей Seagate. Она возникала от переполнения файла с логом событий. А сколько дисков в кирпичи превращалось. Хорошо, что нашли выход…
В частности, у контроллеров Cypress FX2LP (51-е ядро, не поддерживается нашей ОС, но уж больно пример показательный) есть Vendor команда USB, которую нельзя перекрыть. Через неё память пишется и читается. Но это уже разработчику аппаратуры виднее, если он захочет поставить контроллер, у которого есть такая то ли особенность, то ли дыра… Зависит от случая.
В общем, сейчас считаем, что собирается ОС и приложение, это дело как-то «шьётся», после чего — старается работать с максимальной производительностью, обеспечивая работу «железа». Защититься от проникновения средствами контроллера, типа как я описал для FX2LP — ОС бессильна. И её задача — обеспечить хорошую, производительную работу системы.
Если появится Заказчик с иными задачами — будем их решать.
Железку вполне можно оживить и без этого набора. Причём не будем доходить до фанатизма. Простые железки лично я без ядра оживляю, хотя драйверы — мне так нравятся, что я только через них работаю. Ядро нужно, когда система взаимодействий становится сложной.
Если посмотреть на большинство RTOS для низших контроллеров — у них у всех есть этот минимальный джентельменский набор, после которого у нас уже не набор библиотек, а ОС.
А что у нас круче, чем у других — будет ближе к концу цикла. Ну, и объектный подход. Хотя, в комментариях к первой части на эту тему много философии было, а философия — не мой конёк. Я считаю, что это — преимущество…