Публикации на тему встроенных систем

[Dale]

Gojko Adzic.

Avoiding the most common pitfall of large-scale agile.

URL: http://us2.campaign-archive2.com/?u=abe09ce689751513abf6f095f&id=96b4eb0c7d&e=f6d3556d9a

Честно говоря, я не припомню другого столь же глубокого анализа проблем, с которыми сталкиваются действительно большие команды при работе над действительно большими проектами, со времен Фредди Брукса-младшего.

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

Итак, все, что могу в данном случае - это дать ссылку; кликайте на нее и читайте самостоятельно.

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

[Dale]

Gojko Adzic.

Potentially shippable is no longer good enough.

URL: https://gojko.net/2016/02/01/potentially-shippable/

Эссе посвящено феномену "гибкой поставки" ПО (agile delivery), который логически вытекает из семейства "гибких технологий" в целом (например, все чаще его используют команды, практикующие SCRUM).

Современный подход к разработке ПО в частности и инженерии в целом все острее ставит проблему курицы и яйца: различные аспекты разработки так переплетаются и так сложно влияют друг на друга, что их сложно становится рассматривать в изоляции друг от друга; полагаю, любой, кому доводилось сталкиваться с подготовкой профессиональных разработчиков, на себе испытал эти трудности. Не является исключением и agile delivery: будучи продуктом эволюции "гибких технологий" и телекоммуникаций, он, в свою очередь кардинально меняет подход к выпуску релизов как в техническом плане, так и с точки зрения технической политики, маркетинга и т.п.

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

Рекомендую членам agile команд, которые успешно переросли стадию "мальчиков для растирания красок" и играют ключевые роли в процессах.

[Dale]

James Shore.

Continuous Integration on a Dollar a Day.

URL: http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html

Мы уже видели пример "малобюджетного" инструмента для модульного тестирования программ на языке C. Появилась возможность дополнить его столь же "малобюджетным" инструментом непрерывной интеграции.

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

Рекомендую всем, кто заинтересован в использовании CI, но пока не выстроил сквозную цепочку самостоятельно.

[Dale]

James Shore.

How Does TDD Affect Design?

URL: http://www.jamesshore.com/Blog/How-Does-TDD-Affect-Design.html

Хотели знать, какое влияние TDD оказывает на дизайн программного продукта, но стеснялись спросить? Тогда вам сюда.

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

Рекомендую начинающим в области TDD; ветераны, скорее всего, уже успели набить описанные шишки на собственных лбах и не найдут здесь ничего нового.

[Dale]

Matt Chernosky.

Try Embedded Test-Driven Development Right Now with Ceedling.

URL: http://www.electronvector.com/blog/try-embedded-test-driven-development-right-now-with-ceedling

Предельно компактное введение в практику использования одного из моих любимых инструментов embedded TDD, который называется Ceedling.

Автору превосходно удалось выдержать баланс между небольшим объемом заметки и функционально завершенным содержанием. Просто выполните шаг за шагом то, что он рекомендует, и вы пройдете полную итерацию TDD от написания спецификации (разумеется, в духе agile она представлена модульными тестами) до полностью работоспособного кода (хоть там и всего несколько строк, но простую поставленную задачу они решают).

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

Тема не новая для постоянных читателей моего раздела и статей, о Ceedling мы уже неоднократно говорили. Для новичков же в agile embedding она может послужить отличным стартом для дальнейшего развития.

[Dale]

Dan Saks.

Enumeration Constants vs. Constant Objects.

URL: http://www.embedded.com/electronics-blogs/programming-pointers/4023879/Enumeration-Constants-vs-Constant-Objects

При всей любви к языку C (и, разумеется, объектно-ориентированной пристройке к нему C++) мы не перестаем с некоторой досадой замечать, что некоторые его аспекты, наспех слепленные в начале 1970-х, так и остаются недоделанными спустя почти полвека эволюции. Некоторые из этих детских болезней выглядят почти неприлично в столь зрелом возрасте, но строгая совместимость с ранними версиями имеет свою цену.

