Keil uvision5

Содержание

Введение

Не, он, конечно, компилируется, но это же С++, язык, где «program is ill-formed, no diagnostic required» — это норма.

Соответственно, на протяжении нескольких лет я донимал руководство просьбами купить нам лицензию PVS-Studio и, наконец, когда моя просьба неожиданно совпала с моментом, когда нужно было срочно потратить выделенные на закупку ПО деньги, нам ее все-таки купили!

Радости моей с одной стороны не было предела, но с другой оказалось, что не все так хорошо; сходу PVS-Studio встраивается только в Visual Studio (что порадовало отдел разработки под десктопы) и продукты от Jetbrains (CLion, Rider, Idea, Android Studio), для некоторых других систем сборки тоже предусмотрены готовые сценарии, а вот для Keil’a заявлена только поддержка компилятора – и все. А значит, нужно заниматься интеграцией. Кто будет этим заниматься? Ну, мне же больше всех надо…

Разумеется, рабочие задачи при этом с меня не спали, поэтому процесс затягивался довольно сильно. Поначалу я, вопреки всем рекомендациям, занимался проверками «только по праздникам», без всякой автоматизации по самому универсальному сценарию – запускать PVS-Studio Standalone, нажимать «Мониторить запуск компилятора», компилировать проект и читать результаты анализа.

Так продолжалось до тех пор, пока однажды я не потратил 3 дня на отладку очень неприятного бага, который отличался совершенно дикими проявлениями в случайные моменты времени. Баг оказался банальным чтением по нулевому указателю (которое на микроконтроллерах зачастую не приводит ни к каким мгновенным ошибкам типа Access Violation).

Быстренько убедившись, что PVS-Studio находит этот баг, я понял, что хватит это терпеть! – и решил-таки заняться интеграцией с Keil’ом.

И давайте сразу же определимся, что я понимаю под интеграцией:

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

Как вы узнаете к концу статьи, в принципе, более-менее получилось – но с нюансами 🙂

Замедлитель компиляции

