Чому printf () поганий для налагодження вбудованих систем?

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

Я можу зрозуміти, що у вас немає заздалегідь заданого місця для виходу і що воно може споживати цінні шпильки. У той же час я бачив, як люди споживають штифт UART TX для виводу на термінал IDE за допомогою спеціального користуванняDEBUG_PRINT() макросу.

Я можу створити кілька недоліків використання printf (). Майте на увазі, що "вбудована система" може варіюватися від чогось, що має кілька сотень байтів програмної пам'яті, до повномасштабної системи, керованої на стійці до QNX, керованої RTOS, з гігабайтами оперативної пам’яті та терабайтами енергонезалежної пам’яті.

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

• Це не легка функція у всіх контекстах. Це може бути великою справою, якщо у вас є мікроконтролер, що має лише кілька K пам'яті, тому що з'єднання в printf може з'їсти 4K самостійно. Якщо у вас мікроконтролер 32K або 256K, це, мабуть, не проблема, не кажучи вже про наявність у вас великої вбудованої системи.

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

• Це досить марно для роботи з чутливими до часу речами. Вам буде краще з логічним аналізатором, осцилографом або аналізатором протоколів, або навіть тренажером.

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

Що це добре - це швидкий спосіб вивести дані заздалегідь заздалегідь, що кожен програміст на C знає, як використовувати - нульову криву навчання. Якщо вам потрібно виплюнути матрицю для фільтра Kalman, на якому ви налагоджуєте, можливо, було б добре виплюнути його у форматі, який міг би прочитати MATLAB. Безумовно, краще, ніж дивитись на місця RAM по черзі у відладчику чи емуляторі .

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

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

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

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

Є дві основні проблеми, з якими ви зіткнетеся на спробі використання printfмікроконтролера.

По-перше, це може бути болем, щоб передати висновок у потрібний порт. Не завжди. Але деякі платформи складніше, ніж інші. Деякі файли конфігурації можуть бути слабо задокументовані, і може знадобитися багато експериментів.

Друге - це пам'ять. Повна роздута printfбібліотека може бути ВЕЛИКОЮ. Іноді вам не потрібні всі специфікатори формату, хоча і спеціалізовані версії можуть бути доступні. Наприклад, stdio.h наданий AVR містить три різних printfрозміри та функціональні можливості.

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

У мене був екземпляр, коли не було бібліотеки, і я мав мінімальну пам'ять. Тож у мене не було іншого вибору, як використовувати користувацький макрос. Але використання printfчи ні - це дійсно одне з тих, що відповідатиме вашим вимогам.

Щоб додати те, що говорив Спехро Пефхані про "чутливі до часу речі": давайте для прикладу. Скажімо, у вас є гіроскоп, з якого ваша вбудована система проводить 1000 вимірювань в секунду. Ви хочете налагодити ці вимірювання, тому їх потрібно роздрукувати. Проблема: виведення їх з друку призводить до того, що система занадто зайнята для зчитування 1000 вимірювань в секунду, що призводить до переповнення буфера гіроскопа, що призводить до зчитування (та друку) пошкоджених даних. Отож, надрукувавши дані, ви пошкодили ці дані, змусивши вас подумати, що існує помилка в читанні даних, коли, можливо, насправді їх немає. Так званий heisenbug.

Більшою причиною не налагодження в printf () є те, що він зазвичай неефективний, неадекватний та непотрібний.

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

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

Не потрібно: Багато мікроконтролерів можна віддалено налагодити. JTAG або власні протоколи можна використовувати для паузи процесора, зазирнути до регістрів і оперативної пам'яті і навіть змінити стан працюючого процесора без необхідності перекомпілювати. Ось чому налагоджувачі, як правило, є кращим способом налагодження, ніж друковані висловлювання, навіть на ПК з тоннами місця та потужності.

Прикро, що найпоширеніша платформа мікроконтролерів для новачків, Arduino, не має налагоджувача. AVR підтримує віддалену налагодження, але протокол debugWIRE Atmel є власницьким та недокументованим. Ви можете використовувати офіційну платформу розробників для налагодження з GDB, але якщо у вас є, ви, ймовірно, вже не надто переживаєте за Arduino.

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

Навіть якщо хочеться виплюнути дані на якусь форму консолі журналу, printfфункція, як правило, не дуже вдалий спосіб зробити це, оскільки їй потрібно вивчити рядок переданого формату та проаналізувати його під час виконання; навіть якщо код ніколи не використовує будь-якого специфікатора формату, окрім іншого %04X, контролеру, як правило, потрібно буде включити весь код, необхідний для розбору рядків довільного формату. Залежно від того, який саме контролер використовується, може бути набагато ефективніше використовувати код на кшталт:

void log_string(const char *st)
{
  int ch;
  do
  {
    ch = *st++;
    if (ch==0) break;
    log_char(ch);
  } while(1);
}
void log_hexdigit(unsigned char d)
{
  d&=15;
  if (d > 9) d+=7;
  log_char(d+'0');
}
void log_hexbyte(unsigned char b)
{ log_hexdigit(b >> 4); log_hexdigit(b); }
void log_hexi16(uint16_t s)
{ log_hexbyte(s >> 8); log_hexbyte(s); }
void log_hexi32(uint32_t i)
{ log_hexbyte(i >> 24); log_hexbyte(i >> 16); log_hexbyte(i >> 8); log_hexbyte(i); }
void log_hexi32p(uint32_t *p) // On a platform where pointers are less than 32 bits
{ log_hexi32(*p); }

На деяких мікроконтролерах PIC, log_hexi32(l)швидше за все, візьмуть 9 інструкцій, а можуть взяти 17 (якщо lє у другому банку), тоді як log_hexi32p(&l)би взяли 2. log_hexi32pСаму функцію можна було б записати приблизно 14 інструкцій, тож вона заплатила б себе, якщо дзвонить двічі .

Один момент, який жодна з інших відповідей не згадала: У базовому мікро (IE є лише головний цикл () і, можливо, пара запущених ISR в будь-який час, а не багатопотокова ОС), якщо він руйнується / зупиняється / отримує застрягши в циклі, ваша функція друку просто не відбудеться .

Крім того, люди сказали, що "не використовуйте printf" або "stdio.h займає багато місця", але не дається багато альтернативи - embedded.kyle згадує про спрощені альтернативи, і саме це ви, мабуть, повинні бути як звичайно, на базовій вбудованій системі. Основним розпорядником стискання декількох символів з UART може бути кілька байтів коду.