Настольный зубофрезерный станок

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

Итак, начнем с того, что мне понадобились косозубые шестерни с модулем 0,5, вроде бы понятными количеством зубьев и толщиной — ну а прочие параметры пока что не столь критичны. Возможно, будь дело где-то в Америке из воспоминаний Фейнмана, я бы просто взял каталог фирмы Boston Gear (в распространенном переводе «Вы, конечно, шутите, мистер Фейнман» его обозвали «Бостонским каталогом шестерен») и нашел бы там нужную деталь; если бы дело было в Германии, то наверное, стоило бы воспользоваться аналогичным каталогом Zahnradfabric Friedrichshafen — но, конечно, не уверен, что это было бы достаточно дешево. А какие опции доступны «микропроизводству» в Москве в 2025 году? Конечно, можно купить какие-то компоненты на Алиэкспрессе — и для некоторых типов шестерней это самый понятный вариант. Да, если речь идет о сотнях-тысячах деталей, придется подумать о вариантах доставки из Китая — но это будет работать только в случае, если эти детали достаточно «стандартные» (всякие компоненты для тех же 3D-принтеров или хоббийных станков, например). Прямозубые шестерни для игрушек с тем же модулем стоят копейки — можно даже купить в Чип-и-Дипе набор игрушечных шестерен, и может быть, если бы мне подходили стандартные шестерни из этого набора, это было бы даже экономически оправдано в варианте «покупаем набор и 90% из него выкидываем» — но мне понадобились более сложные, косозубые. Их, к сожалению, не получится сделать на термопластавтомате (а я даже приценивался к мини-ТПА, это внезапно не так дорого) — так что пришлось смотреть на другие, более традиционные методы изготовления зубчатых колес.

Чаще всего в этом контексте упоминают нарезание зубчатых колес модульной фрезой на фрезерном станке с делительной головкой, или что-то аналогичное — метод простой, не требующий специального оборудования, подходящий, к примеру, для ремонтных работ — сделать на универсальном станке в одном экземпляре шестерню взамен сломанной — и абсолютно не подходящий для более-менее серийного изготовления, даже если оснастить станок какой-то системой ЧПУ. Если же нужно делать шестерни хоть какой-то серией — то единственно оправданным методом становится зубофрезеровка, и на первый взгляд, это сложно и дорого. «Взрослый» зуборезный станок, какой-нибудь 5К32 — это дура в две тонны весом, расчитанная на нарезку здоровенных крупномодульных колес. Можно, конечно, обратиться и к [info]bougaev, у которого в мастерской есть аж настоящий Pfauter — но что-то мне подсказывает, что партия шестерен фирмы «жадинка Михалыч» выйдет буквально золотой :) Впрочем, на другом «полюсе» есть нищебродские методы, наподобие нарезания червячных эрзац-передач метчиком с крупным шагом — о которых даже пишут на Hackaday!

Что же лежит между этим нищебродством и использованием «настоящих» зуборезных станков? Дело в том, что запатентованный герром Пфаутером в 1897 году метод нарезания зубчатых колес с помощью червячных фрез довольно сложен, требует согласованного вращения фрезы и заготовки, и сложной настройки передач зубофрезерного станка — у которого есть аж две гитары — соло и бас вращения заготовки и подачи фрезы, а для нарезания косозубых шестерен добавляется еще и дифференциал с еще одной гитарой. Если добавить еще и ударные инструменты (без кувалды и зубила ты не слесарь, а мудила) — можно играть heavy metal! Какой-нибудь «справочник зубореза» состоит в основном из таблиц настройки этих гитар — которые еще и здорово отличаются у разных станков!

