«Имея ввиду какое-либо предприятие, помысли, точно ли оно тебе удастся»

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

«Осторожно, там обитает математика».

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

Вопросы оптимизации программ, производящих значительное количество вычислений, к сожалению, недостаточно хорошо освещены в литературе и, как правило, сводятся в некоторым общим принципам, верность которых совершенно не очевидна ни до прочтения аргументов автора, не даже после. Поскольку в упомянутом посте (ищите по закавыченным словам) была предложена не-безынтересная вычислительная задача, которая позволяет продемонстрировать эти принципы и конкретные приемы оптимизации в действии, и был создан настоящий пост, который, хоть и несколько отклоняется от направления, излюбленного автором (я вполне себе вижу решение данной задачи на МК класса М3 и даже Ардуино, попробуйте, но все таки микроконтроллеры предназначены несколько для других целей), но тем не менее вписывается в концепцию курса по программированию МК.

Итак, мы начинаем.

«Если не знаешь, с чего начать, начни сначала, скорее всего, не ошибешься».

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

Путь в десять тысяч ли начинается с первого шага.

Преамбула

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

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

Поскольку мы будем изучать правильную разработку, нам потребуется контр-пример, так как нет ничего проще, чем показывать чужие ошибки, поэтому в качестве отправной точки будет взята известная реализация упомянутого протокола, а именно FREEMODBUS. Не останавливаясь на вопросах функционирования, стиль данного программного продукта мне не представляется идеальным и я постараюсь показать, как его можно улучшить.

Жизнь настолько коротка, что ее едва хватает на то, чтобы совершить необходимое количество ошибок, а уж повторять их — недопустимая роскошь.

В данном посте речь пойдет о том, чтобы не повторять чужих ошибок, что тоже является непроизводительной растратой столь ценного ресурса, как время. И вроде бы ошибка не столь фатальна и есть масса примеров, где она исключена и можно было бы давно научиться ее избегать, но почему то с упорством, достойным лучшего применения, она встречается вновь и вновь в исходных кодах программ для МК (может быть и для больших систем тоже, но я ими не занимаюсь), причем авторы данных программ не то чтоб новички во встроенном программировании, но тем не менее мы видим то, что видим. Искренне надеюсь, что после того, как данный пост будет Вами прочитан (при попытке ввести сочетание «после прочтения» в строго определенном месте текста у меня 6 раз падал Word To Go — впервые за 2 года использования, так что я смирился и написал чуть по другому — это к вопросу об ошибках, хотя данное поведение вряд ли проистекает именно из за той, о которой я пишу, иначе это было бы особенно пикантно). Вы навсегда поймете недопустимость подобной ошибочной конструкции и не наступите именно на эти грабли, ведь вокруг лежит такое количество других, ожидающих своей очереди.

Даже неверное решение, проведенное в жизнь с должной последовательностью и энергией, приводит к успеху

Для начала о том, чего в этом посте не будет. Здесь не будет рассказа о том, как легко написать программу для мигания светодиодами. Здесь не будет сведений о том, где и по какой цене Вы можете купить замечательные платы некоей чудесной фирмы. Здесь не будет рассказа о том, какое голубое небо было до появления этого исчадия ада, и как все теперь плохо. Здесь не будет также рассказа о том, в каком хаосе пребывала отрасль до появления такого чудесного решения, и как все стало хорошо. Здесь даже не будет картинок для привлечения внимания. За всем этим не сюда, подобных постов на Хабре хватает и без того (ни в коей мере не пытаюсь обидеть их авторов, но я пишу несколько о другом).

Здесь будет попытка понять, для чего нужна Ардуино (А), как именно она делалась, какими методами решались различные проблемы, и где их (методы решения) можно было бы постараться улучшить. Несомненно, тут будет большое количество оценочных суждений, субъективного взгляда, вкусовщины, и прочих прелестей, связанных с обсуждением неординарной проблемы. Ну и будут рассуждения на тему, почему А не всегда и не везде торт и как ее (А) в него (торт) превратить (если смотреть на это дело с правильной, то есть моей, стороны).

Дню знаний посвящается...

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

Вы спросите, а что, собственно, тут рассматривать? Функции работы с портами прописаны ясно, есть большое количество примеров, поэтому использование портов не представляет никакой сложности. Начальная программа мигания светодиодом использует эти функции и прекрасно работает, о чем речь?

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

Несмотря на то, что в их ответе есть толика истины, тем не менее такой ответ далеко не полон, в чем то не совсем верен (посмотрите, как именно они рекомендуют работать с регистрами), не вполне оптимален, и не слишком понятен. Заполнить пространство между стандартными скетчами и подобным ответом и предназначен настоящий пост.

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

Этот рассказ мы с загадки начнем,
Даже Алиса ответит едва ли,
Что остается от сказки потом,
После того, как ее рассказали?