Одним из таких аспектов являются константы. Когда программист вырастает из коротких штанишек обильного засевания кода "магическими" константами, либо, пуще того, переходит на C с более развитого языка, он сталкивается с проблемой: каким образом представлять константы на языке, не имеющем такого средства. Конечно, есть несколько путей имитировать определение константы:

Код: (C)

#define buffer_size 256

Код: (C)

enum { buffer_size = 256 };

Код: (C)

int const buffer_size = 256;

К сожалению, каждый из этих путей имеет свои недостатки, и мы вынуждены выбирать из нескольких зол наименьшее. Автор, президент компании по консультированию и обучению C/C++, делится своими соображениями на эту тему, пытаясь облегчить этот непростой выбор.

Рекомендую тем, кто использует C/C++ и уделяет внимание совершенствованию своего стиля; кое-какеры (те, кто кодирует под знаменами "зато работает"), лишь потратят время зря.

[Dale]

Gojko Adzic.

How to implement UI testing without shooting yourself in the foot.

URL: https://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/

Заметка о том, как следует подходить к тестированию пользовательского интерфейса приложения. Аджич делает (небольшой) акцент на "тонкий" клиент, но в целом идея настолько прозрачна, что вполне подойдет и для "толстых" десктопных приложений. Более того, я бы обобщил его и на тестирование аппаратно реализованного интерфейса встроенных систем.

Рекомендую тестировщикам и специалистам по качеству без привязки к предметной области.

[Dale]

Matt Chernosky.

Using Catch to Write BDD-Style Unit Tests for C.

URL: http://www.electronvector.com/blog/using-catch-to-write-bdd-style-unit-tests-for-c

Описано использование фреймворка тестирования под названием Catch. Приведены примеры написания тестов в виде утверждений Given-When-Then, как принято при подходе BDD.

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

Рекомендую приверженцам применения TDD/BDD/ATDD и "гибких" технологий для проектирования встроенных систем.

[Dale]

Steve Merrick.

Donald’s Trap.

URL: https://carelesstalkblog.wordpress.com/2016/01/05/donalds-trap/

Американский политик Дональд Рамсфельд утверждал, что вы никогда не сможете выбраться из ловушки, если даже не поняли, что в нее попали. Такой ловушкой для инженера может стать, так сказать, "незнание о незнании".

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

Ветеран разработки встроенных систем Стив Меррик рассказывает о своем побеге из ловушки. Рекомендую всем, заметка невелика, но поучительна.

[Dale]

Martin Fowler.

Inversion of Control Containers and the Dependency Injection pattern.

URL: http://www.martinfowler.com/articles/injection.html

Одна из статей Фаулера на тему инверсии управления уже попадала в мой обзор. Однако тема настолько неисчерпаема, что закрыть ее одной публикацией не представляется реальным. Данная статья продолжает тему на более детальном уровне.

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

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

[Dale]

Jez Humble.

Make Large Scale Changes Incrementally with Branch By Abstraction.

URL: http://continuousdelivery.com/2011/05/make-large-scale-changes-incrementally-with-branch-by-abstraction/

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

К сожалению, чем дольше мы работает в изолированной ветке кода, тем больше проблем возникнет в процессе дальнейшей интеграции. Такой подход противоречит концепции непрерывной интеграции, которая стала неотъемлемой частью "гибких" практик. Получается, что в попытке улучшить один из аспектов процесса (изоляцию неустойчивого кода), мы вынуждены ухудшить другой (постоянную интеграцию вновь создаваемого кода с основной линией).

Автор предлагает паттерн Branch By Abstraction, который позволяет разрешить это противоречие путем использования небольших устойчивых инкрементов. За счет добавления уровня абстракции (возможно, временного) этот паттерн позволяет избежать необходимости ветвления линии разработки и тем самым сохраняет непрерывную интегрируемость кода проекта.

Рекомендую системным архитекторам.

[Dale]

Martin Fowler.

FeatureBranch.

URL: http://martinfowler.com/bliki/FeatureBranch.html

Если совсем кратко, статья посвящена особенностям работы с ветками кода в распределенных системах управления версиями. Приведены примеры антипаттерна Promiscuous Integration, сравнение его с традиционным паттерном Continuous Integration, основные проблемы интеграции и способы их избежать.

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