Я не зря вспомнил Фейнмана — потому что задачей получения заданного передаточного отношения с помощью подбора шестерен он в своих мемуарах и занимался. Но сейчас у нас не 1941 год, и даже токари-любители-ардуинщики придумали «электронную гитару» — несложный проект, позволяющий с помощью сравнительно недорогих компонентов получить любой коэффициент деления в широких пределах. В общем, дальнейшая идея почти очевидна — соорудить действующий макет зуборезного станка, использовав вместо механических передач «электронные». Может быть, так сработало место расположения моей мастерской, в районе остатков завода «Фрезер», может, дотянулись какие-то флюиды от Станкиновского учебного корпуса неподалеку — но мне это показалось достаточно заслуживающим внимания.

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

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

«Электронная гитара» на Arduino — проект прикольный, я частично подсмотрел там работу с шаговиками и энкодером — но потом все равно все переделал, конечно же :) Как это выглядит? На вал шпинделя (или, в нашем случае, червячной фрезы) ставится энкодер, выдающий, стандартно, 600 импульсов на оборот. Все же зависящие от количества оборотов шестерни передачи оснащаются шаговыми двигателями со стандартными, знакомыми многим по 3D-принтерам, драйверами, у меня завалялось несколько A4988 и TMC2208 (опять же, в виде готовых модулей для тех же 3D-принтеров). В режиме «микрошага» x16 для полного оборота шагового двигателя необходимо выдать 16*200=3200 импульсов, да еще и привод заготовки оснащен редуктором 1:4. В прошивке «электронной гитары» для этого вычисляется целая и дробная часть коэффициента деления — скажем, если мы будем резать шестерню на 127 зубьев (специально подобрал не очень хорошее число — но такие шестерни иногда нужны), то надо сделать один оборот заготовки на 127 оборотов фрезы. Соответственно, 76 200 импульсов энкодера будут соответствовать 12 800 импульсам, которые надо выдать на шаговый двигатель. Делим, и получаем, что коэффициент деления нашей «электронной гитары» должен составлять 5,953125. В ардуиновской прошивке с Chipmaker для такого дробного деления заводятся две переменных, Ks_divisor, с целой частью коэффициента деления, и Km_divisor, с дробной — давайте я приведу здесь максимально упрощенный код, без учета направления вращения вала (можете найти подобное в обработчике прерывания от энкодера):

int Ks_divisor = 5;
int Km_divisor = 9531;
int Ks_counter = 0;
int Km_counter = 0;
void isr(void){
    Ks_counter++;
    if(Ks_counter > Ks_divisor){
        step();
        Km_counter += Km_divisor;
        if(Km_counter > Km_divisor) {
            Km_counter -= 10000;
            Ks_counter = 0;
        } else {
            Ks_counter = 1;
        }
    }
}

В общем, можно понять, что автор ардуиновской прошивки пытается с помощью целочисленных переменных имитировать вычисления с точность 1/10000 (или 4 знака после десятичной запятой). Метод, может, и работающий, но имеющий очевидный недостаток — вы видите в этой программе число 5,953125, полученное в ходе расчетов? Дробную часть пришлось округлить, и это не очень хорошо — при большом количестве оборотов, то есть медленной и печальной, с подачей 0,1 мм на оборот, обработке даже не очень длинной заготовки — скажем, длиной 10 мм — ваша заготовка сделает 100 оборотов, фреза — 12700, ошибка на один шаг уже вылезет. Может, это и немного — но учитывая жесткость станка, точнее, ее отсутствие, вытекающие отсюда небольшие подачи и такой же небольшой съем материала — накапливающаяся ошибка становится проблемой.

Увеличивать разрядность в расчетах можно (хотя на Ардуине это проблема), но давайте посмотрим на задачу с другой стороны. Нам надо на каждые 76 200 шагов по одной «координате» равномерно сделать 12 800 шагов по другой. Классический алгоритм для этого был предложен Брезенхемом из IBM в 1962 году (да, все хорошее в программировании было придумано либо IBM в 60-х, либо DEC в 70-х) — и в аналогично упрощенном виде целочисленный алгоритм Брезенхема будет выглядеть так:

int dx = 76200;
int dy = 12800;
int err = 0;
void isr(void){
    err += dy;
    if(2*err > dx){
        step();
        err -= dx;
    }
}

