Игры и Люди

… одетый только в халат из холщовой ткани, ходил в кабачки и к певичкам. Когда его спрашивали, почему он таков, он каждый раз открывал рот, засовывал туда кулак и не говорил. Император Лян-цзун призвал его и спросил: «Каков принцип Вашего Пути?» Гуйчжэнь ответил: «Одежда тонка — поэтому люблю вино, выпью вина и защищусь от холода, напишу картину — и расплачусь за вино. Кроме этого, ничего не умею». Лян-цзун не нашелся, что сказать…

От игрушек детства мы движемся к другим. Здесь — об этом.

Алхимия игры включает несколько ингредиентов.

Рецептура состоит из Миров, по которым можно путешествовать; не все из них достаточно хорошо населены. Дело — это Игрушка одного из миров.

Объединяя видимые и сокрытые элементы, Алхимия выступает и как самостоятельный Игрок.

Google+

Каким быть военному радиопеленгатору

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

Мой рассказ — об отечественном военном аэродромном пеленгаторе. Именно аэродромном, поскольку АРП другого назначения, в том числе для радиоразведки, поиска и спасения находятся за рамками моего повествования. Да и тема аэродромной радиопеленгации для меня самая близкая, в которой я работаю с 1983 года.

Аэродромный радиопеленгатор для военных

Для чего военным аэродромный радиопеленгатор? Во первых, как одно из средств опознавания цели при использовании в составе радиолокационного комплекса — РЛК. И хотя опознавание может выполняться с помощью ответчика вторичного канала РЛК, пеленгационное опознавание, как и в гражданской авиации, обладает несомненным преимуществом — диспетчер однозначно ассоциирует отметку цели с бортом, с  которым он ведет радиопереговоры. В качестве РЛК могут выступать как первичные радиолокаторы, так и комплексы радиолокационной системы посадки, например РСП-10. И пусть вас не смущает упоминание этого мастодонта времен 60-х. В нашем повествовании будет достаточно антикварной старины, которая до сих пор здравствует, работает и самое неожиданное — закупается )

Второй вариант использования — автономный, в качестве обычного аэродромного пеленгатора. Включая в свой состав средства связи, такой АРП будет самодостаточным средством для привода и посадки (визуальной, конечно) самолета на аэродром. Эта самодостаточность АРП, вкупе с его относительной простотой, является исключительной для быстрого развертывания временных аэродромов или подготовки постоянных аэродромов для прибытия своих сил, пока его обитатели об этом не подозревают )

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

История отечественных военных аэродромных АРП: отражение технологий

АРП-11, радиопеленгатор, DF, Direction Finder

АРП-11. 8-вибраторная антенна пеленгатора расположена на крыше. Рядом — диско-конусная антенна связи

Начнем с ныне здравствующего АРП-11, входящего в состав РСП-10. Пеленгатор имеет 8-вибраторную кольцевую антенную решетку с центральным вибратором. Принцип пеленгования — амплитудный: два противоположных вибратора вместе с центральным образуют диаграмму направленности в виде кардиоиды, которая крутится за счет переключения кольцевых вибраторов. Благодаря направленным свойствам кардиоиды формируется огибающая принимаемого сигнала, которая зависит от направления прихода. Так извлекается пеленг.

Конечно, такая схема гораздо лучше, чем более древняя 4-вибраторная антенна Эдкока, но она также несет на себе родовые травмы амплитудной пеленгации: невозможность держать приемлемую форму диаграммы во всем диапазоне частот 100 — 400 МГц и низкая устойчивость к переотражениям от местных предметов. Плюс низкая технологичность изготовления антенны, сложность регулировки да и эффективность вибраторов в широком диапазоне тоже оставляет желать лучшего. Поэтому среднеквадратическая погрешность пеленгования 2° (что совсем неплохо для малобазовой антенны), максимальная — 4°, дальность действия на высоте 1000м — 80км.

На самом деле, точности лучше 2° для задач привода и опознавания и не нужно.

АРП-11 входит в состав радиолокационной системы посадки РСП-10 которая была разработана в 1960-х. Это невероятно, но ламповый локатор до сих пор пользуется спросом, и этому есть две причины. Первая — то что было разработано в наше время на замену, по своим параметрам как ни странно получилось хуже чем РСП-10. Плюс военные не испытывают желания платить за новый локатор полмиллиарда рублей. Вторая причина: в армию с тех пор не поступило никаких новых радиотехнических средств для посадки самолетов. Разработка современной микроволновой системы посадки MLS, которую вело АО «НИИ Сапфир», закончилась полуобразцом — полумакетом, который так и не прошел испытания. Пока выполнялась ОКР, Сапфир плавно разваливался и пришел к концу 2017 года с «впечатляющими» результатами со знаком минус: выручка за год 90 тысяч рублей (это не опечатка: тысяч, а не миллионов), состав сотрудников — 7 человек. Среди них есть даже один инженер. Знакомая картина, не правда ли? Тем более странно, что некогда процветающее предприятие было колыбелью для московского АО «Азимут», которое открестилось от своей альма-матер, предварительно облегчив последнюю от имеющихся ресурсов.

Поэтому АРП-11 в составе РСП-10 все также изготавливается по имеющимся заказам, правда полноценным изготовлением это сложно назвать. В основном это ремонт и разукомплектование разнообразных ЗИПов, хотя судя по объему контрактов можно было провести полноценную модернизацию, уменьшив объем железа в аппаратной раз так в пять. Однако, это история уже другого разваливающегося предприятия, на которой мы не будем останавливаться.

От АРП «Пихта-3,4» к АРП «Комар-2»

Бум интегральных микросхем совпал с ОКР, которая выполнялась в АО «НИИ Сапфир» в 1980-х годах. Я пользуюсь этим последним названием, поскольку контора несколько раз меняла наименования. ОКР «Пихта» предусматривала создание унифицированного ряда АРП для гражданского и военного применения, с числом одновременных каналов пеленгования от 2 до 18. Этот пеленгатор содержал уже фазовую антенную систему с 16 вибраторами, с радиусом решетки 1.6м. Примечательно, что с особенностями для военной версии решили вообще не заморачиваться — в нее вошли точно такие же блоки и антенна, как и в гражданской. Пихта-3, как АРП на колесной базе ГАЗ-66, дополнительно содержал систему жизнеобеспечения, а Пихта-4, предусматривающая контейнерный вариант, представляла из себя авиационный контейнер, содержащий те же блоки, забитые в тесное пространство контейнера.

