Использование gcc для stm32f100

Примерно полгода назад я обзавелся самым мелким контроллером stm32f100c4. Здесь я хотел бы изложить свой опыт применения средств разработки gcc вживую, без графической оболочки. Описывается установка, создание проекта — использование Makefile, прошивка через UART, отладка через gdb на stm32vldiscovery, ну и самое главное — грабли
GNU cредства разработки
Устанавливаем собственно компилятор. Я предпочел YAGARTO, как наиболее часто обновляемый дистрибутив gcc под arm (yagarto.de). Но пойдет и любой другой. Необходимо скачать собственно сам компилятор и набор утилит типа make и т.д. Все это устанавливается в отдельный каталог. Я не ставил его в Program Files, как он хотел по умолчанию, поскольку пробел в имени – это нехорошо, да и набирать в случае надобности долго. Установщик просит включить путь к gcc файлам в PATH. Но он у меня и так длинный, так что я отказался. Результатом этого является необходимость устанавливать переменную среды PATH перед первым вызовом сборки проекта:
set PATH=d:\yagarto\bin;%PATH%

Все действия по сборке можно проводить из программы “Командная строка”, но я предпочел использовать far.
Как оказалось впоследствии в yagarto не совсем правильный make. Он не понимает символа перенаправления вывода в файл (>). Так что пришлось использовать make от mspgcc. Этот файл я приложил в архиве в каталоге add.

Стандартная библиотека периферии.
Для использования всяких символических имен регистров, а также компиляции примеров от ST необходима стандартная библиотека для STM32. Качается она с сайта ST. В последнее время они изменили дизайн. Так что трудно что либо найти. Нужно найти любой более старый микроконтроллер stm32 серии (например stm32f103re) и выбрать вкладку Design Support. Оттуда необходимо скачать архив стандартной библиотеки периферии (Standard peripheral library). На сегодняшний день там лежит версия 3.4.0, в которой добавлена поддержка мелких дешевых arm серии stm32f100 (low density value line в терминологии ST). Оттуда же необходимо скачать и демонстрационную утилиту загрузки через rs232 (Flash loader demonstrator последняя версия 2.2.0). Все это бесполезно искать для контроллеров stm32f100, этих документов не существует для этой серии. Но поскольку библиотека и загрузчик унифицированы, то они одинаковы для всего семейства stm32.
Стандартную библиотеку необходимо разархивировать. Из получившегося каталога STM32F10x_StdPeriph_Lib_V3.4.0 нас интересует собственно сама библиотека – подкаталог Libraries. Также интерес представляют примеры из каталога STM32F10x_StdPeriph_Lib_V3.4.0\Project\STM32F10x_StdPeriph_Examples.

Для проекта я создал новый каталог. В него поместил каталог Libraries из стандартной библиотеки периферии. Туда же скопировал пример ADC_ADC1_DMA из той же библиотеки. Каталог этого примера я обозвал prj. Таким образом, в каталоге проекта 2 подкаталога: Libraries и prj. В перовом – исходные тексты библиотеки стандартной перифирии, а во втором – пример приложения.
В моем случае – пример использования аналого-цифрового преобразования и прямого доступа к памяти.
Забегая вперед, скажу, что не все примеры из состава стандартной библиотеки периферии у меня собрались. Некоторые предназначены для конкретной платы. Догинать эти примеры для сборки я не стал.

Сборочный файл. Введение в синтаксис.
Основой всего процесса сборки в GNU средствах разработки является сборочный файл (Makefile). Это файл, который выполняется утилитой make для сборки проекта. У сборочного файла очень простой синтаксис. Он описывает, что нужно выполнять (какие программы, и с какими ключами), что бы выполнить цель. Цель в makefile – это файл на диске или просто имя для какого либо действия. Цель зависит от других целей (файлов). Для выполнения цели, необходимо выполнить какую либо программу, которой на вход передаются входные файлы (цели, от которых зависит конечная цель). Результатом работы программы является выходной файл (цель) зависящий от входных и промежуточных файлов (целей). Синтаксис такой зависимости в makefile следующий:
КОНЕЧНАЯ_ЦЕЛЬ:ЦЕЛЬ1 ЦЕЛЬ2
	Программа ЦЕЛЬ1 КОНЕЧНАЯ_ЦЕЛЬ

