В съседната тема се повдигна въпроса за дебъгването и отварям нова тема за целта.

Системите които правя обикновено са в едночиопв вариант и обикновено всички пинове са заети, даже на пин има и по няколко периферии (шерване на пин).

Развойните средства които използвам са нискобюджетни (jtag-ове разни) и съм поставен в условия "с пръдня боя" да правя ... (Предполагам, че повечето от вас работят с подобни ограничения)

Та въпроса е как да дебъгваме устройствата си с възможност да извлечем максимално инфо какво се случва, без да се променят много таймингите на програмата, без да се използат много пинове (защото обикновено няма свободни). В моя случай живо ме интересува и моментната консуюация на устройството (не само на процесора), и дебъг инфото за активността в момента трябва да ми е "синхронно" с консумацията ... Системата е с RTOS, но и да не е- проблемите са сходни...

Малко размисли по темата:

0. Дистанционния ъпдейт трябва винаги да работи, без "ако" "ама" "само, че" и т.н.,че едно гипсиране на полето може да катурне цял бизнес.

1. След като е дистанционно е ясно, че няма как да се дебъгва, затова трябва да има железен лог - по възможност без зависимост от останалата част и хардуер - един външен флаш примерно който да се клати през някакви пинове с някакъв що годе читава структура за да не се губят съобщения. Няма нужда да се записват текстови съобщения, достатъчно е да се запише само адреса на който се е установило, че има грешка. Така се спестява адски много място за грешки а после девлопора с addr2line може да си намери къде точно е грешката - едно макросче и толкова.

2. Обработка на грешки и възстановяване на системата след грешка - колкото по просто, толкова по добре. Едно от най железните решения е рестартиране на цялото устройство при по сериозни грешки или поне на основната функционалност при по отделени възли/задачи - например gps, gprs и т.н. Това не се отнася за подистемата за логване на грешки - там е друга бира, трябва да работи винаги.

3. Forgiveness - има грешки и грешки, понякога някои грешки може само да се запишат в лог-а и да не се отработят като грешка - примерно грешка при някоя спомагателна AT команда в gprs системата.

4. Адски полезно е при грешки да се записва call stack с дълбочина 5-6 функции за да може програмиста после да разбере как се е стигнало до тази грешка (пак да повторя, достатъчно е да се записват само 4 байта с адресите на извикването на функциите - т.е. адресите за връщане от stack frame).

5. В случай на death lock на някоя нишка помага много ако се запишат call stack на всички нишки ( обикновенно са под 10 )

6. Всеки докладван запис в лог файла трябва да се взема в предвид и да се анализира защо се е получил и съответно да се отработи:
- да се оправи ако има бъг
- да се даде повече видимост т.е. да се добавят още съобщения в лог-а за да се изясни ситуацията
- да се махне генерирането на грешка ако това е нормална по време на работа да стават разни грешки - примерно CRC грешка в някоя комуникация, като тук има и няколко нюанса - в началато трябва да се логва за да може да се прецени колко често се логват такива грешки, това може да е заради някакъв друг (включително хардуерен) проблем, и като се установи, че всичко е точно от грешка да стане на предупреждение и т.н.

7. Куче на високо ниво - всички устройства трябва пишат примерно веднъж на ден едно съобщение в лог-а, че всичко е наред. И на сървъра ако някое устройство запази подозрително мълчание да му се обръща веднага внимание - т.е. това, че няма доклад за грешка може да означава и, че всичко е толкова омазано, че не може да се докладва ...

Ще опиша как работя към момента, като се надявам заедно да подобрим варианта.

В почти всички устройства имам поне по един led закачен към пин на проца. Връзвам led-а към захранванв, така че проца го пали с лог. 0.
Това ми дава възможност да използвам изхода на проца като TxD за UART.
Там, където мога конфигуриирам хардуерен уарт (ако има свободен) към този пин и сетвам най-високия баудрейт.
Където не може с хардуерер -правя софтуерно предаване на байт (със задържане на управлението и моментно забранени прекъсвания) и баудрейт няколко мегабита (1,2 или 4). Така задържането на управлението и забавянето на програмата ми е 10uS, 5uS или 2.5uS в зависимост от баудрейта. При хардуерен уарт няма такова забавяне.