[Dale]

Martin Fowler.

FeatureToggle.

URL: http://martinfowler.com/bliki/FeatureToggle.html

Еще один паттерн разработки, в некотором роде комплементарный паттерну FeatureBranch.

Длительная изоляция разработки в отдельной ветке кода чревата дальнейшими проблемами интеграции. Проблемы неизбежны, поскольку применение Continuous Integration вне основной ветки не имеет смысла, а неприменение и является первопричиной этих самых проблем. Паттерн FeatureToggle позволяет достичь компромисса, обеспечивая некоторое подобие "изоляции" части кода в главной ветке и исключая необходимость в ветвлении.

Разумеется, FeatureToggle не является панацеей и сам имеет некоторые недостатки. Перед применением паттерна следует сопоставить эти недостатки с проблемами интеграции и выбрать, какое из зол меньше.

В отличие от предыдущей заметки рискну порекомендовать данную также опытным разработчикам, поскольку она не столь тривиальна.

[Dale]

Martin Fowler.

StranglerApplication.

URL: http://www.martinfowler.com/bliki/StranglerApplication.html

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

Данный паттерн предлагает поэтапную модификацию кода с постепенным "выдавливанием" legacy из проекта методиками agile. Мне такой эволюционный подход представляется гораздо менее рискованным, чем более распространенный метод "большого взрыва", когда новое решение одномоментно заменяет старое.

Рекомендую архитекторам, получившим печальное наследство в виде большого объема активно используемого legacy кода. Сама заметка весьма лаконична, но в ней есть ссылки, более подробно раскрывающие тему.

[Dale]

Chris Stevenson, Andy Pols.

An Agile Approach to a Legacy System.

URL: http://cdn.pols.co.uk/papers/agile-approach-to-legacy-systems.pdf

Пример успешного применения паттерна StranglerApplication на практике. Хотя название паттерна явно не упоминается в статье (возможно, он обрел это название позже), команда применила тот самый подход, о котором вкратце рассказал Фаулер в предыдущей заметке.

Поскольку проблемы эксплуатации legacy систем возникли не вчера и исчезнут не завтра (мне лично доводилось видеть весьма сложную и дорогую систему, ради эксплуатации которой еще лет 10 назад поддерживали на плаву аппаратный комплекс на базе IBM System/390), статья будет актуальна еще длительное время.

Рекомендую командам, которым выпала судьба делать римейки старых систем.

[Dale]

Doug Seven.

Knightmare: A DevOps Cautionary Tale.

URL: https://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/

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

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

[Dale]

Pete Hodgson.

Feature Toggles.

URL: http://martinfowler.com/articles/feature-toggles.html

Ранее я включал в свой обзор заметку Мартина Фаулера об этом паттерне разработки. Но в той заметке был краткий анонс паттерна, из которого можно было лишь узнать, что такой паттерн существует и может оказаться очень полезным при внедрении "непрерывных" процессов. Эту можно использовать как справочник плюс руководство по использованию паттерна, настолько она полна и детальна.

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

Подробно рассмотрена взаимосвязь с более низкоуровневыми паттернами проектирования (например, GoF).

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

[Dale]

Martin Fowler.

CircuitBreaker.

URL: http://martinfowler.com/bliki/CircuitBreaker.html

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

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

Рекомендую разработчикам надежных распределенных систем.

[Dale]

БЛОГ КОМПАНИИ RCNTEC.

Удалённая работа. Распределённые команды: обзор сервисов для эффективных бизнес-коммуникаций.

URL: https://megamozg.ru/article/25717/

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

Удаленная работа приобретает все больше сторонников. Она удобна работнику: не нужно тратить время на дорогу, можно сместить рабочие часы на более удобное время, можно оборудовать рабочее место по своему вкусу. Она удобна работодателю: экономятся существенные средства на аренду либо приобретение офиса. К сожалению, она пока еще непривычна для большинства, но это, полагаю, вопрос времени.

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

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

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

[Dale]

Matt Chernosky.

Why You Should Use Unit Tests to Write Better Embedded Software.

URL: http://www.allaboutcircuits.com/technical-articles/unit-tests-can-help-you-write-better-embedded-software...-heres-how/