Конечно, переменнные dx и dy можно и даже, наверное, нужно сократить на общий множитель (заодно вычисления будут умещаться в меньшую разрядность, полезно, если у вас 16-битный int на AtMega), а умножение на 2, если вы не доверяете оптимизации компилятора, заменить битовым сдвигом — но в целом тут и вычисления проще, и, что важно, ошибка не превышает 1/2 шага и не накапливается. Таким же образом можно получить и любые коэффициенты деления, выражающиеся простыми несократимыми дробями — полезно, если вам надо заменить настоящую чугунную гитару.

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

UPD Латунь («сыпучку», ЛС59-1) станочек вполне успешно обрабатывает с вертикальной подачей 0,3 мм/оборот.

Нюансы произношения

Есть у нас на работе неновый сервер с какой-то весьма ностальгической убунтой (но LTS, правда, и тот уже подходит к концу). Подходит ко мне коллега и интересуется какими-то нюансами работы apt-get на нем, мол «хочу глипс обновить» (попытался максимально правдоподобно передать произнесенное слово). Ну я понял, что чел хочет обновить Eclipse, он там действительно старый, но вроде работающий (хотя сидеть в нем через xrdp — ну так себе занятие) — но ладно, показал нужные заклинания. Дальше чешем языками, мол, раньше-то все работало, зачем новая версия понадобилась? Оказывается, у чувака отвалился плагин Remote-SSH к vscode, и вот поэтому нужно обновить тот самый глипс. Еще минуточку трачу на выяснения, а какое отношение Eclipse имеет к vscode — и понимаю, что словом глипс чувак обозвал glibc — которую обновлять — совершенно дохлый номер.

А как вы произносите glibc?

PS Проблема с Remote-SSH от vscode и старыми версиями glibc действительно есть, только решается она не так — проще «заморозить» версию vscode и плагинов и запретить ей обновляться. Кажется, к идее обновить glibc чела подтолкнул какой-то чат-бот на базе нейронок, совет шикарный, буквально «если у вас скрипят тормоза, смажьте их солидолом».

Нечеловеческие стандарты

Чисто случайно наткнулся на ГОСТ 3.1103 — в версии 2011 и 1982 года. Конечно, хорошо, что ЕСКД и ЕСТД приводят к актуальным реалиям — когда все эти документы разрабатываются в разных САПРах, а олдскульное бумажное представление необязательно (а вот «программистскую» ЕСПД так и не обновили). Но! Старая версия документа была доступна для понимания буквально слесарюге с ПТУшным образованием, а новая начинается с довольно многословного введения с определением, что такое «документ», и какие у него бывают «атрибуты» и «реквизиты». И вроде бы ясно, для чего и зачем это все, но внезапно оказывается, что понять нововведения может только человек, как-то знакомый с принципами построения реляционных баз данных, например — а это даже не все специалисты с профильным высшим образованием осиливают (и это, конечно, можно отнести на счет качества этого самого «высшего образования»). Какой-то античеловеческий подход, если честно.

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

PS И все же нынешний вариант ЕСКД и ЕСТД по-своему прекрасен с исторической точки зрения, в стандартах прослеживаются «слои» из времен, когда документы можно было составлять от руки, и только очень важное что-то печаталось на машинке, в 80-х туда проникла аббревиатура АЦПУ — а в нынешней версии предполагается, что все эти атрибуты и реквизиты могут представляться только в виде «структурированного набора данных».

2 CAMS 1 HUB

А не подскажет ли кто, нет ли в природе USB-хабов, способных протащить сквозь себя видеопоток от двух веб-камер (бескорпусных ELP 720p с алиэкспресса, если что) одновременно? Разумеется, это должен быть хаб типа USB 3.0, но снабженный в «даунстриме» конвертерами протоколов — вот тут яндексоиды немного разъясняют, как это работает и даже показывают куски схем такого хаба, на VL817 (это микросхема хаба для USB 3.1) и VL670 (а это конвертер интерфейса USB 2.0 в super speed USB, он же USB 3-с-чем-то):