Для военной антенны сделали единственное исключение — ее лучи складывались, чтобы ее можно было упаковать в ГАЗ-66 (про зеленый цвет я молчу). Во время смотра военной техники в Борисполе (внимание: это был еще Советский Союз!) наш конструктор с трудом, чертыхаясь, извлекал из задней двери это чудо дизайнерского искусства. Конечно, такая большая антенна военным вообще была не нужна. Но что поделаешь — унификация!

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

Инженерные решения АРП на то время были достаточно продвинутыми, в ногу со временем. Конечно, своего радиоприемника в АРП не было — использовалась радиостанция Р-863. В тракте обработки находился синхронный фильтр с квадратурным разложением, сделанный уже наполовину цифровым способом. По линии связи передавались не напряжения север-юг, запад-восток, как в АРП предыдущих поколений, а формировался многочастотный код. Индикаторы пеленга из электромеханических стали полностью цифровыми. Параллельно быстро начали появляться процессорные технологии, поэтому Пихта как-то быстро начала устаревать. В то время я уже был главным конструктором нового пеленгатора с процессорной обработкой, о чем подробно рассказал в статье «АРП Платан: радиопеленгатор с FreeBSD».

АРП, РП, DF, Direction Finder, Комар-2, Komar-2

Блок АРП «Комар-2»

Следующей вехой были два пеленгатора, которые по сути были практически одинаковыми: АРП «Комар-2» и «Радиан-90». Первый входил в состав военного РЛК, который разрабатывала Tesla Pardubice, второй — в состав военного локатора «Радиан-90» разработки челябинского НИИИТ. Поскольку я уже писал про АРП Комар-2, подробности опустим. Замечу лишь, что точно также опытные образцы АРП «Комар-2» такими и остались — серию военные не заказывали, что в принципе понятно: 90-е годы, Тесла Пардубице ушла вместе с Чехией под крыло НАТО, да и сам НИИИТ с локатором «Радиан-90» был не в лучшей форме. Технически, это был весьма продвинутый АРП, с обработкой на встраиваемой микро-ЭВМ пока еще советского производства, и имеющий складную фазовую 8-вибраторную антенну. Это был мой первый проект военного аэродромного АРП, в котором я был главным конструктором.

Платан-В?

Периодически МО РФ предпринимало попытки запустить целый аэродромный комплекс навигации, связи и посадки, с разработкой современных наземных средств. На излете 80-х годов таковой была ОКР «Мельхиор», где предусматривалась разработка стационарных, мобильных и высокомобильных комплесов данного назначения. Соответственно в ходе ОКР «Мельхиор» предусматривалось создание АРП-С, АРП-М и АРП-ВМ. «Мельхиор» во второй своей реинкарнации снова возник относительно недавно как ОКР «Рейс — 2000» с аналогичным названием «Разработка автоматизированной системы управления полетами, навигации, посадки, связи для военных аэродромов». Что самое интересное, название ОКР всплывает на первых местах в поисковой выдаче не на сайтах заказчиков и исполнителей, а в материалах арбитражных судов, отражая тяжбу МО с исполнителями в ходе выполнения ОКР  🙂 Точно также, в составе комплекса требовалась разработка радиопеленгатора.

Было бы странно, если Азимут не попробовал вписаться в этот проект. Однако, потеря специалистов и последующее скольжение вниз от R&D фирмы до производственно-строительной компании сыграло свою роль: поддерживать на плаву серийные изделия еще можно, но разработать новый АРП — уже нет. Была сделана попытка слепить АРП из тех узлов Платана, которые идут в серии, и тут в полной мере проявили себя просчеты в построении радиоприемного тракта, про которые я написал в статье АРП DF-2000: что пошло не так с этим радиопеленгатором. В условиях жесткой помеховой обстановки, которая сопутствует размещению АРП на военных позициях, приемник прямого усиления просто затыкался. Разработкой широкополосной антенны 100 — 400 МГц занимались уже непрофессионалы, и в результате военные заказчики зарубили этот проект, наспех состыкованный из узлов, разработанных еще в 2000-х.

Штрих к нынешним возможностям завода АО «Азимут»: как-то позвонил инженер, который сопровождает серию АРП DF-2000 (по факту не инженер а product manager). Возникла проблема на пеленгационной позиции в Ростове: АРП дает большую ошибку, зависящую от азимута воздушного судна. До того как сделать звонок мне они конечно попытались решить проблему своими силами, как то: меняя радиоприемники, блок обработки и даже источники питания  😈 Дело дошло до того, что они решили что на аппаратную действует помеха и заэкранировали радиоприемный тракт  🙂 (хотя он и на самом деле очень чувствителен к помехам). В общем, действовали так, как действует горе-автослесарь, который меняет все запчасти по кругу, пока авто не заработает. Между тем, эта неисправность очень характерна, и ее причина — отказ одного из вибраторов антенной системы. Зависимость величины ошибки от угла прихода сигнала объясняется тем, что неправильная фаза отказавшего вибратора занимает разное место в фазовой огибающей. Интересно то, что мне сразу не поверили, но когда провели тесты антенной системы — так оно и оказалось, и ростовская позиция заработала нормально.

Кстати, перед уходом из конторы я завещал оставшимся сделать контроль антенной системы в реальном времени и показал, как его реализовать. Такая система контроля была в АРП «Комар-2». Однако, план по направлениям модернизации АРП «Платан» так и остался на бумаге.

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

Военный аэродромный радиопеленгатор — технологические барьеры

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

  • мобильная широкополосная антенная система диапазона 100 — 400 МГц, обладающая приемлемой фазовой неидентичностью вибраторов в рабочем диапазоне;
  • радиоприемное устройство (РПУ), обладающее высокими характеристиками электромагнитной совместимости (ЭМС), устойчивое к воздействию помех местного электромагнитного окружения;
  • тракт обработки сигнала, выполненный с учетом ограничений по применению комплектующих.

Антенная система

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