В обзор уже попадала книга Мэта о модульном тестировании встроенных программ на С. Данная заметка посвящена этой же теме, но в существенно более сжатой форме.

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

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

(Источник)

[Dale]

Matt Chernosky.

Slicing Embedded Software for Continuous Delivery.

URL: http://www.electronvector.com/blog/slicing-embedded-software-for-continuous-delivery

Continuous Delivery - весьма важная, если не ключевая, часть культуры agile. Медленно, со скрипом, эта культура понемногу протискивается и в поросший мхом и паутиной мир ПО для встроенных систем. Но в культуре agile все настолько взаимосвязано, что ее практически невозможно внедрять по частям, эволюционно: приходится менять все и сразу, доверяясь рекомендациям отцов-основателей, даже если порой поначалу кажется, что они сильно ошибаются. При этом зачастую приходится ломать устоявшиеся привычки: например, задумываться о тестировании кода до, а не после того, как он полностью написан. Почти всем моим коллегам эта идея поначалу кажется странноватой, если не откровенно бредовой, и лишь потом приходит понимание (если вообще приходит, конечно).

Аналогично обстоит дело с выделением фрагмента кода для реализации. Традиционный подход - архитектурное разделение системы на горизонтальные слои с последующей послойной реализацией - плохо укладывается в идею Continuous Delivery. Гораздо лучше в нее вписывается вертикальное сечение по выполняемым функциям, проходящее через все слои, с инкрементной реализацией каждой функции в соответствии с их ценностью для пользователя.

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

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

(Источник)

[Dale]

Max Lincoln.

Commit Often - and Update Your Dependencies!

URL: http://devopsy.com/blog/2012/03/11/commit-often-and-update-your-dependencies/

Концепция "непрерывного развертывания ПО" (Continuous Delivery, CD) прочно легла в основу гибких технологий разработки качественного, надежного кода. Для того, чтобы эта концепция заработала, нужно не только обеспечить ей инструментальную поддержку, но и существенно изменить некоторые привычки и методы работы.

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

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

[Dale]

Erich Styger.

GNU Static Stack Usage Analysis.

URL: https://mcuoneclipse.com/2015/08/21/gnu-static-stack-usage-analysis/

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

Компиляторы GCC имеют полезную опцию -fstack-usage, которая генерирует файл с расширением .su. Этот файл содержит данные о максимальном объеме стека для каждой функции приложения. Эти данные сами по себе весьма ценны, но, к сожалению, не отражают картины в целом. Ответ на вопрос, сколько всего стека необходимо выделить, остается открытым.

К счастью, некто Daniel Beer написал скрипт на Perl под названием avstack.pl. Он выдает отчет, из которого можно выяснить максимальный объем стека, необходимый приложению, с учетом потребностей подпрограмм обработки прерываний.

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

Инструмент особенно полезен при статическом планировании памяти в компактных RTOS.

(Источник).

[Dale]

Write code that is easy to delete, not easy to extend.

URL: http://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to

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

Step 0: Don’t write code
Step 1: Copy-paste code
Step 2: Don’t copy paste code
Step 3: Write more boilerplate
Step 4: Don’t write boilerplate
Step 5: Write a big lump of code
Step 6: Break your code into pieces
Step 7: Keep writing code

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

Автор упоминает практичный паттерн "Big Ball of Mud", который устанавливает разумный баланс для величины технического долга. Попытаетесь постоянно держать долг на нулевом уровне, как призывают пуристы, - и вы потратите массу усилий впустую. Позволите долгу вырасти сверх разумного предела - и погрязнете под массой сложных процентов, которые все труднее выплачивать. Именно поэтому нужно чувствовать, когда следует, к примеру "Copy-paste code", а когда - "Don’t copy paste code". И для сбора, и для разбрасывания камней найдется подходящий момент, главное - не перепутать.

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

(Источник).

[Dale]

Michael Barr.

Top 10 Causes of Nasty Embedded Software Bugs.

URL: http://www.barrgroup.com/Embedded-Systems/How-To/Top-Ten-Nasty-Firmware-Bugs

