«Вбудоване ПЗ неможливо тестувати unit-тестами, для цього потрібна апаратна частина». Я чую це часто, і це правда рівно для одного виду коду: того, що торкається регістрів. Усе решта — скінченні автомати, парсери протоколів, логіка керування, перетворення значень — це звичайний C, який компілюється на вашому ПК. А на вашому ПК він виконується за мілісекунди, без налагоджувача, без кабелю і без прошивання.

Ця стаття показує, як тестувати модуль за допомогою Unity (тестовий фреймворк) і CMock (генератор моків) — від дизайну, який це уможливлює, до файлу CMake, що все збирає. Усе було зібрано й запущено, а вивід нижче справжній.

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

У C немає private, просторів імен і пакетів. Щойно код розділено на файли, файли та система збірки — єдині інструменти, які в нас є, щоб сказати, що належить разом, що є публічним, а що нікого більше не стосується. Тож організація файлів — це не питання смаку, а частина дизайну. Ця стаття описує, як я організовую вбудований проєкт на трьох рівнях: проєкт, модуль і окремий файл.

Скажіть «MISRA» у кімнаті, повній embedded-розробників, і половина зітхне, а друга половина запитає, яким інструментом ви користуєтеся. Репутація цих правил неоднозначна: для одних це бюрократія, що з'їдає тиждень перед кожним релізом, для інших — причина, чому автомобіль не перезавантажується посеред траси. Обидві групи частково мають рацію.

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

П'ять літер, які, здається, є на кожній співбесіді з розробки програмного забезпечення. S, O, L, I та D. Принципи описано для об'єктно-орієнтованих мов, тож поширений висновок такий: «SOLID - для C++ та Java, ми пишемо на C, отже, нас це не стосується». Цей висновок хибний, і я спробую показати чому. Для кожного принципу ви знайдете оригінальну ідею з прикладом на C++, а потім ту саму ідею на C, без класів, без наслідування і без жодного virtual.

OCD. Три чудові літери, які змушують мене постійно думати про архітектуру програмного забезпечення. Це може бути справді болісно, особливо коли доводиться мати справу з архітектурою в стилі «Arduino». Ви напевно її знаєте: весь проєкт у кількох папках, застосунок у папці src, низькорівнева функціональність у папці driver і так далі. Але що робити в складних системах?

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