Микроконтроллеры

Недавно я написал первый пост о том, как начал переделывать обычные светодиодные светильники в диммируемые. Многим не понравилось что свой диммер я делаю на базе микроконтроллера ATmega128. Поэтому хочу объяснить, почему используется именно этот микроконтроллер, и почему в наше время разрабатывая что-то ДЛЯ СЕБЯ, не стоит стремиться всё делать на самом слабеньком микроконтроллере, способном протянуть только лишь функционал разрабатываемого вами устройства.

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

Почему был выбран именно этот микроконтроллер? Да всё просто, потому что по цене ATmega128 всего на 20 центов дороже чем чем ATtiny2313. А ATtiny2313 стоит столько же, сколько и ATmega8. То есть уже про ATtiny2313 можно забыть как страшный сон.
Привожу пару картинок с ценами на AliExpress (а именно там я покупаю детальки) и идём дальше.

ATtiny2313:

ATmega8:

ATmega128:

ATmega2561:

Думаю комментарии излишни, сейчас даже для мигалки обычным светодиодиком куда выгоднее и рациональнее брать сразу ATmega128 чем 8 мегу, про тиньку и вообще молчу, забудьте про её существование как страшный сон. Да даже штук 5 транзисторов и резисторов для мигалки, уже будут стоить больше чем ATmega128. Так что забудьте про все микроконтроллеры слабее 128 меги, их использование в домашних проектах просто невыгодно и нерационально со всех сторон как ни посмотри. Да-да друзья мои, хочется вам или нет, но таковы реалии современного мира.

Следующий аргумент можно заметить если сравнить внимательно распиновку ножек ATmega128 и ATmega2561.

Видим что распиновка ножек очень похожа, выводы SPI для программирования МК совпадают, так же совпадают и выводы питания, в общем почти всё совпадает, там буквально пару ножек различается которые ни на что не влияют, к чему я это веду, да к тому, что разработав плату для ATmega128, вы спокойно можете при необходимости купить и впаять в неё более производительный ATmega2561, а тут и памяти под программу больше в 2 раза и "оперативки". Например, мой главный модуль умного дома будет построен именно на ATmega2561, а остальные на ATmega128. Как итог, мне не нужно будет самому изготавливать плату для ATmega2561. Не знаю как кому, а лично мне, изготавливать в домашних условиях платы для smd микросхем тот ещё геморой. Ну не люблю я разводить такую мелюзгу, особенно ЛУТ-том (другой технологии я пока не освоил). Заказывать в Китае 10 плат ради одного модуля тоже не выгодно. А так мы разводим универсальную плату на базе ATmega128, и в одну из плат впаиваем ATmega2561 для главного модуля умного дома. Как итог, все наши платы для микроконтроллеров изготовлены на заводе в Китае, а в заводские платы даже впаивать smd микроконтроллеры проще, чем в платы собственного изготовления, во всяком случае для меня.

Ну и собственно к самой теме поста.
Схема моих универсальных плат для умного дома:

Вот такие платы пришли из Китая:

После разрезания и впаивания компонентов платы выглядят так:

Плата с модулем ADM488 для связывания всех модулей умного дома в единую сеть:

Плата с модулем беспроводной связи nRF24L01+:

Как видите, на универсальной плате есть 2 специализированных разъёма, для модуля ADM488 и для модуля nRF24L01+, вся остальная периферия подключаемая к таким универсальным платам будет подключаться шлейфами к выведенным штырькам.

Вот собственно и всё. Может кто-то подчерпнёт какие-нибудь полезные идеи и для себя.

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

Далее опишу алгоритм управления ШД с помощью микроконтроллера.

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

Рассмотрим необходимый минимум основ управления ШД , необходимый для понимания принципа управления, описанного ниже. А именно:

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

• Изменение полярности обмотки с помощью Н-моста.

• Принципиальная электрическая схема, включающая в себя 4 драйвера полумоста и 2 Н-моста.

• Способ модуляции синусоидального сигнала с помощью широтно-импульсной модуляции (далее просто ШИМ).

• Способы подключения обмоток.

ШД имеют 4,5,6 или 8 выводов обмоток. При подключении к модулю управления ШД в каждом конкретном случае необходимо задействовать определенные выводы. В четырех выводном ШД задействуются все четыре вывода. Пяти выводной ШД не подходит для метода управления, описываемого в этой статье. В шести выводном не задействуются выводы нейтральных точек. В восьми выводном ШД обмотки соединены последовательно (см. рис. 1). Конечно можно задействовать все выводы обмоток, но эти методы управления выходят за рамки статьи.

Описание полношагового режима управления.

Для управления ШД необходимо подавать определенную последовательность сигналов на обмотки ШД . По сути создавая статором бегущую волну, заставляющую синхронно вращаться поле статора и ротора ШД . На рис. 2 над диаграммой схематично показан статор с обмотками. Цвет обмоток указывает на их полярность. В центре находится ротор в виде магнита. Если обратить внимание на диаграмму, то будет видно, что в середине каждого шага идет поочередное изменение полярности обмоток. В след за изменяющимся полем статора, вращается ротор по часовой стрелке. Для изменения вращения двигателя можно поменять местами выводы одной обмотки, и ротор начнет вращаться в противоположную сторону. Но зачем менять подключение обмоток, если можно программным путем поменять местами подаваемые сигналы, что и сделано с А+ и А- на рис.2. При этом ротор также начнет вращаться в противоположную сторону. Для большей наглядности сигнал на диаграмме имеет прямоугольную форму. Далее в статье прямоугольный сигнал будет заменен на сигнал ШИМ, модулирующий синусоиду.

Изменить полярность обмотки можно с помощью Н-транзисторного моста (см. рис. 3). В первом варианте из 4 транзисторов открыты Т1,Т4. Ток, соответственно, течет через них. Поменять полярность можно, открыв транзисторы Т2 ,Т3 и при этом закрыв Т1 И Т4. Таким образом, ток через обмотку потечет в противоположную сторону.

Для управления ШД используют два Н моста чаще всего на основе восьми N-канальных MOSFET транзисторов. Для управления транзисторами используются мостовые или полумостовые драйверы. Напряжение на затворе зачастую должно быть выше напряжения истока транзистора на 5-15В. Для MOSFET транзисторовэто делают драйверы.

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

Механизм встроенного временного промежутка Dead-Time обеспечивает гарантированное закрытие одного силового ключа до момента начала открытия ключа в противоположном плече. Гарантией надежного закрытия противоположного транзистора является встроенная схема, контролирующая состояние ключей и наличие схемы задержки, формирующей промежуток времени, в течение которого закрыты оба транзистора в плечах полумоста.

На рис.4 приведена принципиальная электрическая схема управления ШД, включающая в себя 4 драйвера полумоста IR2104S и 2 Н-моста на основе транзисторов IRF7836. При подаче 0 В на вход SD драйвера IR2104s драйвер переходит в неактивное состояние.

На приведенной схеме сигнал с диаграмм можно подавать на 4 входа. Так на ШИМ1 А+, на ШИМ2 А-, на ШИМ3 В+, на ШИМ4 В- соответственно (Рис.4).

Ниже кратко опишу принцип работы ШИМ, расчет и модулирование синусоиды.

ШИМ или PWM (широтно-импульсная модуляция или pulse-width modulation) это способ изменения мощности, подаваемой на нагрузку. Управление заключается в изменении ширины импульса постоянной амплитуды, следующих через равные интервалы времени.

На рис.5 видно, как регулируется мощность. Так 20%, 40%, 80%, 100% это время, когда транзистор открыт относительно времени периода. Соответственно среднее напряжение будет приблизительно равно 20%, 40%, 80%, 100% от максимального.

Меняя ширину импульса, можно модулировать различную форму сигнала. Так, по синусоидальному закону, при котором ширина импульсов изменяется следующим образом (рис. 6), максимальна в середине шага, а к началу и концу шага уменьшается. Синусоиду можно увидеть на осциллографе, пропустив ШИМ-сигнал с контроллера через RC фильтр. Для RC фильтра использовал конденсатор 2.2 нФ и резистор 1.5кОм.

На рис. 6 показан пример модуляции одного синусоидального шага, состоящего всего из 4 уровней напряжения. Напряжение питания 12В.

Для формирования модулированного сигнала необходимо рассчитать уровни ШИМ и их количество на один шаг. На рис.7 приведено два примера одного синусоидального шага с разным количеством ШИМ уровней, где ШИМ можно изменять в пределах от 0 до 255, что соответствует напряжению от 0 до 100%. Как видно на рис.7, чем больше уровней ШИМ, тем больше форма модулированного сигнала будет повторять синусоиду. Каждое изменение ШИМ происходит по прерыванию таймера в микроконтроллере. Меняя время срабатывания прерывания, можно регулировать время одного шага соответственно и скорость двигателя.

Формулу для расчета ШИМ уровней можно получить из формулы мгновенных значений синусоидальных функции. U = Umsin(*t + )

Um - амплитудное значение - угловая частота - начальный фаза, значение фазы в начальный момент t=0 аргумент *t + называют фазой синусоидальной функции

Для расчета = 0

Синусоида от 0 до Т/4 повторяет форму половины шага, а от T/4 до Т/2 зеркально отображает вторую половину шага. Поэтому для расчета достаточно взять участок от 0 до Т/4 или от 0 до 90. t для удобства можно заменить на угол = 0 до 90. Um заменим на максимальное значение ШИМ_max в примере 255. U заменим на ШИМ_N. Получается ШИМ_N = ШИМ_maxSIN(). Количество вычислений уровней ШИМ зависит от величины точности к примеру 16 с шагом угла 90/16 = 5,625

Пример:

ШИМ_0 = 255*SIN(0)= 0

ШИМ_1 = 252*(5,6251)= 24,99 25

ШИМ_2 = 252*(5,6252)=49,7450

. . .

ШИМ_16 = 252*(5,625*16)=255

Значения ШИМ необходимо округлять, так как оно может быть только целым.

Вычислив уровни ШИМ, можно модулировать синусоиду. Для этого я занес значения уровней в массив по прерыванию от таймера, поочередно подставляя значения от ШИМ_0 до ШИМ_16 в ШИМ контроллера. Так модулируется половина шага. Для модуляции второй половины нужно наоборот подставлять значения от ШИМ_16 до ШИМ_0.

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

Для удобства я написал небольшую программу для расчета значений ШИМ . Где PWM_MAX присваивается максимальное значение ШИМ, которое настраивается в микроконтроллере, а sampling присваивается количество уровней ШИМ на половину шага. Так как большинство программируют МК на языке С, данную программу я решил написать на этом же языке.

#include <stdio.h> #include <math.h>#define PI 3.14159265 #define PWM_MAX 255 //максимальное значение ШИМ.  #define sampling 16 // количество уровней напряжения на половину шага.int i; int main()    {for(i=0;i<=sampling;i++)             {printf("%d\n",(int)(PWM_MAXsin((double)90/sampling * PIi/ 180) + 0.5));};             return 0;    } 

Выходные данные

0 25 50 74 98 120 142 162 180 197 212 225 236 244 250 254 255

На этом необходимый минимум основ управления ШД завершается. Далее будет описана поставленная задача, возникшие трудности и их решение.

Задача: Двигатель должен вращать массу около 7кг за 0,7 - 1 секунду на 90. Угол поворота отслеживает 10 разрядный или 1024 битный абсолютный энкодер AS5040 закрепленный на валу механизма. При достижении 90 необходимо включить режим удержание ШД. При этом необходимо учитывать воздействие руки человека, толкающей механизм по направлению движения или против, либо удерживающей вплоть до остановки. При этом напряжение питания блока управления ограничено двенадцатью вольтами, а габариты двигателя ограничены по ширине 100мм, а по длине 110мм, включая длину вала. В наличии было три двигателя подходящих габаритов.

Осовные характеристики двигателей:

• двигатель 1 Рабочий ток 3,1 А. Активное сопротивление обмотки 1,5 Ом Индуктивность обмотки 3,5 мГн. Момент удержания 0,3 кг*м Величина полного шага 1,8 (200 шагов на один оборот ротора).

• двигатель 2 Рабочий ток 4А. Активное сопротивление обмотки 0,8 Ом. Индуктивность обмотки 3,1 мГн. Момент удержания 0,45 кг*м. Величина полного шага 1,8 (200 шагов на один оборот ротора).