На самом деле в данной статье Барр анализирует только 5 из обещанных 10 типовых ошибок встроенного ПО, которые он включил в свой топ-лист; остальные вынесены в отдельную часть. Разумеется, в топ вошли не только наиболее часто встречающиеся ошибки, но и наиболее трудные для отладки, а порой даже и для устойчивого воспроизведения. Большинство из них связано с некорректным использованием планировщика ОС реального времени.

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

(Источник).

[Dale]

Michael Barr.

Top 5 Causes of Nasty Embedded Software Bugs.

URL: http://www.barrgroup.com/Embedded-Systems/How-To/Top-Five-Nasty-Firmware-Bugs

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

(Источник).

[Dale]

Glenn E Reeves.

What really happened on Mars?

URL: http://catless.ncl.ac.uk/Risks/19.54.html#subj6

Действительно ли программное обеспечение аппаратов, летающих в открытый космос и исследующих другие планеты, обладает тем высочайшим уровнем качества, о котором благоговейно судачат дилетанты? Как правило - да. Впрочем, даже при высокой квалификации разработчиков, отточенных до совершенства процессах и поистине космических затратах на разработку ПО (например, стоимость кода Space Shuttle оценивается порядка $1000 за строку) ошибки могут вкрасться в готовый продукт и затаиться там до удобного случая.

Именно так случилось с марсианским аппаратом Mars Pathfinder: завис бортовой компьютер. Случай, конечно, неприятный, но не катастрофа: сторожевой таймер перезапустил программу, накопленные данные сохранились в памяти, только прерванный на середине текущий эксперимент пришлось начать заново. Впрочем, после успешного перезапуска команда поддержки на Земле не расслабилась, а начала поиски причины зависания, благо компьютер вел достаточно детальные логи.

Причина оказалась вполне банальной: инверсия приоритетов задач реального времени. Технические детали довольно подробно описаны по ссылке в начале заметки, но ничего особо интересного там нет. Гораздо интереснее то, что данная ошибка проявлялась при наземных испытаниях, но тогда ее локализовать не смогли и рискнули запустить марсоход как есть. Большая удача, что программа удаленной загрузки патчей оказалась работоспособной, и исправленная версия программы продолжила работу успешно.

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

(Источник)

[Dale]

Michael Barr.

Introduction to Preemptive Multitasking.

URL: http://www.barrgroup.com/Embedded-Systems/How-To/RTOS-Preemption-Multitasking

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

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

(Источник)

[Dale]

Michael Barr.

Introduction to Priority Inversion.

URL: http://www.barrgroup.com/Embedded-Systems/How-To/RTOS-Priority-Inversion

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

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

Рекомендую опытным разработчикам систем реального времени.

(Источник)

[Dale]

Matt Chernosky.

For embedded TDD, don't worry so much about testing on the target.

URL: http://www.electronvector.com/blog/for-embedded-tdd-dont-worry-so-much-about-testing-on-the-target

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

В мире ПО для "больших" компьютеров вс большую популярность приобретают "гибкие" методики разработки. Одна из таких методик - "разработка через тестирование" (Test-Driven Development, TDD). Вкратце суть ее состоит в том, что вначале пишутся тесты, проверяющие функциональность модуля согласно его спецификации, и лишь затем - код, реализующий эту функциональность. Не буду распространяться здесь о многочисленных достоинствах такого подхода, он подробнейшим образом описан во множестве книг и статей. Главное здесь - то, что такой подход довольно плохо реализуется на целевой платформе.

Гораздо проще тестировать встраиваемый код на хост-компьютере (рабочей станции разработчика). На первый взгляд это плохая идея, ведь хост не располагает необходимым набором периферийных устройств, которые задействованы во встроенном проекте. Но это лишь на первый взгляд. При правильном подходе к проектированию (активное использование интерфейсов и абстракций, подходящих паттернов проектирования, вынесение аппаратно-зависимых фрагментов кода в драйверы и HAL) большая часть кода (обычно не менее 90-95%) получается независимой от оборудования и других программных модулей, и ее достаточно просто протестировать с использованием мок-объектов для устранения ненужных зависимостей кода.

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

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

(Источник)