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

Блог им. Selin

Всё началось с того, что сходу не получилось «быстро стартануть» Keil µVision 5 + STM32 (везде описание приведено для 4-го Keil-а). Посему решил для себя зафиксировать «опыт» картинками и чуточкой текста :)

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

И так — Keil запущен.
Идём в меню Project — New µVision Project…
Выбираем папку, где будет хранится наш проект и задаём имя.
Далее Keil предлагает нам определиться с микроконтроллером:
Выбираем свой микроконтроллер
В моём случае (STM32F4-Discovery) это STM32F407VG:
Выбираем свой микроконтроллер
Далее Keil предлагает нам сконфигурировать Environment. Здесь я выбираю свою отладочную плату:
конфигурация Environment
Это удобно тем, что сразу можно выбрать и добавить в проект кнопочки и светодиодики своей платы, если нужно:
Кнопочки и светодиодики моей STM32F4-Discovery
Но сейчас мне нужен просто «чистый» проект, так что выбираю только CMSIS Core и StartUp:
Компоненты для нового проекта
После этого получаю вот такой «стартовый набор»:
Стартовый набор
Добавляем свой main.c:
Добавляем свой main.c

Добавляем свой 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

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

RSS свернуть / развернуть
С одной стороны просто и со вкусом. С другой… Брать камень с 1 МБ ПЗУ и среду с ограничениями до 32 кБ не интересно.
0
Выбор IDE обоснован следующими фактами:
— понравившиея мне уроки от Sappise основаны на Keil (бонусом — у меня и плата такая же :) )
— на форуме убедили, что 32кВ — это очень много
— CooCox как-то сходу мне не понравился… Возможно, потому что я взял «попсовую» последнюю версию.
— другие среды даже не рассматривал в виду запугиваний на том же форуме сложностями настройки и т.д и т.п.
Впрочем, сейчас задача немного разобраться с этим процессором и вспомнить С. Для этого, думаю, выбор среды не критичен.
0
32 кБ с головой хватит чтобы научиться, но довольно быстро начинаешь биться лобом об это ограничение. Камень жирный, хочется и USB, и ЦАП… в общем большому кораблю — большое плавание. Мне самому кейл и иар очень нравятся — своей простотой и надёжностью, но крякать дорогущий софт при наличии кучи бесплатных не менее мощных идешек… еще есть emBlocks, или вообще vi+clang.
0
Заодно освойте и STM32CubeMX. Судя по всему такие конструкторы это будущее эмбеддед. Последние 10 лет к этому шло.
0
Уместнее сказать, не освойте, а изучите. HAL от ST — довольно сложная система, и требует осознанного подхода. Это отнюдь не упрощалка для новичков. Надо осознавать все взаимосвязи генерируемого STM32CubeMX кода, и только тогда это будет «в пользу».
Если просто начинать осваивать STM32 с STM32CubeMX, то получите кучу вопросов, на которые нет ответов.
Сначала надо освоить написание кода с CMSIS, совсем без библиотек типа HAL и SPL, перечитывая даташит и въезжая что к чему, и только потом, с приходом осознания что делаешь — смотреть что такое HAL, SPL и STM32CubeMX.
+1
Не соглашусь. Жизнь слишком коротка чтобы писать свои велосипеды. Вы USB Audio или Ethernet тоже предлагаете писать используя только CMSIS? Современный эмбеддер должен уметь использовать библиотеки производителя, и уметь писать свои если по каким-то причинам стандартные либы не подходят.
+1
Про такие вещи, как протокольные интерфейсы — даже вопросов нет. Но НАДО изучать с нижнего уровня, с регистров, тактирования ручками и т.д. и т.п.
А вот когда нижний уровень будет без проблем — тогда всякие протокольные и библиотечные штучки можно пробовать.
Или кто-то будет гордо себя называть Современным эмбеддером, только из-за знания библиотек, и при этом не зная железо (а это регистры, например через CMSIS, а можно и полностью ручками), и оправдывать это отсутствием времени.
Библиотеки облегчают и стандартизируют работу с «железом», но от них «0» толку, если их используют без знания самого этого железа.
0
Но НАДО изучать с нижнего уровня, с регистров, тактирования ручками и т.д. и т.п.

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