Поскольку к военному аэродромному АРП не предъявляются высокие требования по точности, с одной стороны, и требуется высокая мобильность — с другой, антенна может быть малогабаритной и как вариант — складной. Стандартные требования по времени развертывания АРП (из которого львиную долю занимает развертывание АС) — 30 минут личным составом из 2-х человек. Эта логика ведет нас к возможному варианту реализации 8-ми вибраторной антенне диаметром около 1.5м. Уменьшение базы АС, помимо увеличения ошибок, связанных с переотражениями, ведет к другому неприятному эффекту — возрастает роль фазовой неидентичности вибраторов. И если разброс по фазе более чем 5° для большой 16-вибраторной антенны не является критичным, то для малогабаритной антенны это становится преимущественным фактором. При этом, ухудшение точности идет сразу с двух сторон: с одной стороны, уменьшается база и как следствие амплитуда фазовой девиации полезного сигнала относительно фазовой ошибки вибраторов, с другой — уменьшается количество вибраторов, что снижает возможности по подавлению самой фазовой ошибки. В результате увеличивается инструментальная погрешность собственно антенной системы.

Таким образом, мы приходим к необходимости разработки эффективного вибратора на диапазон 100 — 150, 220 — 400 МГц. При этом лишний участок 150 — 220 МГц в существующих реализациях приходится обслуживать «бесплатно». Некий «усредненный» вибратор, покрывающий весь диапазон, будет работать плохо по следующим причинам:

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

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

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

2. Вибратор с переменной электрической длиной, зависящей от того в каком из поддиапазонов: 100-150МГц или 220-400МГц принимается сигнал. Решение подобного типа использует компания Rohde&Scwarz.

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

Радиоприемное устройство

Для сложной помеховой обстановки совершенно не годится цифровое РПУ, выполненное по чистой схеме SDR. Почему — об этом подробно в вышеупомянутой статье АРП DF-2000: что пошло не так с этим радиопеленгатором. Военный аэродромный АРП требует применения приемника, выполненного по супергетеродинной схеме, с хорошим преселектором и эффективной АРУ. Причем это не будет классическое связное РПУ, потому что в радиотракте необходимо обеспечить прохождение двух сигналов: информационного с коммутируемого кольцевого вибратора и опорного с центрального вибратора. В соответствии с этим, появляются следующие альтернативы.

1. Классическая реализация с SSB (однополосным модулятором) в антенном тракте. Замечу, что поскольку в АРП «Платан» сейчас используется не специализированный пеленгационный, а стандартный приемник из АППЦ, однополосный модулятор там по прежнему присутствует. Недостатки этого метода известны: потери на SSB и неоправданное расширение полосы пропускания РПУ, связанное с необходимостью пропуска двух разнесенных частот. Есть еще один, не столь очевидный минус: ограничение по масштабированию, когда может понадобиться пеленгование ЧМ и ППРЧ сигналов. В этом случае низкое значение частоты обработки (такое как 4200Гц в АРП «Тополь» или 5550ГЦ в АРП «Пихта») ставит крест на дополнительном функционале.

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

Direction Finder, DF, АРП, радиопеленгатор, АРП "Пихта-2С", двухканальный радиоприемник

Двухканальный радиоприемник АРП «Пихта-2С»

Такую реализацию я заложил в судовой АРП «Пихта-2С». Впервые в этом радиопеленгаторе было применено специализированное РПУ своей разработки. Поскольку судовые радиостанции работают в диапазоне 100-180 МГц и используют частотную модуляцию, вариант SSB не мог быть использован. В этом РПУ за счет разнесенных по частоте гетеродинов формируется несущий и опорный сигнал стабильной частоты, в результате чего ЧМ которая присутствует во входном сигнале полностью подавляется. Остается только информация о фазовой модуляции, вызванной коммутацией вибраторов антенной системы.

3. Раздельные РПУ для центрального и кольцевого канала, связанные общим синтезатором. Особенности такого построения — это девиация выходной частоты РПУ, связанная с изменением частоты входного сигнала. Другими словами, выходная частота РПУ по центральному и кольцевому каналу не является стабильной, что предъявляет дополнительные требования к тракту обработки сигнала, и в частности исключает прямое использование преобразования Фурье (FFT).

Для устойчивости к помехам РПУ АРП должен иметь возможность точной перестройки относительно узкополосного преселектора и иметь внеполосную АРУ.

Тракт обработки сигнала

Этот компонент наиболее чувствителен к требованию по использованию отечественных комплектующих. Номенклатура встраиваемых вычислительных средств, выпускаемых отечественной промышленностью, серьезно ограничена. За бортом сразу оказываются производительные ARM и DSP процессоры, а также матрицы FPGA. Максимально, на что можно расчитывать — отечественные аналоги контроллеров (MCU)  STM32. Это отбрасывает нас во времена разработки АРП «Комар-2», когда операцию вычисления арктангенса приходилось выполнять численным методом, по причине отсутствия операций с плавающей точкой. Конечно, прибавка в скорости на порядок не помешает, но тесные рамки аппаратной архитектуры все равно будут сказываться. Пожалуй единственное преимущество MCU — это время начало работы, которое можно характеризовать одной фразой: начинает работать сразу. В отличие от встраиваемых платформ на базе Linux, где ждать загрузки операционной системы нужно ждать несколько десятков секунд.

На одной из ARM конференций, организованных Texas Instruments, один из докладчиков рассказывал как они обходили это ограничение. Заказчику демонстрировался включенная LED панель системы в то время как она продолжала свою загрузку. Не самый жестокий трюк для надувательства военпреда )

И само собой, тракт обработки может содержать следующие модули, которые расширяют функциональность АРП:

  • Защита от перемодуляции входного сигнала. То что в ТТЗ написан максимальный коэффициент амплитудной модуляции 80%, ничего не значит. Часто с борта идет перемодуляция с пропаданием сигнала. Радиопеленгатор в этом случае должен сохранять стабильное пеленгования без срыва обработки.
  • Подавление вертолетного эффекта. При работе радиостанции с вертолета возникает паразитная фазовая модуляция, связанная с переотражением передаваемой несущей от лопастей вращающегося вертолетного винта. Тракт обработки обнаруживает наличие дополнительных компонент во входном сигнале, связанных с вертолетным эффектом и подавляет их с помощью включения специальной фильтрации. Вертолетный эффект не изменяет характеристики радиосвязи и влияет только на пеленгацию, из-за фазового принципа АРП.
  • Обнаружение выхода из строя вибратора. В классическом пеленгаторе выход из строя вибратора ведет к прекращению работоспособности АРП. В данном случае процессор с помощью демодулятора определяет вышедший из строя вибратор и исключает его из обработки, дополняя пропущенные значения интерполяционным алгоритмом. За счет некоторого увеличения погрешности пеленгования работоспособность АРП сохраняется до замены неисправного вибратора.
  • Адаптивное сокращение времени пеленгования. Для бортов, не находящихся на предельной дальности, АРП может выдать отсчет пеленга заданной точности не используя всю длительность пеленгуемого сигнала 0,5с. Для подобных сигналов пеленг может выдаваться с ускоренным темпом с периодом 0,2с.
  • Поиск по частоте. АРП может работать в режиме быстрого поиска сигнала по 10 предопределенным частотам. В зависимости от настройки, пеленгатор может остаться на частотном канале на котором был обнаружен сигнал, или продолжить сканирование с записью пеленга в журнал.
  • Оценка дальности и угла места. АРП может оценивать и выдавать косвенную приближенную оценку этих двух параметров. Это особенно полезно, когда радиопеленгатор используется в паре с радиолокатором для опознавания целей. В этом случае оператору проще ориентироватся на индикаторе обстановки;
  • Оценка целостности сигнала. Данная опция повышает устойчивость к помехам РЭБ. АРП позволяет определить направление на источник помехи вне зависимости от используемого вида модуляции.

