Программирование микроконтроллеров *

В предыдущем своем посте я попытался коротко ознакомить вас с платформой Nucleo от ST.
В этом посте я хочу рассказать вам на живом примере некоторые сильные стороны этой платформы, которая имеет все шансы потеснить приевшиеся всем Arduino, и показать что все примеры кода и шилды от Arduino, прекрасно подходят для платформы Nucleo.

Оценочные платы ST Nucleo:



Это открытая, недорогая и легко расширяемая отладочная платформа для разработки с широким выбором специальных плат расширения, для всей линейки 32-х битных микроконтроллеров STM32 архитектуры ARM Cortex-M3 и Cortex-M4.



Платы «ST Nucleo» дают возможность выбирать из различных сочетаний производительность, энергопотребление, и архитектурные особенности микроконтроллера. Платформа позволяет быстро, удобно и легко изучить особенности архитектуры и программирования микроконтроллера, опробовать свои идеи, создать прототипы с любым микроконтроллером семейства STM32.

Наша компания успешно использовала некоторое время чипы серии DSM компании STmicroelectronics — DSM2150F5V. Это микросхема в корпусе TQFP80, которая предназначена для совместной работы вместе с сигнальными процессорами DSP Blackfin компании Analog Devices. Мы эту микросхемку именно так и использовали. В составе DSM2150F5V находятся сразу и FLASH-память для программы, откуда может загрузиться DSP, и программируемая логика, которую можно использовать для каких-то дополнительных функций. Как написано в даташите (который найти в Интернете становится все труднее и труднее, об этом далее), DSM2150F5V специально предназначена для упрощения подключения памяти, внешней логики, портов ввода/вывода к DSP-процессорам Analog Devices семейств ADSP-218x, 219x, 2106x, 2116x, 2153x и TS101. Все в одном, удобная микросхема.



Все было здорово и хорошо, делали мы на микросхеме DSM2150F5V свои приборы и радовались. Но в один не очень прекрасный день к нам пришел снабженец и сообщил, что микросхему DSM2150F5V купить невозможно, никто её больше не продает.

Введение

Т.к. предыдущая статья вызвала интерес, то, как я и обещал, в этой статье будут рассмотрены примеры работы с семисегментными индикаторами, встроенным АЦП, а также произведена сборка программного проекта цифрового термометра на ATmega16 из нескольких рассмотренных в данной и предыдущей статье примеров работы с внутренними периферийными блоками микроконтроллера ATmega16.

Понимаю, что заголовок выглядит как машинный перевод, но лучшего эквивалента " Top 10 Bug-Killing Coding Standard Rules " придумать не смог.

10 главных правил по избеганию багов — подсказали в комментах

Данный пост представляет собой вольный пересказ ключевых понятий книги Michael Barr «Embedded C Coding Standard», изложенных в его выступлении на вебинаре в июне этого года (не знаю как поставить тэг «перевод»).
Часть правил применима только к C++ и расширениям C, а часть и к стандарту языка.

Приветствую всех.
В первой части была рассмотрена концепция самой инфо-панели, которую я собираю для офиса (где, напомню, затруднён нормальный мониторинг за некоторыми серверами, в том числе, из-за топологии сети — серая подсеть с частью важного оборудования, которому не требуется выход в интернет, но от его работы зависит работоспособность услуг телефонии, в частности, TDM и E1).
Теперь накопилось достаточно материала для продолжения темы.

Вот так выглядят индикаторы:



В окончании проекта будет приведён весь код с пояснениями.
Код распространяется по лицензии WTFPL.
За информацию по лицензии, а так же за код для Ethernet модуля ENC28J60 ещё одно спасибо Lifelover.

Проект ещё не закончен, далее будет продолжение.

К сожалению, на текущий момент устройство ещё не собрано, и пришлось довольно много ждать (при разработке столкнулся с неприятными трудностями как при изготовлении плат, так и при закупке некоторых расходников).
Готовы модули индикации (2 из 3), хотя работать можно и только с ними. Частично собрана «библиотека» работы с LED-дисплеем.
Пока нет интерфейса взаимодействия между двумя контроллерами (здесь вопрос к хабровчанам, как сделать лучше — сам склоняюсь к реализации через UART).

Кого заинтересовал — добро пожаловать под кат.
Предупреждение: Много фото.

Иногда мне приходят в голову интересные идеи о том, разработкой какого устройства можно было бы заняться, если бы нашёлся заказчик и потребитель. Иногда — это примерно раз в час. Эти идеи не дают мне спать, не дают работать. Я прикладываю нечеловеческие усилия, чтобы остаться в рамках задач, по которым заключены контракты. Я использовал разные способы, чтобы отвлечься от этих идей: рассказывал их самому большому критику из тех, что я знаю; заставлял себя детально просчитывать стоимость реализации каждой новой идеи, клал под подушку старые MCS51-ые…, но ничего не помогает.

И вот я хочу опробовать очередной способ: рассказать о своих идеях и мыслях на Хабре.

Приветствую!

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

С чего все начиналось