Готовая библиотека даст более простой старт, большие возможности на старте.

Это как и изучение ПК. Наверное есть люди, для которых знакомство с ПК началось со схемотехники и ассемблера, но, подозреваю, что для большинства знакомство началось с игр, Бейсика… И это не помещало потом (ели на то было желание) разобраться в более низкоуровневых вещах.
+1
Но НАДО изучать с нижнего уровня, с регистров, тактирования ручками и т.д. и т.п.
Это мне напоминает утверждения типа «учиться водить обязательно надо на ручке, а еще надо знать устройство двигателя и остальных агрегатов автомобиля». Да, это тоже вариант, но далеко не самый оптимальный для большинства ситуаций. К тому же он, фактически, означает жесткую привязку к одной конкретной архитектуре (и даже к одному конкретному производителю и семейству МК). Перейти на что-то еще становится долго и сложно.

P.S. странно, что при таком подходе остановка делается на регистрах. почему бы не копнуть вплоть до логических элементов, топологии и физики процессов в отдельных транзисторах?
+2
P.S. странно, что при таком подходе остановка делается на регистрах. почему бы не копнуть вплоть до логических элементов, топологии и физики процессов в отдельных транзисторах?
Это все фигня. Начинать надо с квантмеха!
+2
физики процессов в отдельных транзисторах
там и квантовая механика есть…

PS. у меня как раз был предмет в институте «физические основы электронной техники». там все, начиная с квантовой механики и прочей требухи…
0
там и квантовая механика есть…
Вот и я о том. Квантмех — крайний пункт (на сегодня) в изучении снизу :) ФОЭ уже чуть повыше, ну и «физика процессов в транзисторах» — расплывчатое понятие, на некотором уровне еще в школе изучается — но до КМ еще не копает.
0
Если Вы — любитель, с любительскими правами категории «B» — то конечно Вам ни к чему не мех. коробка не устройство авто. А вот в объем знаний профессионального водителя «CE» входит даже несколько больший объем знаний, и они ему нужны для выполнения проф. обязанностей.
Тут также. Просто не представляю, как можно MK использовать без знаний его внутреннего устройства?
Самое обидное — что все они устроены одинаково, и поняв и изучив всего ОДИН — без проблем изучается любой другой. И называть это пустой тратой времени — может лишь тот, кто никогда из любителей не перейдет в… а вообще никуда не перейдет — он всю жизнь будет воспринимать МК как черную коробочку…
0
Если Вы — любитель, с любительскими правами категории «B» …

Это Вы к чему? Вы думаете, что если водитель начал свое обучение с автомата, то он уже никогда не станет профессиональным водителем «CE»? Да ладно…

Просто не представляю, как можно MK использовать без знаний его внутреннего устройства?

Как некую абстракцию, «черный ящик». В реалиях ПК это уже обычное явление (естественно есть несколько условных уровне абстракции, типа системное программирование, прикладное и т. д. но знать весь стек современных технологий просто нереально). Думаю, скоро мы к этому придем и на МК (не зависимо от того хотим мы этого или нет).
+2
МК до ПК, пока — довольно далеко. Да, тому кто пишет вэб страничку регистры ни к чему. Но как без элементарных знаний подходить к МК — не представляю, оканчивается это бесконечными зависонами на форумах, с вопросами «написал и не работает»…
А в современных реалиях — очень важна узкая специализация. Покажите мне спеца «широкого профиля» — это будет «обо всем понемногу», «в подробности не вдаюсь», «за всё берусь». А в итоге — «везде и никак».
0
МК до ПК, пока — довольно далеко.

Да ладно. Посмотрите как за последнее время эволюционировали «интерфейсы» МК. Начиналось все с уровня USART, SPI, а сейчас вполне обыденно явление это USB, Ethernet, WiFi и т. д. И как соответственно выросла сложность решаемых задач.

