Лекция "RTOS Best Practices".

Пятая и последняя часть курса "Embedded System Design Techniques™ - From Bare-metal to Real-Time Operating Systems". Проводит курс Continuous Education Center (CEC). Читает лекцию Джейкоб Бенинго.

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

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

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

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

На пользу пойдет и повторение итоговой таблицы из четвертой лекции, где кратко и по делу анализируется применение основных примитивов синхронизации параллельно выполняемых задач. А вот призыв экономить на таких объектах RTOS, как задачи, семафоры, мьютексы, очереди сообщений и флаги событий более уместен во "Вредных советах" Остера, а не в руководстве для практикующего эмбеддера.

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

Лекция "Debugging Real-Time Embedded Systems".

Четвертая часть курса "Embedded System Design Techniques™ - From Bare-metal to Real-Time Operating Systems". Проводит курс Continuous Education Center (CEC). Читает лекцию Джейкоб Бенинго.

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

Лекция построена на примерах использования замечательного, без преувеличения, инструмента Tracealyzer от шведской фирмы Percepio AB. Он позволяет собирать массу информации о выполняемой программе и представлять ее в различных удобных для восприятия видах - графиках, диаграммах, логах... Правда, цена за этот инструмент не слишком демократична для индивидуальных разработчиков и тем более хоббистов: более 100 тыр за одну лицензию.

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

Как и предыдущие лекции, рекомендую новичкам в RTOS, но с критическим осмыслением факта, что большинство проблем эмбеддинга рукотворны, причем руки эти чаще всего приделаны к самим пострадавшим от их последствий.

URL: https://www.designnews.com/continuing-education-center/april-13-day-4-debugging-real-time-embedded-systems

Лекция "Real-Time Operating System Concepts".

Третья часть курса "Embedded System Design Techniques™ - From Bare-metal to Real-Time Operating Systems". Проводит курс Continuous Education Center (CEC). Читает лекцию Джейкоб Бенинго.

В этой лекции рассмотрены следующие вопросы:

  • основы синхронизации;

  • семафоры;

  • мьютексы;

  • очереди сообщений.

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

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

URL: https://www.designnews.com/continuing-education-center/april-12-day-3-real-time-operating-system-concepts

Рекомендую новичкам в использовании FreeRTOS.

Книга "A Peek at Computer Electronics. Things you Should Know".

Автор: Caleb Tennis.
Название: A Peek at Computer Electronics. Things you Should Know.
Издательство: The Pragmatic Programmers, 2007.
ISBN: 978-0-9776-1668-8



Воистину в этом мире нельзя зарекаться. Не далее как в прошлой рецензии я опрометчиво заявил, что издательство The Pragmatic Programmers никогда не выпускает слабых книг. Теперь я знаю, что это не так. Как минимум одну выпустило.

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

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

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

  • период колебаний маятника определяется его массой;

  • коаксиальный кабель с волновым сопротивлением 75 Ом используется потому, что имеет наименьшие потери на высоких частотах;

  • протоны, нейтроны и электроны состоят из кварков и нейтрино.

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

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

Могу условно порекомендовать новичкам в электронике, но с учетом вышесказанного.

Лекция "Getting Started using Real-Time Operating Systems".

Вторая часть курса "Embedded System Design Techniques™ - From Bare-metal to Real-Time Operating Systems". Проводит курс Continuous Education Center (CEC). Читает лекцию Джейкоб Бенинго.

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

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

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

Рекомендую новичкам в использовании RTOS (особенно FreeRTOS).

URL: https://www.designnews.com/continuing-education-center/april-11-day-2-getting-started-using-real-time-operating-systems

Книга "Exceptional Ruby. Master the Art of Handling Failure in Ruby".

Автор: Avdi Grimm.
Название: Exceptional Ruby. Master the Art of Handling Failure in Ruby.
Издательство: The Pragmatic Programmer, 2011.
ISBN: 978-1-93778-551-2



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

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

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

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

Рекомендую прочитать всем, кто способен понимать код на Ruby. Эта книга научит вас гораздо большему, чем обещает ее обложка.

Лекция "Reviewing Bare-metal Scheduling Techniques".

