×

Embedded-розробки для оптимізації виробництва: чому їх варто впроваджувати

Привіт! Меня звуть Вікторія Таранюк, я Associate QA Manager. Останні 12 років працюю в компанії GlobalLogic.

За ці роки мені пощастило працювати на різних проєктах та стартапах, однак найперспективнішою та цікавою, особисто для мене, стала галузь embedded-розробок. Зокрема, їх інтеграція для оптимізації виробничих процесів.

На мою думку, вбудовані системи — це саме те, що стоїть у центрі так званої Індустрії 4.0, яка своєю чергою базується на IoT, автоматизації і технологіях на основі ШІ. Як перші автоматичні стрічкові конвеєри на початку промислової революції XVIII ст. назавжди змінили світ, так і embended-розробки формують нову революцію, поволі змінюють нашу робочу і не тільки буденність.

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

Що таке embedded-технології

Перш ніж розпочати, дозвольте трішки оновити знання та стисло розповісти, що саме охоплює термін «embedded-розробки».

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

Ключова ідея полягає в тому, що комп’ютерна система знаходиться всередині іншого пристрою та керує його роботою. Таке собі ідеальне злиття та взаємодія між hard та soft. Це може бути як простий контролер, що здатний здійснювати базові обчислення та функціонувати цілий рік на одній батарейці, так і великі інтегровані системи, що можуть вміщати в себе декілька комп’ютерів, операційних систем та SoC (System on Chip), спеціально розроблені для виконання завдань у певній галузі.

Іншими словами, вбудовані системи — це один або кілька пристроїв, що інтегровані в основну систему з метою виконання певної прикладної задачі. Наприклад, embedded-системи можуть використовуватися для моніторингу ефективності обладнання у промислових підприємствах: вбудовані в обладнання сенсори можуть вимірювати рівень енергоспоживання та надсилати дані до центральної системи моніторингу. Це дозволить знизити витрати на електроенергію та підвищити продуктивність, ефективніше використовуючи обладнання.

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

Фанати геймінгу добре знайомі з embedded-технологіями. Наприклад, ґаджети віртуальної реальності (VR) містять датчики руху та спеціальне ПЗ, що занурює користувачів у віртуальний світ та дозволяє взаємодіяти з ним. PlayStation VR або Oculus Rift використовують вбудовані датчики руху та камеру для відстеження рухів користувача та його позиції у просторі.

Використання embedded-розробок зовсім не обмежується сферою розваг та дозвілля. Їх також можна (і потрібно) використовувати, як частину автоматизованої виробничої системи в різноманітних галузях промисловості. Про це й поговоримо далі.

Що вивчати, щоб розвиватись в Embedded

Опишу стек технологій, які стануть у пригоді тим, хто планує працювати і розвиватись у напрямку Embedded. Зазвичай, потрібно опанувати наступні технології:

  • Мови програмування:
    • C/C++. Більшість вбудованих систем використовують C або C++ завдяки своїм низькорівневим можливостям та ефективному управлінню пам’яттю.
    • Мова асемблера. Знання мови асемблера зазвичай потрібне, оскільки вона працює напряму з операціями на процесорі залежно від архітектури без додаткових рівнів абстракції. Такі програми працюють найшвидше та оптимізовані з точки зору обчислювальних ресурсів
    • Python. Традиційно, мова Python не використовується у embedded, втім вона повсякчас застосовується у вбудованих програмах вищого рівня, тестуванні або скриптах. Також на Python зручно розробляти обробку структур даних
  • Основи роботи з мікроконтролерами: розуміння мікроконтролерів має вирішальне значення, включаючи знання їх архітектури, управління пам’яттю, взаємозв’язок введення/ виведення тощо. Корисно мати практичний досвід роботи з популярними мікроконтролерами, такими як ARM, AVR. Також для навчання є багато готових фреймворків та готових апаратних розширень під esp32
  • Real-Time Operating Systems (RTOS, Операційна система реального часу): RTOS часто використовуються в розробці вбудованих систем. Знання операційних систем, таких як FreeRTOS, RTLinux або VxWorks може стати перевагою.
  • Embedded Linux: для складніших вбудованих систем зазвичай застосовується Embedded Linux, відомі дистрибутиви для навчання BusyBox та OpenWrt.
  • Hardware Description Languages (HDLs, Мова опису апаратури): для FPGA програмування та ASIC design використовуються мови VHDL або Verilog.
  • Периферійні інтерфейси: опанування основ роботи з такими широковживаними інтерфейсами, як SPI, I2C, CAN, UART тощо, необхідне для взаємодії з іншими компонентами.
  • Налагодження програми або debugging: знання інструментів і методів налагодження, включаючи використання осцилографів і логічних аналізаторів, також може стати необхідним у певних доменах.
  • Version Control Systems (Системи управління версіями): як і при будь-якій розробці програмного забезпечення, важливі такі системи управління версіями, як Git.
  • Середовище розробки: розуміння основ роботи з інтегрованими середовищами розробки (IDE), що використовуються в розробці вбудованих систем, таких як Keil, IAR або Eclipse, є перевагою. Деяки розробники досі надають перевагу VIM
  • Протоколи: Для багатьох проектів необхідно розуміння базового стеку мережевих протоколів TCP/IP. Для бездротової комунікації можуть також знадобитись протоколи більш низького рівня такі як Bluetooth, ZigBee, Wi-Fi та інших протоколів бездротового зв’язку для підключених пристроїв (IoT).

Крім того, важливим для роботи є розуміння принципів цифрової електроніки та проєктування схем. Також розуміння того, як управляти живленням (power management) — часто це має вирішальне значення у вбудованих системах, особливо для акумуляторних пристроїв.

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

Вбудовані системи: призначення, сфери та способи застосування

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

В першу чергу на думку спадають наступні ринки: харчова промисловість, автомобілі, муніципальна інфраструктура, сільське господарство, машинобудівництво, пристрої для обміну даними, медицина та фармацевтика. Розгляньмо деякі з них детальніше:

Харчова промисловість. Процес виробництва харчових продуктів складається з багатьох не найпростіших етапів. На кожному з них підприємству необхідно відстежувати якість продукції, дотримуватись санітарних норм, законодавчих та галузевих стандартів. Тут на сцену й виходять embedded-розробки.

Наприклад, автоматизовані системи контролю температури та вологості складських приміщень. Ці системи допомагають відстежувати умови зберігання та попереджають про можливі зміни, що може запобігти псуванню продукції.

Ще один приклад — використовувати ці технології для вимірювання ваги або візуальному аналізу, завдяки технологіям комп’ютерного зору. Ці системи дозволяють автоматизувати майже повністю лінію виробництва. Окрема увага також надається керуванню механічними маніпуляторами.

Варто відмітити, що безпосередньо на лініях виробництва є також певний перелік стандартів, технологій та специфічні протоколи передачі даних: SCADA, PLC, DNP3, Modbus

Муніципальна інфраструктура. Розумне паркування — це яскравий приклад вбудованої розробки. Завдяки датчикам, комп’ютерному зору та функціям аналізу даних можна забезпечити багатофункціональний моніторинг руху автомобілів на парковках, а також контроль за вільними місцями для паркування.

Серед прикладів embedded-розробок у smart-паркуванні є і системи автоматичного визначення номерних знаків, і системи розпізнавання облич, а також системи звукового та світлового сигналу про зайняті та вільні місця на майданчику.

Наприклад, одним з проєктів, над якими ми працювали в компанії, є технології вбудованого міста. Для розвитку автономних автомобілів та віддаленого керування нам довелося придумати, як об’єднати різну дорожню інфраструктуру.

Для створення таких систем використовувались групи индустріальних стандартів, таких як RSU4.1, NTCIP, SAE2735, що визначають певну структуру даних та протоколи комунікації, яким повинна відповідати дорожня інфраструктура. Потім, за допомогою індустріальних маршрутизаторів, нам вдалося розробити конектори під кожен протокол (SDN, Software Defined Network), що забезпечило стабільну відправку та отримання даних.

А після отримання даних ми мусили вирішити, як їх обробляти. Зазвичай це питання вирішується додаванням ще одного рівня до архітектури, а саме EDGE intelligence. На рівні EDGE додається логіка з обробки даних, яка дозволяє реалізувати бізнесові задачі, наприклад, отримати дані з погодних радарів, налаштувати динамічні знаки та сповістити водіїв. Наприклад, у разі потреби, швидка допомога може запросити зелений сигнал світлофора на окремій смузі.

Сільське господарство. Embedded-розробки не перший рік використовуються аграріями та фермерами. Завдяки датчикам у ґрунті та обладнанню, що підключене до інтернету речей, можна вимірювати вологість ґрунту, температуру, кількість світла та інші параметри, необхідні для ефективного вирощування культур.

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

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

Як бачимо, вбудовані системи досить широко використовуються, і з цього можна окреслити ключові задачі та ролі, що «лягають на плечі» embedded-розробок.

  • Перш за все, вони допомагають уніфікувати та централізувати контроль над виробничою архітектурою, і таким чином дозволяють вчасно реагувати на зміни будь-яких критичних показників, таких як температура, тиск, вологість тощо.
  • Крім того, можуть використовуватися для діагностичного та профілактичного обслуговування, що знижує витрати на технічне обслуговування.
  • Автоматизація та оптимізація виробництва також можуть бути досягнуті за допомогою вбудованих систем, оскільки вони чудово справляються з контролем енергетичних та виробничих ресурсів.
  • Вбудовані системи незамінні у небезпечному виробництві, оскільки можуть працювати в неприйнятних для людини умовах. Високі температури, тиск або відсутність повітря є також однією із задач, що вирішуються задопомогою вбудованих систем.

Одна з відомих плат R-Car Starter Kit, на якій була встановлена апаратна віртуалізація XEN, завдяки якій було встановлено на одну плату 3 операційні системи: Linux, Android and FreeRTOS