Данную запись можно прочитать следующим образом: что бы получить КОНЕЧНУЮ_ЦЕЛЬ нужно выполнить Программу вот с такими аргументами. В случае если файл ЦЕЛЬ1 или ЦЕЛЬ2 изменились, то нужно снова проделать действия по вызову Программы, что бы обновить результат. В оригинальном файле условные наименования целей должны быть заменены именами файлов, программа – именем программы.
Действий по выполнению цели может быть несколько, по одному в каждой строке. Перед каждым действием в начале строки должен стоять символ табуляции, который является частью синтаксиса, пробелы здесь недопустимы. Цель должна начинаться с первого символа строки.
Таким образом, из исходного файла на языке C утилита make строит путем вызова компилятора объектный файл, а из объектных файлов – собственно программу, из программы – hex файл.
Что бы сделать makefile более гибким, используют переменные. Переменная определяется как НАЗВАНИЕ_ПЕРЕМЕННОЙ = ЗНАЧЕНИЕ. Ни разу не пробовал называть переменные и цели русскими буквами. Лучше использовать латинские. После того, как переменная определена, ее можно несколько раз использовать ниже определения в Makefile.
При использовании переменная должна браться в скобки и перед скобками помещаться символ $. В нашем случае использовать переменную можно так: $( НАЗВАНИЕ_ПЕРЕМЕННОЙ). Значения переменных могут перемежаться с обычным текстом. При этом результатом будет строка с подставленными значениями переменных. Так, например, можно формировать командную строку запуска программы.
Обычно переменные определяются в начале файла. После определения переменных идут цели. Имя первой цели в файле является целью по умолчанию. Именно она начнет выполняться, в случае, если не указать явно цель при запуске make. Обычно она же и является конечной целью. Но в makefile могут присутствовать и другие цели. Типично в каждом makefile присутствует дополнительная цель clean. При выполнении этой цели удаляется результат всей работы по сборке проекта. Что бы выполнить ее, необходимо запустить утилиту make с аргументом – именем цели:
make clean
в нашем случае. Эта цель не имеет зависимостей от файлов и является только именем для действия. При ее запуске не создается никаких файлов, выполняются только действия по удалению. Поскольку зависимостей от файлов нет, то и изменения файлов не отслеживаются и действия выполняются всегда при запуске данной цели.
Существуют так называемые предопределенные цели. Это цели, для которых правила зашиты в сам make. Например, make знает, как из исходного файла на языке C файла получить объектный файл. Он считает, что для этого нужно запустить программу, определенную переменной CC, с аргументами, определяемыми переменной CFALGS. Но это действует только, если исходные файлы находятся в текущем каталоге.
Обычно Makefile строится таким образом, что для получения результата (в нашем случае прошивки) достаточно выполнить утилиту make в каталоге с Makefile.

Файл конфигурации компоновщика.
Что бы собрать проект достаточно скопировать в каталог проекта Makefile и выполнить команду make в каталоге проекта. Но для сборки программы для микроконтроллера необходим особый файл правил для компоновщика. Он указывает, по каким адресам размещать код и переменные программы. Для этого в наш файл проекта добавляется еще один каталог – каталог файлов компоновщика ld.

В нашем случае этот особенный файл называется stm32f100c4.ld. Он предназначен для сборки программ для микроконтроллера stm32f100c4t6b. Этот файл можно адаптировать и для других контроллеров. Необходимо только поменять в строках
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 4K  /* also change _estack below */
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 16K

величины оперативной памяти и флеша.
Также в строке
_estack = 0x20001000;

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

