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

Всім привіт! Мене звати Андрій Неборак, я Senior Embedded Developer у GlobalLogic. Маю 15 років комерційного досвіду — закінчив університет і вирішив не затягувати з цією справою :)

Моя цікавість до цього напряму закладалась поступово. Спочатку гурток програмування в Будинку дитячої творчості, де вивчали мову програмування BASIC, але «справжній» комп’ютер був тільки у викладача. А учні працювали за радянським компʼютерами, в якому сам комп’ютер та клавіатура є одним цілим, з вшитим інтерпретатором мови програмування та чорно-білими моніторами. Згодом переключився на радіогурток, який відвідував до самого завершення школи.

Вступав у Кременчуцький політехнічний університет на спеціальність «Системи керування і автоматика», яка охоплює одразу три напрямки: комп’ютерне програмування, програмування мікроконтролерів та електроніка. Ще прихвалювали, що такі спеціалісти будуть затребувані місцевими заводами. На жаль, тоді інших перспектив не було, та, на щастя, часи саме тоді почали змінюватися на краще.

Останні роки я спеціаліст у напрямі розробки програмного забезпечення для тестування пристроїв під час розробки. Коли ми маємо якийсь пристрій, можемо писати для нього тести ще від самого початку, які будуть запускатися на кожен коміт. Таким чином ми можемо перевіряти якість кожної виконаної задачі та чітко відстежувати, в який момент щось пішло не так. Моя спеціалізація — це мова С для мікроконтролерів, а також Python для другорядних задач. Також я автор курсу CAN Bus і є ментором для Trainee, підтримую їх протягом періоду адаптації.

🙌

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

Що таке Embedded

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

Для чого потрібен Embedded у повсякденному житті

  • Зменшення споживання ресурсу (економія коштів, часу, виробничих потужностей тощо), а також негативного впливу на природу.
  • Підвищення продуктивності людини.
  • Розширення можливостей для дослідження та аналітики даних.
  • Запобігання аваріям.
  • Автономність.

Куди рухається Embedded

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

Здешевлення продуктів, в які будуть вбудовані технології

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

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

Збільшення ККД роботи пристрою

Думаю, що термін ККД багато хто пов’язує з енергетикою: котли та генератори. В цій галузі кожен відсоток ККД є додатковою економією. Останні декілька років нам довелося познайомитися з таким штуками, як інвертори та зарядні станції. ККД визначає автономність нашого житла, майже все інше — перетворюється на тепло, яке треба відвести вентиляторами. Саме тому можна побачити відгуки, що пристрій повністю безшумний (з пасивним охолодженням), має адаптивне регулювання залежно від навантаження або шумить постійно. Думаю, за змоги покупець обере додому менш шумну версію, що дасть перевагу перед конкурентами.

Безпека

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

Спеціалізоване навчання

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

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

Чому Embedded — це не так складно, як здається

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

  • Фундаментальні знання з фізики вже всі відомі з XVIII-XIX ст. До теперішнього часу вони трішки оточуються, робляться нові відкриття в області напівпровідників, але загалом тут більше роботи за самими виробниками напівпровідників.
  • Алгоритми та протоколи лишаються актуальними: TCP/IP, Modbus, CAN, I2C, USB. Звісно, вони розвинулися відносно свого початкового вигляду, але новіші версії застосовуються лише там, де є в тому потреба. Для прикладу, перший серійний автомобіль з CAN-шиною було виготовлено у 1991 році, але він досі в тому ж самому вигляді масово використовується в автомобільній індустрії.
  • Щоб використовувати щось нове, за нього прийдеться заплатити — тому компанії неохоче змінюють свої розробки. Це стосується, наприклад, кожного використання інтерфейсів. За USB досі платять, за SD-карти компанія збирає royalty за кожне використання розʼєму SD (SD, microSD, miniSD). Тут з’являється маленьке пояснення, чому iPhone досить довго використовував Lightning, а не Type-C. Тому що для того, щоб приключитись на нього, треба комусь заплатити.

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

  • Випускають оціночні комплекти. І що дешевше вони коштують, то більш масово буде вивчатися новий мікроконтролер. Свого часу компанія ST випустила демонстраційну плату STM32VLDISCOVERY, що містила Cortex-m3 чіп та програматор/налагоджувач на одній платі, та коштувала всього лише 10$. Думаю, це і принесло таку популярність мікроконтролерам STM32.
  • Випускають безплатні версії програми забезпечення.
  • Спрощують використання складних технологій. супорт такими платами, бібліотеками, прикладами, кількість яких для кожного чіпа дуже велика. Тут би хотів нагадати про появу ESP8266, який максимально спростив підключення для безпровідних мереж. Завдяки цьому, своєю чергою, з’явився фреймворк ESPHome.
  • Новіші мікроконтролери — це нащадки старіших. Насправді жодне серійне виробництво Embedded-пристроїв не хоче зіткнутися з проблемою зняття чіпу з виробництва. Це зупинка виробництва, розробка з новим чіпом, тестування/сертифікація. Тому виробники чіпів стараються запроваджувати нові моделі як трохи розширену версію попереднього покоління: прискорюючи, додаючи новий функціонал і часто здешевлюючи вартість чіпа.

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