Централізований збір даних, дистанційне керування та інші переваги

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

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

Тож далі розглянемо декілька ключових переваг embedded-систем, які допоможуть зрозуміти, чому саме ці технології можуть бути корисними для вашого бізнесу.

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

Крім того, така можливість дозволяє відстежувати бажані показники в режимі реального часу та отримувати повідомлення про будь-які відхилення або проблеми, а значить — вчасно реагувати та уникати можливих проблем.

Не варто забувати й про здатність до інтеграції в будь-які архітектурні рішення: вбудовані системи можуть бути, власне, вбудовані в пристрої, обладнання або мережі, що робить їх невіддільною частиною складних систем. Здатність до інтеграції є особливо корисною у виробничому середовищі, де їх використання особливо впливає на автоматизацію та оптимізацію виробництва.

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

Embedded-технології досить адаптивні у питанні вартості обслуговування. Вона може варіюватись, оскільки залежить від багатьох факторів: складність системи, її надійність та рівень інтеграції з іншими компонентами, доступність запасних частин впливають на ціну. А також від того, наскільки ефективно проєктувалися самі embedded-системи.

На фото система розумного міста, яку ми зінтегрували та розмістилі на одній поверхні. Автомобілі спілкуються по стандарту SAE2735 та їх рух відтворюється на мапі

Гнучкість та легка конфігурація embedded-систем дозволяють перелаштовуватись та розширятись разом з бізнесом, змінюватись відповідно до потреб компанії або клієнтів. Вони можуть бути налаштовані на конкретні потреби та вимоги, а також легко модифікуються у разі появи нових вимог до їх функціональності.

Застосування embedded-технологій може забезпечити ефективніше використання ресурсів, зниження вартості обслуговування, збільшення продуктивності та поліпшення якості продукції. Таким чином, embedded-технології є важливим інструментом для будь-якого бізнесу, який бажає залишатись конкурентоспроможним та ефективним.

Постійний розвиток технологій та поширення IoT буде й надалі створювати нові можливості для застосування embedded-систем. А які застосування embedded-технологій ви знаєте або використовуєте у своєму житті? Як вони покращили якість вашого життя або роботу вашого бізнесу?

👍ПодобаєтьсяСподобалось14
До обраногоВ обраному9
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Стоит развивать новые технологии. Вот и я развиваю новую технологию www.youtube.com/...​/UCmYLzFS7e1K9rl50IBIaTkQ
Очень рекомендую. Поучаствуйте.

Віка, гарна оглядова стаття.
Поправ будь ласка «Openvrt» -> «OpenWrt»

якщо пішла така п«янка, то

Деяки розробники досі надають перевагу VIM

Де яки?

Embedded-розробки

Розробка вбудованих систем, не треба плодити слова сумулякри.
Якщо про мова про виробництво, то це про АСУ ТП.
FPGA — це більше «electrical engineering» а не ембедед-розробки. Якщо про них мова, то чому не згадано CPLD?

специфічні протоколи передачі даних: SCADA, PLC,

це не протоколи передачі.

Стаття, скоріше за все, не проходила редагування

Розробка вбудованих систем, не треба плодити слова сумулякри.
Якщо про мова про виробництво, то це про АСУ ТП.
FPGA — це більше «electrical engineering» а не ембедед-розробки. Якщо про них мова, то чому не згадано CPLD?

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

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

Тому впроваджувати може щось і треба, але умовного джаваскріптера найняти можно за тиждень, ембедщіка, радіоінженера — місяці, ще і робоче місце не 3 коп як макбук коштує, комлект приладів щоб спроектувати та розробляти прилади де є сігнали до 10ГГц вже тягне 40-60к долларів, тому тема буде нішова ще довго.

> хтось взагалі вважає, що запакувавши лінукс на арм на окремой платі це вже топ ембеддед проджект

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

але вже зараз існує проблема хайрінгу інженерів яки розуміють аналогові схеми, радіо, не кажу вже про оптоелектронику.

У вебі відбулась еволюція від веб-мастерів, які тягнуть на собі все від адміністрування заліза в колокейшні до наповнення сайту, до чітко розділених frontend, backend, devops, DBA,...
Чому ж з ембеддедом повинні бути фулл-стеки? І яке відношення, наприклад, має розробка антен чи thermal analysis плати до написання коду?

З сучасними cad це може робити одна людина теж, особливо на референс дізайнах. В ідеале це дві людини, які знають про області один одного але хтось більш програміст, а хтось конструктор, але це не відміняє очикування від того, що кандидат на вакансію «Розробник вбудованих систем» сможе накидати просту схемку на ОП чи мосфеті, чи розказати що таке vswr.

кандидат на вакансію «Розробник вбудованих систем» сможе накидати просту схемку на ОП чи мосфеті

А потім ця простенька схемка через незкомпенсованість частотної характеристики ОП, незадовільні точністні характеристики або шуми запортить всю обробку сигналу з датчика, мосфет почне грітись і генерувати у радіодіапазоні, або ще якась магія станеться.
Тим більше КСХ, знання що це таке можливо врятує життя, лагодячи в окопі перебиту антену до радіостанції, але у хоч трошки мирних умовах з місць де це падає на програмістів потрібно тікати, не озираючись, сигнали на платі повинні просто працювати, максимум, конструктор повинен надати чіткі інструкції, яку термінацію сконфігурувати на пінах.

Ви перегинаєте у інший бік. Достатньо подивитись на спільноту ардуїнщикив, щоб побачити, що буває, коли умовні фронт-ендери починають лабати bare-metal embed.

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

Все, що ви тут закидаєте, у тій чи іншій мірі стосується кожного [потенційного] працівника. Але, думаю, не треба пояснювати різницю між «інкубаторським» джуном та «диким» сеньйором. Перший може й знає тонкощі сучасного воркфлоу, але в принципі не здатний створити продукт. Другий в одне рило може створити продукт, але його треба навчити воркфлоу. Що простіше на вашу думку?

А для чого повинно бути складно, якщо цього і так у достатку у реальному світі?

А так, продукт створити мало, його ще потрібно продати, і навіть у часи міфічних геніїв у гаражах, чомусь Хьюлетт не сам продавав свій спаяний генератор, а разом з Пакардом, Возняк — з Джобсом, Аллен — з Гейтсом, Пейдж — з Бріном, є помітне розділення праці між створенням продукту, і його маркетингом, у широкому сенсі.

У наш же час, об’єктивно дуже мало продуктів, які можна технічно осилити одному, а те що можна осилити — зуміти виготовляти конкурентоздатно і рентабельно. І навіть коли задача супер-нагальна, наприклад, заживити ноутбук під час обстрів електростанцій взимку, навіть маючи знання силової електроніки і широкий асортимент деталей під рукою, є здоровий глузд, що потрібно за еквівалент кількох днів робочого часу купити ДБЖ тут і зараз, а не велосипедити ШІМ на мікроконтролері чи TL494, мотати трансформатори і травити плати хлорним залізом, час простою по робочому проекті і репутаційні ризики дорожчі.

Так про продаж ніхто і не говорив. Ми тут про інжиніринг, начебто, розмовляємо.

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

Так, зараз потреби ринку такі, що складно одинаку створити комерційно успішний продукт. Бо той має бути масовим, дешевим, функціональним, зручним, та красивим зовні.

Але є й інша сторона. Один фірмовий ДБЖ тримає акумулятори в такому режимі, що вони висихають за два роки із ймовірністю 100%. Інший дає сигнал про розряд так пізно, що сучасний комп’ютер із десятками гігабайтів ОЗП просто не встигає увійти у гібернацію. У третьому зекономили на БЖ і він зовнішню батарею заряджає струмом в 1/500 від її ємності. І таке, нажаль, усюди. Навіть за великі гроші.

P.S. І да, пет-проджекти теж ніхно не відміняв. Людина може вигадувати з нуля десятибаксовий девайс просто для задоволення і розширення навичок.

Ринок завжди правий, просто поки самому не спробувати зробити краще, це часто не виглядає очевидно.

Якраз у випадку з ДБЖ, я пробував зробити на іоністорах саморобний, щоб можна було вбудувати в корпус домашнього NAS на одноплатнику, щоб тримав дві хвилини саму плату і 4 HDD, щоб не було зношуваних елементів і лишнього перетворення в 230: imgur.com/a/c2YkocL

ШІМ-контролерів, які штатно можуть працювати стабілізаторами струму від нульової напруги на виході для заряду іоністорів ще треба пошукати, а знайшовши — доставити в Україну, іоністори у наших посередників виявились браковані і довелось проводити вхідний контроль кожного, віра у довготермінову надійність цієї штуки виявилась підпорченою, підключати цей UPS, дебажити всі режими роботи і писати самописний аналог apcupsd виявилось складніше, ніж очікувалось. Заради спортивного інтересу я дотерпів до моменту, коли цей саморобний NAS став десятикратно дорожче за купити на olx HP Microserver gen8 + APC back-UPS CS 500, але фінальним цвяхом стало те, що за час розробки цього пет-проекту змінились потреби, додалась віртуалізація, яка дуже складно робиться на одноплатнику на arm і яка кратно вилізла за можливості саморобного UPS дотягнути до виключення. У той же час, навіть самий дешевий UPS з олксу має кратний запас і по часу резервування, і по потужності, і при необхідності, купується за кілька днів де завгодно.
Висновок зроблено — міняти по регламенту сушені за 2-3 роки акумулятори дешевше, універсальніше і надійніше. Донедавна була порожня ніша ДБЖ для роутерів та інших малопотужних споживачів, але APC і на цей випадок випустили недавно рішення, у форм-факторі мережевого адаптера з вбудованою li-ion батареєю.

