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

Решение довольно простое — открываем файл, читаем записи одну за другой, нужные нам записываем во временный файл. Закрываем файл. Удаляем его. Переименовываем временный в оригинальный. Настолько все просто, что даже код приводить не буду. Неужели же это достаточный повод для статьи?

Пока все работает, повода об этом писать и правда нет. Но потом вдруг однажды «все падает», т.к. переименовывание не происходит из-за ошибки «Access denied». Случается это очень редко, но все же гораздо чаще, чтобы заподозрить космические лучи.

Количество идиотизма в этой истории делает эту заметку достаточно длинной, так что я начну с конца: как сказано в заголовке, 18-летний молодой человек был два дня назад арестован за «взлом» новой системы электронных билетов Будапешта, несмотря на то, что он сразу же сообщил о найденной им уязвимости.

Понадобилось взглянуть в сторону mbed. На первый взгляд выглядело весьма интересно – железонезависимый фреймворк, на С++, с поддержкой кучи микроконтроллеров и демо-плат, онлайн-компилятор с интеграцией в систему контроля версий. Куча примеров, еще более убеждающих в элегантности фреймворка. Прямо «из коробки» доступны практически все интерфейсы микроконтроллера при помощи соответствующих, уже реализованных классов. Вот прямо из коробки бери и программируй на С++, не заглядывая в даташит от микроконтроллера – ну не мечта ли?

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

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

Ну что ж. В кого сразу же летят камни? Про антипрививочников уже выяснили, кто еще в этом списке? Вегетарианцы (а еще лучше – веганы или сыроеды), сторонники родов дома? А, есть еще сторонники домашнего обучения! Но про школы давайте уж в другой раз. И прививки оставим в стороне, их уже обсудили. Вот пара историй из прошлого различной давности.

В последнее время здесь проскакивали посты о переезде в разные страны мира. Решил и я поделиться своим опытом.

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

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

Том закоммитил последнее изменение в файле CSS в SVN и вытер пот со лба. Он обновил локальный репозиторий и переключился назад в Dreamweaver, глубоко вздохнув. Веб-дизайнеры компании настояли, чтобы разработчики использовали Dreamweaver. Он, конечно, не так и плох, подумал Том, хотя есть и инструменты и получше…

Dreamweaver закрылся.

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

Почему-то, когда говорят о тестировании применительно к встраиваемым системам, почти всегда подразумевают под этим платформу, позволяющую «отрезать» эту самую встраиваемую систему, чтобы «независимо от аппаратной платформы» протестировать написанный код.

Безусловно, подход имеет место быть, и с его помощью можно многое протестировать и найти, но…

Вот в качестве примера простенькая система: микроконтроллер и подключенный к нему по I2C инфракрасный датчик температуры. Как будем тестировать?

Когда-то давно я написал статью о принципах проектирования приложения для встраиваемых систем. Тогда я сказал, что есть два основных принципа — бесконечный цикл и ОС реального времени. А вот совсем недавно услышал, что есть еще и третий подход — так называемый Time Triggered Design.

В качестве ознакомления с подходом был использована книга «Patterns for time-triggered embedded systems» автора Michael J. Pont, для заинтересовавшихся — www.safetty.net/publications/pttes
Попытаюсь здесь коротко изложить концепцию.

Когда PVS-Studio сообщили о том, что они наконец-то выпустили standalone версию, не требующую для своей работы Visual Studio, я, конечно же, не мог пройти мимо :) До этого я уже игрался с пробной версией на коде одного из старых проектов. Сейчас же появилась возможность посмотреть на код нашего последнего проекта, собирающегося в среде разработки AVR Studio (которая eclipse-based).

Для работы требуются файлы сразу после препроцессора. Среда AVR Studio это умеет, с одним маленьким исключением — после включения флага «Только препроцессор» на выходе действительно появляются файлы после препроцессора — но по-прежнему с расширением.о вместо ожидаемого .i. Ну что ж, 5-минутный скрипт на Питоне решает это недоразумение, и анализатор отлично запускается!

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

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

