Я розробляю embedded-системи (C++, bare-metal, низькорівнева оптимізація під STM32) і працюю виключно віддалено через фізичні обмеження (ДЦП, 1 група). Поки HR-департаменти звітують про корпоративну інклюзивність, обов’язковий RTO (Return to Office) на практиці миттєво відсікає кваліфікованих автономних спеціалістів, які не потребують щоденного нагляду менеджерів.

У сучасній розробці залізо без проблем тестується на локальних HIL-стендах удома, комунікація чудово лягає в асинхронні процеси, а результат вимірюється стабільністю прошивки, а не присутністю за столом в опенспейсі. Культ офісу позбавляє індустрію сильних практиків лише через небажання бізнесу налаштовувати нормальні процеси Детальніше розібрав цю проблему тут dou.ua/forums/topic/61649

Звісно, розводка силової плати на 10 кВт, розрахунок гейт-драйверів та теплопровід — це окрема велика апаратна задача. Але математика ядра керування та логіка на STM32 залишаються незмінними.

Радий, що так чекаєте на другу частину! Щоб точно не пропустити «вжуххх» — підписуйтесь на YouTube-канал. 😉

Ви трохи плутаєте задачі PLC-інтегратора та Embedded-розробника. Купити готовий модуль Siemens або ABB за тисячі доларів — це найпростіше рішення. Але в реальному R&D, MilTech або при розробці власного продукту так не працюють — там потрібно створювати кастомну електроніку з мінімальною собівартістю в серії.

Щодо потужностей і «глини та палок»: мета цього відео — не спалити кіловати, а показати робочий Proof of Concept (доказ концепції). Якщо я здатен розробити архітектуру, написати математику ПІД-регулятора на C/C++, налаштувати таймери STM32 і підняти стабільну систему на базовому прототипі, то масштабувати її до 5–10 кВт — це виключно питання виділеного фінансування та NDA-проєкту. Математика керування від цього не змінюється. (І ні, мосфети не горять, якщо інженер вміє правильно розраховувати dead-time).

Але головний меседж мого відео взагалі в іншому. Воно наочно доводить, що **навіть такий складний апаратний R&D-процес можна виконувати 100% віддалено**. Немає жодної потреби сидіти в офісному опенспейсі. Якщо роботодавець ставить чітку задачу і дає бюджет на компоненти, я можу побудувати надійну систему будь-якої потужності у власній лабораторії.

Це лише перша частина демонстрації. Далі буде друга, тому чекайте на продовження, обіцяю буде цікаво."

ШІ — це лише зручний інтерфейс для набору тексту, який економить мені купу часу через фізичні обмеження (ДЦП).

Але жоден ШІ в світі не спаяє плату, не налаштує фазовий зсув трьохфазного ШІМ на таймерах STM32 і не напише ПІД-регулятор під реальний BLDC-мотор без інженерних мізків. Спробуйте згодувати нейромережі задачу стабілізації обертів чи роботу з DMA без розуміння архітектури регістрів — вона нагенерить вам красивого сміття, яке в кращому випадку просто не запуститься, а в гіршому випалить силові ключі.

Ось наочний пруф із моєї лабораторії — робота заліза, GUI телеметрія на Python та реальна інженерія:

Інструменти треба використовувати для справи, а судити — по робочому результату на столі, а не по манері тексту."

Розумію вашу позицію. Комусь важлива форма, а комусь — результат. Для мене головний критерій — це стабільний код і працююче залізо. Якщо стилістика тексту стає для вас нездоланним бар’єром, щоб оцінити реально працююче технічне рішення — що ж, маю це прийняти.
> Тим, кому цікава саме архітектура та embedded-розробка, зазвичай вистачає мого коду, схем та відеодемонстрацій, які говорять самі за себе без зайвих літер. Дякую за вашу думку, гарного дня."

ШІ без інженера такий драйвер не напише, дива не буває. Але ШІ, яким керує спеціаліст, що знає, як працює RMII і як читати мануали — зробить це легко. Я використовую нейромережі не для того, щоб вони думали замість мене, а для того, щоб вони виконували рутину за моєю логікою.
> А машинна озвучка — це просто ефективний інструмент презентації. Давайте оцінювати технічний результат (працююче залізо), а не обгортку."

Вітаю товариство! 👋 Дякую редакції DOU за публікацію.
Для мене створення цієї архітектури стало переходом від звичайних «показометрів» до нормального промислового R&D інструменту, який не падає від потоку даних.
Цікаво дізнатися у колег по цеху: хто працює з силовою електронікою або просто зі швидкісним збором даних (від 1 кГц і вище) — які готові рішення чи власні «костилі» використовуєте ви, щоб не класти UI на лопатки?
Буду радий обговорити підходи та відповісти на питання щодо нашої реалізації на STM32 + Python