Настройка Makefile под контроллер и программу.
Настройка выполняется путем изменения в текстовом редакторе значений переменных. Так, что бы изменить файл компоновки нужно подставить в Makefile в строке
LINKERCMDFILE = ../ld/stm32f100c4.ld

другое имя файла вместо stm32f100c4.ld.
Аналогично, настраиваются и другие параметры сборки.
  • DEVCLASS = STM32F10X_LD_VL – выбор класса контроллеров.
  • SOURCES – исходные тексты. Список исходных файлов проекта.
  • OBJECTS – объектные файлы. Список объектных файлов проекта. Должен соответствовать списку исходных…
  • DEBUG – флаги отладки
  • OPT – флаги оптимизации.
Оптимизацию рекомендуется либо не использовать (значение 0) либо использовать оптимизацию по размеру (s).

CFLAGS += -DUSE_STDPERIPH_DRIVER – эта строка определяет макрос USE_STDPERIPH_DRIVER при компиляции. Этот макрос необходим, если используются стандартные библиотеки периферии, а не только символические имена регистров и битов. Именно на это рассчитаны примеры, поставляемые ST.
Прим. В данном случае речь идет о конкретном makefile. Каждый может написать свой собственный с другими переменными.

Компиляция примера от ST.
Вот теперь после копирования Makefile и выполнения make в каталоге проекта мы будем иметь конечный файл, который можно залить в контроллер.

На самом деле в результате работы программы создаются целых 3 файла: один из них в elf формате, второй – binary (образ для заливки во флеш), и третий – hex (тот же образ, но в ascii шестнадцатеричном формате). Кроме того, формируются еще дополнительный файл отчета о сборке: файл дизассемблера – в нем дизассемблируется каждая строчка программы. В файле – строки C и соответствующие им ассемблерные коды. В случае высоких уровней оптимизации это соответствие может нарушаться.

Теперь можно компилировать примеры от ST. Для этого необходимо скопировать каталог с примером в каталог сборки, скопировать Makefile и выполнить make. Для примера я скопировал каталог DualModeDMA_SineWave с примером использования цифро-аналогового преобразователя. После выполнения make имеем файл прошивки main.hex.

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

Hello world
Традиционно микроконтроллерным “Hello wold” является моргание светодиодиком. На easyelectronix.ru я нашел такой пример (кстати там же есть описание использования компиляторов Keil и IAR). Просто моргание светодиодиком. Включение, а потом выключение.

Для программы моргалки я создал отдельный каталог blinky. Туда поместил файл main.c с примером.
Исходный код я немного модифицировал. Прежде всего, использовал порт ввода -вывода B бит 12. Он выводится на 25 ногу 48 пинового корпуса. Отсчитывать ее очень удобно – она в углу корпуса. Не то, что 30, 31 или 44.

Итак, вот код с комментариями:
/* Включение заголовочного файла определения портов и их битов */
#include <stm32f10x.h>

/* Функция задержки */
void sleep(uint32_t x)
{
  /* Ключевое слово volatile не позволяет компилятору оптимизировать код до 
  выкидывания пустого цикла */
  volatile uint32_t i = x;

  while ( i-- );
}

/* Функция инициализации периферии */
void SystemInit(void)
{
  /* Включение тактовой частоты порта B. Без этого в регистры данной периферии записывать бесполезно */
   RCC->APB2ENR |= RCC_APB2ENR_IOPBEN;
   /* Перевод порта в режим вывода на 10 МГц */
   GPIOB->CRH   |= GPIO_CRH_MODE12_0;
   /* Перевод порта в push-pull (двухтактный) режим */
   GPIOB->CRH &= ~GPIO_CRH_CNF12;
   return;
}
 
int main(void)
{
#if !defined(__GNUC__)
  /* Инициализация для не gcc (Keil, IAR) */
  SystemInit();
#endif

  while(1)
  {
    sleep(640000);
    /* Установка  записью 1 в соответствующий бит в регистр 
       Сброса-Установки порта */
    GPIOB->BSRR = GPIO_BSRR_BS12;
    sleep(640000);
   /* Сброс  записью 1 в соответствующий бит в регистр 
      Сброса-Установки порта */
    GPIOB->BSRR = GPIO_BSRR_BR12;
  }
}