Тут ви самі винні. Ви ж не будете створювати прилад, що жере навіть 10mA від CR2032. Тоді чому почали розробку силового ДБЖ із «звичайним» іоністором? Якщо хотілось нелімітованого життєвого циклу, то один нормальний LiFePO4-cell із якісним контролером переживе усі ваші девайси, й, можливо, вас самого. При цьому його ємність буде у 20 разів вищою при тих самих габаритах, і його без гемору можна інтегрувати із існуючою елементною базою.

APC і на цей випадок випустили недавно рішення, у форм-факторі мережевого адаптера з вбудованою li-ion батареєю

Яка напруга? Який роз’єм? Як повідомляє під’єднаний пристрій про перехід на батареї? Про скорий розряд? Змінну напругу вміє видавати для ADSL-модемів?

Так питання ж у оптимізації, здавалось би, для чого робити запас, якщо акумулятор все одно зношується, при цьому у порівнянні зі свинцем, має більшу пожежну небезпеку?
Як виявилось, економічно вигідніше мати кратний запас старого свинцю, так само думають і дата-центри по всьому світі.

Яка напруга?

12В

Який роз’єм?

5.5×2.5

Як повідомляє під’єднаний пристрій про перехід на батареї?

Ніяк, у роутерів немає зазвичай стандартного протоколу для таких задач. Як і необхідності у плавному вимкненні.

Змінну напругу вміє видавати для ADSL-модемів?

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

Так питання ж у оптимізації

Саме так. Іноді фабричні девайси настільки неоптимальні (з точки зору конкретного кейсу), що можна і подимити каніфоль’ю у своє задоволення. Це ж відноситься і до тих ДБЖ, що сушать акумулятори.

Як виявилось, економічно вигідніше мати кратний запас старого свинцю, так само думають і дата-центри по всьому світі.

Я теж більше люблю свинець, але так щоб майже буквально «запаяти елемент на плату», він не підходить.

більшу пожежну небезпеку

LiFePO4 горять дуже погано. На відміну від кубу заряджених іоністорів, доречі.

12В; 5.5×2.5

Ви ж зрозуміли, до чого ці мої питання, чи не так?

Ніяк, у роутерів немає зазвичай стандартного протоколу для таких задач.

У роутерів — немає, у NAS — є. В ж свій девайс не для роутера паяли, і вам такий адаптер із вбудованим ДБЖ вочевидь теж не підійде.

Іноді фабричні девайси настільки неоптимальні (з точки зору конкретного кейсу)

У перерахунку на ціну робочого часу, це ніколи не вигідно, і має сенс виключно як хоббі.

На відміну від кубу заряджених іоністорів, доречі.

І що ж у ньому буде горіти, якщо теплоємність плюс-мінус одинакова, але запас енергії на два порядки нижчий? Навіть при КЗ, саморозігрів не буде більше 5-10 градусів.

Ви ж зрозуміли, до чого ці мої питання, чи не так?

Ні. Коментар був саме про роутери.
А NAS — це в будь-якому разі підключена дротами і не любляча механічні рухи коробка, на 4+ диска ще й об’ємна і шумна, і економія на розмірі ДБЖ і оптимізації з відмовою від проміжного перетворення у 230 насправді не мають сенсу.

я вкладав у сенс розуміти виключно розуміння процессів, того що відбувається за ніжкою GPIO, або за sma-конектором, але може і закон Ома вже не питати на співбеседі ? дайте пораду

Саме так, спитати процес коміту своїх правок в дев-вітку і дії при мерж-конфлікті і провести частину співбесіди англійською усно важливіше. Бо писати і документувати код і спілкуватись з FAE від вендора мікроконтролера/SoC по реально складним, незадокументованим граничним випадкам роботи периферії — це основна робота, а напаювати світлодіоди або щось гірше на GPIO потрібно ну може кілька разів на проект, і перед написанням коду залізо вже повинно бути відтестоване хардварщиками.

тому і важко після галєр людей повертати до нормального тімворка, коли прилад розробляється у колективі, і конструктори та програмисти розуміють сфери один одного

З галер враження зеркальне — не всі розуміють, що «прилади» типу смартфонів, автомобілів чи літаків робляться внеском тисяч людей у тісному, але чітко поділеному по сферах відповідальності контакті, і складність навіть третьорядних компонентів типу USB-otg така, що цим займаються сотні людей, частина з яких поняття не має про закон ома, а інша займається дугогасінням роз’ємів і перехідними процесами при комутації високострумових режимів USB PD, і у код може навіть не заглядати.

Ага, саме тому ми маємо антенагейти, вибухові телефони, та автомобілі із самонаведенням на найближчу вантажівку.

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

ну попрацювавши колись у великої продуктової конторі яка ще жорсткі диски виробляє, бачив приклади як команди будують продукти from scratch, і так, там можуть бути тисячи розробників на 4 офіса по світу, але їх взаїмодія між рівнями є постійною, сінк-колли, спек-колли, технолоджи дрілли, прототипи-демо сумісні hard+soft+mechanical. і навіть pm in firmware знає закон Ома, читає схему, тощо.

перед написанням коду залізо вже повинно бути відтестоване хардварщиками

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

Це реалії «важкого» ембеддеду. Ніхто не дебажить GMII, PCI-E або дисплейний LVDS світлодіодами з резисторами і не тицяє логічними аналізаторами, бо це фізично неможливо без відповідних активних щупів і здатної записувати вміст ліній на таких швидкостях, і, як правило, відповідні функції чітко прив’язані до відповідних пінах.
Помигати світлодіодом на GPIO зі справжнього інтеловського сучасного процесора теж можна, там вони теж є, але це не його справа таким займатись.

Шини немає потреби дебажити з тих часів, коли вони із програмного смикання GPIO-бітів остаточно переїхали на кремній. Там достатньо уважно читати даташит (і про еррати не забувати).

Я ж кажу про «бізнес-логіку» девайсу, тобто саме про те, за що платить замовник, бо розвести шини згідно із референсами навіть мавпа зможе.

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

Я ж кажу про «бізнес-логіку» девайсу, тобто саме про те, за що платить замовник,

Між бізнес-логікою і шинами лежить ще товстий шар. Розподіл пам’яті між ядрами, роутинг переривань від периферії до ядер, написання відповідних драйверів, щоб наприклад, прийняте відео з камери оброблялось відповідним сопроцесором, а потім заводилось у основну ОС через стандартний, абстрагований від заліза механізм, всілякі фічі, типу Intel IME, наприклад у автомобілях буває, що поруч з основною ОС у фоні біжить резервна, яка перехоплює на себе керування ключовою периферією і спрощено виводить критичну інформацію на дисплей у випадку крашу основної ОС.
Врешті-решт, початковий старт ноутбука/сервера, UEFI, узгодження якогось 10 GbE з роботою решти ОС — це принципово такий же ембеддед.
І подібних задач, які теж складні, теж у режимі обмежених (хоч і на кілька порядків більших) ресурсів, але при цьому вже не оперують окремими фізичними пінами, є теж чимало. Просто поріг входження у них вище, практичної застосовності у побуті менше, і ці позиції не на виду.

Розподіл пам’яті між ядрами, роутинг переривань від периферії до ядер, написання відповідних драйверів, щоб наприклад, прийняте відео з камери оброблялось відповідним сопроцесором, а потім заводилось у основну ОС через стандартний, абстрагований від заліза механізм, всілякі фічі, типу Intel IME, наприклад у автомобілях буває, що поруч з основною ОС у фоні біжить резервна, яка перехоплює на себе керування ключовою периферією і спрощено виводить критичну інформацію на дисплей у випадку крашу основної ОС

Все що ви описали — це не конкретний девайс, а велика мережа із десятків девайсів.

Реальний розробник у конкретному проекті буде мати справу із однією лише камерою, чи дзеркалом заднього виду. І там не буде IME, UEFI, 10 GbE і навіть мінімальної ОС. Буде лише декілька десятків кілобайт пам’яті, CAN, PWM для трьох крокових двигунів, декілька бінарних виходів для нагрівачів.

У тому-то і суть, що буде — фреймбуфери з камери вимірюються одиницями-десятками мегабайт, фічі типу відзеркалення зображення, конвертації YUV-RGB або поправок на передачу кольору конкретною матрицею виконуються апаратними блоками, складнішими за просте DMA, які по суті є окремими сопроцесорами зі своєю фірмвар’ю, і число таких блоків іде на десятки, сотні.

І це дуже прикро, що все це сприймається як якась магія білих людей, і Ъ-ембеддед не уявляється за межами дригати GPIO на швидкість і ворочати фазою ШИМів з паяльником у руці.

Я писав про дзеркало заднього виду із централізованим регулюванням та підігрівом.

Якщо ж мова про камеру, то дуже може виявитись, що нутрощі на кшталт фреймбуфера, енкодера, та ефектів, знаходяться у DSP/ASIC на одному кристалі із сенсором і все, що з ними можна робити із свого коду, — це вмикати чи вимикати. Принаймні USB-камери зазвичай саме такі. І ось вже ніякої магії нема, DMA нема, YUV нема, є лише MJPEG-потік у шину і один регістр із одним задокументованим бітом, що вмикає чи вимикає його.

Це як з ардуїно, так, для багатьох задач достатньо стокової камери на USB зі стоковим же UVC в ОС, лишається тільки написати аппку в самій ОС.
Але як тільки камер з’являється багато, з’являються вимоги до латентності передачі картинки і обробка у реальному часі, хоча б банально відмальовувати гайдлайни поверх зображення камери заднього виду, не кажучи вже про нейронні мережі, то доводиться втручатись у весь стек, починаючи з конфігурації сенсора у самій камері.
Але знову ж таки, камера висить зазвичай на одному коаксіальному кабелі, по якому передається і живлення, і відеопотік, і I2C або ще щось низькошвидкісне для конфігурації сенсора, і ніхто з осциллографом і законами Ома роботу serdes-ів вже не контролює, перед якою-небудь роботою з власне камерами все це вже повинно бути відтестовано і просто працювати.

