програмування мікроконтролерів проти об'єктно-орієнтованого програмування

Я зробив декілька базових об'єктно-орієнтованих програмувань за допомогою C ++ (створення B-дерева, алгоритмів хешингу, подвійних зв'язаних списків) і зробив невеликий проект на C (наприклад, виготовлення наукового калькулятора тощо)

Наскільки відрізняється апаратне програмування (спеціально для мікроконтролерів) від програмно-об’єктно-орієнтованого програмування з точки зору мислення та «мислення», яке повинен мати програміст?

Чи вважають одного, як правило, важчим за інших моїх людей?

З моїм досвідом (як описано вище) мені знадобиться велика підготовка до того, щоб перейти до апаратного програмування, чи можу я зануритися прямо без зайвої підготовки?

Вам доведеться повністю відмовитися від об'єктно-орієнтованої парадигми, коли маєте справу з більшістю мікроконтролерів.

Мікроконтролери, як правило, обмежені реєстрацією та оперативною пам'яттю, з повільною тактовою частотою та відсутністю конвеєрних / паралельних кодових шляхів. Наприклад, ви можете забути про Java на ПОС.

Вам належить увійти в режим складання мов асемблерної мови та писати процедурно.

Ви повинні тримати код порівняно рівним та уникати рекурсії, оскільки обмеження оперативної пам’яті часто можуть призвести до проблем із стеком.

Ви повинні навчитися писати ефективні процедури переривання обслуговування (як правило, мовою складання).

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

Ви повинні написати математичний код, який враховує розмір слова та відсутність можливостей FPU більшості мікроконтролерів (тобто робити 32-розрядне множення на 8-бітне мікро = зло).

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

Вам потрібно продумати кілька речей:

• Ви будете використовувати С як мову
• Ви все ще можете створити відчуття орієнтації на об'єкт, використовуючи функціональні покажчики, щоб ви могли переосмислити функції тощо. Я використовував цей метод у минулих та поточних проектах і працює дуже добре. Таким чином, ОО частково є, але не в сенсі С ++.

Існують і інші обмеження, які будуть грати, такі як обмежена швидкість та пам'ять. Отже, як загальне керівництво, я уникаю:

• Використовуючи купу, якщо є спосіб вирішити проблему без Маллока, я це роблю. Наприклад, я попередньо виділяю буфери і просто використовую їх.
• Я навмисно зменшую розмір стека в налаштуваннях компілятора, щоб стикатися з проблемами розміру стека на початку, оптимізую це.
• Я припускаю, що кожен рядок коду буде перерваний подією, тому я уникаю невідповідного коду
• Я припускаю, що навіть переривання вкладені, тому я відповідно пишу цей код
• Я уникаю використання ОС, якщо це не потрібно. 70% вбудованих проектів насправді не потребує ОС. Якщо я повинен використовувати ОС, я використовую лише те, що є вихідним кодом. (Freertos тощо)
• якщо я використовую ОС, я майже завжди абстрагую речі, щоб я міг змінити ОС за лічені години.
• Для драйверів і т. Д. Я буду використовувати лише бібліотеки, надані постачальником, я ніколи не прямую біти, якщо у мене немає іншого вибору. Це робить код читабельним і покращує налагодження.
• Я переглядаю петлі та інші речі, особливо в ISR, щоб переконатися, що вони досить швидкі.
• Я завжди тримаю під рукою кілька GPIO для вимірювання матеріалів, переключення контексту, часу виконання ISR тощо.

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

Я роблю і те, і інше, тому ось мій погляд.

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

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

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

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

Набагато важливіше бути дуже обізнаним, які саме ресурси у вас є щодо ПК. Уважно прочитайте таблиці. Поміркуйте, що ресурс "коштує" всього, що ви намагаєтесь зробити. Вивчіть налагодження налагодження, орієнтовані на ресурси, як наповнення простору стеку магічним значенням для відстеження використання стека.

Хоча деяка ступінь навичок налагодження потрібна як для ПК, так і для вбудованого програмного забезпечення, це набагато важливіше з вбудованим.

Я припускаю, що ваш C ++ досвід базується на ПК.

Часто помилка програмістів, переходячи від ПК до мікроконтролера, полягає в тому, що вони не усвідомлюють, наскільки обмеженими можуть бути ресурси . На ПК ніхто не зупинить вас, коли ви створите таблицю зі 100 000 записів або напишіть програму, яка складається в 1 Мб машинного коду.
Там є мікроконтролери , які мають величезну кількість ресурсів пам'яті, особливо в високому кінці, але це ще далеко від того, що ви звикли. Для хобі-проекту ви, мабуть, завжди можете досягти максимуму, але в професійному проекті вас часто змусять працювати з меншим пристроєм, оскільки він дешевший .
Над одним проектом я працював з TI MSP430F1101. 1 Кб пам'яті програми, 128 байт конфігурації Flash, 128 байт оперативної пам'яті. Програма не вписувалася в 1К, тому мені довелося записати 23-байтну функцію в конфігурації Flash. За допомогою цих невеликих контролерів ви обчислюєте байт . Іншим разом пам'ять програми була на 4 байти занадто маленькою. Бос не дозволив мені використовувати контролер з більшою кількістю пам’яті, але натомість мені довелося оптимізувати вже оптимізований машинний код (він уже був написаний в асемблері), щоб вмістити додаткові 4 байти. Ви отримуєте зображення.