Здесь требуются дополнительные комментарии к коду.

Во-первых, регистр Управления портом (старший и младший) ввода-вывода (GPIO_CRH, GPIO_CRL) имеют ненулевое начальное значение (0x44444444). Поэтому только перевода порта в режим вывода (настройка битов MODE) недостаточно. После этого порт будет настроен на работу в режиме с открытым стоком. Если между землей и ножкой порта включить резистор, то он гореть не будет. Поэтому выполняется сброс битов CNF – перевод порта в двухтактный (push-pull) режим. На эти грабли я потратил несколько часов. В результате собрал пример компилятором Keil, убедился, что в его симуляторе работает так же как в железе. Так что в каталоге теперь остался и проект Keil с его стартовым файлом.

Во-вторых, для gcc средствами прекомпилятора исключен вызов функции SystemInit. Однако она вызывается пред main и должна быть определена. И именно с таким именем. Вызов ее предусмотрен в стартовом коде, написанном на ассемблере. Этот стартовый код находится в файле Libraries\CMSIS\CM3\DeviceSupport\ST\STM32F10x\startup\gcc_ride7\startup_stm32f10x_ld_vl.s. Вот его кусок, отвечающий за вызов SystemInit и main:

  bl  SystemInit   
  bl  main


В-третьих, счетчик задержки нужно определять как volatile. Иначе компилятор увидит пустой цикл, в котором не выполняется никакой полезной работы, и исключит его для ускорения работы всей программы.
Makefile файл был также скопирован в каталог blinky. Он подвергся следующим модификациям:
Закомментированы неиспользуемые объектные и исходные файлы (stm32f10x_it system_stm32f10x), которые поставляются с каждым примером ST.
Закомментирована строчка с определением макроса USE_STDPERIPH_DRIVER. В программе не используется стандартная библиотека периферии.
Исключена зависимость от стандартной библиотеки периферии. Так что и сама библиотека больше не собирается.
Вызов утилиты make в каталоге blinky строит выходной hex файл main.hex.
Замечания о Keil и симуляции.

Кейл имеет прекрасный инструмент – симулятор. Поэтому перед прошивкой проекта можно опробовать, как он будет работать. Он обладает также отличным отладчиком. Симулятор поддерживает ограниченное количество кристаллов STM32. Я использовал stm32f103re. Поскольку это один из самых продвинутых кристаллов, а большинство периферии совместимо, то можно симулировать кристаллы высокой плотности, а заливать прошивку в Value line с меньшими объемами. Но я отступил от темы.

Заливка прошивки.
Для заливки прошивки используется утилита от ST Flash loader demonstrator (демонстрационная программа загрузчика, um0462), скачанная ранее. Устанавливать ее лучше в какой ни будь каталог с именами покороче и без пробелов для надежности. После установки в каталоге находятся две программы: графическая (STMicroelectronics flash loader.exe) и консольная (STMFlashLoader.exe), каталог исходников (Src), документации (Doc), конфигурации(Conf) и каталог настроечных файлов.
Если вы думаете, что ST дала исходники программы прошивки, то это глубокое заблуждение. Те исходники, что идут в демонстраторе только отрисовывают экран да читают-записывают файлы. Вся работа с контроллером зашита в dll-лях, для которых нет исходников.

Правда есть документ по описанию протокола загрузчика AN2606 (STM32F101xx, STM32F102xx and STM32F103xx system memory boot mode).

Для программирования контроллер через преобразователь уровней типа max3232, st3232 подключается к com порту компьютера. Причем выход USART подключается к входу преобразователя и наоборот. В данном корпусе выход USART – это нога 30, вход – нога 31 (согласно Table 4 datasheet на stm32f100c4). Кроме этого, нужно активизировать загрузчик путем подтяжки Boot1 (нога 20) к земле, а Boot0 (нога 44) — к питанию.