Идеята е при преминаване през критични или важни точки в програмата да извеждам диагностични кодове прз уарт-а, които да чета с единия от каналите на логическия ми анализатор. С другите канали си следя останалата част от външния хардуер, а с аналоговия му канал следя моментната консумация на устройството.
Падащия фронт на стартовия бит на уарт-а ми дава инфо за момента (с много малко закъснение) в който съм минал през "критичния" участък/точка от кода, а стойността на байта ми дава инфо за самия участък.
Анализатора може да декодира уарт данните и ги виждам в хекс формат.
Така имам инфо за преминаването през 255 такива контролни точки/участаци в кода.
Допълнително ако искам да изведа някакви данни освен номера на контролната точка/участък - предавам един или няколко байта с данни след това (но не трябва да се прекалява с данните).

С условна компилация заменям функциите за управление на лед-а с празни такива в диагносичен режим. В релиз режим съответно заменям с празни - функциите за извеждане на дебъг и фото през уарт-а.

Как може да се подобри варианта и има ли по-добър?

Мислех за вариант и да логвам данните от уарта на проца в PC-то и после с някакъв "парсер" да ги процесвам... На пример в еклипса може да се направи плъгин за целта... Няма ли нещо готово такова или подобно решение?

П.П
Мислех за диагностика по време на развоя, но palavrov добавя и момента след това...

По време на разработка debug log-а го пренасочвам целия през uart - и винаги имам закачен един FTDI към компа така, че да гледам на живо как работи системата. Вече за по тънки неща клатя някое гпио около кода който ме интересува - забавянето е минимално и дава добра видимост в лог. анализатор колко често се минава през този код, колко време се остава в него и т.н. На практика винаги когато е възможно избягвам дебъгване през JTAG защото спреш ли процесора не значи, че си спрял цялата система - ако има gprs или gps те си работят самостоятелно и става една каша ... затова превантивно писане на ясен и четлив код + повечко дебъг съобщения и четене на логовете. Тънките проблеми винаги са се случвали рядко и то на полето, затова според мен е по важно да се копае в тази посока ... като ти е на бюрото можеш да правиш всичко, ама като е на другия край на страната и клиента реве на умряло дупе да ти е яко

Трейс по принцип е добре да може да се изкарва по наличните интерфейси uart/usb/ethernet според каквото е налично...

Но като скорост и удобство фабрично заложения дебъг интерфейс е най-добре. Ако иде реч за каубойските куртекси, те си имат SWO и по една жица изкарват 50-60 MHz. Всъщност зависи колко як драйвер са сложили, може и по-якичък да е при новите. А може и да е по-кекав, щото се сещам за STM-те най-слабата фамилия F1 е с най-яките драйвери...
SWO-то по принцип може да изкарва стандартен UART, но при тия скорости е супер сложно да се семплира, затова се пуска манчестер кодиране. Така данните падат 2 пъти, примерно на 40MHz излизат 20Mbit/s но се семплира много по-лесно и става независимо от самия клок. Така трейса си работи още от тръгването на проца с вътрешния RC и може динамично да сменяш клока както си искаш.
Та с две думи SWO е супер като скорост и гъвкавост и без алтернатива когато трябва да се дебъгват бързи неща, а не може да се спира. Примерно като дебъгвам етернет просто пускам трейса на пакетите на lwIP от моята страна и wireshark от другата и всичко става ясно...
Определено като скорост няма грижи и изобщо не товари и забавя проца. По-скоро проблем е използването на памет, защото като се сложат много трейсoве с printf и това може да яде стек. Това ни беше голям проблем на нас и за целта се наложи да напиша вариант на sprintf, който не използва буфери.
В случай че трейс интерфейса е бавен (като uart) тогава е добре да има памет, за да може да се буферира. Защото по принцип през повечето време почти няма какво да се трейсва, после изведнъж става твърде напечено и ако е uart без буфер най-интересното обикновено се губи...