Но как без элементарных знаний подходить к МК

А как это сделано на ПК? Разные уровни абстрагирования. Одни пишут драйвера и HAL, другие системные библиотеки, третьи приложения на основе АПИ ОС и т. д.
Подозреваю, аналогичное произойдет и с МК.
+3
Понимаете, никому не платят деньги просто за знания. Никому не интересна глубина Вашего познания тонкостей работы конкретного МК. Деньги платят за решение задачи. Библиотеки придумали чтобы типовые задачи (коих 99%) решать быстро и чтобы код можно было использовать многократно. Во всех известных мне компаниях максимальное использование готового кода это стандарт, а собственные велосипеды наказуемы.
Что касается «зависонов на форумах», то они были всегда. И так само 10 лет назад писали нубы вопросы «не мигает», «не отсылает байт», «не работает». Безо всяких библиотек.
+4
К сожалению ничего не могу сказать по поводу, за что платят при написании кода — МК это моё хобии, хоть и со старым (20 лет назад) образованием.
Я совсем не против библиотек — наоборот, перевел и выложил тут описание описательную часть HAL, перевожу понемногу дальше.
Но считаю, что «0» цена тому спецу, который не знает МК внутри. МК — не компьютер. Да и комп внутри ничего фантастического не имеет. Да, уровень абстракции в современном ПК очень высок. Очень. И МК до этого уровня очень и очень далеко.
0
Я совсем не против библиотек — наоборот, перевел и выложил тут описание описательную часть HAL

Почему Вы считаете, что использовать готовое решение в режиме «черного ящика» допустимо для, например, USB, но при этом считаете зазорным, если программист воспользуется готовым решением (тоже в режиме «черного ящика») для GPIO или настройки тактирования.

В чем принципиальная разница, и где здесь грань?
+2
Во-первых, уровень абстракции 8-битников и Cortex M4 это небо и земля. А любители уже и полноценные процы типа А13, TI Sitara, Blackfin используют и ставят на них линукс с гуём, да так что не всяк и отличит от компьютера.
Но считаю, что «0» цена тому спецу, который не знает МК внутри
А мне кажется, это говорит обида. Типа я трудился, годами изучал тайное искусство, а тут вылазит такой, канифоль еще на губах не обсохла и в полчаса делает веб-сервер на МК, и с файловой системой на флешке.
Мне по работе приходилось сталкиваться с десятком разных МК от различных производителей. Наизусть помнил регистры только на AVR. Если бы я досконально учил все архитектуры перед тем как их использовать, я бы сдох (от голода, т.к. начальство выгнало бы меня не дожидаясь моего просвещения).
Знание МК- не самоцель. Если я бы смог решать задачи автоматизации при помощи волшебного танца или покупки маленьких смышлёных гномиков — я бы так и делал. Мне фиолетово что внутри коробки — меня интересует что коробка может делать. Я предпочитаю потратить время на продумывание изяшного нового алгоритма, а не на развязывание банальных задач типа подключения дисплея и рисования прямой методом Брэзенхема.
+6
Нисколько не умаляю важность системных программистов. Библиотеки, драйвера и ОС нам не спускают с неба, и люди, пишущие их должны досконально разбираться в особенностях работы МК. Но системщиков в жизни нужно значительно меньше чем прикладников.
0
При этом системные программисты, вообще говоря, не являются более знающими, чем прикладные. У них просто другая область знаний.
+2
При этом системные программисты, вообще говоря, не являются более знающими, чем прикладные

Угу. Но, как мы видим (особенно в определенных кругах) существует некий «культ» низкоуровневого программирования. Типа работать на прямую с регистрами, да на ассемблере – это круто, сложно, а значит не каждый сможет!

Хотя, на самом деле любой ассемблер по уровню сложности нервно покуривает в сторонке по сравнению с тем же С++. Писать на ассемблере действительно тяжело но не потому что он сложный, а по тому, что он примитивный.