В настоящий момент, разработаны прототипы этих компонентов АРП. Как только мы выберем самые успешные реализации, сборка образца военного аэродромного АРП не за горами  🙂

Военный аэродромный радиопеленгатор — административные барьеры

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

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

Посмотрим в сторону наших потенциальных противников, этих акул империализма — как они расправляются с малым бизнесом на потребительском рынке (как нам твердят постоянно), а уж о государственных контрактах наверное и смысла нет говорить? Ан нет, вот например в США работают программы SBIR/STTR, которые позволяют маленьким компаниям участвовать на равных в военных разработках. Программа стартанула в 1992 году и будет продолжаться по крайней мере до 2022 года. По американским правилам, каждое федеральное агенство с бюджетом более 100 млн. долл. должно выделять определенный процент для контрактов и грантов для малого бизнеса. Что касается американского Министерства Обороны, ежегодно для целей разработки малому бизнесу выделяется бюджет в 1 млрд. долларов, причем около половины этого бюджета идет малым предприятиям в которых работает менее 25 человек и треть — в которых работает менее 10 (если вас интересуют пикантные подробности, то пятую часть гарантированно отдают меньшинствам и фирмам которые возглавляют женщины). По статистике, каждый год примерно четверть компаний малого бизнеса выигрывает тендер в первый раз. Какой нереальный разрыв между подходами к малому предпринимательству в США и у нас! Все разговоры о защите отечественного малого бизнеса это просто пустые слова по сравнению с реальными американскими бюджетами, которые говорят сами за себя.

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

Программа SBIR/STTR для участия малого бизнеса в военных разработках в США

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

Этап I носит название «осуществимость проекта» и включает в себя только научные, технические и коммерческие предпосылки для предлагаемых идей и решений — нечто вроде НИР. Этот этап оплачивается в относительно небольшом размере. На этапе II выделяются деньги на разработку прототипа, который должен подтвердить достижение целей этапа I — это больше соответствует нашей гостовской стадии эскизно-технического проекта. На этапе III выполняется коммерциализация проекта — привлечение инвесторов для доведения проекта до стадии производства и поставки. Очевидно, что инвестора найти гораздо проще, если у вас есть работающий прототип.

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

Цели программ (в скобках мои комментарии):

  • стимулировать технологические инициативы в частном секторе (малый бизнес это не только торговля мобильными телефонами и стрижка собачек, но и современный уровень техники — американское государство об этом заботится!);
  • использовать возможности малого бизнеса для в разработках федерального правительства;
  • поощрять участие фирм, неблагополучных в экономическом плане (надо же, за государственный счет лузерам помогают);
  • обеспечить сотрудничество между малым бизнесом и исследовательскими институтами (что очень важно, поскольку последние располагают большим массивом информации по перспективным направлениям, уже достигнутым результатам и наиболее актуальным задачам);
  • сократить разрыв между исследованиями и внедрением на рынке (это звучит чисто по-американски).

Подчеркну особенность каждой из двух программ:

SBIR
Своими силами должен быть выполнен объем в 2/3 от всей разработки на I этапе и 1/2 на втором.

STTR
Работа выполняется в партнерстве с исследовательскими институтами в пропорции:

  • 40% получает малый бизнес;
  • 30% работ выполняют НИИ.

Быть военному пеленгатору или не быть?

Последнее время ознаменовалось странной активностью вокруг этой темы  🙂 Появляются разные люди — от директоров заводов до посредников, которые предлагают сделать АРП. Причем, все они действуют по разному: одни пытаются получить подлинники АРП-11 и начать клепать это старье — а что, Минобороны платит. Другие подозревают нас в том что мы прячем под подушкой чертежи нового военного радиопеленгатора и предлагают их выкупить (за смешную сумму). К слову, готовой КД у нас нет, но разработки которые можно в КД быстро превратить есть. Третьи размахивают флагом, говорят о судьбах Родины и предлагают дружно напрячься и сделать радиопеленгатор забесплатно и своими силами, а Родина конечно потом не забудет, все поймет и простит.

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

В общем, сильно похоже на то, как говорят ИТ-шники: деньги на новый мерс есть, на новый сервер нет. На этом и завершим наше эссе  🙂

STM32: добавляем Ethernet

В предыдущей статье я рассказывал о том, как хорошо работать с микроконтроллерами STM32 без операционной системы. Однако может наступить момент, когда вам понадобится наладить взаимодействие с вашим МК по сети. Например, что-нибудь типа умного дома или передача отладочной и диагностической информации на web страницу. Наличие Ethernet интерфейса — это конечно сильный аргумент для того, чтобы бросить STM32 и перейти на полноценный ARM процессор под управлением Linux. Однако, этот аргумент парируется очень просто: на рынке есть компактные Ethernet модули, которые можно задействовать в наших STM32 проектах. Речь идет о чипах семейства W5500 WIZnet, на основе которых эти модули и собраны. Добавляем к нашему проекту этот модуль (хвала Али Экспрессу, как обычно!), и получаем функциональность Ethernet в МК STM32.

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

 

stm32, stm32f103, Ethernet, W5500

Микроконтроллер STM32F103 и модуль Ethernet W5500 в сборе

Работать с модулем W5500 — это сущий ад. В нем куча регистров, в которые нужно заносить и считывать информацию. Когда я раскрыл мануал этого чипа, то первое что я сделал — это сразу закрыл его и начал искать библиотеку, в которой вся эта регистровая часть уже реализована и которая предоставляет такие привычные и понятные интерфейсы: socket(), listen() и так далее. И я ее нашел.