• двигатель 3 не соответствовал характеристикам, заявленным производителем. Производитель утверждал, что он является аналогом двигателя 2. При замере активного сопротивления обмоток выяснилось, что сопротивление не соответствовало заявленным 0,8 Ом, а составляло всего 0,2 Ом. Следовательно, рабочий ток и индуктивность тоже отличались.

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

При испытании двигатель 3 по шуму и вибрациям отличался от первых двух в худшую сторону. Также было замечено, что все блоки управления с этим двигателем сильно грелись. Было решено больше не использовать этот двигатель.

Проблема 1. Свист двигателя. При уменьшении тока на блоках управления шум становился меньше, двигатель более плавно вращает ротор, и всё-таки шум и плавность вращения оставляли желать лучшего. При увеличении дробления шага на блоках управления до 1/16 шум уменьшился, и плавность хода увеличилась, но эти улучшения были незначительны. Дальнейшее повышение дробления вплоть до 1/512 не привело к улучшению показателей.

Решение проблемы 1. Решил сделать свой драйвер управления ШД на основе микроконтроллера PIC18F2331. Он заточен под управление двигателями. Было задействовано 4 канала широтно-импульсной модуляции для управления 4 драйверами полумоста.

Я начал эксперименты с формой сигнала, модулируемого с помощью ШИМ. Подавал треугольный, прямоугольный, трапециевидный сигналы на обмотки двигателя. Результаты: неутешительные показатели по шуму, вибрации и плавности хода были значительно хуже по сравнению с готовыми блоками управления. Подавая на обмотки двигателя синусоидальный сигнал, плавность хода, начиная от 5 об/мин и выше, стала практически незаметной на глаз. Детали механизма не гремели, но если скорость была ниже 5 об/мин, детали гремели, механизм передвигался рывками, ток потребляемый двигателем рос и выходил за пределы рабочего тока двигателя. Что касается шума, даже при скорости выше 5 об/мин был неприятный шум. Свист похожий на звук, издаваемый зарядными устройствами для телефонов ноутбуков, только гораздо сильнее. Такой же шум я слышал от асинхронных двигателей, управляемых частотными преобразователями. Изучив работу частотных преобразователей, стало ясно, что свист зависит от частоты ШИМ. У меня частота ШИМ составляла 4кГц. При изменении частоты свист менялся, и когда я поднял частоту до 20кГц, шум полностью пропал. Слух человека в большинстве случаев не воспринимает частоту выше 20кГц.Так была решена проблема 1.

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

Решение проблемы 2. Когда напряжение питания драйвера с 12V снизил до 9V, рывки при передвижении механизма тоже стали меньше, но всё равно недостаточно плавно. Тогда напряжение выставил 12V, а амплитуду ШИМ синусоиды начал уменьшать, и при 20% амплитуды от максимума движение было плавным и тихим.

Проблема 3. Если запустить двигатель сразу на большой скорости без разгона, то момент на валу двигателя будет недостаточным для вращения механизма. Начнется пропуск шагов, сопровождаемый сильным шумом, который распространяется по всему корпусу механизма. Звук напоминал ведро с болтами, которое трясут изо всех сил. Так как необходимо было провернуть механизм на 90 за 0,7 - 1 сек., я решил, что до 45 буду линейно ускоряться, а с 45 до 90 линейно замедляться. Достигнуть даже приближённо времени в 1сек не удалось. Еще было замечено при старте, что первый шаг периодически сопровождался рывком ротора. Это связанно с тем, что зубцы ротора могут находиться не на оси включенной обмотки статора. В следствие чего зубцы ротора стремительно притянутся к обмотке, произойдёт фиксация ротора, сопровождающаяся звуком, похожим на удар. Все последующие шаги будут плавными.

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

Для примера покажу график Рис.9. Взятый из даташита.

На двигатель FL86STH156-6204 ток фазы 6,0 А. Максимальный постоянный ток потребления от источника питания 3,8 А для блока SMD-9.0 Блоки управления SMD-9.0 (напряжение 72В) и SMD-82 (напряжение 220В) Дробление шага , источник питания 72 В, 300 Вт.

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

В моем случае питание 12В и диапазон допустимых скоростей невысок, так как момент стремительно падает с увеличением скорости.

Так как при равномерном ускорении не удавалось разогнать механизм. Я решил разделить ускорение на три диапазона. Первый при скорости ниже 5 об/мин ускорение максимально, так как момент максимально высокий. Второй диапазон от 5 до 7 об/мин ускорение уже в три раза меньше и последний третий диапазон от 7 об/мин и выше, ускорение в десять раз меньше относительно первого диапазона. Таким образом двигатель набирал максимально быстро скорость в начале пути и укладывался в 1с. Нелинейно разгоняя двигатель, можно значительно сократить время разгона ШД. Замедление механизма проходило в обратном порядке. Так как сохраненной осциллограммы сигнала, подаваемого на драйверы полумостов, у меня не осталось, я нарисовал, как, примерно, должна выглядеть осциллограмма.

При старте, первый шаг периодически сопровождался рывком ротора. Удар можно убрать, путем снижения амплитуды первой половины шага (в моем случае 20% от максимума) и значительно увеличив время первой половины шага по сравнению с другими шагами. Как видно на рис.10, первые половины шагов более вытянуты, чем правые. Это связанно с ускорением. Форма синусоиды искажается, но при этом двигатель работает достаточно плавно и тихо. Как видно на рис.10, ускорение максимально, это заметно по сужению шагов в начале движения. Когда момент максимален, а по мере приближения к максимальной скорости ускорение значительно меньше от изначального. Все диапазоны ускорений подбирались экспериментальным путем. Как регулировать амплитуду и ускорение я описал ранее в этой статье.

Проблема 4. Учет воздействия руки на механизм, если не учитывать воздействие руки, то можно было обойтись парой индуктивных датчиков или оптических датчиков для отслеживания крайних положений и направления вращения. А если учитывать воздействие руки, то без датчика угла поворота (абсолютного энкодера) не обойтись. Если механизм находится в движении, а рука хватает его и удерживает на месте, начинается пропуск шагов и сильный шум. По датчику будет видно, что вал колеблется на месте, и двигатель необходимо отключить и попытаться стартовать через заданный промежуток времени. Эта задача легко решаема. Если рука потянула механизм против направления, по датчику можно легко понять, что механизм вращается в противоположную сторону, и тоже отключить двигатель. И совсем другое дело, воздействие на механизм с увеличением скорости перемещения больше заданной изначально или наоборот притормаживание. Логично было измерять скорость перемещения и подстраиваться, чтобы скорость двигателя совпадала с движением руки, но оказалось, что 10 разрядный датчик as5040 не позволял этого сделать. Предположим, что нужно отслеживать перемещение каждые 1,05 .Так как 10 разрядов это 1024 бита, то вычисляем точность 360/1024 = 0,35, количество градусов на один бит возьмём 0,353 = 1,05. Зная время, за которое двигатель проходит 1,05, можно вычислить скорость. Но не все так просто. У датчика есть погрешность - биение младшего бита, то есть погрешность в один бит, а при измерении скорости нужно сделать два замера пройденного пути. В начале и в конце соответственно погрешность удваивается и составляет 0,352=0,7. Измерить скорость каждые 1,05 невозможно. Логично измерять, например, каждые 0,35*15=5,25. Уже можно оценить скорость, но 5,25 это слишком большой угол, двигатель успеет пройти почти 3 шага или более точно 5,25/1,8= 2,92.

Решение проблемы 4. Целесообразно для измерения скорости использовать 12 разрядный датчик это 4096 бит. Точность измерения увеличится в четыре раза, что позволит точно подбирать скорость движения механизма под скорость движения руки.

Так была решена последняя проблема.

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

Привет, Хабра!

Сегодня одолела ностальгия и хочу рассказать, как делал устройства для музыкантов педальки-контроллеры, наделяющие музыкальный процессор Digitech Whammy новыми возможностями. Устройства мало кому нужны, но кому нужны то позарез)

Этот проект мне очень дорог, потому что с него началась настоящая страсть к созданию чего-то нового. И хоть я давно уже не брался за паяльник, а основное время посвящаю развитию в управлении продуктом, всё ещё не оставляю фантазии о фееричном возвращении в music hardware, которое сделает немного шума в чахнущем царстве рока.

Да и перед именитыми ребятами (на фото, например, CJ Pierce из Drowning Pool, James "Munky" Shaffer из Korn и Wesley Borland из Limp Bizkit, ну и я с девайсами), признаться, стыдно, что пропал на целых несколько лет ни слуха от меня, ни духа о новых устройствах.

Удачно сложилось, что сегодня же есть 3,5 часа в самолёте, так что настало время офигительных историй расскажу, как появились эти железки реально из мусора. Курьёзы и неудачи, какие устройства хотел и что получилось, как они оказались у топ-музыкантов мира и почему я отложил такие крутые штуки в долгий ящик.

Возможно это смотивирует кого-то вернуться и доделать свои идеи, а кому-то просто поднимет настроение. Итак, вперёд! Точнее назад, в 2010 год...

Педаль с Марио

Год 2010 был жутко насыщенным (как, впрочем, и все остальные), потому что я работал параллельно:
а) Продавцом в музыкальном магазине,
б) Администратором в концертном агентстве,
в) Был владельцем двух репетиционных баз и совладельцем магазина игрушек,
д) Играл рок с бандой за какие-то деньги и так далее.

В один из выходных, проснувшись в Музторге, мой коллега Кузьмич показал видео на YouTube диковинной и взрывающей голову педальки от Molten Voltage. Это был midi-контроллер для Digitech Whammy, который превращал питч-шифтер в арпеджиатор.

Стоила педаль 100$ (3 000 по тем временам) и платить такие бешеные деньги за девайс было большим расточительством. А так как я увлекался программированием микроконтроллеров (и даже сделал подсветку днища для друзей, звёздное небо для клуба "Шоколад" и другие кринжовые штуки из 2007-ого), то сходу предложил за трёху сделать педаль сильно лучше.

Папа у меня инженер и с детства дома были кучи радиодеталей и плат, а я паял всякие нехитрые приспособления. Из Музторга была позаимствована Digitech Whammy, в радиомагазине куплен PIC16F628, собрана схема чисто из советских деталей, написана программа на ассемблере и готово. На всё про всё пара месяцев работы по вечерам.

Всё делалось дома вручную. Сложнее всего было напилить квадратные отверстия для разъёма питания и окошко для цифры. Окошко с внутренней стороны было закрыто приклеенным куском прозрачной шайбы, которая всегда была на шпинделе компакт-дисков, помните такую?

Программная часть вообще без каких-то новшеств. Пресеты в EEPROM, на старте читаем активный, загружаем в RAM. Раз в несколько миллисекунд опрашиваем кнопки и рисуем на экране чиселку. Конечный автомат прямо в прерывании таймера за микросекунды делает всю работу + считает темп для функции Tap Tempo (которая, конечно, подвирала).

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

Сразу было сделано 3 таких педали двум друзьям и себе. Мне девайс не понравился не считал темп в bpm, плохие возможности программирования, мало программ, работал только с одним типом Whammy. Тем не менее, я снял видео и тоже залил в YouTube типа зацени, Молтон Вольтейдж, пацаны с лебедевочки тоже могут!

На видео добавляет стиля миди-шнурок, свитый из трёх отдельных проводов, советские аудио-разъёмы DIN-5, демо-версия видео-редактора и порванный носок. Да, тогда YouTube многое прощал.

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

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

Тем не менее до 2013-ого года они продавались именно в таком виде. Начали подтягиваться ребята с именами одна ушла Паше Додонову в Дельфин. Одну подарил Стиву Ваю, когда он приезжал в Новосибирск, но он ей скорее всего максимум ножку стола подпирает. Зато поиграли с ним на гитарах, он и его менеджер Франко Пеона похвалили мой Гибсон Лес Пол, ух хороший вечерок был. Но не об этом.