Мониторинг не успевает отловить запуск компилятора? Так давайте заставим его компилировать подольше!

  • Можно просто запускать Process Explorer вместе с Keil’ом. Но не очень понятно, насколько это помогает и почему.
  • Поскольку один мой коллега упарывался по шаблонам, я попросил его накидать что-нибудь, что хорошенько грузило компилятор, не оказывая никакого влияния на бинарный файл; он мне предложил свое шаблонное вычисление табличного синуса, которое я, пожалуй не рискну выкладывать на всеобщее обозрение дабы не шокировать почтенную публику (и потому что код не я писал 🙂

С помощью флага это принудительно инклудилось в каждый.срр-файл в проекте.

Эти варианты отметаются, поскольку замедляют компиляцию (а еще, потому что это наркомания).

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

Утилита CLMonitorDumpFilter

Поскольку ручные манипуляции – это все-таки довольно грустно, после перебрасывания идеями, команда PVS-Studio разработала для нас специальную утилиту и несколько скриптов.
Основная идея состоит в следующем:

  1. Запуск скрипта перед сборкой (с одним набором параметров), чтобы сформировать дамп окружения, ключей компиляции и т.д. Этот запуск создает копию файла проекта, включает в нем формирование Batch-файла, собирает этот проект, анализирует batch-файл и удаляет копию.
  2. Запуск скрипта перед компиляцией каждого файла вместо мониторинга запусков компилятора.
  3. Запуск скрипта (с другим параметром) после сборки проекта, чтобы выполнить анализ и вывести результат.
    Собственно основной скрипт достаточно объемный и я его здесь целиком приводить не буду (но вот он на гитхабе); к тому же, его мне предоставили представители PVS-Studio 🙂 Я немножко подправил его, в частности, убрал необходимость вручную указывать путь до папки Keil’a.

Соответственно, вызовы в данном случае выглядят так:

  • Before Compile

  • Before Build/Rebuild

Здесь — имя вашего текущего таргета, должно быть в кавычках

Буквы с решетками – Keil называет это «Key Sequence» — по сути это build variables, переменные окружения для сборки.

  • – это путь до папки Keil’a,
  • – путь до текущего файла
  • – путь до файла проекта

Плюсы по сравнению с предыдущим:

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

Минусы:

  • В данный момент не поддерживается ARM Compiler version 6 (т.е. armclang)
  • Название текущей конфигурации нужно указывать вручную в строке вызова скрипта.

Это минус только по сравнению с предыдущим вариантом, где это название указывать не нужно вообще 🙂 К счастью, делать это нужно только при создании конфигурации – но вручную.

Убрать эти надписи у меня не получилось 🙁

А поскольку в Keil нет нормального окна “Errors”, как в большинстве других IDE, окно Build Output приходится читать постоянно, фильтровать его невозможно; соответственно, эти надписи мешают визуально находить ошибки компиляции и предупреждения от компилятора, особенно если в проекте много файлов.

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

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

Подавление предупреждений

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

Итак, подавлять предупреждения можно на нескольких уровнях:

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

Поскольку в embedded есть реальная возможность делать каждый проект самодостаточным (т.е. не зависящим от каких-либо внешних библиотек, просто клонишь его и он компилируется), эту самодостаточность хочется сохранять. Поэтому все скрипты для анализа и файлы для подавления предупреждений тоже нужно будет хранить внутри папки проекта (разумеется, саму PVS-Studio придется ставить отдельно).

Двухъядерные микроконтроллеры. Особенности использования

Микропроцессор 1901ВЦ1Т имеет два ядра — RISC и DSP. Программирование RISC ядра возможно в Keil. Программа для ядра DSP может быть реализована в среде «Code Composer Studio» версии 3.3 и загружена в DSP через RISC-ядро. Подробнее об отладке DSP-ядра описано в статье Пример взаимодействия двух ядер в МК 1901ВЦ1Т.

Программирование и отладка совместно RISC- и DSP- ядер возможны только в среде CodeMaster-ARM с использованием программатора JEM-MultiChip от «Фитон».

МК, разрабатываемый в рамках ОКР «Электросила», имеет 2 ядра Cortex-M4, которые могут работать в режиме DUALCORE. Для параллельной отладки двух ядер в среде Keil можно использовать отладчик ULINK2, ULINKPro или CMSIS-DAP, для среды IAR подходят отладчики I-jet и CMSIS-DAP.

An Introduction to Keil MicroVision

Embedded system means some combination of computer hardware and programmable software which is specially designed for a particular task like  displaying message on LCD. If you are still wondering about an embedded system, just take a look at these circuit applications using 8051 microcontroller. You can call these applications embedded systems as it involves hardware (8051 microcontroller) and software (the code written in assembly language).

1. Voltmeter using 8051

2. Thermometer using 8051

3. Frequency counter using AVR

Some real life examples of embedded systems may involve ticketing machines, vending machines, temperature controlling unit in air conditioners etc. Microcontrollers are nothing without a Program in it.

One  of the important part in making an embedded system is loading the software/program we develop into the microcontroller. Usually it is called “burning software” into the controller. Before “burning a program” into a controller, we must do certain prerequisite operations with the program. This includes writing the program in assembly language or C language in a text editor like notepad, compiling the program in a compiler and finally generating the hex code from the compiled program. Earlier people used different softwares/applications for all these 3 tasks. Writing was done in a text editor like notepad/wordpad, compiling was done using a separate software (probably a dedicated compiler for a particular controller like 8051), converting the assembly code to hex code was done using another software etc.  It takes lot of time and work to do all these separately, especially when the task involves lots of error debugging and reworking on the source code.

Keil MicroVision is a free software which solves many of the pain points for an embedded program developer. This software is an integrated development environment (IDE), which integrated a text editor to write programs, a compiler and it will convert your source code to hex files too.

Here is simple guide to start working with Keil uVision which can be used for

  • Writing programs in C/C++ or Assembly language
  • Compiling and Assembling Programs
  • Debugging program
  • Creating Hex and Axf file
  • Testing your program without Available real Hardware (Simulator Mode)

This is simple guide on Keil uVision 4 though also applicable on previous versions also.

These are the simple steps to get off the mark your inning!

Step 1: After opening Keil uV4, Go to Project tab and

Create new uVision project

Now Select new folder and give name to Project.

Step 2: After Creating project now Select your device model. Example.NXP-LPC2148  

Step 3: so now your project is created and Message window will appear to add startup file of your Device click on Yes so it will be added to your project folder

Step 4: Now go to File and create new file and save it with .C extension if you will write program in C language or save with .asm for assembly language.

i.e., Led.c

Step 5: Now write your program and save it again. You can try example given at end of this tutorial.

Step 6: After that on left you see project window

Now come on Project window.

Right click on target and click on options for target

Here you can change your device also.

Click output tab here & check create Hex file if you want to generate hex file

Now click on ok so it will save changes.

Step 7 Now Expand target and you will see source group

Right click on group and click on Add files to source group

Now add your program file which you have written in C/assembly.

You can see program file added under source group.

Step 8: Now Click on Build target.You can find it under Project tab or in toolbar.It can also be done by pressing F7 key.

Step 9:  you can see Status of your program in Build output window

Now you are done with your program. Next time we will look at Debugging and Simulation of Program. Hope you find it helpful.

Первый проект в Keil 5 + STM32 CubeMX

Details
Автор Super User

В статье описано, каким образом можно создать проект с помощью программы STM32CubeMX (да, именно так она теперь называется) и библиотеки HAL. В проекте используется микроконтроллер STM32F407VGT6, но для других моделей действия будут аналогичны.

Для работы нам понадобятся:

  • Keil uVision 5;
  • STM32CubeMX;
  • микроконтроллер;
  • программатор.

Шаг 0. Если на вашем компьютере не установлен STM32CubeMX или Keil uVision 5, скачайте и установите их. При установке STM32CubeMX может потребоваться установка Java-платформы.

Шаг 1. Запускаем STM32CubeMX, выбираем «New project». В появившемся окне выставляем фильтр на требуемый микроконтроллер, выбираем его и жмем «ОК».

Шаг 2. Попробуем создать проект, в котором контроллер будет управлять работой светодиода. На моей отладочной плате светодиод подключен к выводу «PORTD.12» (узнать это можно из документации к плате). Выбираем нужный вывод микроконтроллера на схеме и кликаем по нему левой кнопкой мыши и из предложенных настроек вывода выбираем «GPIO_Output», т.е. назначаем его на вывод. Контроллер настроен!

Шаг 3. Настройка генерации проекта. Нажимаем «Project»  -> «Settings».

В открывшемся окне на вкладке «Project» в первое поле вводим название проекта, в следующее поле — путь к папке, где будет храниться проект, ниже в выпадающем списке выбираем IDE, для которой создается проект, и нажимаем кнопку «ОК». Про оставшиеся настройки расскажу в следующих статьях.

Шаг 4. Генерация проекта. Для того, чтобы запустилась генерация проекта, необходимо нажать на кнопку с шестеренкой и в открывшемся окне нажать кнопку «Open project».

Шаг 5. Проверка созданного проекта. После нажатия на кнопку начнет запускаться Keil.

Переходим в Keil, в обозревателе проекта раскрываем группу «Application/User», открываем файл «Main.c», ищем в нем цикл «while(1)» и вписываем пару строк кода.

В первой строке кода вызывается процедура, которая меняет состояние вывода на противоположное (т.е. если светодиод светился, то должен погаснуть и наоборот). Вторая строка кода — это пауза.

Далее нажимаем на кнопку постройки проекта.

Пока проект собирается, подключаем отладочную плату к компьютеру. Как только проект будет скомпилирован, нажимаем на кнопку загрузки кода в микроконтроллер. После загрузки необходимо перезагрузить микроконтроллер. По умолчанию STM32CubeMX в настройках проекта устанавливает программатор «St-Link», если используется другой программатор, необходимо зайти в настройки проекта и установить нужный программатор.

Если все сделано правильно, светодиод на плате вам поморгает 😉

Парсинг файл проекта

Едем дальше. Мне довольно быстро показалось, что использовать мониторинг вообще как-то глупо, ведь в файле проекта содержится вся нужная информация – какие файлы будут скомпилированы, с какими ключами и тому подобным. Почему бы просто не парсить этот файл?
Но этот вариант хорош только на бумаге. С одной стороны, непонятно, кто должен этим парсингом заниматься? Конечно, мы купили лицензию, но это не значит, что представителей PVS-Studio можно теперь бесконечно эксплуатировать. Для них мы со своим Keil’ом явно не в приоритете, интегрироваться в каждую встречную-поперечную среду экономически нецелесообразно, собственно, поэтому и предлагается универсальное решение с мониторингом.

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

Конкретные папки на всем компе

Это делается с помощью xml-файлов в папке текущего пользователя. Чтобы они применялись вместе с локальным xml-файлом, в локальном файле должна быть строка . PVS-Studio просто смотрит в папку и применяет все файлы оттуда подряд.

Подведем итоги

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

Отмечу, что подсчитать пользу от постоянного анализа достаточно сложно – ведь ошибка исправляется практически сразу, как только анализатор выдает соответствующее предупреждение. Оценить, сколько времени бы я эту проблему искал сам, без PVS-Studio, достаточно сложно.

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

Отдельные вопросы, которые стоило задать себе перед тем, как начинать этот процесс:

  • Не проще ли было интегрироваться в Eclipse?
  • Не проще ли было встроиться в CI, а не в IDE?
  • Может быть стоило выработать рефлекс «есть баг — сегодня праздник запусти PVS, а сам думай потом».

И, разумеется, примеры на гитхабе.

P.S. Если кто-нибудь знает, как теперь на хабре делать работающее оглавление, подскажите, пожалуйста, я пост поправлю.

Дамп

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

Таким образом, этот вариант делится на две стадии:

  • как-то детектировать, что набор файлов в проекте поменялся; в таком случае запускать мониторинг и сохранять результат мониторинга (не анализа)
  • если набор файлов не менялся, то просто запускать анализ по сохраненному результату

Как детектировать изменение списка файлов? Наверняка можно разными способами, я же пошел первым пришедшим мне на ум путем – через git, поскольку все равно все проекты должны гитоваться.
Если файл проекта менялся с последнего коммита, значит, добавлялись файлы!

Но в файле проекта может меняться много чего, там ведь и опции компиляции и черт знает что еще, поэтому я накидал вот такой однострочник:

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

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

  1. Выключить параллельную сборку (зайти в и поставить галку )
  2. Сменить «обычные» скрипты на «мониторящие» — снять и поставить еще две галки в
  3. Выполнить полную пересборку проекта
  4. Вернуть галки обратно

Минусы этого подхода:

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

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

  • Если в проекте несколько конфигураций сборки (в Keil это называется “Targets”), то при переключении может быть нужно перегенирировать дамп – если в конфигурациях участвуют разные файлы, разные ключи компиляции, активны разные дефайны и т.д. И вот за этим приходится следить самостоятельно, к сожалению, из Кейла автоматически имя текущей конфигурации никак не вытащить (ну, или я не смог найти как).

Наивная первая попытка

Keil, насколько мне известно, не предусматривает никаких «нормальных» способов кастомизации типа плагинов или расширений, поэтому единственный способ встроиться в сборку – это Custom Build Steps, которые в Keil’e называются «User Scripts».

В опциях проекта во вкладке Users предусмотрена возможность запуска сторонних программ (только .bat или .exe, даже .cmd нет!) по трем событиям:

  • перед сборкой всего проекта
  • перед компиляцией каждого файла
  • после сборки всего проекта

Вроде бы, первого и последнего должно быть достаточно. План вырисовывается вроде бы несложный:

  • перед сборкой всего проекта нужно запустить мониторинг
  • после сборки нужно мониторинг остановить
  • запустить анализ
  • вывести результаты в окно Build Output

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

Окей, пройдемся по шагам.

  • Запустить мониторинг можно с помощью консольной утилиты CLMonitor
  • После того, как сборка завершена, запускаем анализ и сохраняем его результат в формате обычного текста.
  • А потом выводим результаты просто с помощью more.
  • И вуаля, вроде бы все работает!

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

Казалось бы, пост на этом можно завершать?

К сожалению, нет.

Через некоторое время я заметил небольшую странность – пересобираю один и тот же проект без изменений, целиком, а результаты анализа PVS-Studio – разные! В них то пропадала, то появлялась ошибка в одном из файлов.

И началась эпическая переписка с техподдержкой, которая – исключительно по моей вине – растянулась почти на год (!). Вот честное слово — техподдержка у PVS-Studio – натурально лучшая из всех, с кем я общался, а общался я со многими, от российских производителей микросхем, где человек поздравлял меня с «днём пирожков с малиновым вареньем» (нет, это не шутка) до крупнейших зарубежных компаний, где меня месяцами футболили от человека к человеку 🙂

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

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

Окей. Что же с этим делать?

Программатор ST-LINK

До недавнего времени программаторы ST-LINK не работали с микроконтроллерами компании Миландр. Статья ссылалась на статью, где приводится информация по перепрошивке программатора — «Превращаем ST-Link в J-Link и дружим его с Миландром».

На момент написания заметки, программатор ST-LINK имеет версию прошивки V2.J34.S7 (07.10.2019), и без каких-либо перепрошивок на J-Link ST-Link программатор умеет работать со следующими микроконтроллерами компании Миландр:

  • 1986ВЕ91У;
  • 1986ВЕ92У;
  • 1986ВЕ93У;
  • 1901ВЦ1Т;
  • 1986ВЕ4У;
  • 1986ВЕ8Т;
  • 1986ВК214;
  • 1986ВК234;
  • Электросила.

Программатор ST-LINK не работает с микроконтроллерами 1986ВЕ1Т и 1986ВЕ3Т

Проверка осуществлялась как в среде Keil, так и в среде IAR (для 1986ВЕ91-94, 1901ВЦ1Т, Электросила). Видимых ограничений по работе в среде IAR в связке с ST-LINK с другими микроконтроллерами компании Миландр нет, достаточно добавить их в среду. 

Программатор ST-LINK работает с микроконтроллерами компании Миландр только в режиме SWD

На рисунке 1 представлен пример настройки программатора в среде Keil для работы на примере микроконтроллера 1986ВЕ92У. В IAR аналогично выбрать режим SWD в окне настройки программатора ST-LINK.

Рисунок 1 — CortexM Target Driver SetupПрограмматор I-Jet
Программатор-отладчик производства компании IAR Systems вместе с официальным паком для среды IAR от компании Миландр, который всегда доступен для загрузки на официальном сайте компании, в разделе с программным обеспечением, умеет работать со следующими микроконтроллерами компании

  • Серия микроконтроллеров 1986ВЕ9х — присутствует официальная поддержка данных микроконтроллеров в среде, начиная с версии IAR Embedded Workbench for ARM 8.32.4;
  • 1986ВЕ1Т;
  • 1986ВЕ3Т;
  • 1901ВЦ1Т;
  • Электросила.

PackInstaller

KeilPackInstaller

Праворуч на вкладці Devices знаходимо наш контролер. У моєму випадку це STM32F103C8, після чого у вкладці Packs зліва по черзі інсталюємо всі пакети.

Після того, як встановимо всі пакети, закриваємо PackInstaller і створюємо проект за допомогою меню
Project -> New mVision Project…

Оибираємо папку та ім`я проекту.

Після чого буде запропоновано вказати мікроконтролер.

Далі з`явиться вікно, у якому потрібно обрати компоненти які будуть використовуватися у проекті.

Обов`язково обрати:

  • CMSIS-CORE — підтримка основного ядра ARM
  • System Startup — основний конфігураційний системний файл
  • Standard Peripherals Drivers Framework — стандартні драйвери периферії
  • GPIO — управління ногами мікроконтролера
  • RCC — управління тактуванням периферії

ResolveОК

Тепер створюємо основний файл програми. Правою кнопкою миші натискаємо на Sourcegroup 1, далі Add New Irem to Group Source Group 1…

Вказуємо тип та ім`я файлу:

Після чого буде створено і відкрито файл main.c. Наберіть в ньому наступний код програми:

Перед тим як компілювати програму потрібно зробити деякі налаштуваня проекту. Натискаємо на Options for Targe…. Відкриється вікно налаштувань проекту.

На Вкладці «Target» потрібно вказати тактову частоту мікроконтролера.

На вкладці «Output» вказуємо формат вихідного файлу.

На вкладці «C/C++» у полі Define: вказуємо такі опції:

USE_STDPERIPH_DRIVER, STM32F10X_CL

Без цих опцій проект не буде нормально компілюватися. Можна вибрати рівень оптимізації.

Тепер можна закрити вікно налаштувань і спробувати зібрати проект за допомогою меню Project->Build target

Після вдалої збірки маємо побачити таку картину:

Успіхів.

Дивись також:

  • 1. STM32. Програмування STM32F103. Тестова плата. Прошивка через UART та через ST-Link
  • 2. STM32. Програмування. IDE для STM32
  • 3. STM32. Програмування STM32F103. GPIO
  • 4. STM32. Програмування STM32F103. Тактування
  • 5. STM32. Програмування STM32F103. USART
  • 6. STM32. Програмування STM32F103. NVIC
  • 7. STM32. Програмування STM32F103. ADC
  • 8. STM32. Програмування STM32F103. DMA
  • 9. STM32. Програмування STM32F103. TIMER
  • 10. STM32. Програмування STM32F103. TIMER. Захоплення сигналу
  • 11. STM32. Програмування STM32F103. TIMER. Encoder
  • 12. STM32. Програмування STM32F103. TIMER. PWM
  • 13. STM32. Програмування STM32F103. EXTI
  • 14. STM32. Програмування STM32F103. RTC
  • 15. STM32. Програмування STM32F103. BKP
  • 16. STM32. Програмування STM32F103. Flash
  • 17. STM32. Програмування STM32F103. Watchdog
  • 18. STM32. Програмування STM32F103. Remap
  • 19. STM32. Програмування STM32F103. I2C Master
  • 20. STM32. Програмування STM32F103. I2C Slave
  • 21. STM32. Програмування STM32F103. USB
  • 22. STM32. Програмування STM32F103. PWR
  • 23. STM32. Програмування STM32F103. Option bytes
  • 24. STM32. Програмування STM32F103. Bootloader
  • STM32. Скачати приклади
  • System Workbench for STM32 Інсталяція на Ubuntu
  • Keil uVision5 – IDE для STM32
  • IAR Workbench – IDE для STM32
  • Керування безколекторним двигуном постійного струму (BLDC) за допомогою STM32
  • Керування PMSM за допомогою STM32