Задачі, з якими ви зіткнетесь, потрапивши на проєкт як Embedded-розробник

Розробка ПЗ

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

Проєктування

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

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

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

Автоматизація

В автоматизацію входять усі процеси, пов’язані з рутиною, і з яких можна виключити людину:

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

Супутня програма забезпечення

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

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

Тож Embedded стоїть за мільйонами приладів, які ми щодня використовуємо в побуті, роботі, дослідництві, виробництві — від пральних машин і пилососів до тренажерів для пілотів і VR/AR-симуляторів. Розширення функціоналу девайсів прямо залежить від того, як змінюються та вдосконалюються вбудовані технології. За прогнозами, ринок вбудованих систем зросте з $95 млрд у 2022 до $162 млрд у 2030.

Висновок

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

У підсумку: всім тим, хто бачить свій шлях в Embedded, раджу робити акцент на мові програмування C, опановувати такі супутні технології як GIT та інші. Другий аспект, але, напевно, не менш важливий — це досвід людини роботи з мікроконтролером. Навіть просто щось зібрати на Arduino і запустити його, скомпілювати, завантажити програму і впевнитися, що вона працює — це вже круто. Адже в людини з’являється знання про те, як воно завантажується, зберігається, що там є якісь обмеження за розміром, проблеми й таке інше. Тому не бійтеся втілювати свої РОС-проєкти — це стане потужним плюсом у резюме в майбутньому.

👍ПодобаєтьсяСподобалось15
До обраногоВ обраному5
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
Embedded — це поєднання мікропрограми та мікропроцесора або мікроконтролера разом, вбудоване в якийсь пристрій, який раніше його не мав. Як приклад може бути пральна машина.

Візьмемо клавіатуру або мишу (на дроті, PS/2 або USB), планшет (графічний), контроллер HDD або SSD, можна довго продовжувати. Можна сказати, що такий пристрій раніше не мав мікропроцесора або мікроконтроллера? Ні, бо таке воно не могло взагалі функціонувати. (Варіант клавіатури з 26 дротами в компʼютер — не розглядаємо, як знущання.) Є воно embedded? Однозначно да. Приклад, хоч і старий, з 8048 процесором і 1KB компактного коду для нього — легко знаходиться.

Тобто тут в означенні вже проблеми.

Мені більш подобається опис від Спольського, хоч і не строгий. Процитую з Five Worlds: «Embedded Software has the unique property that it goes in a piece of hardware and in almost every case can never be updated. This is a whole different world, here. The quality requirements are much higher, because there are no second chances. You may be dealing with a processor that runs dramatically more slowly than the typical desktop processor, so you may spend a lot of time optimizing. Fast code is more important than elegant code. The input and output devices available to you may be limited.»
Головні риси позначені: обмеженість ресурсів всіх видів, обмеженість доступу (і з цього складність діагностики), відсутність звичних інтерфейсів, близкість до «заліза». Не всі одночасно, але коли 2-3 з 4 підібрались, можна казати про відповідність.