Ещё одна ушла Роме Хомутскому в 7Расу. А я стал задумываться, что пора бы сделать следующую версию на порядок круче и для этого нужно подтянуть технологии и инструментарий. И в следующий раз, когда 7Раса поехала в тур в Сибирь, купил в Москве на Авито макбук, чтобы учиться на нём работать и впитывать магию Эпол. Попросил ребят привезти мне его заодно в Новосиб типа, всё равно ж сюда едете. Вот такая звёздная доставка получилась.

Главные ошибки

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

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

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

Итак, краткий список принципиальных улучшений был намечен такой:
сделать точнейшую поддержку темпа в bpm. Мы же говорим про арпеджио, значит надо чтобы эффект точно попадали в контекст трека;
поддержать все типы актульных тогда (да и сейчас) Digitech Whammy, а их 4 штуки;
сделать овер-дофига пресетов и чтобы их было легко программировать, как на самой педальке, так и на компьютере;
сделать полную поддержку MIDI, чтобы педаль встраивалась в цепочки других устройств, синхронизировалась по темпу, могла сама управлять темпом других устройств и т.д.
работать устройство должно от любого блока питания и от батарейки и ещё и контролировать её разряд, ну и так далее.

Было ещё много других хотелок, но даже эти уже слабо ассоциировалось с резисторами млт и стойками из шариковых ручек. Ещё тогда вышел iPhone 4 и мне, конечно же, хотелось делать продукты в стиле Apple чтобы они были офигенные и на голову опережали конкурентов по желанию ими обладать. В общем, наметился переход на более продвинутую технологию, как в hardware, так и в software.

С железом определился легко. Это точно должна быть 2-сторонняя плата и smd монтаж, чтобы получить максимум от домашнего прототипирования плат утюгом. Дальше купил паяльную станцию с феном, сделал несколько плат и обнаружил, что 0805 это раз плюнуть, довольно легко запаиваю 0603, а вот 0402 уже тяжко.

С процессором чуть сложнее. Я остался на микроконтроллерах PIC, потому что к тому времени начал мыслить их ассемблером, и он меня полностью устраивал в голове просчитывал нужное количество тиков в прерываниях, чтобы получить real time точность и т.д. Но сам камень итеративно менял несколько раз, потому что раздувались хотелки и в итоге пришёл к PIC16F1939 в корпусе TQFP. Почти что максимум, что мог предложить Microchip на 8-bit архитектуре.

Но самое сложное оказалось с software. Я несколько недель маялся и принципиально не мог придумать, как мне сделать так, чтобы все задуманные функции выполнялись параллельно, контролируемо и точно. Напомню, я не был программистом. Я был рокером.

Здесь нужно сделать лирическое отступление про образ жизни. Тогда я сдружился с моим лучшим другом Славой, очень известным в узких кругах CG. Слава как-то решил, что хочет делать 3D-мультики ну хотя бы на уровне Pixar и начал делать. Мы с ним быстро опознали друг в друге упоротых людей и сблизились настолько, что я постоянно жил у Славы. Днём в основном мы мотались по делам, а ночи напролёт дули кофе и пилили проекты. Кстати, какой-то мультик не без помощи Pixar мы в итоге сделали, но это совсем другая история)

В итоге как-то поздно вечером я вернулся домой и папа мне подсунул статью из технического журнала. Он знал, что я чёто-то там делаю с микроконтроллерами и время от времени подкидывал интересные, на его взгляд, материалы.

И каково было изумление, когда я понял, что в статье описывается решение моей боли а именно, как в операционной системе работает планировщик задач. Я был ослеплён изящностью и красотой этой идеи, и тут же сел писать демку планировщика. Часам к четырём ночи она была готова, я не думая прыгнул в машину и прикатил к Славе, нашёл его сидящим с краснющими глазами за мониторами и, сбиваясь, в эйфории рассказал про случившийся прорыв. Слава выслушал, посмотрел оценивающе и сказал: "Иди спать, педрила". Так появилось гордое название PeOS в пунктах преимуществ устройства и Pe это не pedal.

Конечно, это было только начало пути, а дальше наступил сезон гастролей и я параллельно начал зачитываться как детективом "Операционными системами" Танненбаума и писать свой менеджер задач core, вокруг которого строилась вся система.

Почему не взял готовый? Да тупой потому что. Даже Git не знал зачем нужен. Ну и хотелось во всём разобраться, сделать идеальный девайс.

Хорошо запомнил ощущение сюра, как в Томске Борис Гребенщиков с Аквариумом изрядно накидались в гостинице, плясали на столах, а я в центре этой вахканалии пишу на ассемблере свою операционную систему.

Выбор ассемблера привёл к понятной проблеме. Вы видели когда-нибудь абсолютно нечитаемый код? Скорее всего вы видели эталон достижений в области программирования по сравнению с тем, что стало результатом работы. 30+ килобайт ассемблерного кода это очень много.

Но дальше сюр будет только крепчать.

Прототипы

Начало работы полностью происходило в симуляторе, но довольно скоро дошло время и до проектирования схемотехники. Схему для первой версии педали чертил в простейшем Sprint Layout. Для второй же версии потребовался инструмент серьёзнее изучил Eagle и разводил платы там.

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

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

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

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

UI весь нарисовал сам. А потом перерисовал. Тогда мы со Славой время от времени нехило рубились в танки, поэтому в педальке все цифры стали трафаретными, как будто с военной техники.

Для соединения педали с компьютером разобрался с Objective-C и написал программу (о, боги, как-то я заглянул в код и чуть не заплакал кровью) под Mac OS. Помню, как у меня бомбило, когда узнал, что в Objective-C есть специальный объект NSNumber для числа. Я привык в 1 байт упаковывать 4-битное число и 4 буля и мне это показалось кощунственным разбазариванием ресурсов.

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

Было ещё несколько ударов судьбы, которые чуть не валили уверенность в блестящем будущем проекта с ног. Точно помню два.

USART
Педалька должна была встраиваться в MIDI-цепочку. MIDI это последовательный однонаправленный протокол с токовой петлёй на физическом уровне. Мне нужен был 1 MIDI-вход для получения данных извне, 1 MIDI-выход для отправки данных вовне и 1 MIDI-выход для отправки данных в процессор Whammy, собственно для прямой функции девайса, ради чего затевался сыр-бор.

Я был абсолютно и непоколебимо уверен, что USART-ов в PIC16F1939 ну минимум 2 или 3, а оказалось, что ОН ОДИН. Это случилось, когда почти вся функциональность была закончена и более-менее протестирована, а оставалась только реализация MIDI. Я настолько тогда охренел, что растерялся.

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

В общем, выкрутился ужасно. На выход USART'а добавил переключатель физических выходов MIDI на транзисторе. И в зависимости от назначения байт отправлялся в один или другой выход. По факту предельная скорость передачи данных снизилась в 2 раза, но на практике с этим решением вообще никаких проблем.

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

В итоге задача свелась к делению 16-ричного числа на 3. А дешёвый 8-битный контроллер не то чтобы вообще умел это делать. Как бы там есть сложение, вычитание и сдвиг, которым можно делать умножение и деление на степень двойки. Но не другого числа.

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

Релиз

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

Цену выставил, как мне тогда казалось, солидную 5 000 за коробочку. Штук шесть у меня купили в первый же день ближайшие знакомые. Ощутил запах победы и что всё не зря. Но дальше продажи полностью остановились. Надо было что-то делать.

Не долго думая, решил использовать способ, сработавший раньше, но с небольшим дополнением. Педаль сфотографировали у знакомого фотографа по-моему за бутылку виски, которая и фигурирует на фотке. Мой друг собрал сайт, который можно посмотреть в веб-архиве. Угадайте, чего не найти на сайте? Правильно, кнопки купить!)

Дальше записал длинное видео с объяснением всех функций, доступных в педальке. Думал показать здесь тот самый видос с разбором всех функций, но лучше добавлю видео ребят, которые встраивали дикие звуки D2 в свою музыку

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

Звёздный сюр

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

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

Hed P.E.
Одним из первых во внимание попал Wesley Geer (экс Hed P.E.). Он приезжал в Новосибирск вместе с Korn, оказался супер-общительным чуваком и с ним удалось посидеть в баре. Договорились, что я отправлю ему педаль на NAMM с кем-то из Нск (сам я не могу поехать, бабок не было), так и вышло. До сих пор время от времени переписываемся.

Drowning Pool
Я долго работал в концертной индустрии, плюс мы много играли рок, поэтому, конечно, знал почти всех организаторов, прокатчиков и промоутеров, и попробовал через них рассказывать о своих педальках приезжающим топ-музыкантам.

Так произошло с группой Drowning Pool. Их гитарист CJ Pierce активно использовал Digitech Whammy в музыке и был отличным кандидатом под "моего" артиста. Через знакомых рассказал их менеджеру про педаль, но так я был вообще на мели, не мог педаль подарить. В итоге менеджер купил педальку и мы здорово пообщались с CJ-ем. Я объяснил ему все функции девайса, он офигел и предложил помочь их продавать в Штатах. Я обрадовался, но опять не хватило опыта дожать тему. Мы просто потерялись.

Но из той встречи я вынес неожиданный бонус. Моя педалька это контроллер для Whammy, который поддерживал 3 вида процессоров. Но своих Whammy у меня тогда не было. И если пятую версию было найти легко, то четвёртую постоянно приходилось одалживать, чтобы проверить новую партию педалей. А у СиДжея тогда в туре сломалась его Whammy IV. Я его не просил, но он просто взял расписался и подарил её мне.

Я так обрадовался, ппц. Починил её дома, аккуратно почистил, чтобы сохранить историческую задроченность и до сих пор тестирую на ней новые девайсы. На фотке в заголовке она на заднем фоне красная. Помните, в самом начале фильма XXX Вин Дизель сбрасывает в пропасть красный корвет С5 под песню "Let the body hit the floor"? Ещё такой мем был с попугаем. Кароче это та самая Whammy, которая в их песнях записана.

Наив
Уже не помню, как продал педальку Валере Аркадину из Наива и Матрикса. Но это один из российских музыкантов, который очень много экспериментировал с её звуком. Она вошла в песню "На пределе", Валера написал большое произведение на заказ с её использованием, рассказал о ней в журнале In/Out. Кароче, Валера, каждый раз когда ты звонишь, чувствую безумную радость и уважение, но и угрызения совести, что до сих пор не выпустил новых девайсов.

Korn
Дальше узнал, что ещё раз приезжают Korn и попросил Wesley рассказать о педальке Хэду и Манки. Он не обломался и Манки вписал меня в список приглашённых группой гостей в Нск. К сожалению, Хэд тогда свалился с камнями в почках в Красноярске и остался там в больнице, так что не пообщались, но педалек я всё равно подарил две.

Это была очень странная встреча на стадионе в Нск мы болтали с Манки, подошёл Джонотан Дэвис и восхитился педалью, рассказал про свой второй проект Killbot. В итоге Манки записал мой номер телефона и email, мы обменялись контактами и я ушёл даже не подозревая, что вообще произошло сейчас.

Crosses и Deftones
Как-то на даче я помогал родителям, копал картошку, и пошёл посидеть в тенёк, потому что припекало. На телефоне высветилось новое письмо заказ с сайта. Имя заказчика Shaun Lopez. "Что за латинос?" подумал я.

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

Так произошло и в тот раз. Но уже через несколько секунд я чуть не навалил в штаны, потому что Шон оказался продюсером Deftones, другом Чино Морено и музыкантом в one-man проекте Crosses. Ну а мы тогда сильно фанатели по Deftones.

Я предложил ему 50% скидку за упоминание Smirnov Electronics на его сайте и традиционную фотку в инстаграм. Собственно, Шон без возражений выполнил свою часть обязательств.

Limp Bizkit
С лимпами была история прям по касательной. Вес на самом деле Wes не использует Whammy в Limp Bizkit и вообще её не то чтобы любит, но у него есть и другие проекты. Плюс иногда он в инсте разыгрывает всякий ненужный ему хлам.

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

Заключение

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

Как резюме, хочу подчеркнуть смотрите, как много я совершил ошибок. Собрал почти все: от неверно выбранной технологической платформы до совершенно не организованных продаж и развития, профукал почти все шансы, упустил время. Но главное-то остаётся с нами музыканты играют на педальках и раз в месяц-два до сих пор ребята интересуются покупкой (безуспешно), как подтверждение, хоть и очень локальной, но ценности.