Изначально мы занимались разработкой программного обеспечения для чип-тюнинга. Одна из основных задач которого — считать прошивку из ЭБУ (электронный блок управления двигателем) и записать ее обратно. Понятное дело, что для этих целей нужно каким-то образом связать компьютер и ЭБУ при помощи адаптера. Когда раньше подавляющее количество ЭБУ использовало простейший способ приема-передачи данных, достаточно было использовать простейший адаптер на транзисторах или специализированной микросхеме. Однако на сегодняшний день большинство автомобилей для «общения» своих компонентов со внешней средой используют CAN шину. Адаптер для CAN шины на транзисторах уже не соберешь, и тут однозначно нужен процессор, который будет управлять всем по определенной программе.
Так возникла первая проблема — как побороть CAN шину. Для того, чтобы не изобретать велосипед выбор сделан на использовании готового адаптера, который работает по стандарту J2534. Для тех, кто не в курсе, стандарт J2534 это стандарт, описывающий аппаратную и программную части устройства, с помощью которого можно произвести подключение к ЭБУ посредством компьютера. Разработали его американцы. Основной причиной его разработки стало законодательное закрепление возможности обновление прошивки ЭБУ не специализированным дилерским сервисом, а любым желающим. Собственно, если каждый желающий может обновить прошивку на своем телефоне, то почему он не может это сделать со своим автомобилем.

Самый доступный импортный аналог стоит в районе 200 долл. США. Как впоследствии оказалось, два одинаковых устройства, удовлетворяющие стандарту J2534, могут работать по-разному с одним и тем же программным обеспечением. Поэтому изначально пришлось привязаться к конкретному производителю и его устройству.

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

На днях, в прцессе портирования FreeRTOS на микроконтроллер с ядром Cortex-M1, о котором я уже писал, возник маленький вопрос, который совершенно неожиденно яростно сопротивлялся всем попыткам найти на него ответ при помощи ГУГЛА всемогущего. Причем в процессе поиска выяснилось, что этот вопрос интересовал не меня одного, а, значит, не может быть следствием врожденной (либо приобретенной) тупости вопрошающего, ну или, в крайнем случае, свидетельствует, что таковая встречается не столь уж редко. Слегка озадаченный невозможностью применить обычный способ поиска ответов, решил прибегнуть к более экзотическому и слегка забытому — подумать и найти ответ самостоятельно. К сожалению, тоже не получилось, равно как не помогла и попытка проконсультироваться с другими неглупыми людьми (сам себя не похвалишь — весь день ходишь как оплеванный). Поскольку на Хабре таковых должно быть в избытке, попробуем экстенсивный путь решения путем вовлечения в этот процесс еще большего количества специалистов. Поэтому вместо победного поста пишу пост жалобный — помогите, люди добрые, кто чем может. Итак, переходим к сути проблемы.

Не все так плохо, как могло бы быть, но не столь хорошо, как хотелось бы.

Прежде, чем приступить к рассмотрению реализации драйверов различных устройств в МК, хотелось бы определиться с объектом, на котором мы вышеупомянутую реализация будем осуществлять. Конечно, можно рассмотреть сферический МК в вакууме, но в этом случае любое неудобство, приводящее к особенностям реализации программы, будет рассматриваться, как нечто искусственно созданное. Если же принять за базовый идеальный МК (если бы я умел их создавать, то наверняка давно бы этим занялся), то для него написание какой-либо программы вообще не представляет никакой трудности и сводится к двум командам: 1) пойми мысли разработчика и 2) сделай это. Поэтому какой-то реальный МК в качестве базового весьма желателен, причем то, насколько он далек от идеала, станет мерилом ценности разработанного ПО (раз оно устойчиво работает на этом МК, перенести его на любой более совершенный нетрудно — сильное утверждение, но примем его без доказательства).

Тема данного поста образовалась почти случайно, в процессе легкой дискуссии по поводу подходов к разработке програмного обеспечения в частности и устройств на МК в общем. Желающие могут ознакомится с самой дискуссией habrahabr.ru/company/coolrf/blog/222801. Хотя обе стороны явно остались при своем мнении, тем не менее определенный вызов был брошен. Я вызовов не боюсь, любой челлендж уже сам по себе хорош, поскольку отвечая на него, ты в чем-то меняешься и, как правило, в лучшую сторону (вариант типа «а слабо выпить 10 литров пива за раз», который очевидно меняет человека НЕ в лучшую сторону, в моем возрасте уже не прокатывает). Итак, мы начинаем.

Все хорошо, что хорошо кончается

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

Введение

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

Однажды я решил сделать подарок своей любимой девушке. Для этого вооружился я паяльником, программатором и компьютером. И, как художник, сотворил светодиодное сердце. Чтобы сердце было особенным, я постарался реализовать всевозможные режимы мигания светодиодами.

Давно думал написать статью на Хабр, но все как-то не решался. Хотя и кажется, что есть мысли, которые были бы небезинтересны сообществу, но останавливает предположение, что это «кажется» проистекает от завышенной самооценки. Тем не менее попробую. Поскольку я профессионально занимаюсь электроникой, в частности, программированием микроконтроллеров, довольно-таки длительное время (как я подозреваю, дольше, чем живет большАя а может даже и бОльшая часть читателей Хабра), то за это время накопилось изрядное количество интересных случаев. Представляю на суд сообщества рассказ об одном из них.