В іншому ж — я не уявляю, як можна казати щось про embedded _в цілому_. Може бути пристрій на 8048, як вище, або його нащадку 8051, що отримав колись шалену популярність — 256 байт оперативки, 4KB ROM, декілька мегагерц тактової у кращому випадку, крутись як хочеш, але завдання має бути виконане. А якийсь лінійний процесор карти в раутері у провайдера світового рівня матиме декілька сотен мегабайт на зберігання CEF дерева в якому BGP fullview, а його тонкощі логіки, що завантажуються в FPGA, будуть у тому, як відпрацовуються атрибути записів дерева. Різниця в ресурсах в міліони разів, спільне лише — див. вище — складність супроводження, відповідальність за помилки.

Тому і підходи можуть бути різні. Я нещодавно «гріб» на проектах, де формально «embedded», але там був Linux на AArch32 з десятками мегабайт RAM. Але я не даватиму порад тому, хто програмує якийсь Z80 у пральній машині чи в інжекторі автомобіля, я не мацав це все своїми руками. А той, хто з таким возився, не зрозуміє моєї проблеми з конфліктом оновлення пакетів із Yocto і APT. Це теж різні світи, про них треба окремо розмовляти.

Можна сказати, що такий пристрій раніше не мав мікропроцесора або
мікроконтроллера?

Можно. Там не настолько изощренный алгоритм, чтобы нельзя было сделать на жесткой логике.

Варіант клавіатури з 26 дротами в компʼютер — не розглядаємо, як знущання.

Обычный сдвиговый регистр, никакой зауми.
Я в свое время застал АОН, сделанный на дискретной логике. И ничего, работал.
Просто на Z80 — компактней и легче для апгрейда.

Можно. Там не настолько изощренный алгоритм, чтобы нельзя было сделать на жесткой логике.

Я вариант «на жёсткой логике» не включаю тут намеренно, потому что по отношению к остальному программированию это туда же, где и embedded, только ещё жёстче.
А сделать, конечно, можно, когда-то ведь делали. Один только каталог периферии к ЕС 10хх потрясает разнообразием, а внутри у такого устройства шкаф микрух серий 131/133/155/итп. И работало же...

Один только каталог периферии к ЕС 10хх потрясает разнообразием

это глупо ну ок у меня есть фонарик подключаемый на usb-a как-то возник вопрос я случайно обнаружил в местном лабазе и помучившись какое-то время пошёл купил и свои деньги он #внезапно отработал

... хотя вещь конечно сферически в вакууме туповая ))

а внутри у такого устройства шкаф микрух серий 131/133/155/итп.

внтетре у ней буквально неонка с радиатором принннём принннём всё забываю замерить его реальное потребление и собственно всё думателя там нет

И работало же...

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

ЗЫ: фонарь строительный dewalt туда не подходит ))

ЗЫ: кстати на сколько я понимаю в акумуляторе строительного фонаря dewalt думатель внутре таки есть ))

это глупо ну ок у меня есть фонарик подключаемый на usb-a как-то возник вопрос я случайно обнаружил в местном лабазе и помучившись какое-то время пошёл купил и свои деньги он #внезапно отработал

Если он просто заряжается по USB, то там может вообще не быть никакой логики, ну кроме ключа, который, например, «на батарее >=4.2V => отсекаем вход».

вроде как последнее время я стал замечать что стало помигивать

«И хто иво знаить, чиво он моргаить» (tm)

Если он просто заряжается по USB

не он проще он только светит )) т.е. буквально а внутре у ней неонка ))

Можно. Там не настолько изощренный алгоритм, чтобы нельзя было сделать на жесткой логике.

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

Обычный сдвиговый регистр, никакой зауми.

при чём этот сдвиговый регистр есть в современном usb контролёре by default и даже отдельно не изобретать ps/2 (интересно их ещё делают? хм ага действительно ещё делают)

Просто на Z80 — компактней и легче для апгрейда.