Так что если у вас в голове есть идеи, но вы не знаете как их сделать, просто делайте. Не думайте, делайте. А как начнёте делать думайте, и тогда это точно приведёт к какой-нибудь крутой истории.

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

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

Stay Heavy \m/

Если у вас большой и серьезный ЦОД, то параметрия температурных режимов не является проблемой. Существуют проверенные решения, например, программируемые контроллеры TAC Xenta, которые работают через LonWorks. Именно так мы собираем данные в московском ЦОД Datahouse. Но непосвящённому смертному весьма непросто собрать правильные показатели из этой связки и выводить их в мониторинг в нужном виде. К тому же решение промышленное и достаточно дорогостоящее. Поэтому при строительстве новой гермозоны
в Екатеринбурге мы решили поэкспериментировать и внедрить альтернативное решение по измерению температуры в холодных и горячих коридорах.

Ничто не предвещало беды

Так как множество систем в этом ЦОДе завязано на открытом коммуникационном протоколе Modbus мы решили заказать температурные датчики, работающие поэтой шине, и собирать данные с дальнейшей интерпретацией в интерфейсе мониторинга. Недорогие датчики быстро нашлись на известном китайском сайте и были заказаны партиями в количестве 20 и 40 штук.

Первая партия из 20 штук пришла достаточно оперативно, но при детальном рассмотрении стало понятно, что датчики незначительно отличаются корпусами. Важно ли это, как выяснилось да.

Из первой партии завелось 15 датчиков. Так как острой потребности в остальных не было, пока работали с ними. К моменту прихода второй партии выявили, что часть уже установленных в шину датчиков имеет поведение новогодней елки: показывают некорректные данные, отдают checksum error или отваливаются по таймауту.

Анализ второй партии показал, что в ней процент брака в разы выше.
В итоге из 60 датчиков мы получили всего 8 стабильных с правильными показаниями.

Вот так это выглядело:

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

Не ищем легких путей

Вскрыли, посмотрели: микросхемы идентичны. Значит дело в прошивке.

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

Пока разбирались с работоспособностью датчиков поняли, как без особых сложностей обнаружить кривую версию прошивки. Если кроме Modbus работают обычные текстовые команды READ, PARAM, AUTO, STOP значит прошивка хорошая. В мертвых прошивках текст не отдается.

Решили взять прошивку с этих живых 8 датчиков, купили программатор Nu-Link,
но хитрые китайцы заблокировали чтение прошивки. То есть перезалить можно, а считать - нельзя. Запросы правильных прошивок у поставщика потерпели фиаско:
Я продаван, я не разработчик.

И тут я психанул, схватил крепкие напитки и закрылся у себя.
Через пару дней вышел с прошивками и программой.

За основу был взят Keil, пакет С51, позволяющий работать с 8-битными MCU.

В начале я научил читать сенсор SHT 20 (который собственно и снимает температурные данные), потом научил передавать эти данные по Modbus. В виду того, что этот MCU ни что иное как Nuvoton N76E003AT20, то вся база знаний, видимо, сосредоточена в руках наши китайских друзей.

В итоге i2c и Modbus сделал быстро, а вот с таймерами пришлось повозиться. Чтобы не было коллизий в шине, добавил возможность смены SLAVE_ID без выключения датчика в Китайской версии прошивки после смены адреса его нужно было обязательно выключать, что не очень удобно.

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

Так стало:

Если говорить про результаты измерений, то нормальные показания появляются только
в помещении с явной циркуляцией и движением воздуха. Без продува датчик показывает 30С. Это объясняется тем, что внутри установлен стабилизатор напряжения, который преобразует 24В в 3.3В, переводя разность в тепло.

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

Несмотря на возникшие осложнения, данное решение имеет два очевидных преимущества: стоимость и гибкость. Датчики можно установить в любом удобном месте, точечно или объединить в гирлянды. Можно измерять как общую температуру, так и частные показания отдельных приборов и устройств. И самое важное, что все это отлично работает по Modbus.

Программа выложена на GitHub кому интересно, можно забрать и поиграться.
Стоимость датчика всего 300 , правда, нужен программатор.

В предыдущей статье http://personeltest.ru/aways/habr.com/ru/post/557242/ была описана схемотехника контроллера резервного питания. Такой контроллер может пригодится в разнообразных технических системах и устройствах. Поэтому конструктив платы был выбран максимально нейтральный с возможностью выноса элементов управления на отдельную панель.

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

• электромагнитная совместимость удовлетворяющая стандартам

• высокая теплоотдача и большая рассеиваемая мощность без радиаторов и вентиляторов

• низкая цена печатной платы

• минимальные размеры

• возможность изменять варианты сборки

• обеспечение электробезопасности и электрической прочности

• ремонтопригодность с минимальной оснасткой и оборудованием

• пригодность для коррекций ошибок трассировки и схемотехники

• технологичность сборки и невысокая цена сборки

• максимальная тестируемость после сборки

• удобство монтажа в целевой системе

Естественно что весь этот список невозможно не только максимально удовлетворить, но даже держать в памяти затруднительно.
Поэтому эмпирически выбираем два-три высших приоритета с которыми работаем в первую очередь.
Низкая серийность позволяет нам сдвинуть цену вниз по приоритетам. Боль прошлого опыта заставляет нас поднять ремонтопригодность и тюнингируемость на пару уровней выше чем это принято обычно.
В верхней строчке может оказаться электробезопасность и соответствие стандартам по ЭМС.
И не только потому что без этого регуляторы просто не позволят эксплуатировать плату. Плохая ЭМС может поднять результирующую цену платы многократно, поскольку приведет к длительному циклу отладки, к повышенному проценту ремонтов, удорожанию технической поддержки и многому другому. Соответственно вердикт - плата должна иметь не менее 4-х слоев.

В 4-х слоях удастся сделать максимально большие полигоны земли и питания, а также полигоны отвода тепла.
Толщину платы выбираем из соображений жесткости и из перечня доступных вариантов у производителя плат. Внутренние слои расположены ближе к внешним чтобы иметь лучшую емкостную связь с дорожками в верхних слоях и обеспечивать лучшую ЭМС, а также для лучшей передачи тепла от SMD компонентов в стороны от них.
Шесть слоев конечно было бы лучше, но нельзя забывать что цена еще не выкинута из списка приоритетов.

Вопрос выбора программных инструментов для трассировки решается в пользу Altium Designer. Как считают его разработчики он на сегодня наиболее массово применяемый инструмент в данной области.
Цена за standalone лицензию Altium до акций могла обойтись пределах 10 тыс. евро, еще 3 тыс. евро возможно придется отдать за опцию PDN Analyzer если потребуется точнее рассчитать потери и наводки в проводниках.
К счастью есть возможность поработать с триальной версией Altium и при должной сноровке выполнить трассировку необходимой нам платы в триальный период.

Результат работы показан ниже:

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

На посадочном месте дисплея находится ряд отверстий под установку разъема. Если дисплей и энкодер нужно вынести, то ставится разъем на который выходят все необходимые для выноса сигналы.

Работа по правилам.
В Altium есть оригинальный механизм правил. Правила позволяют делать автоматическую проверку соответствия трассировки заданным технологическим нормам.

Для данной платы были созданы следующие основные правила:

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

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

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

Площадки и их особенности

Как и при разработке программного обеспечения так и при разработке платы не имеет смысла сразу уделять много внимания форме площадок. Для этого есть рефакторинг и в Altium этот рефакторинг делать достаточно удобно.
Но несколько советов все же дам.

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

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

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

Шелкография

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

Какие рекомендации действительно важны

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

Рекомендация по установке термо-барьеров. Она напрямую конфликтует с требованиями ЭМИ и теплопередачи, однако выполнение рекомендации обеспечивает исключительное удобство ремонта. Как правило если элемент не греется, не проводит большие токи, то ремонтировать его не приходится, если только не считать тюнинга.
Современные контрактные сборщики, по моему опыту, не отдают плат с дефектом надгробного камня, а исправляют его у себя, если он появляется. Они также и претензий не предъявляют в случае отсутствия термо-барьера.
Что же касается ремонта, то современные паяльники без труда справляются с отпайкой компонентов без термо-барьеров. Словом, рекомендация сомнительная.

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

Проблемы земли
Вопрос о земле - важнейший в цифро-аналогово-силовых схемах. Малейшая неосмотрительность может привести к тяжелым финансовым последствиям либо, в лучшем случае, к значительной деградации качества работы схемы.
У Altium есть инструмент под названием PDN Analyzer для точного расчета потенциалов в проводниках с большими токами к которым относятся и полигоны земель. Однако в данном проекте этот анализатор не использовался. Все же это дорогое и трудоемкое удовольствие оправданное в более сложных проектах. Здесь подход был проще.
Были идентифицированы несколько основных доменов земли которые необходимо максимально разделить:
- цифровая земля микроконтроллера
- аналоговая земля микроконтроллера
- возвратная земля силовых ключей и DC/DC преобразователя
- чувствительная земля DC/DC преобразователя
- непосредственно заземление

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

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

Ниже показана результирующая топология каждой из земель.

На этом описание трассировки заканчивается. Насколько это возможно в формате короткой статьи я постарался отметить самые важные на мой взгляд моменты.

Следующим этапом будет программирование, наладка и тестирование платы. Но об этом позже.

Введение

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

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

Всякий раз, когда студент решает что-то сохранить в EEPROM, это выливается во множество багов, связанных как с неверно выбранной архитектурой, так и просто человеческим фактором. Собственно обычно студент лезет в интернет и находит что-то типа этого:

int address = 0;float val1 = 123.456f;byte val2 = 64;char name[10] = "Arduino";EEPROM.put(address, val1);address += sizeof(val1); //+4EEPROM.put(address, val2);address += sizeof(val2); //+1EEPROM.put(address, name);address += sizeof(name); //+10

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

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

Обычно все сводится к двум вариантам:

• Доступ к EEPROM только из одного места. Типа такой EepromManager , который запускается в отдельной задаче и проходится по списку кешеруемых EEPROM параметров и смотрит, было ли в них изменение, и если да, то пишет его в EEPROM.

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

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

• Второй способ - пишем всегда сразу по месту.

  Плюс в том, что пользователь всегда получает достоверный ответ. Мы не задумываясь пишем параметр в EEPROM там где надо, и это выглядит просто.

  Но проблем от этого не меньше: так как мы можем писать хоть что, хоть откуда, хоть куда - скажем журнал ошибок из разных подсистем из разных задач, то придется задуматься о блокировке ресурса EEPROM.

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

Но в обоих этих способах, мы хотим, чтобы доступ к параметрам не был похож, на тот код с Ардуино, что я привел, а был простым и понятным, в идеале, чтобы было вообще так:

//Записываем 10.0F в EEPROM по адресу, где лежит myEEPROMData параметр myEEPROMData = 10.0F;

Но так мы делать не будем, потому что иногда нам понадобится по месту вернуть статус операции записи, вдруг EEPROM битая или проводки отпаялись. И посему мы будем делать, что-то похожее на это:

//Записываем в EEPROM строку из 5 символов по адресу параметра myStrDataauto returnStatus = myStrData.Set(tStr6{"Hello"}); if (!returnStatus){std::cout << "Ok"}//Записываем в EEPROM float параметр по адресу параметра myFloatDatareturnStatus = myFloatData.Set(37.2F); 

Ну что же приступим

Анализ требований и дизайн

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

Давайте поймем, что мы вообще хотим. Сформируем требования более детально:

• Каждая наша переменная(параметр) должна иметь уникальный адрес в EEPROM

  • Мы не хотим руками задавать этот адрес, он должен высчитываться сам, на этапе компиляции, потому что мы не хотим, чтобы студент нечаянно задал неверный адрес и сбил все настройки

• Мы не хотим постоянно лазить в EEPROM, когда пользователь хочет прочитать параметр

  • Обычно EEPROM подключается через I2C или SPI. Передача данных по этим интерфейсам тоже отнимает время, поэтому лучше кэшировать параметры в ОЗУ, и возвращать сразу копию из кеша.

• При инициализации параметра, если не удалось прочитать данные с EEPROM, мы должны вернуть какое-то значение по умолчанию.

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

• Все должно быть дружелюбным простым и понятным :)

