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

«Жуки, жуки, жуки» — всхрапывая, приговаривал во сне Пумба, и они ему снились!

Всем известно, что при написании многопотоковых приложений следует быть особенно внимательными к возможным «гонкам» в момент изменения совместно используемых рзличными потоками переменных. Причем также существует мнение, что подобные гонки весьма редки и по этой причине весьма трудно-обнаружимы, почему и склонны возникать в редких ситуациях и приводить к непредсказуемому поведению, а то и к краху системы. Если с последними утверждениями придется согласиться, то с первым я в настоящем посте намерен поспорить и показать, что процесс проявления возможных неприятностей можно интенсифицировать, что делает и более легким задачу определения причин их появления и устранения оных. Основная идея подобной интенсификации — применение параллельных вычислений на многоядерных системах.

Знал бы где упадешь, соломки подстелил бы

О существовании DMA (Direct Memory Access) — русскоязычное ПДП (Прямой Доступ к Памяти) многие разработчики встроенных устройств слышали, но вот применяют его гораздо реже, чем он (ПДП) этого заслуживает. Кстати, я буду упоминать именно эту аббревиатуру, но не потому, что я такой упрямый патриот и противник англоязычных заимствований, а всего лишь от того, что мне лень лишний раз переключать раскладку клавиатуры.

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

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

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

Предлагаю вашему вниманию устройство для автоматического полива цветов на базе микроконтроллера Attiny13a, подробности под катом.

Ни для кого не секрет что одним из основных интересов вывода информации у приборов является дисплей. В основном на МК подключат символьные дисплеи на основе hd44780. Редким исключением составляется графические дисплеи графические дисплеи WG12864A разрешением 128*64. Но что делать если нужно больше.

Однажды попался мне заказ оцифровать сигнал. Частота дискретизации сигнала была 50кГц. С этой задачей я быстро справился используя мануал из интернета. Однако вскре заказчик не смог выжать из этой скорсти то что ему хотелось и он решил объявил заказ на частоту 50МГц. В связи с тем что частота изменения сигнала от 0 до 5В была не более 10 МГц то я решил что про скин-эффект не стоит заморачиваться и взялся за заказ.

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

Тематику этого поста навеяла рассылка от Шерлока Омса — периодически там размещаются истории о нетривиальных инженерных задачах, возникших при диагностировании различных электронных устройств. Вот и подумалось, а почему бы и нет? Хотя прекрасно понимаю, что тематика достаточно специфическая, требует вполне конкретных узкоспециализированных знаний и вряд ли будет интересна широкому кругу читателей, но нескольно приятных минут узкому кругу ценителей аппаратных загадок способна доставить. Итак для тех, кто знает, что такое шина данных и как она устроена — история, в которой будут

Начну с предыстории, зачем же мне все это нужно. Я задался целью сделать себе HTPC компьютер на базе корпуса от DVD плеера Daewoo DV-500, внешне он мне нравится, и свободного места в нем достаточно для установки необходимого железа внутрь. Но помимо всего, я задумал оставить родной индикатор и задействовать его для отображения различной информации. О том, как я подключал дисплей к микроконтроллеру и расшифровывал протокол обмена этого дисплея, пойдет в этой статье.

В предыдущем своем посте я попытался коротко ознакомить вас с платформой 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-отлдака позволяет забраться во внутрь, посмотреть как выполняется программа по шагам, посмотреть, что происходит в памяти и регистрах, запустить волнение до точек останова, выполнять дизассемблированный вариант программы. Эта возможность позволяет значительно ускорить обучение.