Залежно від платформи, над якою ви працюєте, вам доведеться мати справу з дуже низьким рівнем вводу / виводу . У деяких середовищах розробки є функції запису на РК-дисплей, але в інших ви самостійно, і вам доведеться зчитувати таблицю даних ЖК-дисплея від початку до кінця, щоб знати, як керувати ним.
Можливо, вам доведеться керувати реле, це простіше, ніж РК-дисплеєм, але це вимагатиме переходу на рівень регістра мікроконтролера. Знову таблицю даних чи посібник користувача. Вам потрібно буде ознайомитись зі структурою мікроконтролера, яку ви знайдете на блок-схемі, знову ж таки в таблиці. У часи мікропроцесора ми говорили про модель програмування, яка в основному була лінійкою регістрів процесора. Сьогоднішні мікроконтролери настільки складні, що опис усіх регістрів може містити найкращу частину аркуша на 100 сторінок. IIRC тільки опис годинникового модуля для MSP430 склав 25 сторінок.

$\mu$

Мікроконтролери часто запрограмовані в C . C ++ - це скоріше голодні ресурси, тому зазвичай немає. (Більшість реалізацій C ++ для мікроконтролерів пропонують обмежений підмножина C ++.) Як я вже говорив, залежно від платформи у вас може бути наявна широка бібліотека функцій, яка може заощадити вам досить часу на розробку. Варто витратити трохи часу, щоб вивчити це, це може заощадити вам багато часу пізніше, якщо ви знаєте, що є в наявності.

"апаратне програмування" може означати багато речей. Програмування дуже невеликого чіпа (подумайте 10F200, 512 інструкцій, кілька байт оперативної пам’яті) може бути майже схожим на проектування електронної схеми. З іншого боку, програмування великого мікроконтролера Cortex (1 Мб FLASH, 64 кБ оперативної пам’яті) може бути дуже схожим на програмування ПК / GUI, використовуючи великий інструментарій GUI. IMHO хороший програміст із вбудованим / реальним часом потребує навичок як із програмного забезпечення, так і з боку проектування схеми. Для великих uC C ++ - це хороший вибір мови, для дуже маленьких C може бути єдиним вибором. Знання зі зборів можуть бути корисними, але я б не рекомендував робити серйозні проекти цілком у зборі.

Я робив серйозну вбудовану роботу з людьми з обох сторін (SWI та EE). Я, як правило, віддаю перевагу людям SWI, за умови, що вони мають певний досвід програмування в multu-threaded.

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

Для кожного методу бібліотеки ардуїно, який ви називаєте, існує безліч код C / C ++, що дозволяє це просто упаковувати, щоб використовувати його як API. Погляньте на вихідний код ардуїно в апараті каталогу / arduino / *, і ви побачите всі написані для вас C / C ++, які взаємодіють безпосередньо з регістрами мікроконтролерів AVR. Якщо ваша мета полягає в тому, щоб навчитися писати подібні речі (безпосередньо для обладнання), то є багато чого. Якщо ваша мета полягає в тому, щоб змусити щось працювати, використовуючи їх бібліотеки, про це може не багато говорити, оскільки більшість важкої роботи робиться саме для вас, а їх бібліотеки та середовище розробки дуже прості у використанні.

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

Будьте в курсі, скільки пам'яті ви використовуєте. Як розмір коду (який йде у флеш-пам'ять), так і статичне використання ОЗУ (константи у вашому коді, які завжди будуть існувати в ОЗУ). Я заперечую, що статичне використання оперативної пам’яті є дещо важливішим, оскільки її легко переглядати. Не рідкість у вас є лише 1000 байт, з якими можна працювати для вашої стеки, купи та констант. Будьте розумні в тому, як ви їх витрачаєте, тому уникайте таких речей, як довгі масиви цілих чисел (4 байти кожен), коли байтів або неподписаних знаків (1 байт кожен) буде достатньо. Інша відповідь тут дуже добре стосується деяких інших важливих моментів, тому я зупинюсь тут, я в основному хотів зрозуміти, що є багато, що можна висвітлити, якщо ви не використовуєте бібліотеку arduino і не пишете власні бібліотеки С.

Щодо програмування мікроконтролера та OOP, вони не є чимось протилежністю. Це правда, що всі бібліотеки постачальників знаходяться в простому C, але всі платформи також підтримують C ++ OOP. Крім того, розробники можуть створювати та створювати C ++ бібліотеки високого рівня та мікропрограмне забезпечення пристроїв. Хороший приклад - бібліотеки Arduino, офіційні та побудовані користувачем - в основному це класи C ++. Можливо, не всі переваги OOP можуть бути повністю використані у вбудованому середовищі, але добре відомі переваги C ++ і C є чинними і тут.

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

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

Будьте готові прочитати багато таблиць даних при роботі з новим обладнанням - я думаю, це може бути пов’язано з питаннями "настрій мислення" :) Напевно, знадобляться деякі знання з технічного обслуговування та обладнання.

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