Плюс, как я заметил, большинство эмбеддеров очень консервативны. Практически любая новая технология воспринимается «в штыки».
+2
Да нет никакой тайной обиды. Как и нет сожаления, что работаю не по специальности. И нет никакого тайного искусства — учат, в основном, где брать информацию, и как наиболее эффективно её использовать… кто хочет — научится, кто не хочет — нет.
Если Вы знаете AVR и понимаете как этот зверёк работает — нет ничего удивительного в успешной разработке софта для других МК — аналогий много, а Вы уже умеете работать с документацией и можете быстро найти необходимый абзац и правильно использовать информацию. Досконально знать все МК — да, совсем не обязательно, но и иметь некие системные знания — желательно. И не важно, как эти системные знания были получены.

И все равно считаю, что знание хоть одного МК — необходимо. Возможно у меня устаревшее мнение, но без этого писать для МК просто тяжко.
0
На ардуино вполне успешно пишут без этого понимания. Хотя оно, конечно, полезно, но, например, с ассемблером я познакомился больше не по нуждам программирования, а по нуждам реверс-инжиниринга.
+2
Ардуино — это вещь сама в себе. Шаг влево-вправо и успешный ардуинщик будет в стопоре. Насколько быстро и успешно осваивают ардуино — видел не один раз. Как и поиск ардуинщиком заветного «кубика», к которому есть код…
По ассемблеру — на современном этапе его достаточно понимать, а писать на нем — не обязательно. Например сейчас перетаскиваю ассемблерные вставки с AVR32 на M4… но многим такое понадобится?
+1
Это уже зависит от ардуинщика. На дельфи тоже немало программистов, умеющих только TDoMyWork на форму положить. И не обязательно знать регистры SPI, чтобы успешно подключить по нему средствами ардуино какую-нибудь ENC28J60. Хотя, конечно, код работы с ней и TCP/IP стек на ардуино будет на 99% тем же, что и на регистрах.
+1
учат, в основном, где брать информацию, и как наиболее эффективно её использовать… кто хочет — научится, кто не хочет — нет.

Касательно умения работать с информацией – я полностью с Вами согласен.

И все равно считаю, что знание хоть одного МК — необходимо.

Возможно, мы вкладывает разные понятия в термин «знание МК».

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

К примеру, я знаю, что для чтения 12 битного АЦП, на конкретной платформе, я должен прочитать два регистра (пусть это будут условные ADCH и ADCL и их прочитать нужно обязательно в определенном порядке, ибо чтение оного из регистров является триггером для перезапуска АЦП).

А вот мой коллега, этого не знает, зато знает, что для чтения данных с АЦП нужно воспользоваться функцией HAL, ReadADC().

Могу ли я утверждать, что я знаю, как «работает МК», о он нет? Чем
абстракция на уровне «ADCH, ADCL» принципиально отличается от абстракции ReadADC()?
+1
Это пока Вашему товарищу не предложить при помощи HAL сделать 8-ми битную двунаправленную шину данных с управлением по CS и RW и произвольным расположением всего этого добра по ножкам МК. Да, совсем забыл — чтоб работала на 2-3 МГц.
0
Он даже не скажет, на каком камне это заработает.
0
И заработает атомарно, т.к. все другие ноги использует другой сотрудник, и очень активно…
0
Этак можно вспомнить V-USB в качестве примера того, что писать можно только на ассемблере.
0
… сделать 8-ми битную двунаправленную шину данных с управлением по CS и RW и произвольным…

А в чем принципиальная проблема реализовать такой механизм на уровне HAL?