Данное эссе будет посвящено различным темам, среди которых найдется место и ответу на вопрос, вынесенный в подзаголовок, а развиваться повествование будет в основном вокруг да около проблем, связанных с инициализацией периферии современного МК.
Итак, обозначим основные проблемы, связанные с настройкой аппаратной части МК: необходимость задания значительного количества параметров, из которых бОльшая часть не задается в каждом конкретном случае, но, тем не менее, не может быть оставлена произвольной, а должна принимать некоторые пред-определенные значения. Если Вы верите, что такая простая постановка задачи способна вызвать поток сознания и привести к некоторым не вполне очевидным решениям, то

Когда б Вы знали, из какого сора
растут стихи, не ведая стыда ...

Тема данного поста возникла совершенно неожиданно, в процессе чтения книги «Real-Time C++», более конкретно в процессе чтения раздела 6.13, в котором рассматривалось построение делителя измеряемого напряжения таким образом, чтобы получившийся результат легко (с применением только операции сдвига) масштабировался. Так вот, в конце раздела на странице 121 приводилась формула для оценки погрешности получаемой величины, которая привела меня в некоторое замешательство. Поскольку данную книгу «могут увидеть дети» и получить непоправимую травму психики, если некритично отнесутся к написанному, мною и создан настоящий пост с целью привнести определенный порядок в понимание методики оценки погрешностей измерений молодыми инженерами.

Вот две строки, я гений, прочь сомненья
Даешь восторги, лавры и цветы…

Данный пост посвящен довольно таки старой задаче о считывании таймера, с которой лично я ознакомился в книге Джека Гансли (The Art of Designing Embedded Systems (Second Edition), (2008) by Jack Ganssle) в которой рассматривается борьба с гонками в асинхронных устройства. Сформулирована проблема и показаны 4 способа ее решения (2 неправильных и 2 правильных), рассмотрены их недостатки, в общем, добротная работа в стиле Джека (я к нему отношусь очень хорошо). К сожалению, на мой взгляд, даже работающие решения не имели должной степени элегантности, но более красивое долго не приходило в голову, а вчера неожиданно осенило. Так что я считаю себя вправе изложить данную проблему в ее историческом контексте, поскольку придумал очень элегантное решение (сам себя не похвалишь, весь день ходишь как оплеванный).

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

История эта началась с проектирования переносного устройства, в котором было желательно уменьшить потребление от аккумулятора в режиме отключения, но механический переключатель был неприемлем в силу конструктивных особенностей. Также было нежелательно использовать транзистор в качестве ключа ввиду значительных рабочих токов устройства (более 3А). Поэтому было принято распространенное решение о блокировке работы входящих в состав устройства источников питания (ИП) при помощи управления сигналом разрешения работы. Ничего нового и необычного, таких схем можно найти 12 на дюжину в устройствах с автономным питанием, однако совершенно неожиданно возникли определенные осложнения, которые привели к ряду поучительных выводов.

«и доказал, что поскольку… то схема на частотах требуемого диапазона работать не будет» Савченко «Открытие себя»

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

«Если рассматривать шкалу духовных ценностей по нисходящей, существуют
Вещи В Порядке Вещей, существуют
Вещи Неприятные, Но В Принципе Допустимые, и существуют
Вещи, Которые Терпеть Никак Нельзя». — Мидянин

Как говорил небезызвестный классик «Не могу молчать».
Недавно смотрел исходные тексты на сайте довольно-таки известного производителя и увидел следующий код

*(unsigned int *)0xf80ff000 &= 0xffffefff;

Не надеясь, что эти заметки прочтут в далекой «Индии» (смотри примечание ниже) (складывается ощущение, что они и читать то не умеют), тем не менее хотел бы предостеречь молодых инженеров — так делать НЕЛЬЗЯ.

Примечание от сегодняшнего дня — набросал этот пост больше месяца назад, все руки не доходили довести его до приемлемого вида, так что источник указать не могу, ну да Инет Вам в помощь — подобного кода там чуть меньше, чем очень много.

Несколько лет назад поставщик компиляторов Keil (теперь принадлежит ARM) поместил объявление в Embedded Systems Programming magazine (позже известный как Embedded Systems Design, а сейчас embedded.com) о своем новом компиляторе: COBOL для 8051.
Это была шутка, и размещена она была в апрельском номере. Какой смешная и абсурдная идея продукта! COBOL для встраиваемых систем? И COBOL для 8051! Я позвонил президенту компании и поздравил его с отличной шуткой.
А он ответил мне, что они получили запросы на поставку!

