Англійська для вбудованих і апаратних інженерів: Firmware, RTOS, і IoT Vocabulary
Майстер вбудованих систем англійською: мікропрограмне забезпечення, RTOS, обробка перерв, HAL, MISRA C, MQTT, edge computing і словник комунікації апаратно-програмного інтерфейсу.
Вбудована та апаратна інженерія має свій власний точний словник, який значно відрізняється від веб- або хмарного програмного забезпечення. Під час роботи з міжнародними командами, перегляду таблиць даних або написання технічних специфікацій, вам слід правильно використовувати цей словник. Цей посібник охоплює три основні області словникового запасу: вбудовані системи, Інтернет речей і комунікація між апаратно-програмним інтерфейсом.
Основні значення мови описані в таблиці
** Програмне забезпечення ** — програмне забезпечення, яке назавжди запрограммовано у пристрій пам’ яті тільки для читання у частині апаратного забезпечення. На відміну від програмного забезпечення, мікропрограма тісно пов’ язана з конкретним апаратним забезпеченням, на якому вона працює. « Після оновлення мікропрограми датчик почав повідомляти точні показники. »
** RTOS (Real- Time Operating System) ** — операційна система, розроблена для обслуговування програм реального часу, які обробляють дані і події з точно визначеними обмеженнями часу. Поширені RTOS включають FreeRTOS, Zephyr, і VxWorks. «Ми перейшли на FreeRTOS, тому що планування bare-metal стало неможливим, оскільки ми додали більше завдань»
** Перервати ** — сигнал до процесора, який негайно призупиняє поточне завдання і виконує спеціальну функцію обробки (ISR — Interrupt Service Routine). Переривання запускаються за допомогою таких подій апаратного забезпечення, як натискання кнопки, переповнення таймера або вхідні дані. « Переривання UART запускається кожного разу, коли з модуля GPS надходить байт »
** ISR (Interrupt Service Routine) ** — функція, яку буде виконано у відповідь на переривання. ISR повинні бути короткими і швидкими; довгу обробку слід відкласти до черги завдань. « Тримайте ISR нижче 10 мікросекунд; надішліть прапорець до завдання для важкого підняття »
** Периферичний пристрій ** — апаратний компонент, який з’ єднано з ядром мікроконтролера, наприклад, UART, шина SPI, контролер I2C, ADC або GPIO. « Ми використовуємо периферійний пристрій SPI для зв’ язку з зовнішньою флеш- пам’ яттю на частоті 20 МГц. »
** HAL (Hardware Abstraction Layer) ** — програмний шар, який забезпечує стандартизований інтерфейс для апаратних пристроїв, що дозволяє коду вищого рівня бути більш портативним у різних сімействах мікроконтролерів. « Використовуючи драйвер HAL для ADC, ми змогли перенести базу коду з STM32F4 на STM32H7 за одне післяобіддя. »
MISRA C — набір рекомендацій з розробки програмного забезпечення для мови програмування C, розроблений Асоціацією надійності програмного забезпечення автомобільної промисловості. Широко використовується в системах, що мають критичне значення для безпеки. «Автомобільний клієнт вимагає повної відповідності MISRA C: 2012; наш статичний аналізатор позначає будь-які відхилення»
Bare metal — програмування без операційної системи, запис безпосередньо в апаратні регістри. « Перший прототип працював на bare metal; ми додали FreeRTOS, коли нам знадобилося одночасне керування завданнями. »
** Watchdog timer ** — апаратний таймер, який скидає мікроконтролер, якщо програмне забезпечення не може періодично надсилати сигнал скидання (« kick »). Використовується для відновлення після застою або аварій програмного забезпечення. « Якщо головний цикл зависає більше ніж на 500 мс, система спостереження автоматично скидає систему. »
Словник-довідник
** MQTT (Message Queuing Telemetry Transport) ** — легкий протокол обміну повідомленнями з опублікуванням і підпискою, призначений для обмежених пристроїв і ненадійних мереж. Пристрої надсилають дані брокеру, а абоненти отримують їх. « Датчик надсилає показання температури брокеру MQTT кожні 30 секунд за допомогою з’ єднання 2G. »
** Edge computing ** — обробка даних на або біля пристрою, де вони генеруються, замість надсилання всіх даних в хмару. Зменшує затримку і витрати на пропускну здатність. « Ми перенесли виявлення аномалій на шлюз за допомогою обчислень на межі; до хмари надсилаються лише події з прапорцями. »
** Сполучення датчиків ** — поєднання даних від декількох датчиків для отримання більш точних або повних вимірювань, ніж може надати один датчик. « IMU поєднує дані акселерометра, гіроскопа і магнітометра за допомогою фільтра Калмана для поєднання датчиків. »
** OTA (Over- the- Air) ** — оновлення мікропрограм або налаштувань бездротовим способом, без фізичного доступу до пристрою. « Механізм оновлення OTA включає можливість відновлення на випадок, якщо завантаження нового мікропрограм не вдалося »
** Обладнання пристрою ** — процес налаштування нового пристрою за допомогою реєстраційних даних, сертифікатів і початкових параметрів перед або під час його першого розгортання. « Кожен пристрій проходить автоматичне обладнання на заводі; до того часу, як він потрапить до клієнта, його буде попередньо зареєстровано у нашій платформі керування пристроями. »
Інтерфейс програмного забезпечення
Коли інженери з різних дисциплін співпрацюють, нерозуміння часто виникають через відмінності в термінології. Використовуйте ці фрази для чіткого спілкування між апаратним і програмним забезпеченням.
** Обговорення поведінки на рівні реєстру: **
- “Бит активації знаходиться в регістрі 0x3C, зсув 4. Запис 1 до цього біта починає перетворення.»
- «Ми повинні переконатися, що GPIO налаштований як вивід перед викликом функції ініціалізації.»
** Опис обмежень часу: **
- «Чіп вимагає мінімум 10 мкс між твердженням про вибір чипа і першим кроком такта»
- «ISR має завершитися до наступного таймера, який запускає кожну 1 мс.»
** Звітування про апаратні аномалії: **
- «Під навантаженням, ми бачимо перервані відповіді NACK на шині I2C — можливо порушення часу або проблема з резистором pull-up»
- «Показники ADC показують 50 Hz шумну компоненту, що вказує на перешкоди заземлення від джерела живлення»
Приклади слів у контексті
-
«Ми виявили, що сторожовий собака стріляв у виробництві, тому що завдання RTOS, відповідальне за його скидання, було голодним завданням з нижчим пріоритетом, яке тримало спільний мутекс нескінченно»
-
«HAL абстракція дозволила нам повторно використовувати 90% нашого коду драйвера при міграції до нового сімейства мікроконтролерів, зменшуючи зусилля з портування з приблизно трьох тижнів до двох днів»
-
“Оскільки пристрій працює через NB-IoT з обмеженим наданням даних, ми реалізували сенсорне злиття локально і тільки передаємо подію підсумку, коли злитий вихід перетинає визначений поріг - це ядро нашої стратегії обчислень краю.”
-
«Згода з MISRA C не підлягає обговоренню для цього проекту медичного пристрою; кожне відхилення вимагає документованого обґрунтування, схваленого менеджером з безпеки, перш ніж його можна буде прийняти»
-
«Процес оновлення OTA використовує двобанковий флеш-розклад: нова прошивка записується в неактивний банк, поки пристрій продовжує працювати на активному банку, а потім один атомний перемикач відбувається при наступному перезавантаженні»
Словник технічної документації
Під час написання вбудованої документації — чи то анотації до таблиці даних, специфікації вимог до програмного забезпечення, чи документа з інтерфейсу апаратного забезпечення — використовуйте точну, однозначну мову:
- Використовуйте « should » для обов’ язкових вимог, « should » для рекомендацій і « may » для необмежених вимог.
- Завжди вказувати одиниці: « 200 мкс », а не « 200 одиниць. »
- Визначте кожен акронім при першому вживанні, навіть якщо він здається очевидним — читачі з різних дисциплін будуть вам вдячні.
Вбудовані інженери, які чітко спілкуються через межі апаратно-програмного забезпечення і прошивки-застосунку, значно ефективніші, ніж технічно блискучі інженери, які не можуть сформулювати свої обмеження. Інвестуйте в цей словник, і він принесе дивіденди протягом вашої кар’єри.
Розвиток мовлення: проблеми та перспективи
Як не-рідні носії занурюються в специфічну термінологію вбудованого розвитку - від складнощів RTOS планування до точної мови, необхідної для документування прошивки - це неймовірно поширене зустріти тонкі, але значні відмінності в тому, як концепції передаються. Це не просто про те, щоб знати * що * термін означає; це про розуміння * як * він зазвичай використовується в професійному контексті, особливо при співпраці з досвідченими колегами. Це часто включає інтерпретацію тону і прихованого значення разом з буквальним визначенням.
Однією з найчастіших перешкод є очікування високоточної і детальної комунікації. У розробці програмного забезпечення загалом, але особливо в системах, що мають критичне значення для безпеки, таких як вбудоване мікропрограмне забезпечення, неоднозначність просто не терпиться. Здається простим запит - “виправити цю помилку” - може бути інтерпретовано дуже по-різному в залежності від контексту. Це критична проблема блокування? Потребуется полный анализ причины, или просто простой латок? Аналогічно, зворотній зв’ язок під час перегляду коду рідко надається з ніжним заохоченням; замість цього, ви часто побачите такі фрази, як « Ця функція може бути загрозою для інших функцій » або « Розгляньте можливість використання mutexa для синхронізації доступу ». Ключовим тут є не лише розуміння * проблеми *, але й усвідомлення того, що переглядач повідомляє про серйозну занепокоєність щодо стабільності системи і потенційно небезпечної поведінки. Крім того, навчання, як чітко формулювати свої власні запити - визначаючи очікувану поведінку, бажані результати і будь-які відповідні обмеження - значно зменшує непорозуміння. Неправильно сформулований запит може призвести до марних зусиль і значних затримок.
Іншою областю, де виникають нюанси комунікації, є опис стану Pull Request (PR). Замість того, щоб просто сказати «Я оновив код», ви можете побачити: «PR #1234 - Реалізований драйвер UART з початковими перевірками відповідності MISRA C. Потрібні подальші тестування, щоб забезпечити повну сумісність з існуючим периферійним стеком. “Детальність не тільки про те, що змінилося; це про повідомлення про обсяг, рівень зусиль, які все ще потрібні, і явне позначення потенційних проблемних областей (сумісність з MISRA) - сигналізація про те, що необхідна подальша перевірка. Цей активний підхід демонструє професіоналізм і допомагає рецензентам зрозуміти контекст їх оцінки.
Нарешті, пам’ятайте про використання технічного жаргону в каналах комунікації команди, таких як Slack або Microsoft Teams. Хоча скорочення є звичайними (« BR » для « звіт про помилку »), краще помилятися на стороні ясності, особливо коли ви вперше приєднуєтесь до проекту. Не вагайтеся ввічливо попросити про пояснення, якщо ви не впевнені в чомусь - це набагато краще визнати плутанину, ніж продовжувати на основі неправильного припущення.
# Example: Checking for MISRA violations using `cppcheck`
cppcheck --enable=all your_firmware.c
Ця команда демонструє спільний робочий процес - використання інструментів статичного аналізу, таких як cppcheck, для автоматичного виявлення потенційних порушень стандарту кодування, особливо в контексті наборів правил MISRA C. Вивід програми надає вам докладний звіт, у якому буде виділено певні рядки коду, які не відповідають визначеним стандартам, що полегшить вам виконання цільових заходів з виправлення помилок і покращить загальну якість коду.