И моему товарищу платят деньги за реализацию функциональности устройства, а не за «чтоб работала на 2-3 МГц.» (то, о чем говорил count_enable)
0
Никто не говорит, что регистры и устройство процессора не надо знать. Речь о том, с чего начинать изучение — и я не считаю, что изучать надо с ассемблера и регистров. Ардуино (как библиотека) — тоже хорошая точка для старта, и на мой взгляд — лучше, чем регистры.
0
Я вот так и пробовал стартовать с ардуино в 2012 году (тогда еще полный ноль в цифре) — и как то не зашло. Я не спорю, у меня за вечер получилось уже шаговиком крутить, но не было чувства понимания происходящего и мне это очень не нравилось. А вот когда я забрел на курс по АВР от Ди, регистры, стек, прерывания, ассемблер — вот тогда меня вштырило так вштырило! Дало нормальную такую базу, которая подкрепленная курсом ЦУиМП уже определила область моей дальнейшей деятельности и значительно облегчила мне вливание в профессиональную деятельность. Правда специализация наверное еще уже чем у програмистов-системщиков — разработка мк, т.е. работа на уровне verilog-модели. Хотя часто приходится «всплывать» на уровень пользователя писать тесты и прочее.
0
Ну так это хорошо, что не нравилось непонимание. Стимул вкопаться вглубь.
Сам я оба пути опробовал — в электронику закапывался с основ, в программиирование — с дельфи и вьювера картинок в три строчки (if OpenDialog1.Execute then Image1.LoadFromFile(OpenDialog1.FileName), и второй путь мне, пожалуй, больше понравился.
0
И называть это пустой тратой времени
Разве я называл?
0
Нет, я согласен что электронщик должен уметь работать с регистрами и хотя бы читать (если не писать в ассемблере). Но представьте себе что обычный программист начинает написание проги под винду с создания собственного гуя. И собственного stdlib. И собственного сетевого стека.
Надо посмотреть вокруг и понять реалии. А реалии это кроссплатформенность типа mbed, ОСРВ как норма жизни и высокоуровневый код.
Точно так же студенту полезно написать собственную «ось» или компилятор, но 99,9999% студентов потом будут зарабатывать деньги используя уже созданные инструменты.

Знание наизусть порядка инициализации регистров ПДП в процессорах семейства STM32F103 это плохая самоцель. Работодателю пох на внутреннюю крутизну инженера. Есть просто люди могущие решить задачу с минимальными трудозатратами и максимальной совместимостью кода, и есть неспособные к этому.
+4
Вы всё написали верно. Только изначально привязывать себя к пакетам 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 и обзываем как хочется.
внутри пишем:
int main(viod)
  {
    for (;;);
  }


(не забываем про пустую строчку после фигурной скобки [b]}[/b]) и сохраняем

Жмем кнопочку с двумя стрелочками и радуемся.

Вы только что собрали полноценный и полнофункциональный проект а «чистом» CMSIS…
Дальше — внимательно штудируем [url]http://www.keil.com/pack/doc/CMSIS/Core/html/index.html[/url]. Кстати камень в этом случае сразу стартует на номинальной частоте, без доп. настроек.

Немного поясню пункты 4 и 5 — подсмотрел это в проектах от ST, правильно делать именно так, эта связка позволяет автоматом подключить именно то, что нужно. Так написаны заголовочные файлы.
+2
Спасибо!
Всё получилось :)
Правда, не с первого раза — поначалу ругался:
Error: C4078E: stdin ('-') combined with other files