После этого, согласно описанию в документации на загрузчик, нужно запустить графическую утилиту, выбрать настройки порта (обязательно с проверкой четности – even), включить (перегрузить) контроллер и нажать кнопку Next. Контроллер должен определиться, и появится другая картинка. Но другой картинки я так и не увидел. Думал, что уж спалил контроллер.

Запустил терминал termite (http://www.compuphase.com — как он сам о себе пишет, где я его скачал, уже не помню), выставил скорость 2400 и начал вводить всякие буковки и циферки. И о чудо, иногда он начал отвечать. Тогда полез вот в этот самый документ AN2606 и нашел, что имеется ограниченный набор команд. Первой должен идти один байт 0x7F, на который контроллер должен ответить 0x79. А при передаче ему двух байт 0x02+0xFD, он должен выдать версию чипа. Оказалось, что просто нет настроечного файла для данного микроконтроллера.

Взял за основу файл для 16 килобайтного stm32f103 STM32_Low-density_16K.Stmap из каталога Map. Изменил размер RAM и идентификатор устройства вот так:
[Product]
Name=STM32_Low-density-value_16K
PID=0420
FlashSize=0010
RAMSize=0004
PacketSize=FF
ACKVAL=79
MAPNAME=Pages
PagesPerSector = 4
family = 1;
Измененный файл сохранил под именем STM32_Low-density-value_16K.Stmap в том же каталоге. После этого запустил консольный загрузчик вот такой командой:
STMFlashLoader.exe -c --br 9600 -i STM32_Low-density-value_16K -d --fn D:\stm_samples\blinky\main.hex –v

И файл загрузился. После отключения подтяжки на 44 ноге и перегрузки программа заработала, светодиод заморгал. Если необходимо повторно загрузить прошивку, то сначала нужно стереть флеш командой:
STMFlashLoader.exe -c --br 9600 -i STM32_Low-density-value_16K -e –all


Грабли
Все, о чем я рассказал, работало, пока я использовал простейшие примеры. На реальном проекте вдруг код начал вываливаться в прерывание по умолчанию. После просмотра листинга и прохода отладчиком обнаружил, что неверная операция выглядит примерно так:
struct SimpleStruct A;
struct SimpleStruct B;
A = B;


Структуры большие – 140 байт. Вот на присвоении все и происходит. Заменил присвоение на memcpy – ничего не изменилось. Посмотрел листинг. Оказалось компилятор подставляет инструкцию BLX #memcpy вызова функции. Вот в ней то вся проблема. Посмотрел интернет. Не у одного меня такие проблемы. Несколько сообщений размещены как баги GCC при работе с ARM Cortex-M3 (M0). И в одном сообщении – информация о причине. Оказывается, с gcc идут библиотеки внутренних функций под разные процессоры. Инструкции BLX в наборе Cortex нет. Это инструкция 32 битных команд ARM (7?). Используется она потому, что по умолчанию подхватываются чужие библиотеки. Что бы использовались нужные – нужно и для компоновки использовать gcc (что я делал) и подставлять опции -mthumb -mcpu=cortex-m3.

Использование отладчика gcc.
С того времени как я написал этот текст прошло несколько месяцев. Самодельную платку я замучил. Вместо нее я обзавелся stm32vldiscovery. Написал достаточно объемную программу, пока не столкнулся с вышеописанными граблями. Причем на keil все работает. Gcc отказывается. Пришлось запускать отладчик gdb.
Для запуска необходим gdb server. Пока с ST Link (то что стоит на discovery) работает только один пакет – Autollic TrueSTUDIO. Он раздается бесплатно – нужно только зарегистрироваться. Установить без регистрации не получается – требует ключ. Ключ привязывается к железу. После установки в меню пуск появляется ST-Link GDB Server. По умолчанию он работает через jtag. Настройка на SWD осуществляется в фале config.txt. Необходимо добавить строку: -d. Эта опция заставляет его работать через SWD.

После этого код загружаю STM32 ST-Link utility от ST. Он загружает либо бинарный, либо hex файл. Gdb (точнее arm-none-eabi-gdb – из yagarto) нужно указывать в качестве отлаживаемого файла – elf файл (main.out в примерах). После запуска необходимо выполнить команды:
>tar extend localhost:61234
>b main
>r

Далее работа как с обычным gdb.

Грабли 2
После исправления Makefile код так и не начал выполняться. Но на этот раз попадание в обработчик по умолчанию происходило бессистемно при использовании отладчика. Зато вполне определенно в реальном запуске. На графическом дисплее отображалось всегда полторы первые буквы текста. Проблема оказалась в названии обработчика прерывания DMA, который запускался ADC, который запускался таймером. Оказалось, что в keil этот обработчик должен называться DMAChannel1_IRQHandler, а в GCC DMA1_Channel1_IRQHandler. Решается это применением условной компиляции примерно так:
#if defined(__GNUC__)
void DMA1_Channel1_IRQHandler()
#else
void DMAChannel1_IRQHandler(void) /* Read ADC values */
#endif

Так же отличается названиями и обработчик ADC. Возможно, что-то есть еще. Расскажу принцип их формирования. Названия обработчиков задаются в startup файле, написанном на ассемблере. Keil и gcc имеют различающийся синтаксис ассемблера. Наверняка их писали разные люди. Поэтому такое различие в названиях. Поэтому, если вы активировали обработчик в NVIC, флаги прерывания в периферии устанавливаются, прерывание вызывается, но не то что нужно, а прерывание по умолчанию, нужно смотреть startup файлы на предмет названий обработчиков. Еще можно посмотреть отчеты о компоновке – map файлы и дизассемблированный код.

В заключение ссылка на весь демо проект:Пример проекта rar архив 270 килобайт
И на проект примеров от ST, собираемых gcc (проверял только под linux сборку, в контроллер не заливал): Примеры от ST для gcc архив tar gzip больше полмегабайта
  • +4
  • 01 мая 2011, 12:51
  • OlegG

Комментарии (19)

RSS свернуть / развернуть
Да, средства GNU в очередной раз подтверждают свою репутацию инструментов, написанных студентами за еду во время сессии. :-D

Сама же статья хорошая и нужная. Давно хотел узнать про это, спасибо автору.
0
не в обиду, но скорее всего мало программных продуктов сами покупал? :) согласно законам программирования: любая программа содержит хотя бы одну ошибку, а если программа работает без ошибок, то это – «Hello, World!» :) «Грабли» в статье автора вызваны его малым опытом работы с данным продуктом.