Давайте прикинем дизайн класса, который будет описывать такой параметр и удовлетворять нашим требованиям: Назовем класс CaсhedNvData

CachedNvData

Вообще все должно быть понятно из картинки, но на всякий случай:

При вызове метода Init() мы должны полезть в EEPROM и считать оттуда нужный параметр с нужного адреса.

Адрес будет высчитываться на этапе компиляции, пока эту магию пропустим. Прочитанное значение хранится в data, и как только кому-то понадобится, оно возвращается немедленно из копии в ОЗУ с помощью метода Get().

А при записи, мы уже будем работать с EEPROM через nvDriver. Можно подсунуть любой nvDriver, главное, чтобы у него были методы Set() и Get(). Вот например, такой драйвер подойдет.

NvDriver

Остался еще один штрих, придумать, как автоматически формировать адрес каждого параметра. Для того, чтобы адрес высчитывался автоматически, необходимо, чтобы все параметры для EEPROM были зарегистрированы в каком-нибудь списке. Тогда список может сам посчитать адрес параметра по его положению в списке и собственно вернуть его когда надо.

Например, если у нас есть 3 параметра:

//Длина параметра 6 байтconstexpr CachedNvData<NvVarList, tString6, myStrDefaultValue,  nvDriver> myStrData;//Длина параметра 4 байтаconstexpr CachedNvData<NvVarList, float, myFloatDataDefaultValue, nvDriver> myFloatData;//Длина параметра 4 байтconstexpr CachedNvData<NvVarList, std::uint32_t, myUint32DefaultValue,  nvDriver> myUint32Data; 

То когда мы сделаем какой-то такой список:

NvVarList<100U, myStrData, myFloatData, myUint32Data>

У нас бы у myStrData был бы адрес 100, у myFloatData - 106, а у myUint32Data - 110. Ну и соответственно список мог бы его вернуть для каждого из параметра.

Собственно нужно чтобы этому списку передавался начальный адрес, и список параметров в EEPROM. Также нужно чтобы у списка был метод GetAdress(), который возвращал бы адрес нужного параметра.

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

Сделаем такой базовый класс, назовем его NvVarListBase:

NvVarListBase

В прицнипе то и все.

Код

А теперь самая простая часть - пишем код. Комментировать не буду, вроде бы и так понятно

CaсhedNvData

