Comments 34
За труд, конечно, спасибо. Но судя по объёму статьи — это не для начинающих. На моей памяти самый сложный способ мигать светодиодом. Хорошая ирония «Для нетерпеливых — итог» — видео доставляет
Мне кажется подход у товарища очень правильный.
Его цель лучше познакомить читателей с архитектурой процессора. Понятно что на ардуинке код будет выглядеть куда проще, но для серьёзных задач такой подход не годиться. Я вообще за то чтобы перед тем как пользоваться высокоуровневыми библиотеками изучить архитектуру камня на которым работаешь. Если ты собираешься делать в дальнейшем серьёзные проекты это очень сильно поможет!
Его цель лучше познакомить читателей с архитектурой процессора. Понятно что на ардуинке код будет выглядеть куда проще, но для серьёзных задач такой подход не годиться. Я вообще за то чтобы перед тем как пользоваться высокоуровневыми библиотеками изучить архитектуру камня на которым работаешь. Если ты собираешься делать в дальнейшем серьёзные проекты это очень сильно поможет!
А что тут сложного? Все примитивно. Это же не ардуина!
Подробно рассмотрена настройка универсальной IDE, а сам «способ мигать» элементарный. Тем, кто делает паузы через «нужное количество» nop, честно говоря, хочется руки по отрывать. Тут используются таймеры… Дергать ногой можно было вообще в обработчике (правда за это, то же некоторые по рукам бьют), либо (что самое правильное) написать менеджер, который бы вызывался с определенной периодичностью, проверял состояние флага и выполнял инверсию (либо другие нужные действия) ноги.
А то, что «не для начинающих» видно из названия статьи. Раз уж вы переходите с STM32 на отечественного производителя, то и про таймеры и про прерывания должны знать.
Подробно рассмотрена настройка универсальной IDE, а сам «способ мигать» элементарный. Тем, кто делает паузы через «нужное количество» nop, честно говоря, хочется руки по отрывать. Тут используются таймеры… Дергать ногой можно было вообще в обработчике (правда за это, то же некоторые по рукам бьют), либо (что самое правильное) написать менеджер, который бы вызывался с определенной периодичностью, проверял состояние флага и выполнял инверсию (либо другие нужные действия) ноги.
А то, что «не для начинающих» видно из названия статьи. Раз уж вы переходите с STM32 на отечественного производителя, то и про таймеры и про прерывания должны знать.
Тем, кто делает паузы через «нужное количество» nop, честно говоря, хочется руки по отрывать. Тут используются таймеры
В следующей статье рассмотрено именно мигание с использованием SysTick. После будет с использованием таймера. А после и ОС. Потерпите. Не все сразу.
Дергать ногой можно было вообще в обработчике (правда за это, то же некоторые по рукам бьют), либо (что самое правильное) написать менеджер, который бы вызывался с определенной периодичностью, проверял состояние флага и выполнял инверсию (либо другие нужные действия) ноги.
В будущем будет рассмотрена связь с ОС. В которой все это будет.
Меня вот что интересует. Почему в то время как сегодня в стране вроде как взят курс на собственное ПО для всего и вся, военная контора ориентирует пользователей на Keil и IAR? Легальные дистрибутивы которых от них стоят очень и очень приличных денег, а главное разрабатываются в странах вероятного противника.
Очень странный подход для настоящих джидаев.
Может они хотят нанести максимальный урон врагу используя не лицензионные копии?
Вообще я к продукции обоих этих фирм хорошо отношусь, но надоело пользоваться лекарствами, а покупка их софта слишком дорогое для меня удовольствие. В результате перешёл на бесплатный кокос.
Очень странный подход для настоящих джидаев.
Может они хотят нанести максимальный урон врагу используя не лицензионные копии?
Вообще я к продукции обоих этих фирм хорошо отношусь, но надоело пользоваться лекарствами, а покупка их софта слишком дорогое для меня удовольствие. В результате перешёл на бесплатный кокос.
Мне кажется, что про «наиболее вероятного противника» — это не тот случай: объем памяти кристалла просто не позволит засунуть в него какого-либо зловреда.
Сколько же там памяти? Я думаю, на зловреда хватило бы и 200-500 ассемблерных инструкций в ПЗУ и десяток ячеек ОЗУ. Многие вирусы под MS-DOS были сравнимых размеров.
Зловреда вряд ли, но вот например эти системы проектирования в один прекрасный момент могут выйти из строя или информацию собирать…
А если честно то это уже дело принципа. Большинство политических решений за последние полтора года обусловлено далеко не здравым смыслов. И уж если гнуть эту политику и дальше, то непонятно почему чиновники должны работать на офисных программах с открытым кодом а оборонщики, которые делают свои кристаллы использовать системы разработки своих противников, при том что существуют не плохие системы с открытым исходным кодом.
Странно как то всё это.
А если честно то это уже дело принципа. Большинство политических решений за последние полтора года обусловлено далеко не здравым смыслов. И уж если гнуть эту политику и дальше, то непонятно почему чиновники должны работать на офисных программах с открытым кодом а оборонщики, которые делают свои кристаллы использовать системы разработки своих противников, при том что существуют не плохие системы с открытым исходным кодом.
Странно как то всё это.
вот, кстати, я пока топик читал¹ у меня тоже возникла подобная мысль. В том числе по поводу ОС на скриншотах.
Ну и слишком много в проекте GUI-возни и возни с IDE, при том, что и то и другое к самой теме «посвящения в работу с микроконтроллером» относится весьма и весьма относительно…
¹ кстати, пока дочитал до конца — как обычно забыл где именно встречались опечатки… ув. НЛО, если вы это читаете — запилите уже, наконец, отправку автору опечаток по Ctrl+Enter, ну пожааааалуйста!
Ну и слишком много в проекте GUI-возни и возни с IDE, при том, что и то и другое к самой теме «посвящения в работу с микроконтроллером» относится весьма и весьма относительно…
¹ кстати, пока дочитал до конца — как обычно забыл где именно встречались опечатки… ув. НЛО, если вы это читаете — запилите уже, наконец, отправку автору опечаток по Ctrl+Enter, ну пожааааалуйста!
Записывайте, пожалуйста, их где-нибудь. Я с радостью внесу правки и укажу, кем они были сделаны.
Ее больше не будет. Мы настроили Keil 5 и проект в нем. Теперь можно начать программировать. Если и будет что по настройке — то это мелочи, которые я мог упустить.
Лично для меня это была самая большая проблема. Плата пролежала на столе 2 недели. Каждый день я смотрел на нее и хотел начать, но мысль о том, что пришлось бы потратить несколько часов на настройку — отпугивала до последнего.
Ну и слишком много в проекте GUI-возни и возни с IDE
Ее больше не будет. Мы настроили Keil 5 и проект в нем. Теперь можно начать программировать. Если и будет что по настройке — то это мелочи, которые я мог упустить.
что и то и другое к самой теме «посвящения в работу с микроконтроллером» относится весьма и весьма относительно
Лично для меня это была самая большая проблема. Плата пролежала на столе 2 недели. Каждый день я смотрел на нее и хотел начать, но мысль о том, что пришлось бы потратить несколько часов на настройку — отпугивала до последнего.
Ну с keil'ом, как раз, мало возни. Вы почитайте про запуск STM32 в eclipse под Linux…
У меня возникла такая же мысль. Например, чтобы мне сейчас импортозаместиться, мне нужно купить зарубежную ОС и зарубежные среды разработки. Тем самым финансово поддержать «вероятного противника». Взять «отечественную» ОС (например какой-нибудь AltLinux) и начать разрабатывать под отечественный МК нельзя. Причём для импортных МК вполне успешно можно заниматься разработкой под отечественной ОС. Теоретически даже наверное под ОС Эльбрус можно пересобрать тулчейны для разработки например для STM32 или MSP430. Но здесь сам МК нужно покупать у «вероятного противника».
Так что получается, что в результате импортозамещения нет никакой разницы с этой точки зрения. Где-то здесь нарушена логика, т.к. логично что русский МК должен программироваться из русской ОС.
Читал на форуме Миландра, что они не занимаются разработкой инструментальных средств под Linux, но «интересуются данным направлением». Интересно, кто-нибудь здесь знает как у них обстоят дела с этим направлением сейчас?
Так что получается, что в результате импортозамещения нет никакой разницы с этой точки зрения. Где-то здесь нарушена логика, т.к. логично что русский МК должен программироваться из русской ОС.
Читал на форуме Миландра, что они не занимаются разработкой инструментальных средств под Linux, но «интересуются данным направлением». Интересно, кто-нибудь здесь знает как у них обстоят дела с этим направлением сейчас?
А в чем собственно проблема? Ядро там, как я понял, cortex-m3, который хорошо поддерживается в gcc, нужно только startup файл переписать и накатать ld скрипт для секций, после чего можно с минимальным напильником собирать код из Keil'а.
Да думается, никто бы не возражал, если бы дела обстояли так, что все дружно перебираются на своё ПО, потому что оно полностью написано и потому что оно самое-пресамое во всём белом свете. Но пока ж нету, так что о чём тут говорить?
Думается, можно на обычном gcc скомпилировать программу. Можно допилить какое-нибудь свободное ПО, чтобы оно составило конкуренцию ПО «вероятного противника». Можно даже внаглую не поддерживать вероятного противника рублём.
Конечно, будет совсем неплохо, если своими силами получится сделать среду разработки лучше, чем «зарубежные аналоги». Ещё лучше — если такой средой начнут пользоваться по всему миру, потому что она хорошая. Но думается, такие вещи в одночасье не делаются.
Думается, можно на обычном gcc скомпилировать программу. Можно допилить какое-нибудь свободное ПО, чтобы оно составило конкуренцию ПО «вероятного противника». Можно даже внаглую не поддерживать вероятного противника рублём.
Конечно, будет совсем неплохо, если своими силами получится сделать среду разработки лучше, чем «зарубежные аналоги». Ещё лучше — если такой средой начнут пользоваться по всему миру, потому что она хорошая. Но думается, такие вещи в одночасье не делаются.
> но проект с номером «2» так и не запустился, а в проекте «3» почему-то в меню выбора контроллера чистый лист. Это меня как-то насторожило. Проекта с номером «1» нет в принципе.
Напоминает анекдот про русского и два больших железных шара в пустой запертой комнате :)
Напоминает анекдот про русского и два больших железных шара в пустой запертой комнате :)
1. Вся статья написана в духе «это какое-то шаманство, но делайте так — и всё заработает», особенно вот эта фраза:
Надо было разорбраться и чётко написать, почему эти файлы и где используются. Вы уж определитесь, нужные это файлы или не нужные.
2. Магические числа, «непонятно откуда», но внезапно и удачно всплывающие имена полей структур… Больше напоминает первое знакомство человека с системой.
3. ИМХО очень плохой подход — копировать из библиотеки отдельные файлы для использования. Надо наоборот учить людей, что лучше подключать целую готовую библиотеку, желательно предварительно слинкованную статически! И не надо будет её каждый раз компилировать вместе со всем проектом. Неиспользуемые файлы исключать из списка компиляции Keil умеет, через свойства по ПКМ на файле.
Tutorial таким быть не должен.
А вообще, солидарен с мнениями комментаторов, что лучше под open-source IDE изучать разработку. Тем более, более универсальные среды. Сам пишу под все МК в Eclipse, в том числе под 1986ВЕ9х.
Сознательно не удаляю ту часть файлов, которую не использую, потому что некоторые важные файлы, хоть и косвенно, но ссылаются на них. Поэтому лучше скопировать все.
Надо было разорбраться и чётко написать, почему эти файлы и где используются. Вы уж определитесь, нужные это файлы или не нужные.
2. Магические числа, «непонятно откуда», но внезапно и удачно всплывающие имена полей структур… Больше напоминает первое знакомство человека с системой.
3. ИМХО очень плохой подход — копировать из библиотеки отдельные файлы для использования. Надо наоборот учить людей, что лучше подключать целую готовую библиотеку, желательно предварительно слинкованную статически! И не надо будет её каждый раз компилировать вместе со всем проектом. Неиспользуемые файлы исключать из списка компиляции Keil умеет, через свойства по ПКМ на файле.
Tutorial таким быть не должен.
А вообще, солидарен с мнениями комментаторов, что лучше под open-source IDE изучать разработку. Тем более, более универсальные среды. Сам пишу под все МК в Eclipse, в том числе под 1986ВЕ9х.
Не смотря на то, что в целом с вами согласен думаю не стоит судить автора так строго. Он и так копнул весьма глубоко и честно предупреждал что это его первое знакомство с прибором. Для первого знакомства он пожалуй даже слишком всё подробно описал.
Понятно что нет смысла писать свою среду разработки, но вот помочь разработчикам с работой под Eclipse Миландр вполне мог бы. Не так много ресурсов на это требуется.
Понятно что нет смысла писать свою среду разработки, но вот помочь разработчикам с работой под Eclipse Миландр вполне мог бы. Не так много ресурсов на это требуется.
Заинтересовал данный МК. Решил у производителя спросить как можно купить данный чип, т.к. у их партнеров в Терраэлектронике данный чип не выставлен на продажу. Оказалось что пока никак не возможно купить чип. Фабрика которая делает пластиковые корпуса пока задерживает производство. И ближайшая партия ожидается в июне-июле. Жаль. Кстати стоимость МК у официального торгового дома «Миландр ЭК» — всего 165 рублей — очень заманчиво для промпроизводителей мне кажется — вот их прайс.
А Вас, уважаемый, не смущает дата, указанная на этом прайсе? Осень 2013 года. А так же то что в 2014 году надо было ждать пол года чтобы получить всего навсего один экземпляр из этого прайса по цене в два раза выше, да ещё долго объяснять зачем он нужен?
Вы видно мало имели дел с нашими производителями. Я работал бренд менеджером в фирме торгующими электронными компонентами и у меня есть очень хорошие знакомые в службе продаж Ангстрема. Вы даже представить себе не можете насколько разные подходы у первых и вторых. Я ещё мы как то раз пробовали заложить в наши изделия керамические резонаторы от того же Ангстрема, которые тоже были в прайсе и по весьма хорошей цене. Кстати и качество было удовлетворительное. Не хочу даже вспоминать, что из этого вышло.
Честно говоря я буду очень рад, если вы заложите эти контроллеры в своё изделие. Уверен что после этого на Хабре появится очень интересная статья.
Вы видно мало имели дел с нашими производителями. Я работал бренд менеджером в фирме торгующими электронными компонентами и у меня есть очень хорошие знакомые в службе продаж Ангстрема. Вы даже представить себе не можете насколько разные подходы у первых и вторых. Я ещё мы как то раз пробовали заложить в наши изделия керамические резонаторы от того же Ангстрема, которые тоже были в прайсе и по весьма хорошей цене. Кстати и качество было удовлетворительное. Не хочу даже вспоминать, что из этого вышло.
Честно говоря я буду очень рад, если вы заложите эти контроллеры в своё изделие. Уверен что после этого на Хабре появится очень интересная статья.
1. Вся статья написана в духе «это какое-то шаманство, но делайте так — и всё заработает», особенно вот эта фраза:
Сознательно не удаляю ту часть файлов, которую не использую, потому что некоторые важные файлы, хоть и косвенно, но ссылаются на них. Поэтому лучше скопировать все.
Да, действительно. Звучит не очень хорошо. Исправил.
2. Магические числа, «непонятно откуда», но внезапно и удачно всплывающие имена полей структур… Больше напоминает первое знакомство человека с системой.
Честно сказать, про эту фичу нигде ранее не читал (ни в одном уроке, во время изучения мною STM32, об этом написано не было). Поэтому решил напомнить о ней. Посчитал, что лишним не будет.
3. ИМХО очень плохой подход — копировать из библиотеки отдельные файлы для использования. Надо наоборот учить людей, что лучше подключать целую готовую библиотеку, желательно предварительно слинкованную статически! И не надо будет её каждый раз компилировать вместе со всем проектом. Неиспользуемые файлы исключать из списка компиляции Keil умеет, через свойства по ПКМ на файле.
Исправил. Сообщил, что копируем всю библиотеку. Объяснил, за что отвечает каждый добавленный файл.
желательно предварительно слинкованную статически!
После того, как 1 раз компилируешь проект — библиотеки при последующей компиляции не изменяются.
Tutorial таким быть не должен.
Только начинаю писать. Просто не хочется, чтобы накопленный опыт пропал. Рад любым правкам.
Просто так случается, что со временем забываешь, как работают собственные библиотеки… И когда-то очевидные вещи кажутся ужасно непонятными. Это одна из причин написания этой серии статей.
А вообще, солидарен с мнениями комментаторов, что лучше под open-source IDE изучать разработку. Тем более, более универсальные среды. Сам пишу под все МК в Eclipse, в том числе под 1986ВЕ9х.
Мне очень по душе Keil. Чем-то он пленил меня. С Eclipse так и не смог наладить контакт. Но это уже индивидуальные особенности. Keil не накладывает ограничений на обучение. 32-х киллобайт вполне хватает на то, чтобы беспрепятственно изучить контроллер и начать разрабатывать интересные вещи.
В последующих статья постараюсь излагать материал менее эмоционально, более сжато и понятно.
Keil мне тоже очень нравится. Только в этом году от него отказался.
Однако на сколько я помню в бесплатной версии не работает симулятор, а ведь это главная его фишка, ради которой я им и пользовался. Можно отладить большую часть программы и проверить правильность конфигурации без использования внутрисхемного отладчика, не имея даже камня на руках.
Что касается совета всегда использовать библиотеки только в полном составе мне он кажется спорным.
Однако на сколько я помню в бесплатной версии не работает симулятор, а ведь это главная его фишка, ради которой я им и пользовался. Можно отладить большую часть программы и проверить правильность конфигурации без использования внутрисхемного отладчика, не имея даже камня на руках.
Что касается совета всегда использовать библиотеки только в полном составе мне он кажется спорным.
Однако на сколько я помню в бесплатной версии не работает симулятор
Не правда. Работает. И очень даже хорошо. В статье про тактирование микроконтроллера (сегодня постараюсь дописать и выложить), будет сказано об отладке.
С тех пор, как попробовал Eclipse, вспоминаю IAR и Keil как страшный сон. Конечно, компилятор в IAR, а симулятор в Keil неподражаемы. Eclipse не может их заменить. Если программная часть проекта небольшая, то все ок. Но для больших проектов Eclipse гораздо удобнее.
Здорово что стали появляться такие статьи.
Один нюанс — надо внимательно смотреть на каком порту хотим мигать светодиодом.
Если этот порт используется для JTAG\SW (порты F и D) — даже если пин светодиода не пересекается с пинами JTAG, после первого мигания заливка прошивки и отладка по этому порту станет невозможна.
Чтобы такого не случилось, на форуме Миландра предлагают такой способ:
Способ рабочий, хотя несколько некрасивый. 31 — это 0b11111, то есть надо писать нули во все пины, относящиеся к JTAG/
Если все-таки JTAG порт умер — что делать:
1. Тогда может пригодится другой JTAG порт. Если он не разведен на плате, можно припаяться только к ножкам SW на другом порту (меньше возни)
2. Залить прошивку через UART (штатный загрузчик)
3. Использовать особенности зашитой программы — успеть прошить новую заливку после подачи питания до первого мигания. В варианте автора это практически невозможно. В реальных программах часто программа запускается от внутреннего генератора, затем инициализируется внешний кварц. Если при этом используется бесконечный цикл ожидания — можно отпаять кварц и прошиться до первого мигания.
В этом примере используются функции библиотеки Миландра для своих микроконтроллеров (есть на их сайте).
Инициализация портов с использованием этой библиотеки несколько отличается от решения автора статьи. Как пример:
Один нюанс — надо внимательно смотреть на каком порту хотим мигать светодиодом.
Если этот порт используется для JTAG\SW (порты F и D) — даже если пин светодиода не пересекается с пинами JTAG, после первого мигания заливка прошивки и отладка по этому порту станет невозможна.
Чтобы такого не случилось, на форуме Миландра предлагают такой способ:
temp = MDR_PORTD->RXTX;
temp &= ~(31);
temp&=~( PORT_Pin_10 );
MDR_PORTD->RXTX=temp;
Способ рабочий, хотя несколько некрасивый. 31 — это 0b11111, то есть надо писать нули во все пины, относящиеся к JTAG/
Если все-таки JTAG порт умер — что делать:
1. Тогда может пригодится другой JTAG порт. Если он не разведен на плате, можно припаяться только к ножкам SW на другом порту (меньше возни)
2. Залить прошивку через UART (штатный загрузчик)
3. Использовать особенности зашитой программы — успеть прошить новую заливку после подачи питания до первого мигания. В варианте автора это практически невозможно. В реальных программах часто программа запускается от внутреннего генератора, затем инициализируется внешний кварц. Если при этом используется бесконечный цикл ожидания — можно отпаять кварц и прошиться до первого мигания.
/* Enable HSE */
RST_CLK_HSEconfig(RST_CLK_HSE_ON); // включили генератор на кварце
while (RST_CLK_HSEstatus() != SUCCESS) { }
В этом примере используются функции библиотеки Миландра для своих микроконтроллеров (есть на их сайте).
Инициализация портов с использованием этой библиотеки несколько отличается от решения автора статьи. Как пример:
PORT_InitStructure.PORT_PULL_UP = PORT_PULL_UP_ON;
PORT_InitStructure.PORT_PULL_DOWN = PORT_PULL_DOWN_ON;
PORT_InitStructure.PORT_PD_SHM = PORT_PD_SHM_OFF;
PORT_InitStructure.PORT_PD = PORT_PD_DRIVER;
PORT_InitStructure.PORT_GFEN = PORT_GFEN_OFF;
PORT_InitStructure.PORT_FUNC = PORT_FUNC_PORT;
PORT_InitStructure.PORT_SPEED = PORT_SPEED_MAXFAST;
PORT_InitStructure.PORT_MODE = PORT_MODE_DIGITAL;
PORT_InitStructure.PORT_OE = PORT_OE_OUT;
PORT_InitStructure.PORT_OE = PORT_OE_OUT;
PORT_InitStructure.PORT_Pin = PORT_Pin_10;
PORT_Init(MDR_PORTC, &PORT_InitStructure);
Огромное спасибо за информацию. Обязательно учту это в одной из следующих статей. Но в данном случае речь идет о порте C. Так что можно ничего не бояться. Возможно, вы спасли меня от моря ошибок и многих дней для их поиска.
А разве нельзя в случае подобных проблем поменять конфигурацию BOOT0 и BOOT1 джамперами/переключателями, а потом подать питание, после чего камень запустит неизменяемый загрузчик, и прошиться в этом режиме?
UFO just landed and posted this here
Sign up to leave a comment.
Переходим с STM32 на российский микроконтроллер К1986ВЕ92QI. Настройка проекта в keil и мигание светодиодом