на столько что современная «ручная гаражная сборка на жёсткой логике» чаще самой жёсткой логикой в виде непосредственно ttl логики не заморачивается а просто лепит туда цельную микросхему rom с прошивкой в соотв. с логикой

ЗЫ: я знаю что ты скажешь за сдвиговые регистры и прочие цыклы дальше не надо пож. ))

ЗЫ: опять же ж чистая логика на жостком ttl в современых реалиях тоже есть в виде плис pld стоит как самолёт за юнит а «программистов» на него ещё меньше и ещё дороже

... глупая дискуссия априори зачем я влез ((

Дякую за статтю!

Колись трохи бавився із Arduino, ESP, збирав констуктори типу sunfounder 4wd.
Однак постійно було відчуття, що я роблю «на колінці», а ось справжні ембедери у продакшені мабуть роблять якось інакше.
Можете підказати якийсь матеріал (курс, книга, ...) де можна було б ознайомитись із сучасною embedded розробкою близькою саме до production стандартів та підходів?

В контексте программирования — общая теория: ООП/функциональное,
SOLID, паттерны проектирования итп. Обычно эмбеддеры от электроники грешат спагетти-кодом.
Дальше — операционные системы, опять же теория: скедулеры, объекты синхронизации, IPC.
Если все это хорошо в голове хорошо уляжется — будет получатся красивый и надёжный код.

Обычно эмбеддеры от электроники грешат спагетти-кодом.

обычно все «сишники» так делают )) я проверял

... у эмбеддеров только проблема всё это поместить ну и ещё что компиляторы не всегда поддерживают всякие модные фичи вроде определения переменных где попало а не строко в одном исключительном месте ))

операционные системы, опять же теория: скедулеры, объекты синхронизации, IPC.

я думаю с этим могут быть сложности имхо здесь имеет смысл разделять на «теорию» и «практику» по скольку как исходя из моего опыта и обобщённых наблюдений и размышлений на практике «теория» может не только не понадобиться но и скорее быть вредной

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

практика же ж состоит почти полностью из лишь готовых уже апробированных паттернов как то

объекты синхронизации, IPC.

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

общая теория: ООП/функциональное

имхо конкретно embedded самой своей сложностью до всего этого до таких теорий просто не дотягивает и отдельно имхо это становится разочарованием «начинающих» а также «ошибкой не выжившего» где как раз начинающие как раз всё время пытаются этому противостоять и «изобрести» сложность там где её не было и не может быть ну хотя бы просто потому что она туда просто не помещяется

обычно все «сишники» так делают )) я проверял

Правильно, а кто они? Радиотехники и автоматизаторы выслушавшие семестр по С на втором курсе. Альтернатива — выучившие по мануалам от чипмейкеров.

... у эмбеддеров только проблема всё это поместить ну и ещё что компиляторы не всегда поддерживают всякие модные фичи вроде определения переменных где попало а не строко в одном исключительном месте ))

Та лана, С99 поддерживают все современные компиляторы. А еще можно С код плюсовым компилятором собрать.

имхо конкретно embedded самой своей сложностью до всего этого до таких теорий просто не дотягивает

Дотягивает-дотягивает. Любую микроконтроллерную периферию можно обернуть в класс и даже построить небольшую иерархию типа контроллер ->шина->и2ц. Я уже не говорю о бизнес логике. Тут главное понимать суть ООП и строить правильные абстракции, а не морочить яйца ересью из С++ стандарта.

А еще можно С код плюсовым компилятором собрать.

Щось хоч трохи складне не збереться, спіткнувшись на купі автокастів з void * або використанню зарезервованих слів для змінних.

Щось хоч трохи складне не збереться, спіткнувшись на купі автокастів з void * або використанню зарезервованих слів для змінних.

Компилятор поругается на рискованные касты и будет совершенно правым, но ошибкой это не будет, если не стоит флаг «treat warnings as errors». Кроме того, по крайней мере в g++, есть куча флагов «C and Objective-C only» специально для таких случаев.

Любую микроконтроллерную периферию можно обернуть в класс и даже построить небольшую иерархию типа контроллер ->шина->и2ц. Я уже не говорю о бизнес логике.