Итак, в одной разработке мне потребовалось сохранять значительные объемы информации с целью последующей передачи через сеть в обрабатывающий центр. Поскольку полученное устройство предполагало серийное производство, был выбран вариант с применением относительно недорогих компонентов, и, в частности, микроконтроллера как центрального элемента системы. Поскольку в тот момент (середина 2012 года) предложение микроконтроллеров с Ethernet PHY на борту не отличалось разнообразием (да и сейчас положение не намного лучше), был выбран МК фирмы TI семейства Stellaris, конкретно LM3S8962, тем более что отладочная плата для него у меня уже имелась. МК на тот момент относительно новый, активно продвигаемый фирмой TI (это в конце 2013 года она ВНЕЗАПНО перевела всю серию в разряд NRND), и обладающий вполне достаточными для решения данной задачи параметрами. Для хранения информациии был выбран вариант с SD карточкой, в первую очередь из за их доступности и дешевизны, а также потому, что на отладочной плате наличествовало контактное устройство для них, а на поставляемом с платой отладки CD имелись многочисленные примеры, в том числе и для SD карт. Интерфейс к карточке был реализован простейший — SPI, предложенные примеры сходу заработали, принятое решение позволяло обрабатывать полученные данные до написания интерфейса при помощи элементарного переноса карточки из устройства в кард-ридер ПК, так что первоначальная отладка алгоритмов взаимодействия с объектом управления проблем не вызвало, по крайней мере в этой части проекта. Как все понимают, проблемы возникли несколько позже…

Данная статья является продолжением цикла по программированию микроконтроллеров на базе ядра Cortex-M.
Первую статью можно прочитать здесь:
Начинаем изучать Cortex-M на примере STM32
Задачей статей является подробное описание особенностей, возникающих при программировании МК. Материал не предназначен для желающих за 10 минут запустить пример мигания светодиодом. Я постараюсь подробно описать то, что часто скрывают от новичков, чтобы их не напугать.

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

Основной акцент сделан на изучение документации на ядро Cortex-M и документации на конкретный контроллер.
На этот раз речь пойдет про прерывания, а так же будут затронуты некоторые вопросы архитектуры памяти и структуры прошивки МК.

Здравствуйте, обитатели Хабра. В этой статье хочу поделится своими впечатлениями об опыте программирования микроконтроллеров семейств AVR, MSP430, STM32.

Введение

В бытность мою студентом занимался я прикладным программированием на Delphi и горя не знал, но и счастья не ведал. Пока как-то раз не посетил меня на четвертом курсе предмет «Микропроцессорные контроллеры». Ну и пошло-поехало.

Когда-то давно я написал статью о принципах проектирования приложения для встраиваемых систем. Тогда я сказал, что есть два основных принципа — бесконечный цикл и ОС реального времени. А вот совсем недавно услышал, что есть еще и третий подход — так называемый Time Triggered Design.

В качестве ознакомления с подходом был использована книга «Patterns for time-triggered embedded systems» автора Michael J. Pont, для заинтересовавшихся — www.safetty.net/publications/pttes
Попытаюсь здесь коротко изложить концепцию.

Ingenic представила крошечный, основанный на MIPS, Newton COM для носимых компьютеров и IoT-устройств, работающих на Android или Linux под Xburst SoC, и с встроенными модулем WiFi и другими сенсорами.

О платформе «компьютер на модуле» от Newton сообщили как китайская полупроводниковая компания Ingenic Semiconductor, так и Imagination Technologies, которая лицензирует интеллектуальную собственность MIPS для Ingenic. Сообщение Imagination относилось только к носимым компьютерам, а Ingenic упомянула их только как первые в ряду приложений Internet of Things (IoT).

Кроме того, Newton может применяться в здравоохранении, бытовой технике, сфере безопасности, биометрии, промышленного контроля и потребительской электроники. Imagination также рассчитывает на применение Newton в качестве платформы для нового Android Wear от Google, хотя Ingenic об этом не упомянула.

Данная статья является первой в планируемом цикле статей по изучению программирования микроконтроллеров. Изучая различные материалы я отметил, что практически все они начинаются с того, что новичку предлагается скачать (или использовать идущую со средой разработки) библиотеку для работы с периферийными устройствами и использовать ее для написания своей первой программы (обычно мигание светодиодом).

Меня это сильно удивило. Если верить данным статьям, для программирования не обязательно даже читать документацию к программируемому контроллеру. Меня же учили премудростям «железного программирования» совершенно иначе.

В этой статье, путь от фразы «Да, я хочу попробовать!» до радостного подмигивания светодиода, будет значительно длиннее чем у других авторов. Я постараюсь раскрыть аспекты программирования микроконтроллеров, которые прячутся за использованием библиотечных функций и готовых примеров.
Если вы намерены серьезно изучать программирование микроконтроллеров данная статья для вас. Возможно, она может заинтересовать и тех, кто вдоволь наигрался с Arduino и хочет получить в свои руки все аппаратные возможности железа.