Так, я використовую ШІ як асистента для роботи з текстами. Мій основний інструментарій — це паяльник, осцилограф, С/С++ та Python, а не клавіатура для написання лонгрідів. ШІ просто економить мій час на структурування моїх же думок та інженерного досвіду.
Давайте дивитися на суть: чи змінює «гптшна манера тексту» той факт, що корпоративні стандарти часто ігнорують сильних спеціалістів? Або той факт, що описана в статті в коментарях архітектура телеметрії працює? Думаю, ні."

«Коли закінчуються аргументи про процеси та інженерію, в хід ідуть воукізм і Конфуцій. Дякую за бесіду, далі мені треба повертатися до осцилографа і писати код, а не філософські трактати. Гарного дня.»

«Ви знову намагаєтесь перевести розмову в площину „хто незамінний“ чи сипати академічними термінами про теорію ігор та цикли Кондратьєва. Я ніде не стверджував, що я єдиний чи незамінний — в Україні повно сильних фахівців, значно досвідченіших за мене.

Суть статті взагалі про інше — про підхід і реальну інклюзивність.

Це схоже на ситуацію з міською безбар’єрністю: на папері є норматив, галочка стоїть і пандус наче „є“, а в реальності він зроблений під кутом 45 градусів, бо „шерифу байдуже, таргетується KPI для звіту“.

Я чудово розумію, що один допис не зламає зашкарублі корпоративні стандарти прямо завтра. Але будь-які системні зміни починаються саме з того, що проблему перестають замовчувати. Якщо підсвічувати цю прірву між інклюзивністю „на папері“ та в реальності — бізнес поступово почне розуміти, що втрачає сильний інженерний потенціал заради формальних офісних нормативів. Світ змінюють не ті, хто змирився з неефективністю, а ті, хто пропонує іншу якість роботи.»

Ви дуже зручно виправдовуєте неефективність системи через «монополії та змову». Звісно, легше списати все на те, що «ху карес», ніж визнати, що менеджмент просто не вміє керувати проєктами на відстані.

Але реальність така, що залізо і код пишуться не за правилами олігополій, а завдяки роботі конкретних інженерів. І якщо класичні офісні структури продовжують втрачати кадри через власну ж тугодумність — це їхні проблеми, а не проблема ринку загалом."

Ви трохи підміняєте поняття. Я не скаржуся, що мене «не беруть» — я працюю як незалежна R&D студія (B2B), маю власну лабораторію і сам обираю, з якими замовниками співпрацювати.
> Я підсвічую системну проблему індустрії. Поки компанії граються в бюрократію і шукають «хоч когось, але щоб сидів в офісі», вони втрачають доступ до величезного пулу сильних інженерів по всій країні (зокрема людей з інвалідністю, або тих, хто живе в інших регіонах). Як влучно написали нижче, для проєктування електроніки часто достатньо валізи з обладнанням на домашньому столі.
> Компанії, які цього не розуміють, не «диктують умови» — вони просто стріляють собі в ногу і програють конкуренцію тим, хто купує результат, а не присутність."

Фраза про шерифа та індійців працює лише там, де інженер тримається за роботу від безвиході. У сучасному R&D (особливо в Embedded/MilTech) висококваліфікований спеціаліст — це не підлеглий, а партнер. Саме тому я, наприклад, вибудовую роботу виключно як незалежна студія (B2B). Мій замовник купує мій досвід, мій код і мій працюючий пристрій, а не моє фізичне тіло на стільці в офісі. Якщо компанія (шериф) замість результату вимагає протирати штани під час обстрілів, тим більше від людей, яким фізично важко добиратися, — значить, нам просто не по дорозі. Ринок зараз на боці тих, хто дає реальний продукт, а не імітує бурхливу діяльність в опенспейсі.

Богдане, відповідаю абсолютно чесно. Так, для набору та структурування об’ємних текстів я використовую ШІ. Через фізичні обмеження (ДЦП) мені складно швидко друкувати великі масиви тексту вручну, тому для мене це необхідний інструмент доступності (accessibility).

Проте ШІ виконує лише роль мого «секретаря». Вся інженерна експертиза — конфігурація bare-metal, переведення АЦП на DMA, логіка дворівневого ШІМ та біль від спалених транзисторів через помилки в таймінгах ПІД-регулятора — це мій особистий, вистражданий роками досвід. ШІ вміє красиво складати речення, але розробити архітектуру Motor Control під закрите залізо замість інженера він, на жаль, не здатен. Форма тексту — відредагована, суть — на 100% моя.

Політичну складову коментаря залишу за дужками, оскільки як фаундер R&D студії я фокусуюсь виключно на інженерній площині.

Щодо технічної частини — з першою вашою тезою я абсолютно погоджуюсь. Усе дійсно «влазить у валізу». Сучасна домашня R&D лабораторія (осцилограф, логічний аналізатор, паяльна станція та плати на кшталт STM32G474) дозволяє закривати 95% завдань з розробки архітектури та написання bare-metal прошивок повністю віддалено.

А от із тезою про те, що «тисяча інженерів вже найнята і критичної потреби немає, потрібні лише збиральники» — дозволю собі категорично не погодитися як практик.

