Эмбед программинг

Эмбед программинг (8)

Вопреки расхожему мнению, применение планировщиков/диспетчеров позволяет значительно ускорить разработку приложений, затратив при этом совсем немного памяти. А, как известно, время разработчика дороже последней. Средний диспетчер занимает около 1 кБ flash. Это совсем немного, учитывая те возможности, которые он предоставляет.

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

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

Nigel Jones "Median filtering"

Если ваше инженерное образование похоже на мое, тогда вы наверняка много знаете о различных типах линейных фильтров, основная задача которых, пропустить сигнал в одном диапазоне частот и задержать сигналы в остальных диапазонах. Эти фильтры, конечно, незаменимы для многих типов шумов. Однако в реальном мире встраиваемых систем требуется немного времени, чтобы понять, что классические линейные фильтры бесполезны против импульсного шума (burst noise, popcorn noise).

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

Например, в результате аналогово-цифрового преобразования мы получаем такой ряд значений: 385, 389, 912, 388, 387. Значение 912 предположительно аномальное и его нужно отклонить. Если вы попробуете использовать классический линейный фильтр, то заметите, что значение 912 будет оказывать значительное влияние на выходной результат. Лучшим решением в этом случае будет использование медианного фильтра.

 Майкл Барр

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

   Один из таких навыков относится к созданию заголовочных файлов. Что нужно (или не нужно) размещать в заголовочном Си файле .h? Когда нужно создавать заголовочный файл? И почему?
   На перечисленные вопросы у меня есть свой список ответов.

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

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

#define N_ELEMENTS(X) (sizeof(X)/sizeof(*(X)))

   Данный макрос удобно применять для перебора всех элементов массива в циклах.

void foo(void)
{
   uint8_t bar[] = {0, 1, 2, 3, 4};
   uint8_t i;

   /* передать каждый элемент массива bar[] */
   for (i = 0; i < N_ELEMENTS(bar); ++i){
      txc(bar[i]);
   }
}

Майкл Барр

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

Найэл Мерфи

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

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