Автору спасибо за статью, я вот то же балуюсь с гцц заходи если будет интересно.
0
Да не, я даже не про ошибки, а скорее про юзабилити. :-) В IAR, например, есть две главные кнопки, стоящие на виду: «собрать» и «зашить», как и что компилировать он разбирается сам. Тут же обязательный геморрой с makefile и компанией.
0
достаточно один раз почитать про «это» дело и в дальнейшем все будет очень просто. Конечно каждому свое. Мне нравиться работать в эклипс и использовать майк-файл, при чем не только с гцц, майк универсальная штука.
0
Компилятор и IDE не надо путать. Компилятор IAR ничуть не юзабельней, чем gcc. Те же километровые командные строки.
0
Makefile в принципе удобен тем, что его достаточно один раз написать под себя и потом он будет кочевать из проекта в проект почти без изменений.
0
Кстати, по используемости с GCC пожалуй только компиляторы от M$ потягаться могут. Неплохо для продукта, «написанного студентами за еду». Собственно, весь GNU/Linux им собран.
0
ну для i386, учитывая процентное соотношнение количества компов с ОС от M$ и соответственно софта — это вряд ли.
хотя под виндами есть MinGW — очень даже неплохо выглядит.
а вот с микроконтроллерами же качество генерируемого кода у IARa и Keila всё-таки лучше.
GCC использовать конечно можно, но вот бороться еще и с граблями вызванными компилятором (типа как с копированием структур, описаном в статье) — то еще удовольствие.
0
Да, я про ПК. Под виндами — дохрена чего собрано GCC (хотя кроссплатформа часто собирается GCC под линукс и MSVC под винду). Но в целом, по моим впечатлениям — после MSVC этот наиболее используемый компилятор С/С++ под виндой. Да и в плане оптимизации GCC вполне на уровне таких столпов, как ICC и MSVC.
GCC использовать конечно можно, но вот бороться еще и с граблями вызванными компилятором (типа как с копированием структур, описаном в статье) — то еще удовольствие.
Это не грабли, если скомпилить в IAR'е под ARM7 и попытаться запустить на Cortex-M3 — та же грабля будет. Вот микропаскаль — это да, там грабель с глюками компилятора на каждом шагу припасено. Другое дело, что в IAR/Keil среда заточена под МК и при позволяет просто выбрать целевой МК, под который автоматом настроятся линкер, компилер и библиотека. Использование универсальных инструментов командной строки требует большего курения доков.
0
Оптимизацию рекомендуется либо не использовать (значение 0) либо использовать оптимизацию по размеру (s).
Чем оптимизация не угодила?
описание использования компиляторов Keil и IAR
Сред, на самом деле. Компилятор того же IAR называется iccarm и используется примерно так же, как gcc (в том числе и через make). Только синтаксис командной строки другой.
Я не ставил его в Program Files, как он хотел по умолчанию, поскольку пробел в имени – это нехорошо
gcc обычно лояльно относится к пробелам, и это радует. А DFU demo — и подавно.
Инструкции BLX в наборе Cortex нет. Это инструкция 32 битных команд ARM (7?)
Это переход с переключением системы команд (не помню, только ARM->Thumb или в обе стороны). Для кортексов неактуально — они используют только систему одну команд — Thumb2. Вполне предсказуемый результат компиляции под неправильный таргет. Странно что раньше не вылезло.
+1
  • avatar
  • Vga
  • 01 мая 2011, 17:35