Как работать с библиотекой я расскажу дальше, а пока поработаем с нашим фото.

Пройдемся по макетке слева направо и посмотрим, что я там разместил.

Макетная сборка

Модуль W5500

Слева, как вы уже догадались, Ethernet модуль W5500. В этом варианте исполнения его пины смотрят вниз, что удобно для размещения на макетной плате. Есть вариант и пинами вверх, что будет удобно если вы решите просто соединять контакты напрямую кабелями. Собственно чип W5500 распаян под зеленой платкой, из-за чего создается впечатление что кроме Ethernet разъема больше ничего нет. На самом деле это не так. Чип берет на себя всю работу по поддержке сетевых протоколов, а работать с ним нужно по интерфейсу SPI. Поэтому красные и темные проводки — это и есть соединения SPI с микроконтроллером.

Кто уже работал с SPI, сейчас испытывают небольшой диссонанс. Этот протокол вообще-то говоря принято использовать для внутриплатных соединений, и выводить его наружу считается моветоном. Пришлось поступиться принципами ради демонстрационных целей, потому что нужна скорость, которую другие популярные интерфейсы — I2C и UART обеспечивать не могут. Если же вы распаяете модуль W5500 на своей собственной плате, то правила поведения в приличном обществе будут соблюдены.

UART

Смещаем взгляд правее и видим вертикально воткнутую платку. Это адаптер UART-USB, с которым мы познакомились раньше. Его мы используем исключительно для отладочных целей, для того чтобы выводить сообщения  нашей программы на экран PC.

От МК этой плате требуется только одна линия: Tx (отдаем строчки), которая на адаптере будет обозначаться уже как Rx (принимаем строчки). Ну и само собой кабель, который вы видите на торце платы, подключен к USB разъему PC.

Переключатель на плате устанавливаем в положение 3.3В: это будут уровни линий передачи данных, с которыми работает адаптер.

МК STM32F103 Blue Pill

По центру — наш микроконтроллер, плата МК STM32F103C8T6. Здесь неожиданностей нет, единственное я использовал компактную версию под названием Blue Pill. Есть еще Black Pill, Red Pill но честно говоря не знаю чем все они принципиально отличаются друг от друга. Работать будут все.

В комплекте с этими платами идут линейки пинов, которые я распаял снизу. Это позволяет вставить пины контроллера в макетную плату. Если вы используете Pill’ы в своих устройствах, запаивать пины нет необходимости — можно сразу паять соединения на ламели по краям платы. В нашей конфигурации используются контакты соответствующие UART1 и SPI2.

К разъему JTAG в торце платы МК как обычно подключен программатор/отладчик ST-LINK V2. Его мы видим сверху. Его место — также в USB разъеме PC.

USB разъем для электропитания не используется — напряжение подается непосредственно на пины МК.

Электропитание

На правой стороне макетной платы расположен весьма удобный модуль электропитания, который обеспечивает независимые напряжения 5В или 3.3 В по обеим линиям питания макетной платы (синие и красные линии). Своими пинами модуль ложится в аккурат на эти линии, плюс к этому есть возможность подключиться еще сверху. Входное напряжение для модуля — 12В.

Модуль питания сконфигурирован джамперами на выходное напряжение 3.3В, отбор питания идет по внешним линиям модулями W5500 и МК STM32, которым требуется 3.3В. На фото видны эти желтые и коричневые короткие перемычки, которые идут рядом.

Нюанс: вы пожете подключить к МК вместо 3.3В 5В к соответствующему (другому естественно!) контакту. Эти 5В будут преобразованы в 3.3В.

Внимание! Не подключайте к плате внешнее питание 3.3В и 5В от USB одновременно. Можете потерять МК ) Также по этой причине провод +5В для JTAG от USB PC болтается в воздухе, как может заметить внимательный читатель )

Модуль UART требует электропитание 5В, которое мы обеспечиваем внешним проводком который подключается к пину +5В модуля питания. Есть подозрение, что он прекрасно будет работать и без этого проводка от USB, когда тот подключен (и работает на самом деле).

Ситуация когда к одной цепи питания модуля подключаются два источника питания — не совсем здоровая. Картинку портит поступающие 5В от USB, которые преобразуются в 3.3В и эта цепь потенциально может конфликтовать с внешней линией питания 3.3В. В таких случаях обычно ставят диод Шоттки, который защищает цепи питания 3.3В от реверсного тока. Будем надеяться, что так оно и есть )

Зачем вообще нужен модуль питания, если раньше мы прекрасно запитывали микроконтроллер от USB? Не забываем, что теперь у нас появился серьезный потребитель по напряжению 3.3В — это чип W5500, который не в лучшие для нас моменты готов принять до 185мА. Внутренний преобразователь уровня 5/3.3В микроконтроллера на такой подвиг не способен, если нам в голову придет мысль взять напряжение 3.3В оттуда.

Конфигурация

Как и раньше, для создания проекта воспользуемся услугами STM32CubeMX. По традиции создаем проект на основе Makefile, чтобы не городить огород с визуальными системами разработки (помните наш проект hardcore? Только Makefile и vim!). Как обычно, включаем пункт Debug:Serial Wire в меню SYS, чтобы иметь возможность прошивки и отладки. Сразу включатся пины PA13, PA14: через них STLINK будет общаться с МК.

Осталось сконфигурировать интерфейсы и все. Включаем USART1: Mode Asynchronous (Куб задействует пины PA9, PA10) и включаем SPI2: Mode Full-Duplex Master. На вкладке конфигурации для SPI2 нужно будет подправить параметр Prescaler: установить его в значение 4. Напоминаю еще раз, что UART нужен только для отладки, чтобы получать на нашем компе логи из программы контроллера.

Почему SPI2 а не SPI1? Так было в библиотеке поддержки чипа W5500, я не стал менять интерфейс. Видимо, разработчикам было удобно работать с пинами именно с этой стороны модуля микроконтроллера ) В нашем случае Куб выдаст для SPI пины PB13 — PB15.

Нам еще понадобится управлять пином PB12 как выходным (забегая вперед — библиотека использует его для включения чипа W5500). Поэтому кликаем на него и делаем GPIO_Output. И точно также, сразу делаем выходным пин PC13: к нему подключен светодиод МК, и грех не воспользоваться возможностью поморгать светодиодом в нужных местах.

Создаем проект и переходим к следующему шагу.

Соединения