Фирма АРМ продала более 200 лицензий на ядра Cortex-M, и на рынке представлены тысячи вариантов этих устройств. Хотя фирма создала ядро M7 в прошлом году, которое предлагает невероятную производительность для MCU, начальный уровень линейки ядер продолжает представлять огромный интерес для производителей. Реализация ядра M0 требует около 12000 gates (трудно сказать, идет речь о затворах либо базовых элементах, в любом случае это немного, но в первом — намного меньше — примечание переводчика), так что стоит она чуть больше, чем ничего (реализация, конечно, а не лицензия, кстати, если кто знает цены — поделитесь в комментах — пп). М0 + имеет тот же набор инструкций (как и M0-пп), но показывает лучшую производительность при низком энергопотреблении для устройств с батарейным питанием, плюс расширенные (необязательные) возможности отладки, и даже дополнительный блок защиты памяти (MMU бедняка).

Настал вечер и Шехрезада продолжила позволенные речи

Продолжим рассуждения на тему, как бы мы делали прибор MG328. На очереди у нас измерение конденсаторов, которое должно быть сложнее, чем измерение резисторов, но неожиданно оказывается чуть ли не проще. Но прежде, чем перейти к рассмотрению собственно конденсаторов, немного слов об измерениях в МК системах как таковых.

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

Безумству храбрых поем мы песню

Недавно случайно узнал о существовании очаровательного девайса MG238 — тестера электронных приборов. Посмотрел пару видео, слегка офигел, нашел сайт автора (кстати проект открытый, я думаю, что производители-китайцы авторские не платят), посмотрел схему и офигел окончательно. То есть измерительная часть представлена 3 управляемыми делителями и ЭТО меряет все, что я увидел в ролике?

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

Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича...

Последний пост Макса про неаккуратного инженера, который пренебрегает журналом, побудил меня задуматься о моих собственных записях.

Фиксация сведений о ходе разработки, результатов измерений, принятых (и отвергнутых) решений, выполненных расчетов являются частью любой инженерной работы. В каждом проекте есть много аспектов, подлежащих документированию, а проекты с применением контроллеров и / или программируемой логики, содержат еще и программную часть, вплоть до объектного кода (чтобы потом не пытаться мучительно вспомнить, а под какой средой этот проект компилировался и почему теперь перестал). Причины, по которым мы должны вести записи, включают в себя (но не ограничиваются):

• Подтверждение разработки,
• Получение данных для использования в паспортах,
• Определение подходов для тестирования устройства,
• Патенты,
• Юридическая ответственность,
• Бухгалтерский учет и аудит (для налоговых кредитов или промежуточных выплат),
• Аудит ISO.

В настоящий момент я использую документирование в стиле 20 века — все на бумаге. У меня есть папка для подшивки, в которой я держу требования, спецификации, списки, схемы и другие листки бумаги, а также журнал для заметок (ноутбук). На самом деле мой ноутбук больше похож на журнал для записок. Он содержит рукописные заметки, рисунки и расчеты, вместе с вклеенными страницами, такими, как рабочие листы Excel, фотографии, осцилограммы, описания дизайна и другие. Это все выглядит довольно неуклюже и не слишком удобно в работе, когда пытаешься следовать требованиям аудита ISO.

Ходит птичка весело по тропинке бедствий, не предвидя от сего никаких последствий.

(Найдите оригинал, прочтите, предложите лучшее название, близкое оригиналу, потом будете минусовать — пп).
Я недавно пришел к выводу, что я был неосторожным, озорным инженером. Я заслуживаю серьезного наказания, потому что я пренебрегал своим журналом для заметок.

Это моя вина. Нет никого, кого бы я мог обвинить, я виноват сам. От меня требовали вести журнал во время обучения в университете (у нас он назывался «Журнал прохождения производственной практики» -пп). Позже, когда я приступил к своей первой работе в качестве члена команды проектирования центральных процессоров (CPU) для ЭВМ, мой наставник — Дэйв Поттс, — разъяснял мне преимущества занесения в свой журнал мельчайших деталей.

Бросая камни в воду, смотри на круги, ими образуемые, иначе это бросание будет пустой забавою.

Рассмотрим несложную задачу увеличения точности резистора при помощи параллельного соединения двух резисторов, один из которых назовем базовым и обозначим r, а второй компенсирующим и обозначим R.Сразу отметим, что оба резистора являются постоянными и ни в коем случае не переменными. Причины подобного решения ( не использовать переменный резистор) оставим за скобками обсуждения, хотя это могут быть габаритные характеристики, стоимостные показатели и т.д. В практике разработки подобное решение встречается неоднократно.

Процедура настройки значения выглядит следующим образом: устанавливаем резистор r, измеряем его сопротивление, определяем номинал подстроечного сопротивления, необходимого для создания эквивалентного сопротивления, равного эталонному, берем ближайший номинал и устанавливаем его. Возможно, Вам приходилось подобное проделывать с реальной схемой.

И сразу же возникает вопрос — почему это работает? Ведь если r мы измерили и знаем абсолютно точно (в пределах погрешности измерительного прибора), то R мы просто берем из кассы и его точность определяется точностью изготовления резистора.Для ответа на этот вопрос привлечем немного математики.