або 50+ розробники або пустота на ринку. розробляти повний цикл важко

нагадало розмову із топами Серва, якщо коротка: «ембедед це складно»,

існує проблема хайрінгу інженерів

існує проблема жлобства плати за спеціаліста

існує проблема жлобства плати за спеціаліста

нема кому платити, я як кажуть ended up та почав найнимати з Пакістану, бо з місцевими: 1) англійської не знає принципово — мова супротивника(!) 2) піздюнькає у резюме 3) ліпить у тестове завдання КТ946 4) не вміє нічого окрім Eagle 2006 року 5) гіти та джири ваши нафіг, ми хочемо ексельку на шаред діску в офісі 6) ардуїнщік або рпішник 7) радянський радіоаматор який все хоче звести до хоббійного рівня 8) галєрний, який хоче займатися тікі вузьким напрямком і не знати проект взагалі

це збірний образ, але це результат співбесід травень-червень 17 кандидатів на вакансію інженер-конструктор РЕО з виделкой 4-7к та бронюванням від мобі, тре було підняти до 10к і відразу хтось знайдеться ?

ну я міг би, але не на 4К-7К, іти в офіс, коли є віддалена робота, данунах
якщо переманюєте спеців, то одне,
якщо перебираєте безробітних, це інше

і я РСАД останій раз заглядав у 2008, і що? може погано, хз? для розводки і малювання плат є дєвочкі, які даєш ЦУ вони правлять

за розробку софта останні 30 років башляли в рази більше, чим на аутсорсі за дьоргання мишкою

прийшла розплата, не треба скіглити

з.і.
якщо реально треба, то знайдете і 15куе в місяць оформляти по КЗпП із бронью і нормованим робочим днем та оплачуваною відпусткою

та почав найнимати з Пакістану

Пакистан врятує отца дємократії

тільки до чого скіглення, ринок глобальний

круто коли є власна лаба дома, може вам треба і більше платити тоді. який у вас спектроаналізатор домашній ?

англійської не знає принципово — мова супротивника

Якщо все виробництво електроніки роками було за 200 баксів аспірантської стипендії, і/або для принципово неринкових умов, типу воєнної техніки або контрольно-касових машин, всіляких напарених державі лічильників і подібного, якщо у колективах переважно зроблені у СРСР кадри з російською рідною, то де ж цій англійській узятись?

ліпить у тестове завдання КТ946

Може програміст ще й повинен знати ціни на елементу базу, сам займатись комплектацією і постійно фіксати BOM через недоступність деталей у місцевих бариг? Може ще й сам розмитнювати їздити буде?
Я трохи стикався з цим imgur.com/a/FNP24DC , одного цього пункту достатньо, щоб навіть маючи відповідні знання, принципово відмовлятись зв’язуватись з чимось, де фігурує виробницства або власне виготовлення прототипів, це завжди купа непрофільної роботи і постійні звинування за просрочені дедлайни не по своїй вині. Тільки як хобі для себе.

не вміє нічого окрім Eagle 2006 року

Аналогічно першому пункту, у нас багато місць, які випускають рентабельну продукцію, щоб могти собі дозволити Cadence/Xpedition/Altium? Якщо значна частина розробки робиться у старезних піратських пакетах (і, насправді, рідко потребує чогось кращого, в України межа можливого власного виробницства — 6 шарів з наскрізними віасами і HASL, з цим чогось серйозного не зробиш), якщо чесним студентам максимум доступного по грошам і можливості прощупати повний цикл проектування і замовного виробництва — це EasyEDA, і якщо вміння обирати доступні інструменти і користуватись елементарними формами аутсорсу роботи з порогу гнобити як «ардуїнщиків», сильно вони захочуть іти в «ембеддед» до таких токсиків, замість якогось веб-бекенду?

інженер-конструктор РЕО

Так, ембеддер, чи інженер-конструктор? Чому ці дві, досить різні професії об’єднуються у одну? Розробнику, наприклад, зварювального апарату, або фазованої антенної гратки може не знадобитись писати жодного рядка коду на жодному контролері, у нього по вуха своїх проблем і десятки років набуття своєї експертизи.

або для принципово неринкових умов, типу воєнної техніки або контрольно-касових машин, всіляких напарених державі лічильників і подібного, якщо у колективах переважно зроблені у СРСР кадри з російською рідною,

мені якщо чесно все одно, я сам народився у 70-ті і нічого мені не заважало вивчити англійську

Може програміст ще й повинен знати ціни на елементу базу, сам займатись комплектацією і постійно фіксати BOM через недоступність деталей у місцевих бариг?

тестове завдання це просто накидати просту схемку к контроллеру, але знаходити принципово руснявий компонент це шлях до відмови у наймі, думаю там не було вашего бажання ворк-лайф беленсу не торкатися деталей, а чисто невміння сучасної бази, купувати нічого не було потрібно )

Аналогічно першому пункту, у нас багато місць, які випускають рентабельну продукцію, щоб могти собі дозволити Cadence/Xpedition/Altium?

KiCad це вже стандарт малого на середнього бізнесу, хто не засвоїв або не хоче це робити на етапі онбордінку — не підходе. У галєрах можливо це ок, розкажить

інженер-конструктор РЕО
Так, ембеддер, чи інженер-конструктор?

Я не знаю хто такий цей «ембеддер», firmware engineer? ну ось подивиться які вимоги у світі osiengineering.com/...​erating systems expertise.

Firmware Engineers work with both hardware and software. They need proficiency in both domains, such as programming in C or C++, and they must have hardware, circuit analysis, microelectronics, computer architecture, and real-time operating systems expertise.

Моя первинна теза, що після галєр брати у продукт людей важко нікуди не поділася зі столу, на жаль.

знаходити принципово руснявий компонент

Бувають випадки, коли неруснявий просто не дістати, спробуйте замінити, наприклад, КП304 у електрометрі на щось сучасне, щоб не зіпсувало вхідний струм стабілітронами по затворі і мало окремо виведену підкладку.
Якщо схема справді потребує гігагерцового транзистора на таку потужність, асортимент зарубіжних не те, щоб common knowledge і міг взятись з голови.

У галєрах можливо це ок, розкажить

Галєри спроможні купити Altium і централізувати розробку девборд силами одного або кількох розробників, а далі займатись профільними справами.

Я не знаю хто такий цей «ембеддер», firmware engineer?

Це цілий спектр, частина якого, типу embedded linux, може заліза в очі не бачити, займаючись нутрощами гіпервізорів для доступу до заліза з гостьових ОС і подібними задачами.
Так само як і «інженер-конструктор» — Ви всерйоз вважаєте взаємозамінними, скажімо, розробника силової електроніки і розробника НВЧ-систем? Чи насправді, потрібен такий же ардуїнщик від світу електроніки, який з’єднує референсні схеми і перемальовує референсні розводки плат по інструкції, а імпульсний блок живлення від 220 візьме готовим модулем, бо розрахунок і виготовлення трансформаторів і дроселів то магія, а дебаг з паяльником без чіткого розуміння як це працює може спалити дорогу техніку і навіть себе?

зараз з «нізвидки» появився попит на розробників дронів, прям щоб (АІ, OpenCV, linux kernel, RTOS, DSP, assembler, C, C++17 і вище, англійський не нижче B2, просуний git, Yocto, FPGA Verilog/VHDL, ... і щоб паяв, складав схеми без «совіцких/руснявих» компонентів, розводив багатошарові друковані плати і т.д.) але платити як інженеру РЕО з оборонки на Лук"янівці/Большєвіку
www.youtube.com/watch?v=WrdGyNyDwBw

після галєр брати у продукт людей важко

а я о принце всьо мічтаю ©

Якщо схема справді потребує гігагерцового транзистора на таку потужність, асортимент зарубіжних не те, щоб common knowledge і міг взятись з голови.

навіть я, менеджер, можу такий швиденько на маусері знайти, від інженера якось більше очікувань, завдання у нас домашка, тиску нема

Галєри спроможні купити Altium і централізувати розробку девборд силами одного або кількох розробників, а далі займатись профільними справами.

і кандидат вам каже, що альтіум це фігня, я хочу на іглі-2006, що йому скажуть ?

Це цілий спектр, частина якого, типу embedded linux, може заліза в очі не бачити, займаючись нутрощами гіпервізорів для доступу до заліза з гостьових ОС і подібними задачами.

так де я кажу щось інше ? термінологія широка, тому краще додавати більш конкретних вимог на кожну вакансію і уникати узагальнень. але це усе інженери мають бути, типу «інженер розробник вбудованих систем (linux, arm) з базовими знаннями у sub-ghz радіо» або «інженер-конструктор силової електронікі з базовим знанням програмування контролерів Siemens», якись мають бути гейтвеї у команді.

зараз у пайплайні девайс де багато rf компонентів, але з ними треба по spi розмовляти, от щоб девборд зробити, той хто дебажить рф частину швидко накидав собі майже на ардуіні код який перемикає різні моди щоб подивитися чи нема проблем з дзвіном на платі, бо не усе можно на CAD спроектувати, а головну фірмварь ще не почали писати, так, модулі поки

навіть я, менеджер, можу такий швиденько на маусері знайти

Так на співбесіді доступ до Маузера був, чи з голови накидати схему з компонетами потрібно було?

і кандидат вам каже, що альтіум це фігня, я хочу на іглі-2006, що йому скажуть ?

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

так де я кажу щось інше ?