так вот именно я же ж и говорю а именно бизнес как просто бизнес таким просто не занимается ))

а не морочить яйца ересью из С++

соотв. бизнесу нужен просто рабочий код читай работающий читай в бинарном виде делающий то что задано и не делающий того что не задано

... на что у бизнеса конкретно embedded даже есть куча своих практик которые просто то как сделать это вообще без кода и именно такие tools and approaches продаются бизнесу который делает бизнес на применении микроконтроллёров теми кто хочет продать этому бизнесу лопаты (см. «лопаты золотая лихорадка»)

так что буквально просто бизнес ))

ЗЫ: я же ж говорю

и отдельно имхо это (отсутствие реальной сложности реально на техническом уровне бизнеса) становится разочарованием (для) «начинающих»
соотв. бизнесу нужен просто рабочий код читай работающий

Смотря какой код и какой бизнес. Вон немецкий автомотив уже дочирикался.
Но человек, который писал допустим драйвера для Линукса спагетти уже писать не сможет. Рука набита на другое. С другой стороны, чтобы понимать стиль Linux kernel, нужно понимать ООП подкоркой.

Знайоме відчуття, але це, скоріше, синдром самозванця.
Є проєкти де Ваш код «на колінці» буде зразок, але, тим не менше, той поганий код робить щось іноваційне, покращує світ та годує сім’ї розробників.
Якщо для мікроконтролерів я б радив:
1. Книжку «Effective C: An Introduction to Professional C Programming, Robert C. Seacord» (є переклади)
2. Запросити фідбек на код
3. Запустити cppcheck для свого коду та cppcheck + MISRA плагін. Ну і самі MISRA правила варто почитати.

(є переклади)

... для початку одразу ж порада саме цілеспрямовано «позбутися перекладів» ))

2. Запросити фідбек на код

а ну тут просто «працює або не працює» )) і далі просто з того коду робиш що ще або розумієш що код або точніше сам target до того коду уже сталий і просто починаєш інший код

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

On Writing: A Memoir of the Craft Book by Stephen King

ЗЫ: див. п.п. «позбутися перекладів» але тут ок тут у перекладі можна бо окремо «культурний контекст» вам не дуже суттєвий як то як мені

Ну і самі MISRA правила варто почитати.

імхо слід розуміти що правила є і слід просто мати досвід писати за правилами

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

... для початку одразу ж порада саме цілеспрямовано «позбутися перекладів» ))

Яростно плюсую.

Ну і самі MISRA правила варто почитати.

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

Прийняв, дякую!
А можливо можете ще якісь open source embedded проекти поради?
Для ознайомлення із тим, як варто робити, щоб «все по феншуй».

P.s. звісно завжди можна почитати код linux kernel і т.п. але хотілось би чогось більш адаптованого для початківця, але і не hello world, аля блимання діодами.

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

де можна було б ознайомитись із сучасною embedded розробкою близькою саме до production стандартів та підходів?

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

ні назву виставки не підкажу ))

бо ж реалістично там

production стандартів та підходів?

як таких універсальних саме нема бо ж скажімо що таке контролер на 6 ніжок 0,5кБ SRAM? Що саме з «індустріальних стандартів» слід на нього очікувати? то все буде фактично визначатися тим куди ця «фітюлька» буде вставлятися у якості контролера чи там праска чи там пралка і з цього «стандарти» там доволі широкі і ринок широкий теж

щось як порівнювати то то питання до цифрового осцилографа )) і я сірьозно мені треба було таки токові кліщі мені стало цікаво я зайшов на маркет а там чого тільки нема от чого і нема так це «індустріальних стандартів»

Писав колись на першій роботі код під плату від Texas Instruments на Cortex, якщо не помилиюсь. Юзали FreeRTOS. Досвід цікавий, але я пам’ятаю що тоді було досить туго з інструментами розробки/дебагінгу (відносно того, шо маємо зараз під веб), там навіть якась своя пропріетарна середа розробки була від TI
І шоб в чомусь розібратись приходилось сидіти на форумах Texas Instruments напряму
Цікаво чи зараз так само чи може вже якось краще?