Чем оптимизация не угодила?
Под отладчиком ходить не удобно. Локальные переменные оптимизируются и не просматриваются.
0
А без оптимизации отлаживать бесполезно. Т.к. это уже совсем другая программа.
0
Слишком категорично. Иногда удобно так, иногда этак. В данном случае я бы перефразировал предыдущее сообщение следующим образом. Бывают случаи, что ситуация проявляется только при включенной оптимизации.
0
2 OlegG получается, что ST Flash loader demonstrator не поддерживает загрузку stm32f100c4 ? Слепил макетку, пытался подрубить — ноль эмоций… пишет устройство не познано…
0
Получается, что не поддерживает или не поддерживал на начало года. У меня было то же самое. Я написал, как это поборол.
Попытайтесь повторить действия с терминалом, созданием нового конфигурационного файла и запуском консольной версии.
0
Cпасибо за инфу, так и сделал — написал маленькую прогу для приема/передачи через Сом-порт. Па скорости 2400 отправил 0x7F и получил ответ 0x79. Т.е. теперь знаю, что ляпов на макетке нет. На неделе чего-нибудь попробую залить с помощью STMFlashLoader.exe
0
Сегодня залил прошивку — все заработало. Правда на скорости 9600 STMFlashLoader «не узнавал» stm32f100c4, но после снижения скорости до 2400 все прошло успешно.
0
ST Flash loader demonstrator версии 2.2.0 поддерживает загрузку stm32f100c4, но это прошло только на скорости 2400. На более высоких скоростях облом — устройство не опознано.
0
Хороший код в статье, максимально упрощен, самый минимум, рекомендую начинающим, всё работает как надо, хотя я использовал Keil, с GCC не захотел шпилиться. Другие примеры компилятся с ошибками все почему-то, и от кейла проекты тоже не компилятся и геморроя много с настройкой проекта, как они примеры сочиняли вообще?
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.