Вітка розпочалась якраз з цього — чомусь embedded software мало того, що не поділяють на підвиди (хоча б на процесори без MMU і з MMU), так часто ще й приплітають навики хардварної розробки, навіть не просто тестування у єдину спеціальність.
Скажу чесно, у мене просто підгорає, бо я по недосвідченості оцінював кандидатів по критеріям, близьким до Ваших. В реальності ж, навіть під дрібний мікронтролер, конфігурація унікальної периферії з сапортом від вендора чіпа і інтеграція сторонніх бібліотек зайняла незрівнянно більше часу, ніж пару раз тицьнути двоканальним осциллографом чи перепаяти кілька 0402 перемичок, але якраз вміння в англійску і гіт перевірено належним чином не було.

інженер розробник вбудованих систем (linux, arm) з базовими знаннями у sub-ghz радіо

А що спільного навіть у низькочастотного радіо з драйверами під лінукс? Самий максимум адекватних вимог — це проміжок між драйвером рівня ядра і інтерфейсом до АЦП, якщо дуже добре заплатити, може зможе програмно одночасно і драйвер рівня ядра написати, і на простенькій FPGA parallel LVDS чи що там на АЦП сконвертувати у PCI-e, якщо подолати ардуїнофобію, то може навіть вдасться зоптимізувати у одному Zynq-у.
Але щоб ця людина ще й вміла побудувати радіотракт правильно, зробити схемотехніку і розвести плату — а не злипнеться? Якщо вона все це вміє, то нащо їй решта фірми?

головну фірмварь ще не почали писати

Свого часу, коли я займався вундервафлею для науки, з високими точностями, великими швидкостями, схемотехнічним костилебудуванням через упертість старих інженерів і подібних радощів, залізо за півтора роки худо-бідно у одному екземплярі зібрати і віддебажити повузлово вдалось, а ось прошивка двох Spartan-6, драйвер під Windows 7 рівня ядра і збоку LPC1837 розтягнулась на роки, бо не тільки виробники АЦП, а і постачальники ліб можуть прибріхувати, видаючи характеристики з припискою up to і не уточнюючи про можливість їх одночасної реалізації, а за час багаторічного копирсання у системі ключовий компонент системи (вимірювач інтервалів з роздільною здатністю в 8 пс) можуть депрекейтнути, а його розробників оптом відправити на мороз.
З тих пір, я проекти естімую в першу чергу по часу на написання коду з нуля і можливості задіювання готових прикладів, а схемотехніка, хай навіть з рекордними характеристиками іде другорядно.

Неуважно прочитав про домашку, з цим згоден, що інженер дивне рішення обрав.

Моя первинна теза, що після галєр брати у продукт людей важко нікуди не поділася зі столу, на жаль

работать у вас большає чєсть

Працюю на ембедед-проекті в GL.
Плюсів і перспектив багато не бачу.
— Ембедед не такий популярний і поширений в айті як інші напрямки, і оплачується як мінімум не краще за інші домени. Той же бекенд і веб, це в рази більший ринок.
— В ембедед більше ніж в інших доменах все залежить від проекту. Твої скіли які були незамінні на одному проекті можуть виявитися повністю марними на іншому. Відповідно під кожен проект треба більше підлаштовуватися, і ти залежний від нього більше ніж в інших доменах. Може бути таке що зі свого проекту ти нічого не винесеш собі в плюс для вартості на ринку, крім глибокого знання свого проекту, які потрібні тільки на цьому проекті.

Мій проект наприклад в плані організації — жахливий. Всі процеси — в «іксельці» в кращому випадку. Замовник ніяк не може визначитися що йому потрібно і яка в нього стратегія. Комунікація ніяка. Плани постійно змінюються. Інфраструктура замовника — допотопна і незручна. Працювати з нею це біль, сльози і купа змарнованого часу. Чогось особлиовго по хард і софт скілах не наберешся.
Зарплату відмовилися піднімати вже 2 раз. При тому що роботи і завдань навпаки — збільшилося. На прооекті я виконую мало не сіньйорську роботу мануальщика, працюю з автоматизацією, навіть сам собі менеджер подекуди, але цеи все не оплачується і не враховується. Всі вважають так і має бути, і зарплата в такому випадку в тебе має бути джуна — мануала тестувальника.
Тому якось так.
Сподіваюся, дорочі читачі, у вас історія з ембедед краще склалася.

Ну профіль тестувальника стандартний: Лінукс,теорія тестування і мережі. Проектів з цим стеком досить багато. Але згодна, що домени дуже відрізняються, хтось в цьому бачить плюс. Я за 12 років попрацювала і з чіпами і з індустріальними роутерами і з вайфеєм і з медициною. І для мене це є саме перевагою, що потрібно нарощувати знання. Звичайно, є нудні проекти як і кругом. З приводу перегляду зп, то це не стосується ембеддед. Це зачіпило багато компаній також. Багато коштів було вкладено в евакуацію, старлінки, додаткове забеспечення тих, хто пішов захищати домівки. Компанія досить сильно підтримує робітників в складні часи, звичайно, в такі періоди, компенсація для існуючих спеціалістів сповільнюється.
Окрім цього, ембеддед більш захищений ніж бекенд, його важче кудись перевезти і на нього важче знайти заміну.
Тож сподіваюсь, що досвід у вас надалі буде більш цікавий.

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

Описали (за винятком процесів в іксельці та перегляду рейту) мій поточний проект (останніх півроку), але це не ГЛ

Плюсів і перспектив багато не бачу.
— Ембедед не такий популярний і поширений в айті як інші напрямки, і оплачується як мінімум не краще за інші домени. Той же бекенд і веб, це в рази більший ринок.
— В ембедед більше ніж в інших доменах все залежить від проекту. Твої скіли які були незамінні на одному проекті можуть виявитися повністю марними на іншому. Відповідно під кожен проект треба більше підлаштовуватися, і ти залежний від нього більше ніж в інших доменах. Може бути таке що зі свого проекту ти нічого не винесеш собі в плюс для вартості на ринку, крім глибокого знання свого проекту, які потрібні тільки на цьому проекті.

А хтось навпаки скаже, що відчуває цінність в Embedded розробці і має хороші можливості для саморозвитку, і не цікавить світч в інший домен в погоні за вищим доходом, також є багато Embedded-розробників, для яких мейнстрімні напрямки розробки — це якісь «свистілки» для вебу, крипто-сками і бюрократія в ентерпрайзі. Тут кожному своє, як кажуть => «Риба шукає де глибше, а людина — де краще»

Мій проект наприклад в плані організації — жахливий. Всі процеси — в «іксельці» в кращому випадку. Замовник ніяк не може визначитися що йому потрібно і яка в нього стратегія. Комунікація ніяка. Плани постійно змінюються. Інфраструктура замовника — допотопна і незручна. Працювати з нею це біль, сльози і купа змарнованого часу. Чогось особлиовго по хард і софт скілах не наберешся.
Зарплату відмовилися піднімати вже 2 раз. При тому що роботи і завдань навпаки — збільшилося. На прооекті я виконую мало не сіньйорську роботу мануальщика, працюю з автоматизацією, навіть сам собі менеджер подекуди, але цеи все не оплачується і не враховується. Всі вважають так і має бути, і зарплата в такому випадку в тебе має бути джуна — мануала тестувальника.

Співчуваю вам, але, напевно, з таким ставленням Agile-методологія розробки вам не підходить, бо якщо вас продають як кросс-функціональну команду, то процеси, якщо не встановлює клієнт, тоді вони від вас залежать. І можетете скаржитися на менеджмент, але такі реалії, що до кваліфікації менеджерів в GL загалом низькі вимоги, у випадку вашого проекту PM скоріше-всього — це не billable позиція, його/її тільки турбує операційнийний та аккаунт менеджмент, тобто головне => щоб клієнт був задоволений перформансом, щоб не було конфліктів і мінімум attrition rate, а також хороший показник прибутковості для GL, ... і та ж «ікселька» потрібна фактично тільки для PM-ма, як зручний облік виконавців, версій та статусів (фактично ваше звітування GL, а не клієнту), а як ви заморочуєтеся з трекінгом та документацією в Jira і Confluence — це вже ваше і клієнта діло.

Ембед просто не для всіх підходить. Ембед — це не про «стильно-модно-молодіжно», не про новий фреймворк кожний рік, не про нову мову програмування кожні п’ять-десять років. До того ж для ембеду треба розуміти не тільки те, що знаходится у пам’яті комп’ютера: мережеві протоколи низького/фізичного рівня, електроніку із схемотехнікою, зв’язок, та таке інше.

Хтось тут питав: «де зараз працюють 50-річні програмісти?». Так от багато хто сидить на довгограючих ембед-проджектах у Глобалах, Епамах та інших Циклумах, де має свої $4k+ за спокійну роботу без авралів та менеджерських експериментів із черговою «срібляною кулею».

Ембед — це не про «стильно-модно-молодіжно», не про новий фреймворк кожний рік

На жаль, на багатьох проектах це саме воно і є, привіт STM і NXP з нескінченними змінами систем настройки периферії мишкою в IDE.
Тільки на відміну від вебу, вся ця срань релізиться вендорами в zip-архівах і хронічно не вміє в VCS-friendly конфіги, роз’їдаючи нормальні практики командної розробки і, після рівня компенсацій, це найбільша біль від ембеддеду взагалі.
Але на щастя, є embedded linux, який з одного боку, теж embedded, з іншого, просто небо і земля в плані тулінгу.

Зміни тулкітів від вендорів зазвичай відчутні лише на старті нових проектів. Після отримання кінцевої «болванки» вся ця братія надовго ховається у шухлядку.

А embedded linux підходить далеко не всім девайсам, ви ж самі розумієте. Багато де навіть RTOS не можна собі дозволити, не те що linux.

Проекти на дрібних (без MMU) контролерах невеликі, активна фаза на аутсорсі триває недовго, менеджмент зазвичай хоче саме нове і розрекламоване, тому тулінг доводиться змінювати часто. Верхній коментатор у гілці має рацію, знання цих тулзовин і периферій конкретних сімейств не дуже переноситься між проектами.

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

