Почему разработчик с нуля перешел на операционные системы

Оглядываясь назад на" эпоху чистого металла "

Впервые я узнал о встроенном ПО примерно в 2008 году, был второкурсником и начал изучать программирование на 51-м чипе. Поскольку я специализировался на информатике, большинство моих программ выполнялось на ПК. Это был совершенно другой опыт - видеть программы, работающие на голой металлической плате, и я до сих пор помню волнение, когда моя первая программа с велосипедными лампами работала успешно. Однако чем больше я писал программ на «голом железе», тем больше проблем встречал. Я резюмирую их следующим образом:

Параллелизм

Для программ на «голом железе» неизбежно существует огромный цикл «while (1)», который содержит почти всю логику транзакций всего проекта. Каждая транзакция вызывает одну или несколько функций задержки, и они выполняются последовательно, когда ЦП выполняет функцию задержки, остальные транзакции должны ждать. Таким образом, большая часть времени ЦП тратится на пустые циклы, что приводит к довольно низкому параллелизму.

Модульность

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

• Как упоминалось выше, большинство функций собраны в огромный цикл while (1), и их сложно разделить на модули.
• В качестве другого примера разработчики должны быть осторожны при использовании функций задержки, когда задействован сторожевой таймер. Если время задержки слишком велико, основная функция не имеет возможности сбросить сторожевой таймер, тогда сторожевой таймер сработает во время выполнения. Итак, для разработки на «голом железе» необходимо учитывать слишком много вещей даже при вызове функции задержки. Чем сложнее проект, тем больше нужно внимательности.

Экосистема

Многие передовые программные компоненты должны зависеть от реализации операционной системы нижнего уровня. Например:

• Я разработал проект с открытым исходным кодом, основанный на «FreeModbus», который я планировал перенести на различные платформы, включая даже платы без покрытия. Но по сравнению с удобством адаптации его к различным операционным системам, некоторые функции слишком сложны для реализации на всех платах с нуля. С другой стороны, многие реализации должны разрабатываться с нуля на разных аппаратных платформах из-за отсутствия общности, что является скучной и трудоемкой задачей. На данный момент моя реализация стека Modbus все еще не может работать на платах без покрытия.
• Многие комплекты разработки программного обеспечения (SDK) WiFi, предоставляемые такими крупными компаниями, как Realteck, TI и MediaTek, можно запускать только в операционной системе. Они не публикуют исходный код микропрограмм для изменения пользователем, поэтому вы не можете использовать их в среде с нуля.

В реальном времени

Для некоторых областей применения необходима возможность работы в реальном времени. В этой ситуации некоторые критические шаги программного обеспечения должны запускаться в определенное время. Для промышленного контроля механические устройства должны выполнять действия в заранее определенном порядке и в определенное время. Если невозможно обеспечить возможность работы в реальном времени, это вызовет сбои в работе, которые могут поставить под угрозу жизнь рабочих. На платформах без операционной системы, когда все функции объединены в один большой цикл «while (1)», невозможно поддерживать возможности реального времени.

Возможность повторного использования

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

Преимущества операционных систем

Это было примерно в 2010 году, когда я впервые использовал операционную систему. Серия микроконтроллеров STM32 стала популярной. Благодаря мощным функциям многие люди запускали на них операционные системы. Тогда я использовал операционную систему RT-Thread, для которой есть много доступных, готовых к использованию компонентов. По сравнению с другими операционными системами я чувствую себя более комфортно и разрабатываю на ней 10 лет.

Исходя из моего понимания, я хотел бы обсудить преимущества операционных систем:

Модульность

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

Параллелизм

Когда поток вызывает функцию задержки, он автоматически передает ЦП другим нужным потокам, что улучшает использование всего ЦП и, в конечном итоге, параллелизма.

В реальном времени

ОСРВ разработана с возможностью работы в реальном времени. Каждому потоку назначается определенный приоритет. Более важные потоки имеют более высокий приоритет, менее важные потоки - более низкие. Таким образом гарантируется работа всего программного обеспечения в реальном времени.

Эффективность разработки

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

Операционная система - продукт мудрости группы компьютерных фанатов. Многие общие программные функции, такие как семафор, уведомление о событии, почтовый ящик, кольцевой буфер, список односторонней цепочки / двусторонний список и т. Д., Инкапсулируются и абстрагируются, чтобы эти функции были готовы к использованию.

Операционные системы, такие как Linux и RT-Thread, реализуют стандартный набор аппаратных интерфейсов для фрагментированного оборудования, известный как структура драйверов устройств. Таким образом, программистам нужно сосредоточиться только на разработке, и им больше не нужно беспокоиться о базовом оборудовании или перестраивать колеса.

Программная экосистема

Богатство экосистемы превращает процесс количественных изменений в качественные.

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

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