Первая часть курса "Embedded System Design Techniques™ - From Bare-metal to Real-Time Operating Systems". Проводит курс Continuous Education Center (CEC). Читает лекцию Джейкоб Бенинго.

Первая лекция посвящена организации вычислительного процесса на "голом железе", без поддержки операционной системы. Рассмотрен вариант кооперативной мультизадачности с циклическим планированием. Должен заметить, что реализация предложена чересчур примитивная даже для целей иллюстрации. Есть совсем несложные кооперативные планировщики на основе механизма сопрограмм (например, на базе машины Даффа), которые эту задачу решают гораздо изящнее. В качестве примера могу привести protothreads от Adam Dunkels со товарищи.

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

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

Доступ к записи лекции после регистрации: https://www.designnews.com/continuing-education-center/april-10-day-1-reviewing-bare-metal-scheduling-techniques

Статья "Unit testing with flash (EEPROM)".

Автор: Matt Chernosky.
Название: Unit testing with flash (EEPROM).
URL: http://www.electronvector.com/blog/unit-testing-with-flash-eeprom

Автор блога о хороших практиках разработки качественного firmware (и в частности о TDD) Matt Chernosky рассказывает о приемах модульного тестирования кода, предназначенного для сохранения данных в энергонезависимой памяти (Flash либо EEPROM) и считывания их оттуда.

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

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

Другой пример: устройство записывает логи на флеш-карту SD. Мы хотим проверить, что устройство не зависает в бесконечном цикле ожидания ответа, если карта перестает отвечать на запросы. Мы также хотим убедиться, что повреждение некоторого блока (вполне реальная ситуация, если небольшая карта используется циклически, а лог достаточно подробный) не приводит к "окирпичиванию" девайса. Найти набор реальных карт с описанными дефектами не так просто, да и подсовывать их каждый раз при тестировании хлопотно, а главное, требует ручного вмешательства (прощай, автоматическое тестирование!). Сделать стенд, имитирующий отказы флеш-карты, реально, но его разработка и изготовление потребуют времени и средств. Выход из ситуации тот же: мок-объект для драйвера карты.

Если кто-то считает, что я чересчур сгущаю краски и тщательное тестирование можно заменить непринужденной пошаговой прогулкой по коду в отладчике, могу для начала рекомендовать погуглить историю "новогодней ошибки" плеера Microsoft Zune. Если этого мало, поищите истории Therac-25 и его собрата Sagitar-35, отправивших несколько человек на тот свет и еще множество сделавших инвалидами; баг в firmware ракеты Patriot, благодаря которому не ожидавшим подвоха солдатам прямо в казарме свалился на голову SCUD; несколько эпических багов firmware от Toyota (начиная от сравнительно безобидного, превращавшего Prius в неподвижную тыкву, до летального бага управления дроссельной заслонкой, унесшего не одну жизнь) и множество других (многие из них подробно анализируются в обзорах в моем блоге). Я уверен, что авторы этих программ искренне верили, что умеют создавать качественный софт, но ничего конкретного не сделали для обеспечения этого качества.

Рекомендую профессионалам, практикующим TDD и другие "гибкие" методологии разработки встроенного ПО.

Вебинар "Inexpensive Firmware Process Improvements for Small Teams".

Начало: 28 июня 2017 г. (ср) 01:00 PM US/Eastern (20:00 по Москве).
Длительность: 1 час.
Проводит: Barr Group.
Докладчик: Susan McCord.
Ссылка для регистрации: https://barrgroup.webinato.com/register/11351490294175

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

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

Update. Только что просмотрел/прослушал. Не сказать чтобы совсем уж полная бессмыслица, но и продвинутыми идеями тоже не пахло. От Barr Group, конечно же, ждал гораздо большего.

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

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

Ну с анализом понятно, вещь безусловно полезная. Ассерты как-то больше с Керниганом-Ритчи ассоциируются. Люди хотя и достойные, но за 40 лет другие, не менее достойные люди много чего полезного придумали, например, исключения. Стандарты кодирования - да, реально необходимы, особенно если у кода больше одного автора. Тем более что у Barr Group есть собственная версия стандарта, довольно неплохая. Без метрик оценка кода превращается в какой-то спор о вкусах. Наконец, ревизия при правильном подходе - тоже бесценный инструмент, но слишком велик риск превратить ее в балаган.

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

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