Переделал с нуля ещё раз — всё получилось. Возможно, ошибся на каком-то шаге.
0
Кстати — вопрос:
Если привязываться к пакетам Keil-а не есть хорошо — зачем тогда их (пакеты) вообще делают?
Ведь IDE разрабатывают такие же програмисты… И должны понимать такие вещи.
Тем более, что ST предоставляет все необходимые пакеты бесплатно. И на их сайте, как правило, версия более свежая, нежели у Keil-а (что вполне логично).
Или тут замешан гадко-мерзкий маркетинг?
0
Ну на самом деле и Keil и ST просто хотят не облегчить жизнь эмбеддерам, а максимально привязать потребителя к своей продукции. При этом максимально не приветствуются: со стороны производителей камней — те средства, что позволят без проблем менять производителя камня; а со стороны производителей IDE — не приветствуются такие средства, которые позволят «перепрыгнуть» на другую IDE.
Отсюда пакеты в Keil, дабы клиент жить без них не мог, и библиотеки у ST — по той же причине.
0
Ну на самом деле и Keil и ST просто хотят не облегчить жизнь эмбеддерам, а максимально привязать потребителя к своей продукции.
Раньше — да. Теперь те, кто действует по такой схеме, быстро оказываются на обочине.
При этом максимально не приветствуются: со стороны производителей камней — те средства, что позволят без проблем менять производителя камня;
Вот только ST явно действует вопреки этой схеме. Недавнее вбрасывание пачки плат на mbed тому пример. Да и сраться с ARM-ом, который прямо заинтересован в поддержке максимального числа пользователей (и именно по этой причине поддерживает gcc для ARM) производителям камней совсем не с руки. Ну а производители IDE, естественно, будут пытаться привязать пользователей к своим продуктам, но делается это не путем усложнения перехода с их продукции на альтернативы, а предложением более продвинутых и развитых продуктов. Попытки привязать сугубо несовместимостями закончатся тем, что все перейдут на бесплатные продукты типа того же эклипса, благо они если и уступают платным конкурентам, то незначительно, а ресурсов для дальнейшего развития у них в разы больше, чем у самых толстых контор.
+1
Тем не менее Keil мало что сделал, для облегчения переноса проектов с других IDE на свою, и не предоставит, сам, методы для переноса проектов из его IDE в IDE конкурентов. Среди платных IDE — такое не приветствуется. Если кто знает исключения — прошу озвучить.
А об конфликте ST и ARM вообще речи не идет. Идет речь об переносе проекта типа ST -> NXP или ATMEL -> ST.
0
Тем не менее Keil мало что сделал, для облегчения переноса проектов с других IDE на свою, и не предоставит, сам, методы для переноса проектов из его IDE в IDE конкурентов
Тогда он отправится на свалку.

Идет речь об переносе проекта типа ST -> NXP или ATMEL -> ST.
Угу. Я об этом и говорю: mbed изначально ориентировался на NXP. Сейчас там и NXP, и ST, и некоторые конторы помельче. А внутри mbed переход между платформами сильно упрощается.
0
Мною mbed воспринимается как попытка подобрать под своё крыло ардуинщиков. Без него, как и без ардуино обойтись как два пальца об асфальт.
Покажите хоть один серьезный коммерческий проект на mbed или arduino.
Эти платформы — для популяризации и зарабатывания денег на «кубиках» для платформ.
0
Мною mbed воспринимается как попытка подобрать под своё крыло ардуинщиков. Без него, как и без ардуино обойтись как два пальца об асфальт.
Вопрос на засыпку: нафига подбирать под свое крыло ардуинщиков? Они, по большому счету, ничтожно малое число потребителей.
0
Покажите хоть один серьезный коммерческий проект на mbed или arduino.
А как ты предлагаешь его опознавать? Сорцы комерческого проекта никто не даст, а иных опознавательных признаков у ардуино нет.
Опять же, считать ли серьезным коммерческим проектом коммерческие контроллеры коптеров на основе multiwii, который на ардуино?
0
Arduino это сам по себе очень успешный коммерческий проект. Ненавидя его всеми фибрами души легко пропустить тот факт что его придумали для обучения и быстрого прототипирования, а не создания конечных устройств.
0
А за что ненавидеть Ардуинку?
С таким же успехом можно ненавидеть Lego, например… Это ведь просто игрушка :)
Можно собрать свой личный авторский термометр и радоваться жизни :) Даже паять ничего не нужно будет! И для обучения это очень важно — не убить энтузиазм сложностью создания первого рабочего девайса.
+1
Arduino я видел в руках очень серьёзных людей, включая лаборатории института нейроинформатики Цюриха и Манчестера. Трудились они во всех мыслимых вариантах, как самые дешевые и простые драйвера — интерфейсы между реальным миром и прототипными ASICами за безумные деньги. На них не было сделано ни одного коммерческого продукта, но если переложить на человеко-часы их помощь в тестировании и облегчении работы это будут сотни тысяч евро. Хороший инженер не холиварит на тему хорош или плох инструмент — он просто использует что ему лично удобно.
+3
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.