template<typename NvList, typename T, const T& defaultValue, const auto& nvDriver>class CaсhedNvData{  public:    ReturnCode Set(T value) const    {      //Ищем адрес EEPROM параметра в списке       constexpr auto address =                 NvList::template GetAddress<NvList,T,defaultValue,nvDriver>();      //Записываем новое значение в EEPROM      ReturnCode returnCode = nvDriver.Set(                                address,                                reinterpret_cast<const tNvData*>(&value), sizeof(T));      //Если значение записалось успешно, обновляем копию в ОЗУ      if (!returnCode)      {        memcpy((void*)&data, (void*)&value, sizeof(T));      }      return returnCode;    }    ReturnCode Init() const    {      constexpr auto address =                 NvList::template GetAddress<NvList,T,defaultValue,nvDriver>();      //Читаем значение из EEPROM      ReturnCode returnCode = nvDriver.Get(                                address,                                 reinterpret_cast<tNvData*>(&data), sizeof(T));      //Tесли значение не прочиталось из EEPROM, устанавливаем значение по умолчанию      if (returnCode)      {        data = defaultValue;      }      return returnCode;    }    T Get() const    {      return data;    }        using Type = T;  private:    inline static T data = defaultValue;};

template<const tNvAddress startAddress, const auto& ...nvVars>struct NvVarListBase{        template<typename NvList, typename T, const T& defaultValue, const auto& nvDriver>    constexpr static size_t GetAddress()    {       //Ищем EEPROM адрес параметра с типом       //CaсhedNvData<NvList, T, defaultValue, nvDriver>      using tQueriedType = CaсhedNvData<NvList, T, defaultValue, nvDriver>;                  return startAddress +             GetAddressOffset<tQueriedType>(NvVarListBase<startAddress,nvVars...>());    }      private:       template <typename QueriedType, const auto& arg, const auto&... args>       constexpr static size_t GetAddressOffset(NvVarListBase<startAddress, arg, args...>)   {    //Чтобы узнать тип первого аргумента в списке,     //создаем объект такого же типа как и первый аргумент    auto test = arg;    //если тип созданного объекта такой же как и искомый, то заканчиваем итерации    if constexpr (std::is_same<decltype(test), QueriedType>::value)    {        return  0U;    } else    {      //Иначе увеличиваем адрес на размер типа параметра и переходим к       //следующему параметру в списке.        return sizeof(typename decltype(test)::Type) +                 GetAddressOffset<QueriedType>(NvVarListBase<startAddress, args...>());    }  }    };

Использование

А теперь встанем не место студента и попробуем это все дело использовать.

Задаем начальные значения параметров:

using tString6 = std::array<char, 6U>;inline constexpr float myFloatDataDefaultValue = 10.0f;inline constexpr tString6 myStrDefaultValue = {"Habr "};inline constexpr std::uint32_t myUint32DefaultValue = 0x30313233;

Зададем сами параметры:

//поскольку список ссылается на параметры, а параметры на список. //Используем forward declarationstruct NvVarList;   constexpr NvDriver nvDriver;//Теперь можем использовать NvVarList в шаблоне EEPROM параметровconstexpr CaсhedNvData<NvVarList, float, myFloatDataDefaultValue, nvDriver> myFloatData;constexpr CaсhedNvData<NvVarList, tString6, myStrDefaultValue,  nvDriver> myStrData;constexpr CaсhedNvData<NvVarList, uint32_t, myUint32DefaultValue,  nvDriver> myUint32Data;

Теперь осталось определить сам список параметров. Важно, чтобы все EEPROM параметры были разных типов. Можно в принципе вставить статическую проверку на это в NvVarListBase, но не будем.

struct NvVarList : public NvVarListBase<0, myStrData, myFloatData, myUint32Data>{};

А теперь можем использовать наши параметры хоть где, очень просто и элементарно:

struct NvVarList;constexpr NvDriver nvDriver;using tString6 = std::array<char, 6U>;inline constexpr float myFloatDataDefaultValue = 10.0f;inline constexpr tString6 myStrDefaultValue = {"Habr "};inline constexpr uint32_t myUint32DefaultValue = 0x30313233;constexpr CaсhedNvData<NvVarList, float, myFloatDataDefaultValue, nvDriver> myFloatData;constexpr CaсhedNvData<NvVarList, tString6, myStrDefaultValue,  nvDriver> myStrData;constexpr CaсhedNvData<NvVarList, uint32_t, myUint32DefaultValue,  nvDriver> myUint32Data;struct NvVarList : public NvVarListBase<0, myStrData, myFloatData, myUint32Data>{};int main(){        myStrData.Init();    myFloatData.Init();    myUint32Data.Init()        myStrData.Get();    returnCode = myStrData.Set(tString6{"Hello"});    if (!returnCode)    {        std::cout << "Hello has been written" << std::endl;    }    myStrData.Get();    myFloatData.Set(37.2F);        myUint32Data.Set(0x30313233);        return 1;}

Можно передавать ссылку на них в любой класс, через конструктор или шаблон.

template<const auto& param>struct SuperSubsystem{  void SomeMethod()  {    std::cout << "SuperSubsystem read param" << param.Get() << std::endl;   }};int main(){    SuperSubsystem<myFloatData> superSystem;  superSystem.SomeMethod();}

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

Ссылка на пример кода тут: https://godbolt.org/z/W5fPjh6ae

P.S Хотел еще рассказать про то, как можно реализовать драйвер работы с EEPROM через QSPI (студенты слишком долго понимали как он работает), но слишком разношерстный получался контекст, поэтому думаю описать это в другой статье, если конечно будет интересно.

Заказывая много оценочных плат из Китая, я и подумать не мог что всюду будет брак, недоработки и подделка. Всё это ужасно путало в изучении и порой было тяжело понять то ли мой код кривой, то ли контроллер. Примерно в это же время я нашёл микроконтроллеры и другую рассыпуху дешевле чем в Китае при это локально в России. Я сразу загорелся тем, что бы сделать себе платы и забыть о китайских корявых blue pill.

Земля на ножках для прошивки висела в воздухе, после доработки всё окей.

Я как раз переезжал, и из-за этого у меня появилось много свободного времени, чем я и воспользовался, когда рисовал платы в EDA. Начать было решено с STM8S003F3U6 потому как очень уж полюбилась мне эта серия микроконтроллеров.

v1

Тут я ещё не знал, что для нормальной прошивки мк нужен pull-up резистор на ногу сброса.

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

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

В итоге у меня было куча плат, с пяток контроллеров и разных вторичных компонентов, выпаянных из разных плат. Всё это вылилось в 3 рабочих прототипа.

В итоге у меня было куча плат, с пяток контроллеров и разных вторичных компонентов, выпаянных из разных плат. Всё это вылилось в 3 рабочих прототипа:

Немного о платах

Остановился на 6 светодиодах. Всего 3 группы: питание, 4 GPIO, 1 GPIO(ШИМ) на обратной стороне. У каждой группы есть маленькая напаиваемая перемычка.

USB только питание, по входу стоит диод, защита usb выхода от обратного напряжения которое может пойти если запитать схему >5в напряжением. Стабилизатор выдерживает пиковые 16в, штатное до 14в.

Контроллер может без проблем работать и от 5в, но расчёт резисторов для светодиодов выполнял для 3.3, да и базово считаю что лучше работать с 3.3, ибо потом по привычке можно что-нибудь спалить.

Продолжаем вакханалию

Это была только половина пути, я ведь хотел много плат и очень не хотел делать их вручную.

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

И так, надо было решать как спаять всё быстро и с минимумом косяков. Трафарета у меня не было и я решил попробовать просто намазать тонким слоем паяльную пасту (благо она была).

Сказано сделано, вот что из этого вышло:

Мелкие капельки припоя что никуда не стекли прилипли прилично, далеко не с первого раза я их смог убрать, так же видно что 2 контроллера немного поплыли и встали криво. Выглядит жуть, но в целом получилось неплохо. Я делал несколько прогонов, первый мк и обвязка, остальное вторым. И по выходу получилось около 70% годных и готовых сразу без танцев плат.

Финальный результат, usb портов к этому времени не подвезли, так что без них.

Пока остановился на этом, с новой партией плат должен прийти трафарет, там уже будут другие танцы и другие бубны.

Планы у меня наполеоновские, уже нарисовал и под stm32f0 и под f1 платы, ещё есть идея создать плату на stm32f4(7) с интегрированных ethernet.

В следующей статье затрону контроллер и среды, в которых пишу. Ни пуха ни пера и не болейте!

Продолжим анализировать какие иностранные микросхемы используются в России на основании таможенной статистики. Как мы это делаем ? Из данных ФТС выбираем записи в которых указан номинал ввезенной микросхемы, и используя внутреннюю базу данных дополняем эту запись основными параметрами микросхемы, начиная от производителя, разрядностями, диапазонами питания и заканчивая типом корпуса, упаковки и так далее. В данной части посмотрим АЦП/ЦАП и микроконтроллеры.

АЦП/ЦАП

Все типы аналого-цифровых и цифро-аналоговых преобразователей согласно нашей базе разбит на группы:
- АЦП - преобразователи аналогового сигнала в цифру;
- ЦАП - преобразователи цифры в аналоговый сигнал;
- совмещенные АЦП/ЦАП (обычно это разные аудио АЦП/ЦАП, но без кодеков, которые идут другой группой);
- Analog Front End (AFE) - схемы цифро-аналогового и аналого-цифрового преобразования (обычно используются для радиосвязи);
- цифровые потенциометры - схемы совмещающие датчик и АЦП/ЦАП используемые как датчики температуры.

Больше всего ввозится микросхем AFE - радиоприемопередатчики, но не имеющие в своем составе процесорных ядер - более 182К штук. Самым популярным АЦП является ADS1000A0IDBV. Самым популярным ЦАП - DAC6311IDCK. Самым популярным аудио АЦП/ЦАП - PCM5102APWR. Самый популярный RF приемопередатчик - CC1020RSSR. А самый популярный цифровой датчик - DS18B20+. Практически все от Texas Instruments.

Самыми маржинальными оказались Аудио АЦП/ЦАП - наверное любители звука готовы переплачивать не только за безкислородный медный кабель. Какие же фирмы лидируют на данном рынке?

Texas Instruments выпускает самые популярные микросхемы и поставляет больше всего аналого-цифровых микросхем.

АЦП

Самая популярная разрядность чистых АЦП - 12 бит

16 и более - это в основной сигма-дельта АЦП, которые точные, но обычно не очень быстрые. Какая же самая популярная частота выборки? По частоте преобразования для АЦП распределение выглядит следующим образом

Самый крутой АЦП, который официально ввезли в Россию - AD9208BBPZ-3000 (14 бит @ 3GSPS).

ЦАП

Распределение ЦАП по разрядности

Распределение скорости преобразования ЦАП

Микроконтроллеры

Из проанализированных примерно 1 млн микроконтроллеров - самые популярные в России микроконтроллеры от Микрочип (479К), STM(305К) и NXP (126К).

Самым популярным при этом является микроконтроллер STM8S003F3P6TR. Как это ни странно, но до сих пор 8-ми битные МК самые популярные. Но это скорее всего опять таки из за того, что таможня не видит все ввозимые микроконтроллеры.

Сколько памяти нужно для решения микроконтроллерных задач ?

По тактовым частотам работы микроконтроллеров следующее распределение

По числу выводов корпуса распределение следующее (к сожалению не для всех номиналов у нас были данные)

Итого

В результате среднестатистические АЦП и ЦАП на нашем рынке имеют разрядность 12 бит. Скорость преобразования АЦП на уровне 1 MSPS, а время преобразования ЦАП на уровне от 1KSPS до 100KSPS. Обе микросхемы будут от Texas Insruments. Среднестатистический микроконтроллер будет 8-ми битным, с 16 выводами и 8 Кбайтами Flash, работать с тактовой частотой до 16-20 МГц и выпущенный Микрочипом.

В третьей части статьи будут рассмотрены микросхемы памяти.

Здравствуйте! Меня зовут Александр, я работаю инженером-программистом микроконтроллеров.

Пишу на С/С++, причем предпочитаю плюсы, ибо верую в их эволюционную неизбежность в embedded.

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

Я стараюсь следовать этому очевидному посылу, благо небожители ведущие С++ программисты и консультанты щедро делятся своим опытом и идеями на разных площадках (например здесь, или здесь).

Некоторое время назад я посмотрел мощный доклад Сергея Федорова про построение конечного автомата с таблицей переходов на шаблонах.

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

// Transition table definitionusing transitions =  transition_table<  /*  State       Event       Next       */  tr< initial,    start,      running    >,  tr< running,    stop,       terminated >>;};// State machine objectusing minimal = state_machine<transitions>;minimal fsm;//...and then callfsm.process_event(start{});fsm.process_event(stop{});

А если добавить к этому перенос части функциональности кода в компайл тайм, заявленную автором потокобезопасность, улучшенные по сравнению с Boost::MSM выразительность, читаемость кода и скорость сборки, header only модель библиотеки, то - надо брать, решил я.

Вот только попытка собрать и запустить даже простейший пример на STM-ке закончилась матерком компилятора: "cannot use 'typeid' with "-fno-rtti" и "exception handling disabled".

Да, все так. Более того, помимо отключенной поддержки RTTI и исключений, у меня также выставлены флаги -fno-cxa-atexit, -fno-threadsafe-static. А еще в линкере применены настройки --specs=nano.specs (используем урезанную версию стандартной библиотеки с++ newlib-nano), --specs=nosys.specs (применяем легковесные заглушки для системных вызовов).

Исходники проекта докладчика, включая зависимости, - это двадцать файлов со смертоноснейшей шаблонной магией. Перекроить их так, чтобы не юзать typeid и exceptions, простому смертному в моем лице - too much.

Делать нечего, поступимся принципами, включим поддержку RTTI, а вместо throw в исходниках автора проставим заглушки.

На этот раз все собралось. Вот только при использовании тулчейна gcc-arm-none-eabi-9-2020-q2-update и уровне оптимизации -O3, размер исполняемого файла превысил 200Кб.

Это несколько огорчительно, хотя какие могут быть претензии - библиотека изначально разрабатывалась под "большого брата".

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

Итак, с наскоку взять высоту не удалось, и я на некоторое время переключился на другие задачи. Но красота идеи меня не отпускала, и на днях я все-таки решился "достучаться до небес" - написать extra light embedded версию FSM из упомянутого доклада самостоятельно.

Уточню свои хотелки:

• Оперировать состояниями, эвентами и действиями как пользовательскими типами.

• Таблицу переходов реализовать в виде шаблонного параметра

• Перетащить что возможно в компайл тайм

• Асинхронно и атомарно постить эвенты

• Переключать состояния за константное время

• Выйти в итоге на приемлемый по меркам встроенного ПО размер кода

• Повторить header only модель библиотеки

Забегая вперед, скажу, что в итоге что-то получилось и даже взлетело.

А вот как - не сочтите за труд, давайте посмотрим вместе. И не сдерживайте себя в метании тухлых яиц, ибо лучшей питательной среды для самосовершенстования трудно представить.

Первым делом опишем базовые сущности:

struct StateBase{};template <base_t N, typename Action = void>struct State : StateBase{  static constexpr base_t idx = N;  using action_t = Action;  };

Здесь и далее base_t - платформозависимый тип, машинное слово. В моем случае это unsigned int.

Состояния пусть будут двух типов - пассивное, в котором никаких действий не происходит, и активное - при нахождении в котором будет выполнятся переданный шаблонным параметром функтор, action_t.

Цель статического члена idx уточню далее по тексту.

struct EventBase{};template <base_t N>struct Event : EventBase{  static constexpr base_t idx = N;};

Элементарная структура, все ясно.

Действие при наступлении события и смене состояний:

struct action{  void operator()(void){    // do something};

Безусловно, сигнатура operator() может и должна варьироваться от задач приложения, пока же для упрощения остановимся на самом легковесном варианте.

Сторож состояния:

enum class Guard : base_t{  OFF,  CONDITION_1,  CONDITION_2,  //etc.};

Идея сторожа - допустить переход в новое состояние, только если в данный момент выполнения программы текущее значение сторожа соответствует заданному пользователем значению в типе перехода/transition-a. Если такого соответствия нет, то переход в новое состояние не происходит. Но тут возможны варианты. Например, все же переходить, но не выполнять действие, переданное в состояние. Up to you.

Итак, пока все тривиально. Идем дальше.

Переход:

struct TrBase{};template <typename Source,          typename Event,          typename Target,          typename Action,          Guard G,          class =          std::enable_if_t<std::is_base_of_v<StateBase, Source>&&          std::is_base_of_v<EventBase, Event> &&          std::is_base_of_v<StateBase, Target>>          >  struct Tr : TrBase{  using source_t = Source;  using event_t  = Event;  using target_t = Target;  using action_t = Action;    static constexpr Guard guard = G;};

Структура Tr тоже элементарна. Она параметризуется типом исходного состояния - Source, типом события Event, по наступлению которого произойдет переход в целевое состояние Target, и типом Guard.

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

Таблица переходов:

struct TransitionTableBase{};template<typename... T>struct TransitionTable : TransitionTableBase{    using test_t = typename NoDuplicates<Collection<T...>>::Result;    static_assert(std::is_same_v<test_t, Collection<T...>>,                "Repeated transitions");    using transition_p = type_pack<T...>;    using state_collection = typename NoDuplicates   <Collection<typename T::source_t... ,typename T::target_t...>   >::Result;    using event_collection = typename NoDuplicates  <Collection<typename T::event_t...>    >::Result;    using state_v = decltype(get_var(state_collection{}));  using event_v = decltype(get_var(event_collection{}));  using transition_v = std::variant<T...>;};

Нуу, тут я набросил на вентилятор, конечно. Хотя все не настолько пугающе, как выглядит.

Структура TransitionTable параметризуется списком переходов/transition-ов, которые собственно и описывают всю логику конечного автомата.

Первым делом нам необходимо подстраховать себя от копипаста и просигналить при компиляции, что у нас повторы в списке. Исполняем это с помощью алгоритма NoDuplicates из всем известной библиотеки Loki. Результирующий тип под псевдонимом test_t сравниваем в static_assert-e с исходным списком переходов.

Далее, допуская что static_assert пройден, параметризуем некую структуру type_pack списком переходов и выведенному типу назначаем псевдоним transition_p. Структура type_pack, а также современные алгоритмы и методы по работе со списками типов собраны в файле typelist.h. Данный хедер написан под чутким руководством этого продвинутого парня.

Тип transition_p понадобится нам далее в конструкторе класса StateMachine.

Следом проходим по списку переходов, вытаскиваем, очищаем от повторов и сохраняем в отдельные коллекции состояния и эвенты. Эти коллекции alias-им как state_collection и event_collection соответственно.

К чему эта эквилибристика?

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

Удобным вариантом для этой цели является std::variant (тафтология умышленна).

Последовательно параметризуем std::variant списком переходов (выведенному типу назначим псевдоним transition_v); списком состояний и списком эвентов и назначаем для удобства псевдонимы state_v и event_v соответственно.

Тут нюанс. Чтобы вывести transition_v нам достаточно пробросить в шаблонный параметр std::variant variadic pack (T...) из шаблонного параметра класса TransitionTable.

А вот чтобы вывести state_v и event_v мы используем

template<typename... Types>constexpr auto get_var (th::Collection<Types...>){return std::variant<Types...>{};}

Далее мы инстанцируем получившиеся типы в конструкторе класса StateMachine и сохраним их для дальнейшего использования в подходящих контейнерах, о чем совсем скоро.

Оставшихся к этому моменту читателей я не обрадую - начинается основной замес.

Целиком приводить класс StateMachine не буду, он громоздок, прокомментирую его для удобства восприятия по частям.

template<typename Table>class StateMachine{//other stuffprivate:using map_type =std::unordered_map < Key, transition_v, KeyHash, KeyEqual>;Key key;map_type transitions;};

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

Объект типа Key хранит у себя значения индексов состояния и эвента:

struct Key{  base_t state_idx = 0;  base_t event_idx = 0;};

Теперь стало понятно назначение статических членов idx в базовых сущностях. Я просто не знаю, как писать хэшеры для пустых структур. Тащить в строку название самого типа через typeid и _cxa_demangle для нас не вариант, мы же условились, что не пользуем RTTI.

template<typename Table>class StateMachine{//other stuffprivate:using queue_type =  RingBufferPO2 <EVENT_STACK_SIZE, event_v, Atomic>;    queue_type events;};

events - очередь, в которую будут прилетать эвенты. Так как это чисто рантаймовая история, необходимо избежать динамических аллокаций. Поэтому реализуем ее на базе статического кольцевого буффера RingBufferPO2, который я позаимствовал здесь (отличная для своего времени работа!).

Помимо указанных контейнеров, в объекте типа StateMachine мы будем хранить текущее состояние/state и значение сторожа/guard:

template<typename Table>class StateMachine{//other stuffprivate:state_v current_state;Guard guard = Guard::OFF;};

Саспенс уже не за горами.

template<typename Table>class StateMachine{public:using transition_pack = typename Table::transition_p;StateMachine(){  set(transition_pack{});} // other stuff};

В конструкторе метод set принимает аргументом объект с информацией о списке переходов, пробегается по нему, достает инфо о каждом состоянии и эвенте, заполняет контейнер transitions, а также запоминает начальные состояние и значение сторожа:

template <class... Ts>void set (type_pack<Ts...>){(set_impl(just_type<Ts>{}), ...);};template <typename T>void set_impl (just_type<T> t){using transition = typename decltype(t)::type;using state_t = typename transition::source_t;using event_t = typename transition::event_t;Guard g = transition::guard;Key k;k.state_idx = state_t::idx;k.event_idx = event_t::idx;transitions.insert( {k, transition{}} );if (0 == key.state_idx) {key.state_idx = k.state_idx;guard = g;current_state = state_t{};}}

Итак, объект StateMachine сконструирован, пора его как-то шевелить.

Но перед этим забудем как страшный сон суммируем что уже рассмотрели к этому моменту:

• Определили типы компонентов конечного автомата: состояние/state, событие/event, действие/action, сторож/guard

• Определили тип переход/transition, который должен параметризоваться типами source state, event, target state, guard.

• Определили тип таблицы переходов. В качестве шаблонных параметров ему передается список переходов/transition-ов, который и определяет алгоритмы работы автомата.

• При компиляции в классе TransitionTable, на основе std::variant выводятся типы-коллекции переходов, состояний и эвентов, которые впоследствии при конструировании объекта StateMachine инстанцируются и сохраняются в контейнеры, с которыми уже можно работать в рантайме.

Стержневая идея моей имплементации автомата такова (вдохнули): при наступлении события, мы достаем из его типа индекс (idx), объединяем его с индексом текущего состояния в объекте Key, по которому в контейнере transitions находим нужный нам переход, где получаем знания о целевом состоянии, стороже и действии, которое требуется выполнить в этом переходе, а также сверяем значения сторожа с текущим, для подтверждения или отмены перехода/действия(выдохнули).

Теперь рассмотрим методы API нашего автомата, реализующие эту логику.

Переключать состояния мы можем двумя способами: вызывать немедленный переход методом fsm.on_event(event{}) (шаблонная версиия fsm.on_event<Event>() если тип события известен на этапе проектирования), или можем складывать события в очередь методом fsm.push_event(event{}), чтобы потом, например в основном цикле, разобрать ее методом fsm.process(). Также, если в состояние передано какое-то действие, то мы можем вызывать его методом fsm.state_action().

Рассмотрим их детальнее, начиная с последнего

template <typename... Args>void state_action (const Args&... args){state_v temp_v{current_state};    auto l = [&](const auto& arg){      using state_t =  std::decay_t<decltype(arg)>;    using functor_t = typename state_t::action_t;        if constexpr (!std::is_same_v<functor_t, void>){    functor_t{}(args...);      }  };    std::visit(l, temp_v);}  

В методе мы создаем локальную переменную типа std::variant<State...> temp_v и инициализируем ее текущим состоянием. Далее определяем лямбду, которая послужит аргументом в методе std::visit.

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

Знаю, что иногда лямбда может юзать кучу, но похоже, это не мой случай. Поправьте меня, пожалуйста, если я заблуждаюсь. В этом случае не сложно будет заменить лямбду на callable object.

template <typename Event,class = std::enable_if_t<std::is_base_of_v<EventBase, Event>>>void on_event(const Event& e){Key k;  k.event_idx = e.idx;  k.state_idx = key.state_idx;  on_event_impl(k);}void on_event_impl (Key& k){transition_v tr_var = transitions[k];    Key &ref_k = key;  Guard &ref_g = guard;  state_v &ref_state = current_state;    auto l = [&](const auto& arg){    using tr_t =  std::decay_t<decltype(arg)>;    using functor_t = typename tr_t::action_t;        if ( GuardEqual{}(ref_g, tr_t::guard) ){          using target_t = typename tr_t::target_t;            ref_k.state_idx = target_t::idx;      ref_state = target_t{};            functor_t{}();      }   };      std::visit(l, tr_var);}

Здесь, как я уже описывал, мы достаем индекс из эвента, объединяем его в Key с индексом текущего состояния, и в качестве ключа передаем в приватный метод on_event_impl(Key& k).

Там мы по принятому ключу достаем из контенера transitions объект типа std::variant<Tr...> и инициализируем им локальную переменную tr_var. Ну а далее - логика, схожая с предыдущим примером. Вызываем std::visit c tr_var и лямдой l, в которой из типа Tr получаем сведения о состоянии, в которое нужно перейти (target_t), стороже (tr_t::guard)и типе действия (functor_t) к исполнению.

Сверив значение сторожа перехода с текущим сторожем, мы или оcуществляем переход, инстанцируя и вызывая functor_t, и сохраняя target_t в переменную с текущим состоянием(current_state), или возвращаемся в исходное состояние. Где ждем смены значения сторожа и нового события.

template <unsigned int N>void push_event (const Event<N>& e){  events.push_back(e);}

Тут все просто.

void set_guard (const Guard& g){  guard = g;}

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

void process (void){    state_action();    auto it = transitions.begin();    Key k;  k.state_idx = key.state_idx;    for (uint32_t i = 0; i != events.size(); ++i){        auto v = events.front();     auto l = [&](const auto& arg){      using event_t =  std::decay_t<decltype(arg)>;      k.event_idx = event_t::idx;      it = transitions.find(k);    }        std::visit(l, v);        if ( it != transitions.end() ){            events.pop_front();      on_event_impl(k);      return;        } else {      events.push_back(v);      events.pop_front();    }  }}

При вызове метода мы первым делом выполняем некое полезное действие (если не void), переданное в состояние, state_action().

Ну а далее пробегаемся по очереди эвентов и просто воспроизводим логику, уже описанную для метода fsm.on_event(event{}).

Разумеется, работу с событиями можно значительно ускорить, при этом расширив функционал автомата. Тип Event модернизируем

template <base_t N, base_t Priority>struct Event : EventBase{  static constexpr base_t idx = N;  static constexpr base_t pri = Priority;};

Теперь мы можем не пушить все события в одну очередь, а завести, скажем, std::array<queue_t, PRIRITY_NUM>, где индексом ячейки будет служить приоритет события. Тогда у нас получится приняв эвент, вытащить его приоритет, по нему, как по индексу за константное время попасть в нужную очередь событий, которая будет гораздо меньше, чем общая и быстрее в обработке.

И, что не менее важно, так мы сможем прыгать между состояниями не по очередности принятых эвентов, но по их приоритету.

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

Хорошо, каков же будет практический результат этой разнузданной шаблонной вакханалии?

struct green_a {/*toogle green led every 50ms*/}struct yellow_a {/*toogle yellow led every 50ms*/}struct red_a {/*toogle red led every 50ms*/}struct green_f {/*toogle green led every 150ms*/}struct yellow_f {/*toogle yellow led every 150ms*/}struct red_f {/*toogle red led every 150ms*/}using STATE_A(green_s, green_f);using STATE_A(yellow_s, yellow_f);using STATE_A(red_s, red_f);using EVENT(green_e);using EVENT(yellow_e);using EVENT(red_e);using fsm_table = TransitionTable    <    Tr<green_s, yellow_e, yellow_s, yellow_a, Guard::NO_GUARD>,    Tr<yellow_s, red_e, red_s, red_a, Guard::NO_GUARD>,    Tr<red_s, green_e, green_s, green_a, Guard::NO_GUARD>    >;int main(void){  //some other stuff  StateMachine<fsm_table> fsm;  fsm.push_event(red_e{});  fsm.push_event(yellow_e{});  fsm.push_event(green_e{});  while (1){    fsm.process();  }}

В этом примере структуры типа color_a(ction) - это действия при переходе; color_f(unctor) - функторы, которые будут выполняться каждый раз при заходе в стейт, ну и далее понятно.

Объявляем стейты, эвенты, переходы, таблицу переходов. Конструируем из класса StateMachine<fsm_table> наш конечный автомат fsm. Пушим события, заходим в while и наблюдаем аквасветодискотеку на нашей отладке.

Обращу еще ваше внимание на макросы, через которые организована декларация состояний и событий. Задача была исхитриться и не делать так:

using even_t = Event<1, 15>;

using state_t = State<1, state_functor>;

Очевидно, почему это плохо. Ручная индексация - практически неизбежные ошибки и очепятки.

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

#define STATE_A(str, act) str = State<name(#str), act>#define EVENT(str) str = Event<name(#str)>constexpr base_t name (const char* n){    base_t  res = 0;    for (base_t i = 0; n[i] != '\0'; i++){        char data = n[i];        for (base_t j = sizeof (char) * 8; j > 0; j--){            res = ((res ^ data) & 1) ? (res >> 1) ^ 0x8C : (res >> 1);      data >>= 1;    }  }  return res;};

После крайнего проекта на работе у меня на руках осталась отладка NUCLEO-H743ZI2, на ней я и запилил тестовый вариант (забирайте здесь).

С оптимизацией -O3 реализация приведенного примера (только сам FSM) заняла 6,8Кб, с HAL-ом и моргалками - 14,4Кб.

Конечно же, пока это не более чем эксперимент, проверка концепции. Но агрегат завелся, черт его дери.

Будет очень здорово, если сообщество укажет на неизбежные факапы и укажет путь к улучшениям. Также смею надеяться, что кто-то выделит из материала и что-то полезное для себя.

Спасибо за внимание!

Доброго времени суток!

Меня зовут Александр, я работаю программистом микроконтроллеров, и это история о Фрэнки.

. . .Фрэнки родился чуднм. Родителями были пионэрский задор вашего автора и требования заказчика.

Когда младенца скомпилировали и по его венам потекли животворные байты, мой коллега процедил:

- Вы слепили монстра, герр Франкейштейн, но он не лишен некоторого очарования. . .

В то время я писал прошивку для станка с ЧПУ, причем заказчик наложил ограничения - строго Си, никаких сторонних библиотек, допускался только HAL с открытыми исходниками от производителя МК.

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

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

Ну хорошо, а какой тогда должна быть архитектура приложения, когда нет итогового ТЗ и при этом низзя(!) ни в какие сторонние РТОСы и диспетчеры? Как выстроить программу, чтобы не перелопачивать все исходники, если вдруг осознаешь в середине проекта, что логику нужно править?

Напрашивался принцип конструктора Лего. Детальки разных размеров и цветов с унифицированным креплением дают большое разнообразие форм и неограниченные перспективы расширения.

Объединив эту аналогию с возможностью корректно декомпозировать workflow станка на набор состояний, я сформулировал следующие принципы будущей программы:

1. каждое состояние (стейт) - одна деталька Лего

2. связь между стейтами через единый интерфейс

3. что именно делает стейт должно быть понятно с первого взгляда

Пункт 3 требует детализации:

3.1. логика внутри стейтов будет описана независимыми модулями

3.2. модули должны быть самодокументированы

3.3. один модуль - одна строка кода

3.4. модули будут подписываются на уведомления от внешнего окружения и внутри стейта

3.5. модули общаются между собой и внешним окружением через message box

Ну и нацелился я написать все это так, чтобы заглянув в исходники через полгода, не вытекли глаза.

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

Станок мы в итоге разработали, оттестировали и сдали. Пока, тьфу-тьфу, фурычит без нареканий.

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

Плюсы настолько могучи, что весь бывший сишный код проекта я уместил всего в две строчки:

int main (void){    //some vendor's HAL stuff    Device device;    while(1){        device.action();    }}

Эх, с девочкой продакт-менеджером это бы прокатило, но вас-то не проведешь :)

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

class StateSlow final: public StateInterface<StateSlow> {private:void on_enter_impl (void) {     // some state's specific code  }void tracks_go_impl (void) {Track< topic::no, 500, restart_blink_slow >::go(topic::green);Track< topic::green, 250, toggle_green >::go(topic::yellow);Track< topic::yellow, 250, toggle_yellow >::go(topic::red);Track< topic::red, 250, toggle_red >::go(topic::green);Track< topic::no, 5000, stop_blink >::go(topic::state);Track< topic::state, 0, breaker >::go(msg::exit);}States_e on_exit_impl (void) {States_e next_state = States_e::SF;if ( DeviceHandler::get_failed_track() ) {next_state = States_e::ES;} else if ( Post::get_msg(msg::exit).confirmed ){next_state = States_e::SS;}if (next_state != States_e::SF){DeviceHandler::set_state_status(status_e::stopped);}return next_state;}friend class StateInterface<StateSlow>;};using SS = StateInterface<StateSlow>;

Этот пример взят из тестового проекта, ссылку на который вы найдете в конце статьи.

Здесь стейт - это класс StateSlow, который наследует единый интерфейс от класса StateInterface. Для реализации статического полиморфизма применен паттерн CRTP, но об этом чуть позже.

В интерфейсе всего три метода:

• on_enter_impl(). В нем при первом заходе в стейт выполняется работа, специфичная для конкретного стейта.

• tracks_go_impl(). Здесь поочередно вызываются модули/Tracks, собственно и реализующие функционал стейта. У модулей есть общие черты с т.н. сопрограммами/корутинами. Но так как все удобные подходящие имена уже заняты (coroutines, fibers, threads), я окрестил их tracks в значении путь/тропа/курс. Track вызывается или по подписке, или по таймеру, или по обоим вместе; может быть вызван единожды или многократно. В качестве полезной нагрузки принимает в себя указатель на функцию с произвольным количеством аргументов.

• one_exit_impl(). В этом методе мы разбираем результаты работы стейта, возникшие ошибки и по итогам определяем в какой стейт прыгаем дальше. Если работа стейта пока не окончена и все штатно, остаемся в текущем стейте. Конкретно в приведенном выше фрагменте кода, мы последовательно проверяем два условия:

• есть ли "упавшие" track-и, и при наличии таковых переходим в ErrorState.

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

Итак, что же конкретно происходит в приведенном стейте? Читаем сверху вниз.

Метод on_enter_impl() пуст - никакой специфичной работы при каждом входе в стейт выполнять не нужно.

В tracks_go_impl() выполняются 6 треков. Первый не подписан ни на какое уведомление (topic::no), запустится по таймеру через 500мс с момента первого входа в стейт и выполнит переданную параметром шаблона функцию restart_blink_slow(). Последняя принимает в качестве аргумента уведомление topic::green и при своем вызове отправляет его подписчику. По завершении restart_blink_slow() возвращает код ret_e::оk, отключая свой трек.

Второй трек подписан на уведомление topic::green, при его получении он запустится по таймеру через 250мс и выполнит переданную ему функцию toggle_green(), передав ей как аргумент уведомление topic::yellow. Функция toggle_green() выполнит свою работу, вышлет подписчикам уведомление topic::yellow и вернет код ret_e::repeat, перезапустив свой трек.

Функции, передаваемые в треки могут принимать произвольное количество аргументов, и по соглашению фреймворка должны возвращать один из трех кодов. Код ret_e::repeat перезапускает трек; код ret_e::ok отключает трек; код ret_e::err отключает трек и сохраняет в классе DeviceHandler (о нем чуть позже) номер "упавшего" трека для последующей обработки ошибок в методе on_exit_impl().

Оставшие треки считываем аналогично, а метод one_exit_impl() мы уже рассмотрели выше.

Ну и в конце мы назначаем короткий alias для имени стейта, что пригодится нам позднее.

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

Начнем с основного фрагмента ДНК Фрэнки - с состояния (стейта).

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

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

Виртуальный интерфейс нам, как разработчикам встроенного ПО, не очень подходит, ибо vtable откусывает память, а сам виртуальный вызов стоит дорого. Поэтому воспользуемся комбинацией паттернов "CRTP" и "Шаблонный метод" (здесь и далее по тексту за разъяснением используемых техник направляю к этому автору). Еще раз взглянем, как рабочий стейт наследует базовому:

class StateSlow final: public StateInterface<StateSlow>{...}

Класс StateSlow наследует шаблонному классу StateInterface, параметризованному StateSlow. Этот рекурсивный трюк, определяющий саму природу паттерна CRTP, позволяет базовому классу еще на этапе компиляции получить информацию о классе-наследнике. Что дает нам возможность вызывать методы производного класса из объекта базового без дополнительных накладных расходов (пруф). Помотрим на реализацию базового класса:

template <typename T>class StateInterface{public:    using derived_t = T;using derived_ptr = T*;StateInterface(){}States_e operator() (void){on_enter();tracks_go();return on_exit();};private:derived_ptr derived(void){return static_cast<derived_ptr>(this);}void on_enter_impl (void){}void tracks_go_impl (void){}void on_enter_base (void){derived()->on_enter_impl();}States_e on_exit_base (void) {return derived()->on_exit_impl();}void on_enter (void) {if (DeviceHandler::get_state_status() == status_e::stopped){Publisher::clear_box();Post::clear_box();DeviceHandler::clear_state_param();DeviceHandler::set_state_status(status_e::active)ж              derived()->on_enter_base();}}void tracks_go (void) {derived()->tracks_go_impl();}States_e on_exit (void) {DeviceHandler::reset_track_cnt();return derived()->on_exit_base();}};

Это шаблонный класс, он параметризуется типом рабочего стейта. Его интерфейс определен сигнатурой operator(), и он нам уже знаком:

метод on_enter() содержит обязательную логику для всех стейтов, а также вызывает метод унаследованного стейта derived()->on_enter_base().

метод on_exit() также содержит логику, общую для всех стейтов, и вызывает метод унаследованного стейта derived()->on_exit_base().

метод tracks_go() подменяется вызовом метода derived()->tracks_go_impl() в котором содержится логика стейта, выраженная модулями/track-ами (см. выше).

Метод on_exit() возвращает тип перечисления States_e, по значению которого будет осуществляться переключение между стейтами:

#define STATESSF,SS,ESenum class States_e : base_t{  STATES};

Единственный дефайн кода фреймворка содержит список названий типов стейтов. Дефайны в С++ стараются не использовать, но в данном случае он оправдан, так как сокращает точки настройки проекта. Второй раз дефайн STATES используется в конструкторе класса Device, о чем чуть позже.

В приватном сегменте класса StateInterface требуют особых пояснений два метода-пустышки:

void on_enter_impl (void){}void tracks_go_impl (void){}

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

Общая обязательная логика при входе в стейт, реализованная в методе on_enter() самодокументирована и понятна.

Класс DeviceHandler предоставляет доступ к общим параметрам стейтов и треков. Класс Publisher ответственен за систему уведомлений. Класс Post процессирует систему сообщений. Сообщения, в отличие от уведомлений, могут нести payload - указатели на данные.

Эти три класса объединяет их дизайн - они реализованы через паттерн static Singleton. Действительно, мы пишем встроенное ПО, которое будет работать в одном конкретном устройстве, поэтому очевидно, что доступ к функционалу этих классов должен следовать принципу "одного окна".

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

Для примера приведу реализацию класса Post:

// in message.hpptypedef struct{void* body{nullptr};bool confirmed{false};}MessageParam;using post_t = std::array<MessageParam, MAX_MESSAGE_NUM>;class Post{public:  template<typename T>  static void push_msg (msg m, T* data);  static void push_msg (msg m);  static MessageParam& get_msg (msg m);  static void clear_box(void;private:  Post() = delete;Post(const Post&)= delete;Post& operator=(const Post&)= delete;static post_t mbox;static MessageParam res;};// in message.cpppost_t Post::mbox;MessageParam Post::res;             

Отправка сообщения с данными может выглядеть примерно так:

void some_func (void){  // some code    static UserType val{15, 20};    Post::push_message(msg, &val);}

Рассмотрим далее класс Track:

template<topic N, base_t T, auto* Func>struct Track{static_assert( !std::is_null_pointer_v<decltype(Func)> );template<typename... Args>static void go (Args... args){    bm_clock::duration dur;TrackParam& p = DeviceHandler::get_track_param(); switch (p.entry){    //track logic    }}};

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

Так как мы пишем в плюсовом окружении, для работы с таймером сподручно использовать инструментарий стандартной библиотеки <chrono>. Для этого нам необходимо переопределить стандартную функцию now(), возвращающую локальное время вашей системы. Возможную реализацию этого приема вы найдете в хедере bm_chrono.hpp.

Итак, к этому моменту нам понятна основная идея фреймворка; мы рассмотрели реализацию стейта и треков; выяснили, что взаимодействие между сущностями фреймворка и внешней средой осуществляется через сервисы уведомлений и сообщений.

Осталось прояснить, кто и как жонглирует состояниями.

class DeviceImpl;class Device{public:Device();void action(void);private:Device(const Device&)= delete;Device& operator=(const Device&)= delete;static DeviceImpl& impl(void);DeviceImpl& impl_;};

Класс Device реализован через паттерн Singleton в варианте Мейерса в комбинации с идиомой pimpl. Такой подход позволяет подчеркнуть разделение интерфейса класса от его реализации. Весь полезный функционал скрыт в классе DeviceImpl.

class DeviceImpl{public:using state_p = type_pack<STATES>;using state_v = std::variant<STATES>;using state_a = std::array<state_v, size(state_p{})>;constexpr DeviceImpl() : idx(0) {    set(state_p{});  }private:template <class... Ts>constexpr void set (type_pack<Ts...>){(set_impl(just_type<Ts>{}), ...);};template <typename T>constexpr void set_impl (just_type<T> t){using state_t = typename decltype(t)::type;std::size_t i = find(state_p{}, t);states[i].emplace<state_t>(state_t{});}public:state_a states;base_t idx;};

Класс DeviceImpl преимущественно в компайл тайм конструирует и сохраняет контейнер состояний(стейтов), переданных фреймворку. С помощью уже знакомого дефайна STATES мы выводим и алиасим необходимые типы. state_p - это просто пак типов стейтов. state_v - объект этого типа будет содержать конкретный стейт. state_a - тип контейнера стейтов.

В конструкторе DeviceImpl с помощью методов set() и set_impl() мы создаем объекты состояний и размещаем их в контейнере. Необходимые для этого размер контейнера и индексы мы вычисляем в компайл тайм с помощью constexpr функций size() и find(). Подробнее о них и других современных способах работы со списками типов рассказано здесь.

Вернемся к классу Device. В его конструкторе мы создаем объект DeviceImpl и сохраняем ссылку на него:

Device::Device() : impl_( impl() ){}DeviceImpl& Device::impl(void){static DeviceImpl instance;return instance;}

Переключение состояний реализовано в единственном методе класса Device - action().

void Device::action(void){base_t temp_idx;auto l = [&temp_idx](auto&& arg){    temp_idx = static_cast<base_t>( arg() );  };std::visit(l, impl_.states[impl_.idx]);impl_.idx = temp_idx;}

В нем мы создаем объект лямбды, выполняющей единственное действие - вызов оператора () у текущего стейта и получение кода возврата, который будет в качестве индекса контейнера указывать на ячейку со следующим стейтом. Передав в качестве параметра сконструированный объект лямбды в std::visit, мы посетим объект std::variant с текущим стейтом и сохраним код возврата в виде индекса.

Что ж, с теорией покончено, переходим к практике. Как пользоваться Фрэнки? Совсем несложно.

В заголовочнике defs.hpp алиасите базовый тип своей платформы, задаете максимальные количества треков на один стейт, и сообщений/уведомлений - на весь проект. Там же, в определениях классов topic и msg в ходе работы над вашим проектом перечисляете нужные вам сообщения и уведомления. Выглядеть это будет примерно так:

using base_t = std::uint32_t;constexpr base_t MAX_SUBSCRIPTION_NUM = 8;constexpr base_t MAX_MESSAGE_NUM = 8;constexpr base_t MAX_TRACK_NUM = 8;enum class topic: base_t{no,green,yellow,red,state,};enum class msg: base_t{no,stop,exit,  test};

Далее по примерам из статьи определяете классы своих рабочих стейтов, создаете им удобные псевдонимы и перечисляете их в дефайне STATES там же, в defs.hpp. Подключаете заголовочники получившихся стейтов в файл frankie.cpp. Ну и росчерком мастера вносите в main те самые две строчки, с которых мы начали.

Уфф, Уроборос наконец-то укусил свой хвост.

Если заинтересовались, забирайте Фрэнки здесь, не обижайте его. Там же выложен пример для отладки NUCLEO- H743ZI2 (-std=gnu++17, -O3, программа грузится из RAM). Весит проект с этими настройками примерно 12Kb, сам фреймворк - 5,5Kb.

В примере три стейта: быстрая змейкая, медленная змейка и аварийный стейт. Стартуем с быстрой змейкой, затем переключаемся на медленную. В стейте быстрой змейки первый трек веерно рассылает уведомления трекам с моргалками, в медленной - треки моргалок подписаны друг на друга. Медленная змейка завершается с ошибкой и происходит переход в аварийный стейт с красной моргалкой. И все по новой.

Берем отладочную плату, шьем и выпускаем magic smoke запускаем пример.

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

В то же время нужно учитывать, что это решение для soft real-time систем. Дествительно, стейты и треки выполняются последовательно, время их реакции зависит о переданных функций. Если же в вашем проекте есть условия, при которых требуется быстрая реакция системы за константное время, Фрэнки можно прокачать context switcher-ом, например, как показал в своей статье уважаемый @lamerok.

На этом все, спасибо за внимание!