Попробую немного рабочего написать - не всё же про ретро железки :)

Есть такой производитель микроконтроллеров Artery, и есть у него такая штука SPIM - которая, в теории, берёт на себя все нюансы работы с флеш-памятью - настраиваем тип микросхемы и поехали. Но вот на практике…

Столкнулся с багой в программе - включаю SPIM, читаю одну ячейку и получаю не то значение, которое там записано. Перечитываю через некоторое время - уже правильный байт. Хм… Напаяв МГТФ-паука и подрубив логический анализатор вижу, что этот SPIM срезает углы где можно и где нельзя.

После включения он пишет в два регистра статуса значение 0x02 для настройки QSPI и защиты от записи. Запись именно 0x02 в первый регистр не имеет смысла т.к. первые два бита в нём только для чтения. Ну да ладно - срезали угол, но результат тот же, ок. Но дальше полагается ожидать окончания записи (tW 10-15мс для W25Q128FV) - до этого момента микросхема не принимает почти никакие команды. А вот это сделать забыли и шпарят команды сплошным потоком. Упс.

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

cmake -DPKG_CONFIG_USE_CMAKE_PREFIX_PATH=1 -DCMAKE_PREFIX_PATH=/opt/dsview/ ../

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

• What Every C Programmer Should Know About Undefined Behavior 1 2 3
• Undefined behavior ближе, чем вы думаете
• Тест на понимание работы оптимизатора GCC
• Перевод объявлений переменных с языка Си на английский и обратно
• 20 ловушек переноса Си++ - кода на 64-битную платформу
• Как я написал компилятор C за 40 дней
• memset — сторона тьмы
• Объекты нулевого размера
• Про C++ алиасинг, ловкие оптимизации и подлые баги
• Разбор типичных ошибок при разработке на С/С++
• [Несколько очень интересных презентаций](http://www.slideshare.net/olvemaudal?utm_campaign=profiletracking&utm_medium=sssite& utm_source=ssslideview)
• What is C in practice? (Cerberus survey v2): Analysis of Responses
• О пользе понимания работы кэша в современных процессорах
• SEI CERT C Coding Standard
• Understanding Strict Aliasing

Различные нюансы:

• Сигнатуры main
• (void) vs ()
• Про автоподмену builtin-функций

При разработке для встраиваемых систем зачастую приходится писать свои реализации printf и подобных функций. Однако для самописных функций не работает опция “-Wformat”: проверка вызовов на корректность аргументов (сверка количества и типов аргументов со строкой форматирования). Для решения этой проблемы в GCC существует специальный атрибут функции “format”. Пример применения:

int fmt( void (*put)(char,void**), void *putarg, const char *fmt, ... )
    __attribute__ ((format (__printf__, 3, 4)));

Первым аргументом атрибута идёт тип проверки (printf, scanf, strftime, strfmon), второй - номер аргумента с форматом (нумерация с 1), третий - номер аргумента с которого начинается список аргументов (…).

Есть два пути получения лямбд в Си:

1. Использовать дополнительный препроцессор cmacro. Идея очень интересная, но, к сожалению, реализация подводит. У меня этот препроцессор не только спотыкался на простейших конструкциях (например, лямбда, возвращающая указатель), но и умудрялся портить совершенно сторонний код (“return -1” чудесным образом превращается в “return- 1”). Проект по всей видимости заброшен.

2. Использовать расширения компилятора GCC. Это простой и безболезненный путь если нет необходимости сохранять совместимость с другими компиляторами. Для этого варианта достаточно объявить макрос:

#define lambda(l_ret_type, l_arguments, l_body)         \
  ({                                                    \
    l_ret_type l_anonymous_functions_name l_arguments   \
      l_body                                            \
    &l_anonymous_functions_name;                        \
  })

Пример создания и использования лямбды:

    printf("%s world\n", lambda(char*, (void), { return "Hello"; } )() );

Обратите внимание: GCC волен размещать код вложенных функций (и, как следствие, лямбд) в стеке!

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

В таких случаев поможет связка ПО CrashDebug и CrashCatcher. CrashCatcher - библиотека подключающаяся к прошивке МК. Она берёт на себя обработку исключения HardFault и вывод содержимого регистров и памяти на последовательный порт (либо любым другим реализованным программистом способом). Полученный по последовательному порту дамп сохраняется в файл и передаётся утилите CrashDebug, выступающей в роли target для GDB. Дальше уже можно работать любыми привычными средствами - консольным arm-none-eabi-gdb, ddd, либо даже Eclipse (через тип конфигурации “GDB Hardware Debug”).

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

… то не забывайте перед калибровкой отключать DMA (ADC1->CFGR1 &= ~ADC_CFGR1_DMAEN) и сбрасывать значение счётчика DMA1_ChannelN->CNDTR.

static void adc_recalibrate( void )
{
    ADC1->CR |= ADC_CR_ADSTP;                                                       // Stop current conversion
    while( ADC1->CR & ADC_CR_ADSTP );                                               // .. and wait
    ADC1->CFGR1 &= ~ADC_CFGR1_DMAEN;                                                // Disable DMA req
    ADC1->CR |= ADC_CR_ADDIS;                                                       // Disable ADC
    while( ADC1->CR & ADC_CR_ADEN );                                                // .. and wait
    DMA1_Channel1->CCR &= ~DMA_CCR_EN;                                              // Stop DMA transfer
    while( DMA1_Channel1->CCR & DMA_CCR_EN );                                       // .. and wait
    ADC1->CR |= ADC_CR_ADCAL;                                                       // Start ADC calibration
    while( ADC1->CR & ADC_CR_ADCAL );                                               // .. and wait
    ADC1->CR |= ADC_CR_ADEN;                                                        // Enable ADC
    while( !(ADC1->ISR & ADC_ISR_ADRDY) );                                          // .. and wait
    ADC1->CFGR1 |= ADC_CFGR1_DMAEN;                                                 // Enable DMA req
    ADC1->CR |= ADC_CR_ADSTART;                                                     // Start ADC conversion
    DMA1_Channel1->CNDTR = ADC_CHAN_COUNT * ADC_FILTER_SIZE;                        // Set cycle size
    DMA1_Channel1->CCR |= DMA_CCR_EN;                                               // Start DMA transfer
}

Пример кода для STM32F030C8

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

Такие дела.

Для отладки RTOS помимо плагинов IDE можно использовать встроенные средства OpenOCD. На данный момент поддерживаются FreeRTOS, ChibiOS, eCos и другие.

Для использования этой функциональности нужно в параметры запуска openocd добавить следующую строку (для openocd 0.9 и stm32f4):

-c "stm32f4x.cpu configure -rtos auto"

В случае FreeRTOS версий старше 7.5.3 нужно выполнить дополнительные движения:

• Добавить в исходный код определение:

const volatile int __attribute__((used)) uxTopUsedPriority = configMAX_PRIORITIES;

• Добавить в параметры запуска компоновщика:

-Wl,--undefined=uxTopUsedPriority

Инструкций сходной тематики в интернете немало, но как то вышло что информацию мне всё равно пришлось собирать по кусочкам. В этой статье я подытожу весь процесс от А до Я. Всё будет делаться на примере дистрибутива Debian Sid и отладочной платы STM32F4Discovery.