Keil µVision 5 + STM32F4 Discovery - Начало

Вроде как и делал всё по инструкциям: добавлял файлики, раскрывал коментарии для своего процессора, conf файл, StartUp… Но проект собираться всё равно не хотел.
В итоге плюнул на интернеты и решил, наконец, пойти самым простым путём — путём, предлагаемым самим Keil-ом :)
Потратив вечер, решил для себя оформить краткую инструкцию, ибо отличия от 4-й версии всё ж немного есть и на начальном этапе я, бывает, всё ещё туплю :(
И так — Keil запущен.
Идём в меню Project — New µVision Project…
Выбираем папку, где будет хранится наш проект и задаём имя.
Далее Keil предлагает нам определиться с микроконтроллером:

В моём случае (STM32F4-Discovery) это STM32F407VG:

Далее Keil предлагает нам сконфигурировать Environment. Здесь я выбираю свою отладочную плату:

Это удобно тем, что сразу можно выбрать и добавить в проект кнопочки и светодиодики своей платы, если нужно:

Но сейчас мне нужен просто «чистый» проект, так что выбираю только CMSIS Core и StartUp:

После этого получаю вот такой «стартовый набор»:

Добавляем свой main.c:


Пишем в нём самый минимум:
int main()
{
}
И собираем:

Вот и всё!
Да — если видим такой Warning:
main.c(3): warning: #1-D: last line of file ends without a newline
Значит в конце указанного файла (main.c) Keil-у для полного счастья не хватает «пустой строки»: просто жмём в этом файле Ctrl+End и Enter.
Вот теперь точно всё :)
Спасибо всем, кто досмотрел, дочитал до конца :)
- +3
- 07 апреля 2015, 10:55
- Selin
С одной стороны просто и со вкусом. С другой… Брать камень с 1 МБ ПЗУ и среду с ограничениями до 32 кБ не интересно.
- count_enable
- 07 апреля 2015, 15:31
- ↓
Выбор IDE обоснован следующими фактами:
— понравившиея мне уроки от Sappise основаны на Keil (бонусом — у меня и плата такая же :) )
— на форуме убедили, что 32кВ — это очень много
— CooCox как-то сходу мне не понравился… Возможно, потому что я взял «попсовую» последнюю версию.
— другие среды даже не рассматривал в виду запугиваний на том же форуме сложностями настройки и т.д и т.п.
Впрочем, сейчас задача немного разобраться с этим процессором и вспомнить С. Для этого, думаю, выбор среды не критичен.
— понравившиея мне уроки от Sappise основаны на Keil (бонусом — у меня и плата такая же :) )
— на форуме убедили, что 32кВ — это очень много
— CooCox как-то сходу мне не понравился… Возможно, потому что я взял «попсовую» последнюю версию.
— другие среды даже не рассматривал в виду запугиваний на том же форуме сложностями настройки и т.д и т.п.
Впрочем, сейчас задача немного разобраться с этим процессором и вспомнить С. Для этого, думаю, выбор среды не критичен.
32 кБ с головой хватит чтобы научиться, но довольно быстро начинаешь биться лобом об это ограничение. Камень жирный, хочется и USB, и ЦАП… в общем большому кораблю — большое плавание. Мне самому кейл и иар очень нравятся — своей простотой и надёжностью, но крякать дорогущий софт при наличии кучи бесплатных не менее мощных идешек… еще есть emBlocks, или вообще vi+clang.
- count_enable
- 08 апреля 2015, 11:06
- ↑
- ↓
Заодно освойте и STM32CubeMX. Судя по всему такие конструкторы это будущее эмбеддед. Последние 10 лет к этому шло.
- count_enable
- 08 апреля 2015, 11:18
- ↑
- ↓
Уместнее сказать, не освойте, а изучите. HAL от ST — довольно сложная система, и требует осознанного подхода. Это отнюдь не упрощалка для новичков. Надо осознавать все взаимосвязи генерируемого STM32CubeMX кода, и только тогда это будет «в пользу».
Если просто начинать осваивать STM32 с STM32CubeMX, то получите кучу вопросов, на которые нет ответов.
Сначала надо освоить написание кода с CMSIS, совсем без библиотек типа HAL и SPL, перечитывая даташит и въезжая что к чему, и только потом, с приходом осознания что делаешь — смотреть что такое HAL, SPL и STM32CubeMX.
Если просто начинать осваивать STM32 с STM32CubeMX, то получите кучу вопросов, на которые нет ответов.
Сначала надо освоить написание кода с CMSIS, совсем без библиотек типа HAL и SPL, перечитывая даташит и въезжая что к чему, и только потом, с приходом осознания что делаешь — смотреть что такое HAL, SPL и STM32CubeMX.
Не соглашусь. Жизнь слишком коротка чтобы писать свои велосипеды. Вы USB Audio или Ethernet тоже предлагаете писать используя только CMSIS? Современный эмбеддер должен уметь использовать библиотеки производителя, и уметь писать свои если по каким-то причинам стандартные либы не подходят.
- count_enable
- 08 апреля 2015, 13:51
- ↑
- ↓
Про такие вещи, как протокольные интерфейсы — даже вопросов нет. Но НАДО изучать с нижнего уровня, с регистров, тактирования ручками и т.д. и т.п.
А вот когда нижний уровень будет без проблем — тогда всякие протокольные и библиотечные штучки можно пробовать.
Или кто-то будет гордо себя называть Современным эмбеддером, только из-за знания библиотек, и при этом не зная железо (а это регистры, например через CMSIS, а можно и полностью ручками), и оправдывать это отсутствием времени.
Библиотеки облегчают и стандартизируют работу с «железом», но от них «0» толку, если их используют без знания самого этого железа.
А вот когда нижний уровень будет без проблем — тогда всякие протокольные и библиотечные штучки можно пробовать.
Или кто-то будет гордо себя называть Современным эмбеддером, только из-за знания библиотек, и при этом не зная железо (а это регистры, например через CMSIS, а можно и полностью ручками), и оправдывать это отсутствием времени.
Библиотеки облегчают и стандартизируют работу с «железом», но от них «0» толку, если их используют без знания самого этого железа.
Но НАДО изучать с нижнего уровня, с регистров, тактирования ручками и т.д. и т.п.
Я вот не считаю, что изучение с нижнего уровня – это единственно правильный путь. Почему бы не начать с готовой библиотеки, а уже потом погрузится в тонкости периферии МК (если до этого дойдет, и человеку действительно захочется развиваться в этом направлении).
Готовая библиотека даст более простой старт, большие возможности на старте.
Это как и изучение ПК. Наверное есть люди, для которых знакомство с ПК началось со схемотехники и ассемблера, но, подозреваю, что для большинства знакомство началось с игр, Бейсика… И это не помещало потом (ели на то было желание) разобраться в более низкоуровневых вещах.
Но НАДО изучать с нижнего уровня, с регистров, тактирования ручками и т.д. и т.п.Это мне напоминает утверждения типа «учиться водить обязательно надо на ручке, а еще надо знать устройство двигателя и остальных агрегатов автомобиля». Да, это тоже вариант, но далеко не самый оптимальный для большинства ситуаций. К тому же он, фактически, означает жесткую привязку к одной конкретной архитектуре (и даже к одному конкретному производителю и семейству МК). Перейти на что-то еще становится долго и сложно.
P.S. странно, что при таком подходе остановка делается на регистрах. почему бы не копнуть вплоть до логических элементов, топологии и физики процессов в отдельных транзисторах?
Если Вы — любитель, с любительскими правами категории «B» — то конечно Вам ни к чему не мех. коробка не устройство авто. А вот в объем знаний профессионального водителя «CE» входит даже несколько больший объем знаний, и они ему нужны для выполнения проф. обязанностей.
Тут также. Просто не представляю, как можно MK использовать без знаний его внутреннего устройства?
Самое обидное — что все они устроены одинаково, и поняв и изучив всего ОДИН — без проблем изучается любой другой. И называть это пустой тратой времени — может лишь тот, кто никогда из любителей не перейдет в… а вообще никуда не перейдет — он всю жизнь будет воспринимать МК как черную коробочку…
Тут также. Просто не представляю, как можно MK использовать без знаний его внутреннего устройства?
Самое обидное — что все они устроены одинаково, и поняв и изучив всего ОДИН — без проблем изучается любой другой. И называть это пустой тратой времени — может лишь тот, кто никогда из любителей не перейдет в… а вообще никуда не перейдет — он всю жизнь будет воспринимать МК как черную коробочку…
Если Вы — любитель, с любительскими правами категории «B» …
Это Вы к чему? Вы думаете, что если водитель начал свое обучение с автомата, то он уже никогда не станет профессиональным водителем «CE»? Да ладно…
Просто не представляю, как можно MK использовать без знаний его внутреннего устройства?
Как некую абстракцию, «черный ящик». В реалиях ПК это уже обычное явление (естественно есть несколько условных уровне абстракции, типа системное программирование, прикладное и т. д. но знать весь стек современных технологий просто нереально). Думаю, скоро мы к этому придем и на МК (не зависимо от того хотим мы этого или нет).
МК до ПК, пока — довольно далеко. Да, тому кто пишет вэб страничку регистры ни к чему. Но как без элементарных знаний подходить к МК — не представляю, оканчивается это бесконечными зависонами на форумах, с вопросами «написал и не работает»…
А в современных реалиях — очень важна узкая специализация. Покажите мне спеца «широкого профиля» — это будет «обо всем понемногу», «в подробности не вдаюсь», «за всё берусь». А в итоге — «везде и никак».
А в современных реалиях — очень важна узкая специализация. Покажите мне спеца «широкого профиля» — это будет «обо всем понемногу», «в подробности не вдаюсь», «за всё берусь». А в итоге — «везде и никак».
МК до ПК, пока — довольно далеко.
Да ладно. Посмотрите как за последнее время эволюционировали «интерфейсы» МК. Начиналось все с уровня USART, SPI, а сейчас вполне обыденно явление это USB, Ethernet, WiFi и т. д. И как соответственно выросла сложность решаемых задач.
Но как без элементарных знаний подходить к МК
А как это сделано на ПК? Разные уровни абстрагирования. Одни пишут драйвера и HAL, другие системные библиотеки, третьи приложения на основе АПИ ОС и т. д.
Подозреваю, аналогичное произойдет и с МК.
Понимаете, никому не платят деньги просто за знания. Никому не интересна глубина Вашего познания тонкостей работы конкретного МК. Деньги платят за решение задачи. Библиотеки придумали чтобы типовые задачи (коих 99%) решать быстро и чтобы код можно было использовать многократно. Во всех известных мне компаниях максимальное использование готового кода это стандарт, а собственные велосипеды наказуемы.
Что касается «зависонов на форумах», то они были всегда. И так само 10 лет назад писали нубы вопросы «не мигает», «не отсылает байт», «не работает». Безо всяких библиотек.
Что касается «зависонов на форумах», то они были всегда. И так само 10 лет назад писали нубы вопросы «не мигает», «не отсылает байт», «не работает». Безо всяких библиотек.
- count_enable
- 08 апреля 2015, 18:12
- ↑
- ↓
К сожалению ничего не могу сказать по поводу, за что платят при написании кода — МК это моё хобии, хоть и со старым (20 лет назад) образованием.
Я совсем не против библиотек — наоборот, перевел и выложил тут описание описательную часть HAL, перевожу понемногу дальше.
Но считаю, что «0» цена тому спецу, который не знает МК внутри. МК — не компьютер. Да и комп внутри ничего фантастического не имеет. Да, уровень абстракции в современном ПК очень высок. Очень. И МК до этого уровня очень и очень далеко.
Я совсем не против библиотек — наоборот, перевел и выложил тут описание описательную часть HAL, перевожу понемногу дальше.
Но считаю, что «0» цена тому спецу, который не знает МК внутри. МК — не компьютер. Да и комп внутри ничего фантастического не имеет. Да, уровень абстракции в современном ПК очень высок. Очень. И МК до этого уровня очень и очень далеко.
Я совсем не против библиотек — наоборот, перевел и выложил тут описание описательную часть HAL
Почему Вы считаете, что использовать готовое решение в режиме «черного ящика» допустимо для, например, USB, но при этом считаете зазорным, если программист воспользуется готовым решением (тоже в режиме «черного ящика») для GPIO или настройки тактирования.
В чем принципиальная разница, и где здесь грань?
Во-первых, уровень абстракции 8-битников и Cortex M4 это небо и земля. А любители уже и полноценные процы типа А13, TI Sitara, Blackfin используют и ставят на них линукс с гуём, да так что не всяк и отличит от компьютера.
Мне по работе приходилось сталкиваться с десятком разных МК от различных производителей. Наизусть помнил регистры только на AVR. Если бы я досконально учил все архитектуры перед тем как их использовать, я бы сдох (от голода, т.к. начальство выгнало бы меня не дожидаясь моего просвещения).
Знание МК- не самоцель. Если я бы смог решать задачи автоматизации при помощи волшебного танца или покупки маленьких смышлёных гномиков — я бы так и делал. Мне фиолетово что внутри коробки — меня интересует что коробка может делать. Я предпочитаю потратить время на продумывание изяшного нового алгоритма, а не на развязывание банальных задач типа подключения дисплея и рисования прямой методом Брэзенхема.
Но считаю, что «0» цена тому спецу, который не знает МК внутриА мне кажется, это говорит обида. Типа я трудился, годами изучал тайное искусство, а тут вылазит такой, канифоль еще на губах не обсохла и в полчаса делает веб-сервер на МК, и с файловой системой на флешке.
Мне по работе приходилось сталкиваться с десятком разных МК от различных производителей. Наизусть помнил регистры только на AVR. Если бы я досконально учил все архитектуры перед тем как их использовать, я бы сдох (от голода, т.к. начальство выгнало бы меня не дожидаясь моего просвещения).
Знание МК- не самоцель. Если я бы смог решать задачи автоматизации при помощи волшебного танца или покупки маленьких смышлёных гномиков — я бы так и делал. Мне фиолетово что внутри коробки — меня интересует что коробка может делать. Я предпочитаю потратить время на продумывание изяшного нового алгоритма, а не на развязывание банальных задач типа подключения дисплея и рисования прямой методом Брэзенхема.
- count_enable
- 08 апреля 2015, 18:45
- ↑
- ↓
Нисколько не умаляю важность системных программистов. Библиотеки, драйвера и ОС нам не спускают с неба, и люди, пишущие их должны досконально разбираться в особенностях работы МК. Но системщиков в жизни нужно значительно меньше чем прикладников.
- count_enable
- 08 апреля 2015, 18:49
- ↑
- ↓
При этом системные программисты, вообще говоря, не являются более знающими, чем прикладные
Угу. Но, как мы видим (особенно в определенных кругах) существует некий «культ» низкоуровневого программирования. Типа работать на прямую с регистрами, да на ассемблере – это круто, сложно, а значит не каждый сможет!
Хотя, на самом деле любой ассемблер по уровню сложности нервно покуривает в сторонке по сравнению с тем же С++. Писать на ассемблере действительно тяжело но не потому что он сложный, а по тому, что он примитивный.
Плюс, как я заметил, большинство эмбеддеров очень консервативны. Практически любая новая технология воспринимается «в штыки».
Да нет никакой тайной обиды. Как и нет сожаления, что работаю не по специальности. И нет никакого тайного искусства — учат, в основном, где брать информацию, и как наиболее эффективно её использовать… кто хочет — научится, кто не хочет — нет.
Если Вы знаете AVR и понимаете как этот зверёк работает — нет ничего удивительного в успешной разработке софта для других МК — аналогий много, а Вы уже умеете работать с документацией и можете быстро найти необходимый абзац и правильно использовать информацию. Досконально знать все МК — да, совсем не обязательно, но и иметь некие системные знания — желательно. И не важно, как эти системные знания были получены.
И все равно считаю, что знание хоть одного МК — необходимо. Возможно у меня устаревшее мнение, но без этого писать для МК просто тяжко.
Если Вы знаете AVR и понимаете как этот зверёк работает — нет ничего удивительного в успешной разработке софта для других МК — аналогий много, а Вы уже умеете работать с документацией и можете быстро найти необходимый абзац и правильно использовать информацию. Досконально знать все МК — да, совсем не обязательно, но и иметь некие системные знания — желательно. И не важно, как эти системные знания были получены.
И все равно считаю, что знание хоть одного МК — необходимо. Возможно у меня устаревшее мнение, но без этого писать для МК просто тяжко.
Ардуино — это вещь сама в себе. Шаг влево-вправо и успешный ардуинщик будет в стопоре. Насколько быстро и успешно осваивают ардуино — видел не один раз. Как и поиск ардуинщиком заветного «кубика», к которому есть код…
По ассемблеру — на современном этапе его достаточно понимать, а писать на нем — не обязательно. Например сейчас перетаскиваю ассемблерные вставки с AVR32 на M4… но многим такое понадобится?
По ассемблеру — на современном этапе его достаточно понимать, а писать на нем — не обязательно. Например сейчас перетаскиваю ассемблерные вставки с AVR32 на M4… но многим такое понадобится?
Это уже зависит от ардуинщика. На дельфи тоже немало программистов, умеющих только TDoMyWork на форму положить. И не обязательно знать регистры SPI, чтобы успешно подключить по нему средствами ардуино какую-нибудь ENC28J60. Хотя, конечно, код работы с ней и TCP/IP стек на ардуино будет на 99% тем же, что и на регистрах.
учат, в основном, где брать информацию, и как наиболее эффективно её использовать… кто хочет — научится, кто не хочет — нет.
Касательно умения работать с информацией – я полностью с Вами согласен.
И все равно считаю, что знание хоть одного МК — необходимо.
Возможно, мы вкладывает разные понятия в термин «знание МК».
Мы знаем общую архитектуру, обобщенные схемы, знаем регистры периферии (то, что нам предоставил в документации разработчик МК). Но мы до конца не знаем, как оно там внутри работает, для нас это «черный ящик», с которым мы можем взаимодействовать через интерфейс регистров.
К примеру, я знаю, что для чтения 12 битного АЦП, на конкретной платформе, я должен прочитать два регистра (пусть это будут условные ADCH и ADCL и их прочитать нужно обязательно в определенном порядке, ибо чтение оного из регистров является триггером для перезапуска АЦП).
А вот мой коллега, этого не знает, зато знает, что для чтения данных с АЦП нужно воспользоваться функцией HAL, ReadADC().
Могу ли я утверждать, что я знаю, как «работает МК», о он нет? Чем
абстракция на уровне «ADCH, ADCL» принципиально отличается от абстракции ReadADC()?
… сделать 8-ми битную двунаправленную шину данных с управлением по CS и RW и произвольным…
А в чем принципиальная проблема реализовать такой механизм на уровне HAL?
И моему товарищу платят деньги за реализацию функциональности устройства, а не за «чтоб работала на 2-3 МГц.» (то, о чем говорил count_enable)
Я вот так и пробовал стартовать с ардуино в 2012 году (тогда еще полный ноль в цифре) — и как то не зашло. Я не спорю, у меня за вечер получилось уже шаговиком крутить, но не было чувства понимания происходящего и мне это очень не нравилось. А вот когда я забрел на курс по АВР от Ди, регистры, стек, прерывания, ассемблер — вот тогда меня вштырило так вштырило! Дало нормальную такую базу, которая подкрепленная курсом ЦУиМП уже определила область моей дальнейшей деятельности и значительно облегчила мне вливание в профессиональную деятельность. Правда специализация наверное еще уже чем у програмистов-системщиков — разработка мк, т.е. работа на уровне verilog-модели. Хотя часто приходится «всплывать» на уровень пользователя писать тесты и прочее.
Ну так это хорошо, что не нравилось непонимание. Стимул вкопаться вглубь.
Сам я оба пути опробовал — в электронику закапывался с основ, в программиирование — с дельфи и вьювера картинок в три строчки (if OpenDialog1.Execute then Image1.LoadFromFile(OpenDialog1.FileName), и второй путь мне, пожалуй, больше понравился.
Сам я оба пути опробовал — в электронику закапывался с основ, в программиирование — с дельфи и вьювера картинок в три строчки (if OpenDialog1.Execute then Image1.LoadFromFile(OpenDialog1.FileName), и второй путь мне, пожалуй, больше понравился.
Нет, я согласен что электронщик должен уметь работать с регистрами и хотя бы читать (если не писать в ассемблере). Но представьте себе что обычный программист начинает написание проги под винду с создания собственного гуя. И собственного stdlib. И собственного сетевого стека.
Надо посмотреть вокруг и понять реалии. А реалии это кроссплатформенность типа mbed, ОСРВ как норма жизни и высокоуровневый код.
Точно так же студенту полезно написать собственную «ось» или компилятор, но 99,9999% студентов потом будут зарабатывать деньги используя уже созданные инструменты.
Знание наизусть порядка инициализации регистров ПДП в процессорах семейства STM32F103 это плохая самоцель. Работодателю пох на внутреннюю крутизну инженера. Есть просто люди могущие решить задачу с минимальными трудозатратами и максимальной совместимостью кода, и есть неспособные к этому.
Надо посмотреть вокруг и понять реалии. А реалии это кроссплатформенность типа mbed, ОСРВ как норма жизни и высокоуровневый код.
Точно так же студенту полезно написать собственную «ось» или компилятор, но 99,9999% студентов потом будут зарабатывать деньги используя уже созданные инструменты.
Знание наизусть порядка инициализации регистров ПДП в процессорах семейства STM32F103 это плохая самоцель. Работодателю пох на внутреннюю крутизну инженера. Есть просто люди могущие решить задачу с минимальными трудозатратами и максимальной совместимостью кода, и есть неспособные к этому.
- count_enable
- 08 апреля 2015, 17:22
- ↑
- ↓
Вы всё написали верно. Только изначально привязывать себя к пакетам Keil — зло.
Вот как это делается без пакетов, скопипастил из своего же сообщения на форуме.
Скачайте у ST последний HAL и «выдерните» оттуда из драйверов папку CMSIS
1) Создайте в Keil пустой проект в режиме «Legacy Device Database», с указанием используемого камня, от добавления [i]startup_XXX.s[/i] отказываемся
2) Скопируйте в проект [b]ТОЛЬКО[/b] два файла — [i]startup_XXX.s[/i] (соответствующий Вашему камню) и [i]system_XXX.c[/i] из папок [i]CMSIS\Device\ST\STM32Fxxx\Source\Templates\arm[/i] и [i]CMSIS\Device\ST\STM32Fxxx\Source\Templates[/i] соответственно
3) Припасенную папку «CMSIS» располагаем так, что бы она была на уровень выше папки с проектом (тогда её можно будет использовать и в других Ваших проектах).
4) идем в настройки проекта, вкладка с/с++ в поле [i][b]Include Paths[/b][/i] добавляем пути к заголовочным файлам "[i]CMSIS\Include[/i]" и "[i]CMSIS\Device\ST\STM32Fxxx\Include[/i]" — IDE сама найдет [b]тут[/b] все нужные заголовочные файлы CMSIS
5) на этой же вкладке добавляем в поле "[i][b]Define[/b][/i]" дефайн своего камня, например «STM32F401xE» но без кавычек. Какой конкретно — смотрим в файлах папки "[i]CMSIS\Device\ST\STM32Fxxx\Include[/i]"
6) Добавляем свой файл с расширением .c и обзываем как хочется.
внутри пишем:
(не забываем про пустую строчку после фигурной скобки [b]}[/b]) и сохраняем
Жмем кнопочку с двумя стрелочками и радуемся.
Вы только что собрали полноценный и полнофункциональный проект а «чистом» CMSIS…
Дальше — внимательно штудируем [url]http://www.keil.com/pack/doc/CMSIS/Core/html/index.html[/url]. Кстати камень в этом случае сразу стартует на номинальной частоте, без доп. настроек.
Немного поясню пункты 4 и 5 — подсмотрел это в проектах от ST, правильно делать именно так, эта связка позволяет автоматом подключить именно то, что нужно. Так написаны заголовочные файлы.
Вот как это делается без пакетов, скопипастил из своего же сообщения на форуме.
Скачайте у ST последний HAL и «выдерните» оттуда из драйверов папку CMSIS
1) Создайте в Keil пустой проект в режиме «Legacy Device Database», с указанием используемого камня, от добавления [i]startup_XXX.s[/i] отказываемся
2) Скопируйте в проект [b]ТОЛЬКО[/b] два файла — [i]startup_XXX.s[/i] (соответствующий Вашему камню) и [i]system_XXX.c[/i] из папок [i]CMSIS\Device\ST\STM32Fxxx\Source\Templates\arm[/i] и [i]CMSIS\Device\ST\STM32Fxxx\Source\Templates[/i] соответственно
3) Припасенную папку «CMSIS» располагаем так, что бы она была на уровень выше папки с проектом (тогда её можно будет использовать и в других Ваших проектах).
4) идем в настройки проекта, вкладка с/с++ в поле [i][b]Include Paths[/b][/i] добавляем пути к заголовочным файлам "[i]CMSIS\Include[/i]" и "[i]CMSIS\Device\ST\STM32Fxxx\Include[/i]" — IDE сама найдет [b]тут[/b] все нужные заголовочные файлы CMSIS
5) на этой же вкладке добавляем в поле "[i][b]Define[/b][/i]" дефайн своего камня, например «STM32F401xE» но без кавычек. Какой конкретно — смотрим в файлах папки "[i]CMSIS\Device\ST\STM32Fxxx\Include[/i]"
6) Добавляем свой файл с расширением .c и обзываем как хочется.
внутри пишем:
int main(viod)
{
for (;;);
}
(не забываем про пустую строчку после фигурной скобки [b]}[/b]) и сохраняем
Жмем кнопочку с двумя стрелочками и радуемся.
Вы только что собрали полноценный и полнофункциональный проект а «чистом» CMSIS…
Дальше — внимательно штудируем [url]http://www.keil.com/pack/doc/CMSIS/Core/html/index.html[/url]. Кстати камень в этом случае сразу стартует на номинальной частоте, без доп. настроек.
Немного поясню пункты 4 и 5 — подсмотрел это в проектах от ST, правильно делать именно так, эта связка позволяет автоматом подключить именно то, что нужно. Так написаны заголовочные файлы.
Кстати — вопрос:
Если привязываться к пакетам Keil-а не есть хорошо — зачем тогда их (пакеты) вообще делают?
Ведь IDE разрабатывают такие же програмисты… И должны понимать такие вещи.
Тем более, что ST предоставляет все необходимые пакеты бесплатно. И на их сайте, как правило, версия более свежая, нежели у Keil-а (что вполне логично).
Или тут замешан гадко-мерзкий маркетинг?
Если привязываться к пакетам Keil-а не есть хорошо — зачем тогда их (пакеты) вообще делают?
Ведь IDE разрабатывают такие же програмисты… И должны понимать такие вещи.
Тем более, что ST предоставляет все необходимые пакеты бесплатно. И на их сайте, как правило, версия более свежая, нежели у Keil-а (что вполне логично).
Или тут замешан гадко-мерзкий маркетинг?
Ну на самом деле и Keil и ST просто хотят не облегчить жизнь эмбеддерам, а максимально привязать потребителя к своей продукции. При этом максимально не приветствуются: со стороны производителей камней — те средства, что позволят без проблем менять производителя камня; а со стороны производителей IDE — не приветствуются такие средства, которые позволят «перепрыгнуть» на другую IDE.
Отсюда пакеты в Keil, дабы клиент жить без них не мог, и библиотеки у ST — по той же причине.
Отсюда пакеты в Keil, дабы клиент жить без них не мог, и библиотеки у ST — по той же причине.
Ну на самом деле и Keil и ST просто хотят не облегчить жизнь эмбеддерам, а максимально привязать потребителя к своей продукции.Раньше — да. Теперь те, кто действует по такой схеме, быстро оказываются на обочине.
При этом максимально не приветствуются: со стороны производителей камней — те средства, что позволят без проблем менять производителя камня;Вот только ST явно действует вопреки этой схеме. Недавнее вбрасывание пачки плат на mbed тому пример. Да и сраться с ARM-ом, который прямо заинтересован в поддержке максимального числа пользователей (и именно по этой причине поддерживает gcc для ARM) производителям камней совсем не с руки. Ну а производители IDE, естественно, будут пытаться привязать пользователей к своим продуктам, но делается это не путем усложнения перехода с их продукции на альтернативы, а предложением более продвинутых и развитых продуктов. Попытки привязать сугубо несовместимостями закончатся тем, что все перейдут на бесплатные продукты типа того же эклипса, благо они если и уступают платным конкурентам, то незначительно, а ресурсов для дальнейшего развития у них в разы больше, чем у самых толстых контор.
Тем не менее Keil мало что сделал, для облегчения переноса проектов с других IDE на свою, и не предоставит, сам, методы для переноса проектов из его IDE в IDE конкурентов. Среди платных IDE — такое не приветствуется. Если кто знает исключения — прошу озвучить.
А об конфликте ST и ARM вообще речи не идет. Идет речь об переносе проекта типа ST -> NXP или ATMEL -> ST.
А об конфликте ST и ARM вообще речи не идет. Идет речь об переносе проекта типа ST -> NXP или ATMEL -> ST.
Тем не менее Keil мало что сделал, для облегчения переноса проектов с других IDE на свою, и не предоставит, сам, методы для переноса проектов из его IDE в IDE конкурентовТогда он отправится на свалку.
Идет речь об переносе проекта типа ST -> NXP или ATMEL -> ST.Угу. Я об этом и говорю: mbed изначально ориентировался на NXP. Сейчас там и NXP, и ST, и некоторые конторы помельче. А внутри mbed переход между платформами сильно упрощается.
Мною mbed воспринимается как попытка подобрать под своё крыло ардуинщиков. Без него, как и без ардуино обойтись как два пальца об асфальт.
Покажите хоть один серьезный коммерческий проект на mbed или arduino.
Эти платформы — для популяризации и зарабатывания денег на «кубиках» для платформ.
Покажите хоть один серьезный коммерческий проект на mbed или arduino.
Эти платформы — для популяризации и зарабатывания денег на «кубиках» для платформ.
Покажите хоть один серьезный коммерческий проект на mbed или arduino.А как ты предлагаешь его опознавать? Сорцы комерческого проекта никто не даст, а иных опознавательных признаков у ардуино нет.
Опять же, считать ли серьезным коммерческим проектом коммерческие контроллеры коптеров на основе multiwii, который на ардуино?
Arduino это сам по себе очень успешный коммерческий проект. Ненавидя его всеми фибрами души легко пропустить тот факт что его придумали для обучения и быстрого прототипирования, а не создания конечных устройств.
- count_enable
- 08 апреля 2015, 18:33
- ↑
- ↓
А за что ненавидеть Ардуинку?
С таким же успехом можно ненавидеть Lego, например… Это ведь просто игрушка :)
Можно собрать свой личный авторский термометр и радоваться жизни :) Даже паять ничего не нужно будет! И для обучения это очень важно — не убить энтузиазм сложностью создания первого рабочего девайса.
С таким же успехом можно ненавидеть Lego, например… Это ведь просто игрушка :)
Можно собрать свой личный авторский термометр и радоваться жизни :) Даже паять ничего не нужно будет! И для обучения это очень важно — не убить энтузиазм сложностью создания первого рабочего девайса.
Arduino я видел в руках очень серьёзных людей, включая лаборатории института нейроинформатики Цюриха и Манчестера. Трудились они во всех мыслимых вариантах, как самые дешевые и простые драйвера — интерфейсы между реальным миром и прототипными ASICами за безумные деньги. На них не было сделано ни одного коммерческого продукта, но если переложить на человеко-часы их помощь в тестировании и облегчении работы это будут сотни тысяч евро. Хороший инженер не холиварит на тему хорош или плох инструмент — он просто использует что ему лично удобно.
- count_enable
- 08 апреля 2015, 20:05
- ↑
- ↓
Комментарии (51)
RSS свернуть / развернуть