Чи слід завжди визначати всі пастки?


18

Зараз я бачив два випадки із dsPIC 30F4013, коли контролер скидався через невизначену пастку. Чому ці пастки піднімалися в першу чергу, досі залишається загадкою, але це не моє найближче питання. Я починаю вважати, що було б гарною практикою програмування завжди визначати всі пастки, навіть якщо пастки ніколи не виникатимуть, тому я отримую принаймні чітке повідомлення про помилку замість випадкового скидання. Це стандартна практика, про яку я не знаю? Чи є недоліки в цій практиці, які я повинен врахувати?


4
Не відповідь на ваше запитання, але я відчував такі симптоми в системах dsPIC & PIC24 трохи раніше. У моєму випадку пастки з'явилися в результаті бітів коду, де я відніс покажчики 16-бітових значень, і самі ці вказівники мали непарні (не парні) значення, оскільки вони вказували на круговий буфер comms - і у мене не було попереднього спосіб дізнатися, чи розпочнеться 16-бітове значення на непарній чи навіть межі. Компілятор XC16 не захищає вас від апаратних зависань тут. Я закінчив писати макрос обгортки для цих функцій, який примушував 2 8-бітових покажчиків де-реф.
брхани

Відповіді:


13

Моє неформальне правило:

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

Хоча навіть без цього правила, аркуш даних чітко відповідає на ваше запитання:

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

( Джерело , розділ 8.3, перша примітка)

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


Так. У мене є стандартний модуль з цілями для всіх пасток.
Олін Латроп

16

Так, це гарна ідея - єдиний недолік - це трохи зайвий розмір коду, і вам потрібно вирішити, що робити з пасткою (випромінювати повідомлення на послідовний порт? Увімкнути світло "FAILED"? Мовчазно перезавантажити? Тощо) )


4
Зазвичай у мене просто працює процесор у нескінченному циклі NOP / GOTO. Таким чином стек не був зіпсований із пастки, і при налагодженні я маю шанс розгадати його та зрозуміти, що сталося. Я не отримую пасток часто, але 80% часу це пастка для непарних адрес, як правило, тому, що сміття завантажується як вказівник. Іноді вказівник стека псується та створює пастки непарної адреси. Їх важче налагодити, оскільки стека вже немає. На щастя, це справді рідко.
Олін Латроп
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.