Проблема в тому, що сучасний Hardware R&D — це не статичний процес. Це не ситуація, де один раз написали прошивку і віддали на завод. Постійно з’являються нові нестандартні (або китайські пропрієтарні) двигуни, під які треба з нуля писати алгоритми Motor Control. Змінюються умови роботи — треба на льоту переписувати DSP-фільтри, переводити АЦП на DMA, щоб розвантажити ядро для складнішої математики, боротися з шумами та оптимізувати таймінги апаратних таймерів.

«Збиральники та фіксери» можуть спаяти плату по готовій схемі. Але коли система починає дивно поводитися під динамічним навантаженням або треба вижати максимум з архітектури ARM Cortex-M4, збиральник не допоможе. Тут потрібна глибока експертиза в обробці сигналів та мікроконтролерах. І саме таких фахівців на ринку — критичний дефіцит, що б там не заявляли компанії."

Богдане, проблема не в рівні інтелекту випускників, а у величезній прірві між академічною «теплицею» та жорсткою реальністю R&D. Випускнику заважають розібратися три фундаментальні речі:

1. Синдром «ідеального даташиту»
В університеті дають готову налагоджену плату, вичерпну документацію та чітке ТЗ. У реальному реверс-інжинірингу перед тобою лежить пропрієтарний «чорний ящик» без жодного папірця. Випускник звикає читати мануали, а тут треба брати осцилограф, аналізувати таймінги всліпу і самостійно будувати архітектуру сигналів з нуля. Університет не вчить працювати в умовах повної відсутності вхідних даних.

2. Тотальна залежність від абстракцій (HAL/Arduino)
Більшість випускників вміють блимати світлодіодами через високорівневі бібліотеки (на кшталт HAL). Але коли задача вимагає генерації дворівневого ШІМ із внутрішніми високочастотними стробами та мікросекундною синхронізацією, HAL починає безбожно гальмувати ядро. Щоб розв’язати цю проблему, треба відкидати абстракції, лізти на рівень bare-metal, вручну конфігурувати регістри таймерів та переводити АЦП на DMA, щоб не блокувати процесор. Цій інженерній жорстокості не вчать на парах.

3. Фатальна ціна помилки
Для студента-програміста помилка в коді — це просто червоний текст компілятора (Exception) або перезапуск дебагера. В силовій електроніці помилка в таймінгах або зрив синхронізації ПІД-регулятора на мілісекунду — це вибух силового каскаду, магічний дим із транзисторів і спалене залізо. Випускники бояться брати на себе відповідальність за алгоритми, які можуть фізично знищити обладнання.

Саме тому написати софт по API можуть тисячі, а написати Motor Control з власною кастомною телеметрією під закриту апаратну архітектуру — одиниці.

Денисе, ви маєте рацію, якщо говорити про загальний ринок чи базове написання коду по готовому ТЗ. Там дійсно черга. Але в hardware-розробці та R&D (наприклад, написання Motor Control алгоритмів під bare-metal) ситуація кардинально інша. Тут помилка — це не просто баг на екрані, це згоріле силове обладнання. Фахівців, які можуть самостійно розібратися з таймінгами закритої апаратної архітектури, на ринку одиниці, і саме тому якість та безпека розробки для компаній мають бути на першому місці."

До речі, для тих, кому цікаво, як саме виглядає результат роботи в ізольованій домашній лабораторії порівняно з опенспейсом — щойно виклав в архівну рубрику розбір нашого старого проєкту. Реверс-інжиніринг пропрієтарного двигуна, перехід на STM32 bare-metal, DMA та власна телеметрія. Буду радий почути фідбек від практиків щодо архітектури:

Дякую всім за увагу до матеріалу! Мені справді цікаво почути думку як інженерів-практиків, так і технічних лідів: як у ваших командах вирішують питання безпеки та віддаленого зневадження заліза? Чи вдається знаходити баланс між корпоративними політиками та реальною автономністю спеціалістів?

Привіт! Дякую за коментар та влучні питання 🤝

Щодо «дабл чеку» — абсолютно погоджуюся! Сліпо довіряти ШІ в bare-metal не можна. Саме тому в системі реалізований локальний компілятор: ШІ не просто генерує текст, а сам компілює його і перевіряє на відсутність помилок. Фінальне рев’ю логіки, звісно, залишається за людиною.

Стосовно машинного наратора — тут все прозаїчно. Для озвучки я використав сервіс ElevenLabs. Хотів зробити максимально чисте і зрозуміле демо, де голос звучить рівно і фокус залишається виключно на архітектурі та роботі заліза.

Щодо задачі з RMII, ETH PHY та NuttX — це крутий челендж! Відповім чесно: прямо зараз, «з коробки», моя модель це не зробить. Причина в тому, що я файнтьюнив Qwen 3B на своєму датасеті, який зараз заточений суто під HAL-драйвери та архітектуру STM32Cube. Але краса підходу з RAG та локальним датасетом у тому, що систему можна донавчити. Якщо згодувати їй еталонну документацію по NuttX та приклади імплементації кастомних драйверів — вона зможе генерувати цей специфічний код. Нарощування бази знань — це якраз мій наступний етап.