Поскольку распиновка модулей W5500 и UART-USB и так известна, а распиновку Blue Pill мы уже получили с помощью Куба, займемся соединениями. Работа приятная, медитативная, навевает мысли о тщете всего сущего, хорошо заниматься этим перед сном, глубокое погружение гарантировано 🙂

Начнем с модуля W5500. Все, что нам от него нужно — это цепи SPI и питания. С подключением питания все понятно — задействуем цепи 3.3В и GND, самое главное — правильно соединить линии интерфейса SPI. Поскольку на модуле нет нумерации пинов, на схеме соединений слева будем указывать SPI обозначение пина по версии W5500, справа — номер пина и SPI обозначение по версии Куба:

Распиновка модуля W5500


 

Памятка по SPI:

  • MISO — Master In, Slave Out: если мы в режиме мастер — принимаем данные, в режиме периферии — передаем;
  • MOSI — Master Out, Slave In: в режиме мастер передаем данные, в режиме периферии — принимаем.

В нашей конфигурации W5500 будет периферийным модулем, который будет выбираться сигналом SCNn с МК. Поэтому по линии MISO данные будут идти от W5500 к МК, по линии MOSI — в противоположном направлении. Обратите внимание, что нет необходимости переполюсовки Tx/Rx как в UART: назначение вывода (вход или выход) меняется в зависимости от того, в каком режиме — Master или Slave работает модуль.

С модулем UART-USB все просто. Нужна только одна линия передачи данных:

И в заключение — подключаем программатор/отладчик ST-LINK V2:

Цепь 3.3В остается неподключенной!

Не забудьте соединить «земли» всех модулей с землей модуля питания и подать 3.3В на модули W5500 и Blue Pill. Модуль UART-USB, как я говорил до этого, подключается к пину 5В модуля питания.

W5500 Library

Наконец наступил долгожданный момент — подключение библиотеки модуля W5500, чтобы с ним можно было работать вменяемым образом. Саму библиотеку можно скачать здесь. На самом деле, это не совсем библиотека, а набор файлов которые нужно включить в наш проект. Они точно также будут компилиться и собираться, как и наши собственные файлы. Поэтому по структуре это не library, а дополнительные к нашему проекту кусочки. Но я все равно буду называть это библиотекой — по существу. Кому нравится — могут называть это также драйвером; сама WizNet вообще использует наименование Library_Driver.

Подобные продукты третьих сторон я храню отдельно от своего проекта, потому как не нужно дублировать исходники в каждом отдельном проекте и тем более включать их в систему контроля версий. Для этого у меня специальная директория — /home/user/bin, куда и скачаем библиотеку WizNet она же драйвер W5500.

Распаковываем архив и меням имя на ioLibrary_Driver. Далее, нужно настроить библиотеку на определенную версию чипа. Для этого в файле Ethernet/wizchip_conf.h ищем строчку вида

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

Теперь нужно как-то интегрировать исходники библиотеки в наш проект. Это делается через Makefile. Добавляем в него строки следующим образом (будьте внимательны: показаны также существующие строки, чтобы вам было проще ориентироваться по make-файлу):

Все достаточно просто, не правда ли? Наступил момент запуска библиотеки. Для этого ее нужно инициализировать и выполнить тестовый пример — запустить TCP сервер который будет принимать входящее соединение и отвечать чем-то в стиле «Hello World».

Software

Как вы наверное уже догадались, все это будет жить в файле tcp.c. Но вначале библиотеку нужно инициализировать. Код инициализации разместим в main.c, поскольку так ему будет проще доступаться к интерфейсным переменным.

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

Теперь библиотеке нужно как-то сообщить о нашей проделанной работе. Регистрация наших callback-функций в библиотеке выполняется следующей парой строк:

Само собой, это уже вызовы функций библиотеки. Дальнейшая инициализация:

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

Ну а теперь можно вызывать нашу функцию tcp_server(), которая будет делать всю полезную работу. Функцию разместим в файле Src/tcp.c. Не забудем объявить ее в заголовке main.h:

Так уж и быть, выложу полное содержание tcp.c. Как все это работает, описал в комментах. Для тех, кто знаком с логикой создания входящих tcp соединений, трудностей не будет никаких.

Проверяем все это так. Соединяем патчкордом модуль W5500 и наш комп. Конфигурируем проводное соединение, у меня на PC Ubuntu это адрес 192.168.77.5 (заметьте, что это также адрес шлюза для W5500). С нашей машины пингуем модуль: ping 192.168.77.6, убеждаемся что пинги проходят.

Дальше, достаем швейцарский нож хакера — программу netcat, коннектимся к модулю:

и получаем в ответ долгожданное «Hello World», а в экране minicom наблюдаем логи, которые посылает нам trace через модуль UART-USB.

Некоторые размышления по структуре программы. В ожидании входящих соединений, МК видимо будет выполнять полезную работу. Например обрабатывать поток радиолокационных данных ) Возникает проблема одновременной поддержки двух процессов. В Linux среде это решается просто — системным вызовом select(), который может зависать на нескольких событиях. В STM32 Линукса нет, но зато для STM32 есть простая операционная система реального времени FreeRtos. И она умеет работать с потоками, то есть содержит простейший планировщик заданий. Даю наводку, а как вы ей распорядитесь — ваше дело )

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

STM32: жизнь без операционной системы

Возможно, вы очень хотели заняться чем-нибудь, что связано с чипами, прошивками, возможно даже использовать новые знания для домашних поделок — мало ли вещей, которые можно автоматизировать, начиная от контроллера солнечной батареи и заканчивая автоматом запуска бензоагрегата? При этом, не сильно погружаясь в особенности операционных систем Linux / Windows и не используя сильно избыточные платы, такие как Raspberry Pi, BeagleBoard  и подобные. Тогда добро пожаловать сюда: здесь мы запускаем микроконтролллер STM32, чистый «bare metal», никакой операционки, железо на расстоянии вытянутой руки и богатая собственная периферия.

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

В этой статье не будет длинных листингов кода, которыми так славятся ресурсы по STM32, и не будет утомляющих скриншотов STM32CubeMX. Все будем описывать текстом — емко и кратко.

Набираем инструменты

Нам понадобятся приложения:

  • STM32CubeMX — конфигуратор;
  • текстовый редактор, например vim (категорически рекомендую освоить его);
  • ST-LINK, которое состоит из двух утилит: st-flash для прошивки STM32 и st-util для отладки, или точнее st-util это настоящий gdb сервер;
  • комплект для кросс-компиляции arm-none-eabi.