, де має свої $4k+

слоупоки і терпіли

лол, у людини є реальні поради як бути фінансово незалежним, кидайте той ембеддед взагалі fi202x.blogspot.com/2023/05/20.html

дійсно, навіщо нюхати випари свинцю ... нехай пакистанці

це точно, фінансові гуру будуть нюхати бебру та жити на $117, але працювати так і не підуть

Вікторія, дякую за чудову статтю!
Хочу поцікавитися, чому з мов не згадані Go & Rust?

На них невеликий зараз попит. Було багато навколо них розмов, але місць для роботи мало. Вакансій з Rust не бачила поки. Я не люблю обговорювати технології на які низький попит

Дуже дякую за статтю. Було цікаво прочитати )

Намагаюсь зрозуміти чому всі юзть STM

Роздача халявних девборд на конференціях десяток років тому і повний Аліекспрес клонів stm32f1 і програматорів зробили свою справу, після Ардуїно сама доступна платформа для освоєння. Наявність девелоперів з досвідом впливає і на вибір платформи, особливо для малотиражних виробів.

Поки Microchip жався на дев борди, STM32 видала жменю кожному, і такі ж жмені для колег та друзів

Ціна грає роль або для студентів, яким на стипендію хочеться щось потримати в руках, або при крупносерійному виробництві.
Для більшості ж пет-проектів або дрібних серій не принципово, 2 бакси коштує контролер, чи 20 — час девелопера на перенавчання може виявитись дорожчим, естімейти менш надійними, більші ризики якихось несподіваних проблем, та і до ціни ще додається ціна плат, корпусу, інших деталей.
Наприклад, нижче показував термостат, при ціні прецизійного термодатчика в 20 баксів, еталонного 0.01%-го резистора ще в 20 баксів, АЦП в 10 баксів, ще сотні баксів на власне термостат, і разовості задачі, туди хоч атмегу став, хоч STM32H7 — економіка мало зміниться.

Мінуси:
1. Робота в офісі.
2. Менше платять в порівнянні із тим же бекендом.
3. В аграрній супер державі безперспективно

А які застосування embedded-технологій ви знаєте або використовуєте у своєму житті? Як вони покращили якість вашого життя або роботу вашого бізнесу?

Embedded-технології весь час оточують сучасну людину, наприклад, в багатоквартирних будинках побудованих в 00-х роках окремі мікроконтролери відповідають за управління гарячим та холодним водопостачанням, опаленням, системами вентиляції, протипожежними системами, дистанційний збір показників лічильників та ін.; а в ТРЦ, паркінгах, промислових, офісних та адмін. будівлях та ін. застосвуються ще складніші embedded-технології.
Є великі резервіви для економії ресурсів та можливості покращення якості надання послуг — це, наприклад, типові житлові будинки побудовані при СРСР, там великий простір для модернізації із заміною автоматики з релейною логікою на мікроконтролери, а також приведення до сучасних норм та стандартів.

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

Така мета статті і подальші приклади схожі на якийсь маркетинг стосовно того, що й так дуже давно застосовується, сучасний об’єкт автоматизації — це не про те чи варто задуматися інтегрувати embedded-технології, а давня конкурентна боротьба між => 1) мікроконтролери та обладнання якого виробника будуть застосовані; 2) який підрядник запропонує проектне рішення із конкурентнішим балансом функціоналу та ціни, ... або, наприклад, компанії Intel вигідна і потрібна співпраця із GlobalLogic, тому українським розробникам випадає можливість працювати на проектах американської компанії через outstaffing чи outsourcing моделі, але у випадку компанії Nvidia — це свій офіс в Україні і співраця з українськими розробниками напряму.

Периферійні інтерфейси: опанування основ роботи з такими широковживаними інтерфейсами, як SPI, I2C, CAN, UART тощо, необхідне для взаємодії з іншими компонентами.
Протоколи: Для багатьох проектів необхідно розуміння базового стеку мережевих протоколів TCP/IP. Для бездротової комунікації можуть також знадобитись протоколи більш низького рівня такі як Bluetooth, ZigBee, Wi-Fi та інших протоколів бездротового зв’язку для підключених пристроїв (IoT).

В промисловій автоматизацїі найпоширеніший тип інтерфейсу для цифрового зв’язку — це RS-485, а стосовно протоколів, то коли йде річ про системну інтеграцію, якщо певні системи застосовують власний чи закритий протокол, то для міжсистемної взаїмодії найчастіше обирається стандартизовний і відкритий протокол Modbus. Також, якщо говорити про взаємодію нижнього та верхнього рівня програмного забезпечення, то не обов’язково необхідним є TCP/IP, бо в багатьох випадках між мікроконтролером з ПЗ нижнього рівня та ПК із ПЗ верхнього рівня (наприклад SCADA-система) є просто перетворювач інтерфейсів RS-485/USB.

Так Віталій, стаття оглядова, бо тема складна. Дуже приємно читати влучні коментарі, що розкривають тему глибше

Що Вікторія скаже про Rust в embedded, Глобал ще немає експертизи такої)?

Вендори не особливо поспішають HAL на Rust робити. А без цього трохи проблемно оцінити переваги. Мав досвід писання байндінгів щоб юзати С бібліотеки в Rust, це ще та розвага. А ще є багато спеціалізованих бібліотек, RTOS на С чи С++. Дуже сумніваюся, що ближчим часом для ембеддед це буде актуально.

простий контролер, що здатний здійснювати базові обчислення та функціонувати цілий рік на одній батарейці

— ошибаетесь, ничего простого там в помине нет — это высший пилотаж в эмбед — поинтересуйтесь каким трудом дается этот год на одной батарейке — борьба за каждый мкА, оптимизация кода и перефирии. Почему все кто знает С думают, что могут программировать embedded системы?
Embedded — это не граница между железом и софтом, это граница между физическим миром (с его реалиями с температурой в отсчетах АЦП из мкВ которые дает термопара, временем в тиках системного кварца, ошибках связи, проблемном питании, помехами, фильтрацией, сдвигом фаз, перерегулированием, самовозбуждением и пр. «радостями») и виртуальным миром Linux/Windows IoT в котором программист порой даже время отклика на прерывание или частоту опроса датчиков не знает, как и то откуда беруться данные и как, как и то что каждые 4мсек не проц, ни DMA, никто другой не имеет доступа к SDRAM — потому что регенерацию надо делать, а на экране логического анализатора ты видишь «непонятные» разрывы в передаче по SPI при помощи DMA и с сожалением вспоминаешь микроконтроллеры с встроенным в DMA буфером :) А после выхода из спячки нужно ждать — долгие миллисекунды пока раздуплится акселерометр...
Это и есть embedded. И правильно выбрать уровни приоритетов каналов DMA, приоритетов прерываний и скорректировать задачу hardware — это то же обязанность embedded программиста. Embedded — это боль и заниматься этим нужно только если тебя от этого «прет»! :))) Если нет — джава, пайтон, флаттер ... — мир программирования велик!
Хорошая статья — нужная, но тема embedded не раскрыта ;)

Границя з фізичним світом — це не ембеддед, і тут на жаль навіть «низкорівневі» ембедери люто косячать.
Наприклад, коли намагаються хаками типу dithering-у або рандомно взятими операційними підсилювачами «ловити мікровольти з термопари», не розуміючи як формується точність вимірювань, і чому це не інтегровано відразу у микроконтролері. Або, городити ШІМ-ом і алгоритмами DSP контролери силових блоків живлення/інверторів/зварювальних апаратів, не розуміючи фізики процесів у силовій електроніці і номенклатури існуючих аналогових контролерів, які часто вирішують задачу дешевше, швидше, або можуть взяти на себе швидкі захисні функції, лишивши софту більш інтелектуальне керування.
Тим більше не їх задачею мають бути проблеми з живленням, наприклад — power integrity для чогось типу мобільного телефону або материнської плати комп’ютера це ціла професія, і після роботи відповідного спеціаліста залізо повинно бути абсолютно стабільним і відтестованим ще до того, як на платформі почали підіймати софт.

Очнитесь! Как раз embedded чисто граница физики — остальное уже боле-менее десктоп, и «люто косячат» бывает у всех и именно потому что большинство embedded проектов — это RnD и свойства среды могут выйти из границ, которые установили на этапе исследований.
В контроллеры давно уже интегрировано много всего и частотные преобразователи уже то же очень давно используют микроконтроллеры для управления 3-х фазными мостами IGBT, защитами и всем силовым хозяйством. Смотрите доки по зарядным микросхемам для Li аккумов — там внутри то же микроконтроллер и соотв. есть embedded программеры, которые написали для него прошивку :) Разберите блок управления гидроусилителем руля — внутри то же микроконтроллер! Автоматические коробки передач — микроконтроллер! Блок управления подушками безопасности — микроконтроллер! Все надежно и работает годами, если программист понимает, что делает — в противном случае самолеты падают, чеки посреди перекрестка и прочее.
И с чего это «проблемы с питанием» не дело embedded? А переключение на резерв, а анализ запаса аккумов — Вам же нравиться когда в правом углу Вашего смартфона гордо горит 100%? ;)
Embedded всегда требует понимания физических/химических/технологических моментов от программиста — это сложно!
Сейчас задачи в embedded усложнились и это вызвало рост мощности микроконтроллеров, появление многопроцессорных микроконтроллеров. Часто проект делают несколько embedded программистов — с OS — это проще, но это никак не изменяет основы — короткий, лаконичный, быстрый код. Часики то тикают.
Тесты сильно помогают, но это огромные затраты и embedded программист должен сразу писать код с учетом тестов, т.е. кроме предметной области владеть и этим аспектом и все равно это не решает всё проблемы, потому что железо ломается. И тогда нужно «красиво», без искр и пламени выключиться, но так чтоб это не привело к «окирпичиванию».