https://habr.com/ru/companies/yandex/articles/898282/

Задача у них была похожая, подключить к одному порту с поддержкой USB 3 много устройств, поддерживающих протоколы не выше USB 2, именно для этого конвертер интерфейсов и нужен:

https://hackaday.com/2022/03/07/a-chip-to-address-the-fundamental-usb-3-0-deficiency/

С веб-камерами человечество мучится уже давно, вот даже у авторов OpenPNP этому вопросу посвящена отдельная страничка:

https://github.com/openpnp/openpnp/wiki/USB-Camera-Troubleshooting-FAQ

Ну хоть для чего-то образовательная робототехника пригодилась

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

Тугая струя Linux-experience со звоном ударяет в таз

В честь дня защиты детей решил заменить собранную со студентами Московского Института Элегантных Мужчину говносборку из старой вайфайной точки доступа Zyxel и OrangePi, на которых вертится Chirpstack в МИЭМе, благо на Озоне по очень привлекательной цене (5000 рублей за какой-никакой, но x64, 8 Гб оперативки и 128 Гб SSD — это просто даром, взял сразу два) обнаружились китайские MiniPC с двумя независимыми Ethernet-адаптерами, это для того студенческого проекта довольно важно:

В общем, получил посылку, достал один из мини-пэцэ, успешнь накатил Ubuntu Server и решил перенести туда кое-какие файлы с OrangePi’евской MicroSD-карты (на 128 Гб, это важно). Дырки для SD-карт в мини-пэке нет, зато есть USB в количестве и где-то валяется адаптер для MicroSD.

Засовываю микросдшку в адаптер, адаптер в минипэку — и хуй там плавал! Файловая система не видна, точнее, «все сложно» — fdisk показывает ее наличие, но за пределами 3840 секторов диска (то есть от всех 128 Гб видно что-то порядка 1,88 Мб :) ). Начинаю проверять с разными карточками, преимущественно полудохлыми, и понимаю, что адаптер неправильно определяет количество секторов на карточках свыше 32 Гб — но в Windows это все работает, а Linux отказывается монтировать файловые системы, которые расположены «за пределами» диска.

Наверное, труЪ-линуксоид бы тут пропатчил ядро, возможно, прямо в бинарном виде — но я не труЪ, я пошел в ближайший ДНС (не путать с DNS) покупать другой адаптер. В ДНСе обнаружилось три модели адаптеров марки DEXP, стоимостью 120, 150 и 799 рублей — но я уже ученый, я посмотрел, написано ли где-то про то, что адаптер поддерживает microSD XC (карточки эти бывают трех стандартов, просто microSD, High Capacity и eXtra Capacity, наверное). Буковки XC упоминаются только на том, который стоит 799! :) С другой стороны, вероятно, что и более дешевые адаптеры работать будут, но гарантий этого никто не даст, да и не факт, что кто-то вообще знает, что китайцы туда воткнули.

Интересны в этой ситуации две вещи:

— как вообще вся эта околокомпьютерная хрень может работать, если к стандартам что в софте, что в железе подходят настолько «творчески»?
— а есть ли вообще шансы узнать, заработает ли очередная ноунейм-железка (а в этой категории все ноунейм, даже вроде бы приличные «бренды» могут не знать толком, что же там внутри на самом деле) с софтом чуть более экзотическим, чем самая свежая версия Windows?

Идея для стартапа

SMD-расстановщик под псевдонемецкой маркой Hellinger. Надо будет заняться сразу после того, как обзвоню все объявления «мастер рейки» с вопросами о ремонте рулевой рейки от некроBMW :)

UPD Подсказали, что СМД у психологов и примкнувшим к ним означает «системную мыследеятельность» — так что придется заняться смд-расстановками!

Посрался в интернетиках

Затроллил в разных чатах до обеда аж двух Chief Technical Officer’ов каких-то стартапов. День начался удачно!

