You are currently viewing Автоматизація робіт з прошивки програмним забезпеченням готових пристроїв у оточенні NodeMCU з Lua
Lua NodeMCU

Автоматизація робіт з прошивки програмним забезпеченням готових пристроїв у оточенні NodeMCU з Lua

Чи доводилося шановним читачам прошивали 20 однакових пристроїв? Причому, спочатку спеціально підготовленою прошивкою, а потім ще і програмним забезпеченням?

Ми нещодавно прошивали готові до продажу пристрої і можемо поділитися своїм досвідом.

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

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

Поглянемо докладніше на звичайний процес (з наскоку)

  1. Встановити модуль ESP8266-12 у програматор.
  2. Прошити двійкову прошивку NodeMCU/Lua за допомогою PyFlasher.
  3. Після перезапуску ESP8266 дочекатися у Lua Loader (саме ця термінальна програма нами використовується), доки завершиться процес форматування внутрішньої флеш-пам’яті після процедури прошивки.
  4. Завантажити по одному через UART вихідні Lua-файли (всього у нас 10 таких файлів).
  5. По черзі компілюємо кожен файл, крім файлу init.lua. На етапі компіляції таокж з’ясовуємо, що файли не містять помилок, які здатен виявити компілятор.

Примітка 1. Скомпілювати файли можливо лише у середовищі контролера. Інакше, потрібно будувати крос-компілятор, а це задача не проста. Цитата: “…the NodeMCU compiler output uses different data types (e.g. it supports ROMtables) so the compiled output from standard luac cannot run on the ESP8266.” Тут можливо прочитати деталі: https://nodemcu.readthedocs.io/en/release/compiling/

Примітка 2. Існує також альтернативний шлях: виконати всю компіляцію один раз у контролері, а потім завантажити фінальні двійкові lc-файли на ПК. І вже потім тиражувати їх, завантажуючи на всі інші контролери. Це найефективніший підхід, але з різних причин, ми ним не змогли ним скористатися цього разу. В основному, через необхідність індивідуалізації програмного коду на кожному контролері з партії у 20 штук. Тому ми не могли взяти двійковий код і записати його однаковим у двадцять пристроїв. Невеликі індивідуальні зміни теж займають час, але ми їх опускаємо тут, адже вони однакові за будь-якого способу заливки ПЗ.

  1. Оскільки у цьому прикладі йдеться про готовий комерційний продукт із закритим вихідним кодом, після процедури компіляції, нам потрібно видалити всі зайві файли з кожного контролера. Тобто, щонайменше 9 lua-файлів (-1 init.lua). Оскільки ми робили це з наскоку, то все реалізувалося щоразу шляхом виводу переліку файлів у консоль і видалення всіх зайвих по-одному за раз. Це було дуже довго і ризиковано, адже людина схильна робити елементарні механічні помилки: видалив не той файл і маєш епік фейл!
  2. Перевірити, чи прошитий контролер працює на всю глибину програмного коду. Тобто перевірити, що код запускається – абсолютно недостатньо, адже потрібно також перевірити, чи вся структура файлів програми на місці і якісно читається з флеш і правильно запускається.

Примітка 3. за весь час роботи з контролерами ESP8266, було лише декілька збоїв запису у флеш. Ця помилка дуже добре відслідковується на етапі компіляції lua-коду. Якщо node.compile() знаходить незрозумілі помилки у коді протягом компіляції, зверніть увагу на lua-файл, можливо він “криво” записався і читається з помилками. Нам допомагає видалення файлу і повторний запис з компіляцією. Компіляція починає відпрацьовувати вірно.

Примітка 4. З останньої партії у 100 модулів ESP8266-12, ми виявили лише один бракований контролер виробництва AI-Thinker, у якому взагалі не працює флеш-пам’ять (процесор працює і виходить на помилку, бо не може отримати доступ до флеш). 1% браку для заводу це не мало, але при вартості у контролера у 80-150 грн, це не такі вже великі втрати і ризики для нас. Як буде час, спробуємо зазирнути під кришечку і з’ясувати в чому там проблема.

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

По часу, без урахування перерви на сон та з перервами на каву, підготовка контролера і базове його тестування 10 контролерів на стенді зайняло десь 24 години (два дні).

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

Естімейт для режиму з наскоку:

1 крок Програматор – 3 хв
2 крок Прошивка – 7 хв
3 крок Форматування – 5 хв
4 крок Завантаження – 10 х 3 = 30 хв
5 крок Компіляція – 1 х 9 = 9 хв
6 крок Видалення – 2 х 9 = 18 хв
7 крок Перевірка – 10 хв

—-

Разом: 82 хв, або майже 14 годин на десять контролерів.

Мабуть, ми п’ємо забагато кави, бо у нас це реально забрало два дні життя 🙂

І от саме за кавою, вже прошивши 10 з 20 контролерів, ми усвідомили, що так далі не піде і потрібно терміново щось змінювати у цій виснажливій процедурі на краще.

Поглянемо, як виглядає частково автоматизований процес:

Дякуючи розробнику заточеної на NodeMCU / Lua, термінальної програми Lua Loader, ми змогли значно скоротити етап завантаження вихідних файлів у контролер (крок 4). У Lua Loader як виявилося, є дуже зручна можливість – завантажити у контролер всі файли з поточної робочої папки. Таким чином, ми отримали пакетне завантаження всіх потрібних файлів.

Також ми написали ще один, службовий lua-скрипт, який автоматизував процедуру компіляції (крок 5) всіх потрібних файлів та видалення (крок 6) після компіляції всіх зайвих файлів. Файлів у папці стало 11.

Естімейт для напівавтоматичного режиму:

  1. крок. Програматор – 3 хв
  2. крок. Прошивка – 7 хв
  3. крок. Форматування – 5 хв
  4. крок. Завантаження – 11 х 1 = 11 хв
  5. крок. Компіляція – 0.1 х 10 = 1 хв
  6. крок. Видалення – 0.1 х 10 = 1 хв
  7. крок. Перевірка – 10 хв

—-

Разом: 28 хв, або майже 5 годин на десять контролерів.

Висновки

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

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

Бажаємо успіхів!