Сразу примечание: берем кросс-компилятор именно с «none», поскольку опять таки bare metal и другие варианты типа arm-linux-eabi  нам не подходят, потому как подразумевают наличие операционной системы со всем набором сопутсвующих библиотек, которые у нас будут отсутствовать напрочь.

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

Вторая самостоятельная работа — приобретение оборудования (хвала Али Экспрессу!). Нам понадобятся:

  • плата с микроконтроллером STM32F103;
  • программатор и отладчик St Link V2, похожий на флешку;
  • миниатюрная платка адаптера UART — USB.

Цена вопроса за все про все — около 500р, ждать не больше месяца.

Да, чуть не забыл: закажите еще набор проводков с окончаниями «мама»: их удобно надевать на пины плат, получится очень аккуратно.

Roadmap

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

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

Сразу скажу, что Куб умеет формировать проекты для IDE разных типов. Мы, как поклонники vim и хардкора, никакими IDE пользоваться не будем — зачем нам эти бестолковые графические прослойки, заслоняющие реализацию? Редактор и Makefile — вот и все что нам нужно.

После того как структура проекта создана, мы внесем в исходники нечто похожее на вывод Hello World: должно же быть и какое-то наше участие в проекте. Сильно заморачиваться не будем, от нас потребуется буквально пара строчек. Сразу назовем наш проект сочно и звучно — hardcore.

После этого проект готов. Запускаем make и компилируем его, в результате чего создастся директория build и там появятся интересующие нас файлы: hardcore.bin — прошивка и hardcore.elf — исполняемый файл, который ценен тем что содержит отладочную информацию.

Следующим этапом прошиваем микроконтролллер:

и после этого наша программа начнет работать. Мигающий на плате светодиод мы увидим и так, а чтобы посмотреть на заветную строчку Hello World которую выдает наше приложение, на компе нужно будет запустить терминал (конечно, если вы не забыли подключить адаптер UART — USB):

Мы также можем начать отладку нашей программы — например, пройти ее пошагово, для этого запускаем st-util и потом отладчик arm-none-eabi-gdb.

Общая картина ясна, дело за подробностями.

Связи

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

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

В комплекте к донглу идет как раз четырехжильный кабель, которым мы и воспользуемся. Подключаться нужно к 20-пиновому JTAG разъему платы микроконтроллера. Схема подключения:

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

Если вы решили запитать плату STM32 от внешнего источника питания, контакт +3.3В подсоединять не нужно. И помните золотое правило: прежде чем подавать питание все «земляные» контакты должны быть уже соединены!

Проверим наличие связи с платой:

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

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

Во-вторых, нам нужно соединить плату STM32  и терминал в компе, чтобы посылать на терминал строчку Hello World. Для этого соединим пин PB6 платы и пин Rx адаптера UART — USB, а также свяжем их «земляные» контакты. Почему именно этот пин? Забегая вперед — именно его нам выдаст Куб когда мы будем настраивать UART. Схема соединений:

Подключаем кабелем адаптер ко второму разъему USB, Линукс увидит его как устройство /dev/ttyUSB0. К этому устройству мы и подключаем терминал, как было показано выше.

Куб

Вот так с этими микроконтроллерами — столько возни из-за двух строчек кода. Запускаем Куб, и он первым делом потребует от нас указать, с каким микроконтроллером мы работаем. Если вы не ошиблись с заказом на Ali Express, то смело указывайте STM32F103C8Tx, в противном случае берите лупу и читайте обозначение на корпусе чипа. Далее быстро вспоминаем, какие две вещи мы должны проделать с конфигуратором.

Во первых, настройка коннектора JTAG. Открываем пункт SYS и устанавливаем Debug в состояние Serial Wire: это наш последовательный интерфейс связи платы с донглом St-Link V2.

Во-вторых, настраиваем UART: открываем USART1 и ставим Mode Asynchronous. Больше ничего делать не нужно. После этой манипуляции на вкладке Configuration появится кнопка USART1, где можно менять параметры порта. Заметим, что на схеме чипа появится метка у пина PB6: он будет назначен как передающий (Tx).

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

Вот в принципе и все. Заходим в Project/Settings, даем нашему проекту имя hardcore и в выпадающем меню Toolchain / IDE выбираем Makefile, как и договаривались — никаких IDE!

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

Нажимаем на кнопку с шестеренкой, и наш проект готов: он появится в папке hardcore по тому маршруту, который вы указали в настройках.

Исходные файлы созданы, это вполне рабочий проект. Мы можем запустить make из директории hardcore, после этого исходники откомпилируются, скомпонуются и во вновь созданном каталоге build появятся исполнительные файлы hardcore.elf и hardcore.bin. Файл bin — это прошивка контроллера, файл в elf формате это исполнительный формат Linux. Конечно, исполнять его никто нигде не собирается — он нужен лишь постольку, поскольку в нем содержится отладочная информация: нумерация строк кода, имена переменных, функций и так далее. Нюанс: на самом деле собирается hardcore.elf, а потом уже из него утилитой objcopy извлекается прошивка hardcore.bin, избавляя последнюю от всего лишнего.

Та часть структуры проекта, которая представляет для нас интерес, лежит в каталогах Src/ и Inc/. Остальное трогать не нужно. Куб рассматривает созданное им дерево файлов и каталогов как свою безраздельную собственность, поскольку ему добавлять или удалять куски файлов в зависимости от того, как мы будем менять конфигурацию проекта. Он милостиво разрешает нам писать свой код в места обозначенные как /* USER CODE BEGIN */ и гарантирует, что трогать их не будет. Поэтому запускаем vim, открываем Src/main.c и ищем такой кусок в районе while(1).

Vim

Наверное несколько странно что после инициализации железа программа в main.c входит в бесконечный цикл ) А чего вы ждали, операционной системы нет, соответственно нет планировщика, и чем будет заниматься контроллер в холостом режиме — полностью наша забота. Поэтому после while(1), строго не выходя за рамки установленные нам Кубом, вставляем строчки кода таким образом:

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

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

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

Команду можно вбить перед задержкой.

Когда выше я сказал, что можно запустить make, я несколько слукавил. Makefile для работы не хватает информации о том, где расположены все инструменты для сборки — toolchain. Обычно для этого задают переменную окружения GCC_PATH, но у меня на машине несколько разных компиляторов, поэтому я указал эту переменную в самом Makefile. Выглядит это так:

Ваши инструменты могут быть в другом месте, у меня они находятся под каталогом /opt.