Впрочем, надо аккуратнее тыкать палочкой и не начинать с острых вопросов «а вы что, правда CTO вот этого вот говнища?» (ссылка на адски глючащую страничку прилагается). Заодно в качестве метода троллинга крайне рекомендую цитаты из КТ-178B, прекрасный документ с описанием самых разных подходов к тестированию!

Немного про электронику

Чувствую себя персонажем шуточки про «имея осциллограф, можно починить все, кроме этого осциллографа; имея два осциллографа, можно починить вообще все» — купил китайскую портативную балалайку Jinhan JDS6052s, спалил (?) в ней генератор сигналов, сейчас ковыряюсь внутри, используя «стационарный» Rigol DS1054z. Так вот, Jinhan устроен занятно:

— входные усилители на AD603 особо не удивляют;
— АЦП с затертой маркировкой (да и хрен с ним);
— ПЛИС Lattice LCMX02 (собственно, все интересное происходит в ней);
— ЦАП TI DAC904;
— выходной усилитель на Renesas EL5462 (счетверенный ОУ с токовой обратной связью).

На второй плате стоит микроконтроллер (вроде бы что-то из серии GD32, но я туда не лез), подключен экранчик и кнопочки — но опять же, ничего удивительного. Вот что мне интересно — то, что генератор сделали на ПЛИС, ЦАП и широкополосном усилителе — а в то же время «популярные» любительски-студенческие проекты обычно используют банальную AD9851. Неожиданно, что решение на «рассыпухе» оказалось более правильным и выгодным, чем полностью «интегрированное».

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

Обиженки из опенсорса

Есть такой довольно древний проект эмулятора еще более древних вычислительных платформ — SIMH. Залез я на днях в его репозиторий и увидел в лицензии очень странную формулировку (и еще кучку каких-то разъяснений):