остальное уже боле-менее десктоп

«Решта» теж має широкий спектр. Комп’ютер з Windows, вбудований у осциллограф чи банкомат — це за визначенням теж ембеддед.

Смотрите доки по зарядным микросхемам для Li аккумов — там внутри то же микроконтроллер и соотв. есть embedded программеры, которые написали для него прошивку :)

IC design зазвичай не відносять до embedded, абсолютна більшість критичних контролерів не мають можливості заливки ззовні firmware, і цікаво, в Україні крім Melexis і Cypress/Infineon є ще якісь місця, де розробляють саме мікросхеми, не готові вузли з їх використанням?

А переключение на резерв, а анализ запаса аккумов

PowerPath і fuel gauge з точки зору програміста — це зазвичай чорний ящик, розміщений на платі схемотехніком і у якого стирчать назовні визначені регістри чи навіть просто піни. Дригати їх асемблером чи скриптом на Python вже не принципово.

Embedded всегда требует понимания физических/химических/технологических моментов от программиста

Чим більше це винесено на відповідні рівні, щоб акумуляторами займались профільні електрохіміки, схемотехнікою займались профільні аналогові електронщики, трасуванням плат, фізичною компоновкою, EMC, аналізом тепловиділення,..., тим краще у такому місці work-life баланс, а ембеддед тим більше виглядає як нормальне програмування, з колективною роботою з bus factor > 1, контролем версій, CI/CD та іншими здобутками, і займаються тоді вони власне програмуванням, створенням середовища, яке пов’язує порти з регістрами з бізнес-логікою у максимально ефективний спосіб.
І навпаки, якщо намагатись бути фулл-стеком, від ручної пайки, до написання веб-інтерфейсів, то за це і будуть платити 200 баксів і постійно навішувати відповідальність за проколи, які неминуче будуть при поверхневому підході до кожного шару стеку. Мати скіли вбік від свого стеку прикольно, інколи стають у нагоді для дебагу, але все ж таки, майбутнє — за професіоналізмом і розподілом обов’язків.

Комп’ютер з Windows, вбудований у осциллограф чи банкомат — це за визначенням теж ембеддед.

ага — а комп вставленный в дупло дерева даст плоды? Я делал банкоматное железо и писал софт для спецэлектроники — в банкоматах есть embedded: контроллер диспенсера, контроллер принтера, карт-ридер, клавиатура с модулем шифрования, спецэлектроника, но в ПК там просто десктоп. PC104-е платы придумали не просто так! :))) Есть встроенные системы под WindowsCE, но там и WachDog уже и порты наружу и Windows другая.

можливості заливки ззовні firmware

— ест однократно программируемые микроконтроллеры и для них то же кому то надо писать прошивки :)

це зазвичай чорний ящик

— значит это не embedded программисты. Как говорили мои учителя программист это на 30% железячник и на 70% программист — давно конечно это было :)))

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

— если бы эти достойные люди могли — embedded программисты были бы не нужны, но химики вот вообще дупля не отбивают в программировании и электронике или может мне так 30 лет везло :)))
Embedded никогда не будет «нормальным программированием», но в этом его смак!

ага — а комп вставленный в дупло дерева даст плоды?

Я взагалі противник пхати мікроконтролери і особливо інтернет туди, де і без них все добре працює.

Как говорили мои учителя программист это на 30% железячник и на 70% программист — давно конечно это было :)))

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

химики вот вообще дупля не отбивают в программировании

— так вони і не повинні, у них 6 років навчання, з прикладною квантовою механікою і роботою з прикладним софтом для моделювання молекул і матеріалів на обчислювальних кластерах, аналізами всіляких ЯМР-спектрів, навички роботи з лабораторним посудом і тому подібного, їм потрібно, щоб інструменти просто працювали, або надавали DSL зі зручним і зрозумілим для них описом системи. І це прекрасно, що їх потреби створюють роботу для програмістів.

пхати мікроконтролери і особливо інтернет туди, де і без них все добре працює

та не — стирать вручную и разогревать на огне — сомнительное удовольствие, а «умные девайсы» не потому что сложные, а потому, что гемора с ними меньше, как не крути но карбюратор хуже инжектора, а при протечке «антипотоп» перекроет воду и сбережет Вам нервы и деньги, что же в этом плохого? А если еще и ремонтников вызовет так как Вы слегка на работе, так вообще супер! ;)
А если

з віком романтика від паяння «крутих штук» проходить

, тем более не стоит оставаться в embedded, у меня вот не прошла, как начал в 90х, так и до сих пор :))))
Но с «нормальным программированием» — это не embedded — когда для отладки нужен осциллограф, логическиq анализатор, программаторы (на плате два проца и ПЛИС) переходники для интерфейсов, все это часто нужно гальванически развязанное — что тут из «нормального»? ;)
Оплата это функция от того что делаешь и на каком уровне — не один человек не сможет вручную удержать градиент температуры 0.5С/минуту вакуумной печи с фазовым регулятором на 10кВт нагреватель и 100кг полезной массы, а контроллер может! И термопары там были напрямую в АЦП без всяких усилителей ;))))
А про гос.заказчиков — лучше не стоит — эта лошадь перспектив не имеет.

при протечке «антипотоп» перекроет воду и сбережет Вам нервы и деньги

Розумний вентиль зриває гідроударом при аваріях так само як і звичайний, а пороги спрацювання датчиків затоплення на практиці доволі грубі, щоб не було помилкових спрацювань на швабри. Зате мороки (не стільки технічної, скільки сертифікаційної) з гальванічно розв’язаним живленням або регламентною заміною батарей у подібних системах додається чимало.
Це якраз гарний приклад того, що первинно повинен бути кваліфікований сантехнік, який сформує ТЗ до системи, а вже потім підбір контролерів і код.

тем более не стоит оставаться в embedded

Саме так, варто пробувати різні варіанти. Наприклад, комфортний баланс я для себе знайшов у Linux kernel і Linux generalist позиціях.

что тут из «нормального»? ;)

Якщо одна людина пише під FPGA і під мікроконтролери, і ще й проектує залізо і пише наукові статті по результатам вимірювання, зазвичай виходить не дуже нормально, часто приймаються дорогі і складні рішення там, де можна справитись за копійки готовим.

не один человек не сможет вручную удержать градиент температуры 0.5С/минуту вакуумной печи с фазовым регулятором на 10кВт нагреватель и 100кг полезной массы, а контроллер может!

Та може, може. Можна і плату з контролером і АЦП спаяти imgur.com/a/L7UyPvX , і термостат склеїти imgur.com/a/1F6Ns9u , і побавитись PID-регулятором imgur.com/a/L7KqCCB , і допоміжним термометром imgur.com/a/oN04ITI контролювати рекорди стабільності температури imgur.com/a/53Cms9I
Але одна справа, бавитись цим довгими ковідними вечорами, і зовсім інша, робити це в стресових умовах за гроші, кратно менші за традиційне ІТ. А це, на жаль, скоріше правило, ніж виключення.

мороки (не стільки технічної, скільки сертифікаційної)

— да некоторые правила написаны не только чернилами и по этому электронная схема не должна приводить к катастрофическим последствия при выходе из строя одного ЛЮБОГО компонента. Аналогично и софт, если конечно для Вас важна жизнь и здоровье того кто будет пользовать Ваши устройства. Но полноценных обработчиков хард фолов я не много в коде и не встречал! Даже простейший отказ системного кварца при котором система сваливается на встроенный RC обычно разруливают перезапуском по WDT :))))

Linux kernel і Linux generalist

— кто против — о вкусах не спорят. :) Я то же часто смотрю в сторону iOS — нравиться мне их устойчивость, на сайте Apple год вакансия embedded for iOS висит — интересно было бы покопаться во внутренностях M2, контроллере кеша и арбитраже мультипроцессорного камня — мням! :)))

Якщо одна людина пише під FPGA і під мікроконтролери, і ще й проектує залізо і пише наукові статті по результатам вимірювання, зазвичай виходить не дуже нормально

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

Та може, може. Можна і плату з контролером і АЦП

— стопе — не махлевать — в «ручную» значит руками, в крайнем случае, я бы принял схему ПИД регулятора на ОУ :)))) но таких динозавров я знаю всего двух :)))
А вот про

умовах за гроші

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

Даже простейший отказ системного кварца

Чому це «простейший»? Якщо не ставити китайский ноунейм з невідомими реактивностями і слідувати вимогам від контролера, то крім цілеспрямованого втручання з метою обійти секьюрність, нічого з ним не станеться. Від вібрацій чи жорсткого термоциклювання, наприклад, скоріше трісне з КЗ якийсь керамічний конденсатор по живленню або частотній компенсації зворотного зв’язку у імпульсному стабілізаторі, і це вже ніяким кодом не вдасться обійти.
Відмова RTC від бруду і вологості на платі стається часто, але сподіваюсь Ви розумієте, чому у якості системного стоять високочастотні кварци, а не просто PLL для годинникового.

я бы принял схему ПИД регулятора на ОУ

Вона там теж є, у вигляді стабілізатора струму.

это зависит от того насколько мы ценим свой труд

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

китайский ноунейм

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

робити це в стресових умовах за гроші, кратно менші за традиційне ІТ.

146%

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

певна група людей яка досі вибирає роботу, бо цікаво.

штрейкбрехери

бо цікаво

для цього є хоббі

Це питання про вже про філософію, а не ембеддед . Як людина регулює це в середині. Ваша позиція зрозуміла

Ситуація в Україні з ембедед була погана і буде ще гірше. Це не філософія, це доконаний факт. На старих «ентузіастах» ще який час можна тягнути.

Для таких висновків повинна бути аналітика більш фундаментальна ніж ваші відчуття. Статистика каже , що ринок ріс і росте. Ембеддед ринок в одній компанії, виріс з 265 людей, до більше тисячі за 8 років.

