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

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

Эта статья — с цифрами для разработчиков. Как до, так и после 21 сентября. Исследование по HR, менеджерам и дизайнерам выйдет позже, если этот пост вам понравится.

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

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

Дано: ненужная ТВ-приставка + острая потребность в компьютере с низким энергопотреблением под Linux. Почему бы не превратить одно в другое?

Некоторое время назад автор этих строк взялся разрабатывать компактный регистратор одно-полярного аналогового сигнала в пределах 3 вольт с максимально возможной скоростью считывания и минимально возможными затратами и размерами. В список минимально возможных затрат я вписал также и свою головную боль и выбрал хорошо знакомый мне STM32F303. Это, напомню, Cortex-M4 на 72 мегагерца от известной компании, со встроенными 12 разрядными, довольно шустрыми, аналого-цифровыми преобразователями (АЦП или ADC, кому как нравится) и с CAN интерфейсом на борту.

Таких небольших регистраторов требовалось несколько десятков. А наличие у микроконтроллера корпуса о 48-ми ногах вселяло надежду на то, что получится назвать этот считыватель компактным. Интерфейс CAN, с которым у меня уже тогда были хорошие отношения, давал мне возможность объединить весь этот джаз в достаточно удобной манере.

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

Однако, некоторый осадок остался. Осталась мысль, что, в отношении быстродействия, выжато было не все.

И вот, совсем недавно появляется серия STM32G4 с тактовой частотой до 170 мегагерц с вариантом в маленьком корпусе, и с почти такими же шустрыми АЦП на борту в количестве пяти штук. Надо было что-то делать.

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

Зачем нам консоль в МК?

• Требует относительно мало ресурсов МК, и минимум аппаратных затрат — последовательный интерфейс типа UART или любой другой имеющийся в МК, это может быть встроенный USB или внешний USB-Com адаптер или даже TCP если ваше микроконтроллер достаточно серьезный.
• Удобно подключаться — достаточно терминала поддерживающего Com-port (putty для Windows или minicom для linux).
• Удобно использовать — цветной вывод в терминал, поддержка авто-дополнений, горячих клавиш и истории ввода.

Всем привет! В процессе работы над гексаподом AIWM я все чаще задумывался о каком-нибудь удобном интерфейсе для общения с ним. В результате тесной работы с Linux через терминал я подумал, а почему бы не использовать такой же интерфейс и в гексаподе? Я был очень удивлен, что по запросу "STM32 terminal" я не нашел готовых реализаций. Ну раз нет готовых, то напишем свою реализацию терминального сервера, которую можно использовать в микроконтроллерах. Сделаем это без использования динамической памяти и прочих опасных радостей.

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

...и не только!

Это история о том, как я создал конструктор для решения повседневных проблем. Для меня он стал незаменимым помощником по жизни. Возможно, и вам придется по вкусу (древесины:))

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

Общаясь сейчас со связистами на предмет «сообщите, кому какой припой нужен», получил достаточно типовой ответ — «хороший, чтобы всё паял». Углублённое обсуждение вопроса вынесло на поверхность несколько запомнившихся людям торговых марок — в первую очередь Asahi — но и только. Про флюсы и их различия сказано ничего не было.

Спектр задач по пайке при этом у связистов простирается от антенно-фидерного хозяйства (кабели, разъёмы), через аксессуары (зарядки, гарнитуры) и до ремонта собственно радиоаппаратуры (SMD-компоненты).

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

Итак: какие бывают флюсы в припоях, что лучше — ORL0 или ROM1 (я проверил гуглем, обе аббревиатуры на Хабре встречались 0 раз), где искать эту информацию и зачем вообще это надо.

В этом году меня в очередной раз позвали в Московский институт электроники и математики (МИЭМ) НИУ ВШЭ читать студентам магистратуры (четвёртый курс на наши деньги) департамента электронной инженерии курс «Обеспечение взаимодействия элементов системы IoT, интерфейсы и протоколы».

Когда-то давно я уже читал вводный курс по программированию микроконтроллеров в МИРЭА, от лекций которого остались любезно сделанные вузом видеозаписи (от семинаров не осталось ничего, увы), потом — курс по Интрнету вещей (там было сочетание микроконтроллеров, их программирования и введения в специфику IoT-систем) уже в МИЭМ НИУ ВШЭ, от которого, увы, тоже не осталось никаких публично доступных материалов.

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

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

Итак, поехали.

Да