Дуже залежить від чіпа, умовно, якщо мікроконтролер на 6 ніжок всього, то 2 віддати під дебаг забагато. Там досі дебажиться через «смикання» пінами в певних місцях коду і спостереження за сигналами осцилографом. В деяких системах повноцінний дебаг + логування.
Але прям сильно ситуація не покращилася)

якщо мікроконтролер на 6 ніжок всього

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

а потім на симуляторі котрий усі 6 ніжок просто тримає під осцилографом і можна буквально по ніжках подивитися що там на справді робиться

Основна складність ембеддеду, це від’ємний диференційний рейт, де чим ближче до заліза і взагалі ширше коло обов’язків, тим гірше платять і в цілому гірший WLB.

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

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

Зависит от компании. В том же глобале и автомотив и медикал и телеком, а не только милка, как тут многие считают(в смысле, в Украине полно не милтек эмбеддед проектов, просто не все на них по скиллам подойдут).

там треба 6 років в універі і ше 5-10 років працювати і/шоб шарити

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

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

Тільки не веб, а девопс.

Основна складність ембеддеду, це від’ємний диференційний
рейт

Никогда не жаловался. То есть в кровавом энтерпрайзе и каких-нибудь трендовых стартапах конечно платят поболее, но всегда предпочитал синий диплом с красным лицом.
Плохо платят микроконтроллерщикам лячкающим процедурный код в ломаном IARе. Если уметь в gcc, git и командную строку, то мир начинает светится другими красками.

ширше коло обов’язків, тим гірше платять

Это особенность конторы, а не отрасли. В другом месте не платы бы паял, а принтеры заправлял

Если уметь в gcc, git и командную строку, то мир начинает светится другими красками.

Але закономірність зберігається — мігрувати на нові ядра чи релізи yocto і вирішувати проблеми типу reproducible builds значно виграшніше по WLB, ніж писати нутрощі якогось навантаженого нетворкінгу з оффлоадом у залізо.

мігрувати на нові ядра чи релізи yocto

Это уже становится индусячей работой со всеми вытекающими.

писати нутрощі якогось навантаженого нетворкінгу з оффлоадом
у залізо.

А вот за это платят, если конечно люди знающие, а не прости Господи, «отечественный производитель».

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

платять як вдасться домовитися

Повторюсь — не надо связываться с нашими. У постсовка отсутствует понятие о ценности знания и труда. Буржуи напротив — прекрасно в этом ориентируются.

У постсовка отсутствует понятие о ценности знания и труда.

от за Родину шас абыдна была ((

Embedded — це не складно

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

Embedded-спеціалістів точно не меншає

— їх ніколи не достатньо, бо не кожен може їм стати.

Embedded, як і інщі галузі, різний. Десь треба математика і фізика, десь зовсім не треба — чистий С і вперед.

Напомнило как на одном из проектов сидим на колле и тут внезапно:
Аналитик: «Гайз, можно ли какой-то тренинг пройти, а то я ничего не понимаю, что вы говорите на стендапе — фарады, омы и амперы какие-то»
Девелопер: «Я могу посоветовать книгу, называется Физика 7й класс» xD

Буває і таке. Але останні років 5 в мене немає проєктів де фаради, генрі потрібні. Здебільшого бутлоадери, комунікаційні пристрої, може трохи обчислень CRC.

я ничего не понимаю, что вы говорите на стендапе — фарады, омы и амперы какие-то

в ІТ абсолютно типова ситуація з РМ-ми

Наверное у нас какое-то разное айти, я уже давно не технических ПМов не встречала.

Все кто хотел в этом разобраться — разбирались. Поэтому в Embedded и вообще в электронике все еще сохраняется некая «ламповость», без смузи-айтишников)

это не профессия, это класс людей которые «мигают светодиодами»

Поэтому в Embedded и вообще в электронике

ну там на самом деле пришёл тот самый iOt (IoT?) который позволяет «писать приложения» уже на нормальном православном питоне в интернете ))

... что впрочем и раньше было со всякими там scada opc

IoT це більше про хмару (Azure/AWS)

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

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