Any use of this codebase that changes the code to influence the behavior of the disk access activities provided by sim_disk.c and scp.c is free to do that as long as anyone doing this is explicitly not licensed to any subsequent changes to any part of the codebase in the master branch of the git repository (https://github.com/simh/simh) made by Mark Pizzolato after the LICENSE.txt was added to the master branch of repository. Changes that qualify for this restriction at least include: changing the behavior or default of SET AUTOSIZE/NOAUTOSIZE, or any code in scp.c and sim_disk.c or any simulator components that use the sim_disk routines.

Что это могло бы значить? Сначала перебирал в голове мысли о том, что функциональность дисковой подсистемы ограничили специально, из-за каких-то «требований правообладателя» — мол, ваш эмулятор может быть использован для того, чтобы пиратить какой-то древний, но очень дорогой софт. Но реальность оказалась куда смешнее:

https://github.com/simh/simh/issues/1059

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

Немножко про авиацию

Вот в очередной раз встретил мнение, что в Российской Империи в 1914-1917 году все с авиацией было если не отлично, то хотя бы хорошо:

https://t.me/rusengineer/5174

В тексте довольно много цифр, и неплохо подобранных, создающих впечатление, что вплоть до 1917 года все было в принципе неплохо. Но… Сразу бросается в глаза — а почему нет вообще никакой статистики по Великобритании, которая тоже входила в число союзников по Антанте? А все потому, что если посчитать выпуск самолетов даже одного производителя — то охуеют все (циферки беру из Википедии):

Сопвич «полуторастоечный» — 5939
Сопвич «Pup» — 1796
Сопвич «Camel» — 5490

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

В годы Первой мировой войны Военному ведомству России было сдано 1 569 самолётов и гидропланов. В 1917 году завод выпускал до 60-70 аэропланов ежемесячно, став одним из крупнейших производителей аэропланов в России. Всего в 1910—1917 годах «Дукс» построил более 1 750 самолётов разных моделей — это треть от всех построенных в то время в России.

Если 1750 самолетов — это «треть от всех построенных» — то общее число самолетов, выпущенных в России в 1910-1917 годах уступает даже тиражу одной-единственной удачной модели Сопвича. Это «мощная и развитая промышленность»? Нет, это несколько мелких предприятий по лицензионной сборке иностранных моделей, типа того же «Дукса», причем страдавших от отсутствия поставок «критических» компонент. Собственно, по первой ссылке дефицит двигателей тоже упоминается, как и зависимость от импортных поставок, но акцент на ней не делается.

PS А теперь примерьте написанное выше на отечественных «дроностроителей», которые с гордостью заявляют о том, что созданные ими производственные и технические решения надо массово тиражировать.

И про новости

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

Специалисты IT-компаний не смогут уволиться, не погасив IT-ипотеку, сообщает Минцифры РФ.

«Минимальный срок работы в IT-компании: было — пять лет с момента оформления кредита, стало — в течение всего срока ипотеки», — говорится в сообщении.

https://t.me/bbbreaking/187220

Айтишники, не отягощенные гуманитарным образованием, завопили, что это крепостное право и новый ГУЛаг, но на самом деле, конечно же, это просто оформление нового «сословия» по Кордонскому. С другой стороны, забавно, что возглавляет этот процесс Министерство цифрового развития.

Вынесу из вконтактика

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

Начнем с измерения силы тока:

Мы рассмотрели разные варианты измерительных схем:

Измерили разные параметры операционных усилителей:

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

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

Долго подбирали компоненты:

Боролись с помехами:

Написали прошивку и интегрировали девайс в большую систему:

Все требования технического задания были выполнены:

Работа защищена на отлично!

Дипломники, блин

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

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

— все было плохо;
— циферки, почему все плохо;
— пришли мы и сделали что-то получше;
— циферки, почему стало получше;
— мы молодцы, поставьте нам хорошую оценку!

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

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

Во-вторых, при подготовке бакалаврских дипломных работ их уже испортили необходимостью соблюдения совершенно дегенератских требований — они начинаются от объема «точно в 60 страниц, не больше, ни меньше» (это самое простое) и продолжаются процентом оригинальности по данным какого-то из сервисов антиплагиата (пережить можно, если работа пишется самостоятельно — то даже 10% заимствований не наберется), и наконец, на днях меня выморозило вот такое требование к списку литературы, текст оригинала сохранен:

Количество литературы — не более 40 с актуальным сроком информации не старше 5 лет.

Как думаете, что спросит у руководителя испорченный бакалавриатом студент? Разумеется, «А что делать, если у меня 41 пункт и есть ссылка на ГОСТ 23089.14-88?» — и хорошо, что спросил, а не побежал исправлять список литературы!

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

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

Испытываю странное чувство

Хотел в продолжение предыдущей телеги написать, что DO-178 — самый аджайловый из аджайловых стандартов, а за меня это сделали чуваки из Airbus:

https://hal.science/hal-02156357/document

Впрочем, пригодится :)

Про CI/CD

Прочитал студентам проповедь про CI/CD в embedded, поделюсь и тут:

Как учат нас всякие нормативные документы — возьмем, например «авиационный» стандарт DO-178B или в русском переводе — КТ-178B — «интеграция» — это процесс, в рамках которого «исполняемый код загружается в целевой вычислитель» (раздел 5.4) — то есть примерно то, когда вы в Riot выполняете команду make flash или в каком-нибудь красивом IDE типа Keil или IAR (ну или в крайнем случае Arduino IDE) нажимаете кнопку «Run», которая делает то же самое — ваш проект компилируется и загружается в подключенное к вашему компьютеру через отладчик устройство. Это может быть устроено немного более сложно, но пока такого представления об этом всем достаточно.

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

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

«Наивный» подход к разработке ПО (свойственный инженерам-электронщикам, кстати говоря) — это то, что показано для «компоненты W» — формулируем требования, выдаем их кодеру, он пишет код, потом заливаем его в целевое устройство, …, PROFIT! Проблема в том, что он… не работает, но при этом широко применяется, вот довольно яркое описание принятых у электронщиков рабочих процессов в программировании:

Качество кода? Ревью? Разделение задач? система контроля версий? Да о чем вы! Высрал бинарник в пизженом кейле и отдал на производство. Человек ушел, работы не приняли, новый начинает с нуля все заново.

https://mbr.livejournal.com/606449.html

Так вот, «непрерывная интеграция» — это в точности то, что сделано в Riot’овских тестах, запускающихся на базе iotlab:

— основная «ветка» безо всякого участия программиста компилируется (это результат «процесса кодирования», пункт 5.3.2 в документе), причем «эталонным» компилятором (я видел, как некоторые проекты «ломались» от смены версий gcc);
— выполняется «процесс интеграции» (раздел 5.4);
— дальше проводится то, что в КТ-178 называется словом «испытания» (программисты скорее будут использовать слово «тестирование») — «выхлоп» программы сравнивается с ожидаемым.

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

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

В embedded это все особенно ярко видно, потому что «целевой вычислитель» — вот он у вас, в руках или на столе в виде отладочной платы.

Понятно, что все эти вещи можно делать разными средствами — да хоть даже «вручную» — написал код, выполнил команду make или нажал Compile, отдал получившийся бинарник тестировщику (и все это еще оформить документально журналом по принципу «сделал — запиши, не сделал — запиши два раза» — в принципе, и такие «процессы» возможны), но если можно автоматизировать эту работу — то почему бы и нет? Заодно в какой-то степени из процесса испытаний исключается человеческий фактор, все, что можно проверить автоматически — будет проверено, в идеале — для каждого существенного изменения в вашем гитлабовском репозитории (а контроль версий на языке тех же стандартов входит в то, что называется «управлением конфигурациями»).

Собственно, именно это и называется «непрерывной интеграцией», а вовсе не бездумное использование GitLab, Docker и прочих Ansible — важны не инструменты, а то, что вы с помощью этих инструментов делаете. Более того, если строго следовать требованиям КТ-178 — то используемые в процессе валидации инструменты должны быть «квалифицированы», то есть разработаны в рамках предъявляемых стандартом требований. Разумеется, такие программные продукты тоже есть, стоят дорого, как и все авиационное — но возможно, и с ними в жизни придется встретиться.

Про массовое производство

Не очень умные хохлы смеются над сделанным в лучших традициях «военки» блоком управления УМПК — моднейшей российской корректируемой авиабомбы. Не отрицая того, что вот эти жгутики с кембриками и разъемы DB-9 — чудовищный пример антитехнологичности, скажу просто — молитесь, чтобы начинку УМПК не начали делать по технологиям, скажем, автоэлектроники — девайс существенно проще, скажем, автомобильного ЭБУ, так что собирать их по несколько сотен в час можно без особого труда:

А тех, кто топит за жгутики и кембрики, в Прекрасной России Будущего отправят в исправительно-трудовые лагеря, на строительство заводов по производству современных разъемов (хотя вот отечественный Ethernet показывали, КРОСИВОЕ).

Embedded, мать его

Как это, руководить проектом (пусть даже студенческим) по разработке мелкого устройства на микроконтроллере? Да очень просто:

— вчера ты шутишь про «быстрые китайские чопперы» (не мотоциклы);
— сегодня — разбираешься в нюансах работы gdbserver поверх TCP;
— завтра — еще какая-нибудь ебала вылезет.

Впрочем, now it’s official — удалось прикрутить к Blackmagic Debug Probe поддержку TCP, причем нормально, а не как в ctxLink:

Дальше в планах — дальше допиливать обещанный как-то в комментах «отладчик с мониторингом энергопотребления для устройств Интернета вещей, … сочетающий в себе свойства Segger J-Link Pro, Blackmagic Debug Probe и Unwired Devices Energymon». Скорее всего, даже заопенсорсим устройство (прошивку уж точно) — хотя есть у меня обоснованные сомнения касательно всякого Open-source hardware.

Ну и в качестве развлечения — быстрый китайский чоппер (на этот раз мотоцикл):