Ситуація в Україні з ембедед була погана і буде ще гірше.

vs

ембеддед ринок в одній компанії

за 2022 рік? в українському офісі ГЛ?

Для таких висновків повинна бути аналітика більш фундаментальна.

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

Насправді, не все так погано, місцями платять на рівні веб-бекенду і зі схожою якістю процесів. Місцями навіть краще — у кернелістів, наприклад, не буває такого що прод упав і потрібно серед ночі в суботу терміново фіксити. Просто потрібно не підписуватись витягувати весь стек (особливо розробку схемотехніки і монтаж плат) і займатись тільки софтом. Звичайно, софту в авр-ки або стм32 багато не поміститься, як правило це проекти під великі SoC.

дивимося ширше:
1. Кородони відкриті?
2. Нові проекти заходять?
3. Що там з освітою і молодняком?
Те що зараз ще якось ніби і не дуже зле (на хліб з маслом вистачає, і на маржу)... але в ГЛ пишуть рекламну статтю, і кажуть що в когось погана аналітика на майбутнє, і що хочуть того хто «вибирає роботу, бо цікаво», а не зарплату і WLB

по бекенду присилають 8..10К місяць
Rust від 160K в рік
в Джинні в статистиці найм останній в ембеддед бачив на 6К

HR Ембеддед: «6К це много, ви ж бачите яка ситуація»

Крім першого пункту (хоча ембеддед буває і з повним ремоутом), все це б’є по ІТ в цілому. По вебу можливо навіть у більшій мірі через жорсткіші вимоги до аптайму і часу реакції на проблеми, в той же час, дрібного ембедеду на військові цілі стало навіть більше потрібно.

Проблема з емб системна: вимоги топ, а ринок маленький. Топ у двох вимірах: 1) багато технічних обмежень, 2) багато інтеграцій й комплаєнсу. Маленький у двох вимірах: 1) на боці споживача недостатнє масштабування, 2) у рамках одного технічного фаху погане перенесення знань. Тобто приблизно вимоги у квадраті, можливості як з під квадратного кореню. У таких умовах і технічним фахівцям важко, а менеджерам загалом капець. Останнє впливає так, що у керуванні командами та проектами переважно утримуються сабстандартні особистості. Все загалом дає об’єктивний недолік десь 10^-5. Градієнт пятого ступеня приблизно відповідає градієнту знань джун-сеньйор. Тобто за повністю справного ринку ембед сеньор з разробки якогось купюроприймача мав би отримувати як джун мобільного додатку, у котрого на AWS 100M DAU.

Цікаво, що розумною інженерією можна 10^3 витягнути. Тобто організаційний фахівець разом з технічним фахівцем можуть зробити 10^6. Но з вищезазначених обставин, таке маловірогідно. Тому емб у виконанні команд загального програмування статистично є більш ефективними.

Вы об одном и том же спорите. Надо только с определением определиться.

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

. Как видим, это чисто за опыт, знания и творчество. А химия это, электроника или квантовая физика или еще какая отрасль вплоть до гинекологии — не важно.

Embedded — это боль и заниматься этим нужно только если тебя от этого «прет»! :)))

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

Дякую Сергій, так це оглядова стаття. Розкрити світ ембеддед в одній статті неможливо. Було б чудово якби люди писали більше і спілкувались на цю тему. Я не писала, що тема з батарейкою проста. Контроллер простий(що так само відносно), а код писати щоб мінімізувати використання батареї дійсно вищий пілотаж. Згідно наших досліджень тільки С не достатньо тому ми включили також електроніку у перелік. А також глибоке знання операційних систем та драйверів. Дякую за важливе доповнення

Нажаль в Україні немає embedded спільноти, мабудь тому що це буде клюб неанонімних алкоголіків :))) Нажаль...

Ми доречі в КПІ маємо лабу, там є трішки обладнання, але ми не маємо менторів, хто буде теж приходити і допомагати робити проекти. Є можливісті для спільноти, просто коли ми хотіли знайти людей згодних додатково порозбиратись, то всі були втомлені. Знайшли бажаючих прийти подивитись:) Але якщо спільнота хоче драйвити, то можливості такі є

Ми всі мріємо про пенсію на кафедрі в м’яких макасинах, але пенсія нам не світить і не зігріє ;)))

а на якому факультеті лаба? чи можеш пошарити контакти?

ФІОТ, КПІ. Я і є контакт :)

в Україні немає embedded спільноти,

аграрна супер держава

Аграрная супер держава — это про ГрейтБритан — там рекорды 150ц с га, а нам просто подвезло с землей и то 30ц/га с трудом :( Но думаю причина не в этом — просто жлобство надо изживать, но «не бит не крашен прадик на газу» будет сильно против :))))

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

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

Процесосри від AVR нажаль уже мертві, тому я б на Arduino сильно не розраховував, хіба для швидкої перевірки ідеї, маштабуватись вже не вийде, тому після успішної перевірки варто задуматись про міграцію Вашого проекту на STM32.

Якщо не виготовляти промислові партії і не вибудовувати supply chain з гарантіями на роки вперед, це не принципово, можна просто купити пожиттєву партію мікроконтролерів для саморобних штук. З іншого боку, навіть імениті виробники можуть свиню підсунути, наприклад, STM одним днем перевів всю STM8 лінійку в NRND.
Але так, краще одразу звикати до повноцінних arm/risc-v і не прив’язаних до конкретного IDE, корисно і з точки зору довготермінової підтримки проектів, і менше перенавчатись з низькорівневого ембеддеду на щось більш оплачуване.

Ми активно будуємо навчальні програми на STM32. Але для вивчення велику роль грає популярність технології. Тому з нашого боку варто скористатись недорогими платами з великою кількістю периферії та готових бібліотек на ESP32 та Arduino. Це дешевше та доступніше. Щодо конкретної промислової задачі, вибір контроллера і елементів має розглядатись окремо під задачу. Технологічний розвиток контролерів не стоїть на місці, тож протягом професійного шляху, швидше за все доведеться бути готовим до перекваліфікації

Для багатьох проектів необхідно розуміння базового стеку мережевих протоколів TCP/IP. Для бездротової комунікації можуть також знадобитись протоколи більш низького рівня такі як Bluetooth, ZigBee, Wi-Fi та інших протоколів бездротового зв’язку для підключених пристроїв (IoT).

Задумался..По моему протоколы Bluetooth, ZigBee, Wi-Fi выше уровня TCP/IP

Дякую за запитання. Всі протоколи , що відносяться до фізичного середовища не можуть знаходитись вище 2го рівня. TCP/IP стек запаковує більш низькорівневі протоколи і працюють від MAC частини 2го рівня і до 4го рівня

Я все понял. Сори.. Я поддержал с юмором. А то, кто-то подумает что серьезно поддержал..

Вот это

здатність до інтеграції в будь-які архітектурні рішення:
заощаджувати час та кошти на розробку й подальший випуск власних систем

И многое другое..я давно предлагаю.. Разработал и фундаментальную модель недетерминированной машины, систему и новый язык программирования и даже отправлял на Global Lodgic. Если интересует ( а оно должно заинтересовать) то звони.. Пообщаемся.. Здесь размещать нет смысла. Мало кто поймет с первого раза. Совсем новая технология.. Минимум три сеанса общения требуется.

Я думаю для новітніх розробок такого рівня краще підійдуть наукові конференції, а також готовий продукт продемонстрований на kickstarter. У компанії GlobalLogic трошки інша бізнес модель, але ми завжди раді, коли люди створюють цікаві технологічні рішення. Тож успіхів вам у просуванні

Дуже цікаво! А які задачі та бізнес-проблеми клієнтів ця нова машина та нова мова програмування зможе вирішити краще чим існуючі рішення? Як щодо реалізації прототипу машини та проведення порівняльного тестування в плані продуктивності / ефективності (споживання, апаратна складність в реалізації і т.п.) з наявними платформами?

Дуже цікаво! А які задачі та бізнес-проблеми клієнтів ця нова машина та нова мова програмування зможе вирішити краще чим існуючі рішення?

Прежде всего это новая архитектура компьютера и новая система и технология программирования. Вплоть до того, что это не совсем программа, не совсем алгоритмы и содержимое памяти не двоичное, а в представляет собой множество объектов работу которых можно представить в виде графа, где вершины -объекты, а адресация -ребра ( перцептроны). Само собой адресация «умнее» чем в обычных компьютерах и все это способно работать в многопроцессорных компьютерах с несколькими шинами данных. Это что касается эффективности. Сильно пугаться не надо. Виртуальная машина может работать и в обычных компьютерах и это «нечто» может работать на любом контроллере в котором установлена виртуальная машина. Размер системы 14кб. Виртуальной машины −10 кб. Это об экономии на программирование. Интерфейс I2C написанный на контроллере шнайдер будет работать на SMT32. Т.е. библиотека растет как снежная баба. Прога написанная один раз работает всегда и везде. Сложное-изменение сознания. Ибо машина работает не так, как классическая.. Где-то в моих темах здесь есть и описание архитектуры и примеры. Есть еще другие методы программирования и возможности.. Это уже в подробном общении. Кстати, я живу под Харьковом. В связи с боями под Белгородом сотовая связь у нас выключена. Общение через инет.

Як щодо реалізації прототипу машини та проведення порівняльного тестування в плані продуктивності / ефективності (споживання, апаратна складність в реалізації і т.п.) з наявними платформами?

Хороший вопрос. Все это я сочинял что б было проще и дешевле и аппаратно и мышление и размеры. Единственный «недостаток» надо поменять себя. Машина работает не последовательно команда за командой, а строго событие — подписка. Нет события нет работы.

Я бажаю вам успіхів. Цікава тема.

Підписатись на коментарі