Теперь запускаем make, и наша прошивка готова. Результаты работы — объектные и исполняемые файлы создаются в каталоге build.

Прошивка микроконтроллера STM32

Надеюсь, к этому моменту вы осилили соединение донгла St-Link V2 и платы микроконтроллера. Вставляем St-Link V2 в usb и начинаем прошивку.

Прошивать будем из командной строки. Если вы в папке hardcore, запускайте команду:

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

Признаком хорошего тона будет выполнять прошивку по команде make install. Для этого добавим в конец Makefile пару строк:

Внимание: перед st-flash должна быть табуляция а не пробелы! make весьма строго относится к этому, и если вы напутаете это может быть источником трудно распознаваемой ошибки.

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

Очистка всего проекта с удалением каталога build выполняется соотвествующей командой make clean.

Запуск

После прошивки микроконтроллер запускается (если он притормозил, дайте пинка кнопкой reset  на плате), и наблюдайте мигающий светодиод.

Дальше, если вы не накосячили с подключением UART, после подключения адаптера вы увидите устройство /dev/ttyUSB0. Usb теперь стало стандартным последовательным устройством unix, поэтому с ним можно работать с терминальной программой. Запускаем ее:

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

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

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

Отладка

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

Перед тем как двинуться дальше, сделаем небольшой экскурс в кроссплатформенную отладку. Если вы пользовались знаменитым отладчиком gdb на своей станции, то скорее всего для вас было само собой разумеющимся то, что результаты отладки и само исполнение программы происходит на одной и той же машине. Однако, в общем случае это не так. Для нашей кроссплатформенной системы мы запускаем отладчик на своей PC Ubuntu, а программа работает на микроконтроллере STM32. Как все это должно быть состыковано вместе?

Все это уже предусмотрено в gdb. Мы даже не подозреваем о том, насколько это мощное приложение. В нашем случае мы будем использовать возможности работы отладчика в режиме клиент — сервер. Клиент — это приложение gdb на нашей машине, а сервер… занавес открывается… в качестве сервера будет выступать наш донгл St-Link V2. Не забываем о том, что помимо программатора это также gdb — сервер!

Принцип отладки выглядит следующим образом. Донгл St-Link V2 работает с платой микроконтроллера по интерфейсу JTAG и имеет возможность запускать и останавливать исполнение программы аппаратным способом. Все таки будет приятно знать, что когда мы соединяли его проводками, мы получили не только программатор но еще оказывается и отладку! С другой стороны, gdb сервер донгла запускается утилитой st-util и начинает прослушивать порт 4242 на нашей машине (значение порта по умолчанию можно поменять в командной строке). Мы со своей стороны запускаем отладчик gdb также на нашей машине, и указываем ему приконнектиться к gdb серверу донгла. С этого момента запущенный нами gdb становится клиентом, и все команды которые мы будем вводить в командной строке, будут исполняться St-Link V2.

До этого момента для краткости изложения я говорил про приложение gdb, но на самом деле конечно же мы используем не родной отладчик Ubuntu, а кроссплатформенный отладчик который идет в составе toolchain:

Общий принцип теперь ясен, переходим к деталям. Чтобы не плодить консоли, запускаем gdb сервер донгла St-Link V2 в фоновом режиме:

Запускаем в этой же консоли кроссплатформенный отладчик

или просто arm-none-eabi-gdb, если вы включили маршрут /opt/arm-none-eabi/bin в переменную окружения PATH. Отладчик выводит приглашение (gdb) и переходит в интерактивный режим.

Первым делом цепляемся к gdb-серверу донгла:

С этого момента появляется возможность задать специальные команды для сервера через ключевое слово monitor; первое что сделаем — это сбросим и остановим микроконтроллер:

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

Чтобы не вводить эти команды каждый раз при запуске отладчика, поместите их в файл debug.txt и запускайте в командной строке

Подчеркну еще раз, как мы используем elf и bin файлы в кроссплатформенной отладке: bin файл не нужен отладчику, поскольку он уже прошит в контроллере. Из elf файла ему нужна только отладочная информация, код из elf — файла не запускается.

После того как мы подключились к gdb серверу, отладка идет в обычном режиме. Ставим точку останова на функции main() и запускаем на выполнение:

Точку останова можно поставить и на номер строки (включите отображение номеров строк в vim).

Осмотримся:

Продолжим выполнение в пошаговом режиме:

или в полном написании next. Если мы хотим зайти в функцию, вместо next используем step. Чтобы выйти из функции не дожидаясь пошагового выполнения, задаем finish.

Краткая памятка команд отладчика:

Если вы что-то подзабыли, смело просите о помощи, например так:

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

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

Успехов в ваших начинаниях!

ARM + DSP. Распределяем память

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

Мы будем

Читать дальше

Препарируем Blockchain

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

Читать дальше

Google Contacts API и авторизация OAuth2

Когда в адресной книге Google набирается несколько тысяч клиентов, становится тяжеловато ворочать этим объемным списком. Импорт/экспорт в странички Excel становится неудобным; кроме того появляются CRM-подобные приложения, в которых хотелось бы интегрировать самые разные базы данных, в том числе и контакты Google. Значит, пришло время доступиться к нашим контактам через консольные приложения, используя Google Contacts API.

Читать дальше

Согласованный фильтр 2D: поиск соответствия в изображении

Согласованную фильтрацию можно рассматривать как во временной, так и в частотной области.

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

Еще

Читать дальше

Алгоритм MUSIC: MUltiple SIgnal Classification в оценке спектра

Вот мы наконец и добрались до этого метода. Литературы по этой технике — целая куча, но как обычно смысл ускользает. Само описание MUSIC достаточно простое: это поиск экстремума произведения двух матриц. Однако что происходит внутри этих матриц — с этим нам предстоит разобраться.

Эту тему довольно сложно понять с нуля, не имея относительно прочной опоры

Читать дальше

АРП DF-2000: что пошло не так с этим радиопеленгатором

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

Читать дальше

Устойчивость АФАР/AESA радиолокатора F-35 к блокированию T/R модулей

Антенная решетка локатора AN-APG-81 самолета F-35

Бортовые радиолокаторы военных самолетов, предназначеные для поиска и сопровождения целей проходят эволюцию от пассивных фазовых антенных решеток (ПФАР, или PESA — Passive Electronically Scanned Array) к активным фазовым антенным решеткам — АФАР, или AESA: Active Electronically Scanned Array). Базовым элементом и тех и других является приемо-передающий модуль —

Читать дальше