Но самой интересной, из-за чего я и пишу этот пост, была одна-единственная строчка «Possible NULL pointer dereferencing»…

Сегодня же пятница, да?

Прочитал совсем недавно довольно известную книгу «Человек, который принял жену за шляпу». Книга действительно стоит быть прочитанной, но я сейчас не об этом.

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

Хочу немного рассказать о двух подходах проектирования ПО в embedded. Два подхода эти – c использованием суперцикла или же с использованием RTOS (Real-Time Operation System, операционная система реального времени).

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

Надеюсь, будет интересно всем тем, кто хочет заглянуть в мир разработки для встраиваемых систем. Для тех, кто в embedded уже собаку съел, скорее всего, не будет ничего нового.

Хочу немного поделиться негативным опытом использования микроконтроллеров Atmel в промышленной разработке.

Atmel как целевую платформу выбрал заказчик, хотя мы его и отговаривали (еще даже не зная, что нам предстоит — интуиция, что ли?). Ну что же, «заказчик всегда прав».

В продукте было два контроллера — 32-битный UC3A3 и 8-битный ATMega164. В качестве дебаггера выбрали AVR One!, в качестве среды разработки — AVR Studio 5.0 (последняя версия на момент старта).

И началось!

Чтобы не откладывать дело в «долгий ящик», продолжу рассказ о своем опыте использования статических анализаторов кода. (Начало здесь и здесь).

Попробовав Klocwork, я попытался заинтересовать в нем руководство, однако цена в 30 тыс. евро послужила главным останавливающим критерием, все остальное было уже не важно.

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

Не успел я поделиться впечатлениями от PVS-Studio, как сразу же последовали обвинения в рекламе. Что ж, расскажу о своем первом опыте использования систем static code analysis.

Так получилось, что первой системой, с которой я столкнулся, стал Klocwork. Это произошло лет 8-9 назад, когда я работал в украинском филиале одной словенской компании. Тогда анализатор запускался в головном офисе, мы же лишь получали экспортированные в эксель результаты. Но даже в таком виде, помнится, меня приятно удивляло то, насколько хорошо находились потенциальные (а порой и реальные) проблемы.

И вот (уже тоже в далеком 2010 году), увидев на Embedded World стенд того самого Klocwork-a, подошел порасспрашивать их насчет триал-лицензии для «попробовать». Спустя какое-то время получил от них е-мейл с вопросом: «Вы интересовались, все еще хотите?».

Интерес к статическим анализаторам кода у меня уже давно, с первого знакомства с Klocwork где-то лет шесть назад. Кроме него, довелось некоторое время поработать с PCLint. И вот теперь немного потестировал PVS-Studio. (А на очереди – Parasoft и Coverity).

Тестирование я провел исключительно из любви к искусству – интересно было попробовать еще один анализатор.

Еще на заре своей карьеры мне довелось поработать с RTOS VxWorks и средой разработки Tornado. Впечатления остались крайне положительные (тем более что сейчас есть с чем сравнивать), но пост не об этом. Составной частью системы тогда была система сбора и визуализации информации о переключении задач в реальном времени. Сразу скажу, что вещь крайне полезная, не зря ведь говорят, что лучше один раз увидеть. Скажем, если у вас в системе есть хотя бы два десятка задач, то с уверенностью в 99% можно сказать, что вы сильно удивитесь, когда увидите визуализацию переключения задач — она будет совсем не такой, какой вы ее себе представляли.

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

Но что же делать, если приходится работать с RTOS и окружением, где такого удобного механизма нет? Конечно же, сделать его самому!

Однажды мне понравилось высказывание «Думаете, что ошибка в компиляторе? Проверьте получше свой код!». Действительно, в моей практике такое случалось – когда, казалось бы, все разумные причины ошибки были отброшены и мысль о том, что вот на этот раз уж точно глюк где-то в системе, вдруг находилась какая-нибудь до смешного банальная ошибка в своем коде, сразу объясняющая все предыдущие странности.

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

Сразу хочу сказать, что речь идет о небольших проектах — 2-5 человек, продолжительностью около года или менее.

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

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

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