Разбирането на хардуерни и софтуерни грешки по примера на други вградени системи може да ви помогне да идентифицирате, диагностика и ремонт на грешки в собствената си система.
Въпреки факта, че нито една от тези грешки не са причинили сериозни щети, всички от които илюстрират интересни характеристики. В хода на повествованието, ние гледаме на някои функции на Препроцесорът С, и Аз ще дам някои предупреждения, свързани с използването на таймери.
Първата група от грешки води до промяна, която по никакъв начин не трябва да се отрази на системата, но незнайно защо това се случва. Различни възможности за оптимизация не трябва да повлияе на поведението на системата по отношение на производителност, те се отразяват само на скоростта на кода и неговата големина. Разбира се, когато системата работи в реално време, бързо започва да изпълнява определени части от код може да е сигнал за състояние, раса, но има и други фини ефекти на оптимизация, поради които може да бъдат уловени.
В един случай, аз и моите колеги са открили грешка в кода, който не беше в предишната версия. Те са учили история на промените от предишната версия на тока и стесни търсенето към този съставител опции. По-подробно код, проучването установи, че поради немарливо извършената работа ние сме станали уязвими по отношение на влиянието на оптимизация. Обява 1 показва опростена версия на това, което правим.
х = "здравей"; // hello1
Сега включете оптимизация, и промяна в поведението. Тъй като низ в hello1 и hello2 идентични, компилаторът поддържа едно копие на "здравей" и затова hello1 и hello2 се обърнат към тази позиция. В този случай, изпълнението на линии х = "здравей" и у = "здравей" води до факта, че резултатът за сравнение х и у е вярно.
Долната линия е, че ако (X == у) не е правилния тип сравнение. Винаги трябва да се използва strcmp () функция или тяхната равностойност.
Във филма "Джурасик парк", има сцена, в която героят Джеф Голдблум открива, че техния метод за проверка дали всички динозаври са налице, се брои общият брой на животните, и след като достигне определена точка, сметката се прекратява. Фактът, че броят на динозаври увеличава, не е забелязал, защото героите във филма, достигайки очаквания брой динозаври, никога не се съхраняват на полувремето. Интелигентни животни са измислили как да се възпроизвеждат, въпреки факта, че, както се твърди, всички клонирани динозаври са били жени.
Голдблум герой показва, че компютърът е търсил за по-голям брой динозаври, както и броя на животните, намерени е по-голяма от първоначалната сума, групата осъзнава, че те имат много по-големи праисторически животни от очакваното. Аз наричам тази грешка "грешка Джурасик парк". Това е грешка за определяне на горната граница на стойност, фалшива увереност, че повече няма да се срещнат или няма да има значение в събитието. Това е рационален метод, който често опростява програмирането, но тъй като тя може да има неочаквано състояние, невидим за системата.
Може ли това да е бъг в софтуера си? Ако държите на номер в променливата на 8-битов, трябва да спрете за сметка на 255. Тази стойност може да се разглежда като някаква грешка в състояние или като приближение на максималната възможна стойност на променливата в системата. Кой от тези варианти е най-добре зависи от това дали тезгяха 255 достигне състояние, повреда или нормално състояние.
Когато използваме аритметични преградни номерата на цялата и дробната част, може да бъде полезно да се ограничи стойността на тези части, така че изчисления с използване на много голям брой не водят до преливане на променливи.
Като илюстрация на "грешките Джурасик парк" ще дам един пример от моята практика. Имахме една система, която измерва притока на газ. Обикновено, системата за контрол на потока 15 л / мин. Горната граница на измерва потока, успяхме да изградим една 25 л / мин. Ние вярвахме, че дори ако дебитът на газа ще надхвърли 25 литра / минута, може да се счита за равна на тази стойност.
В някои случаи, потокът не надвишава 25 л / мин, но ние вярваме, че тези случаи могат да бъдат пренебрегнати, защото системата не е в контрола на държавата. Един такъв случай е теста, които бяха сравнени потоци открити от две идентични сензори. При условие, че сензорите функционират правилно и позволи на точни показания потоци във всеки сензор е трябвало да бъде в рамките на толерантност един към друг. Когато външното налягане в системата за доставяне на газ е много висока, изпитването може да се получи с излишък ремък 25 л / мин. Ако приемем, че калибриране на сензора е преместена, скоростта на потока се измерва от двата сензора е равна, например, 26 л / мин и 29 л / мин. И двете от тези стойности впоследствие са закръглени до 25 л / мин за причините, описани по-горе. Когато дойде време да сравните двете показания, те са били в размер на 25 л / мин, съответно, и са равни помежду си. Намирането на такава ситуация, ние сме забранили използването на сравнителен тест за дебит над 25 л / мин.
Дори и да не поставя ограничение на софтуера за разчитане, ограничения върху вашия проект може да наложи хардуер. Така например, сензор за изходното напрежение ще има горна граница за ограничаване посочване поток. Аз бих препоръчал, че винаги ще се използва сензор с по-широк кръг от очаквания диапазон от вашата система. Все пак, имайте предвид, че ще трябва да обменят широк обхват на сензора от разделителната способност на инструмента. А сензор с по-малък обхват и по-висока резолюция може да бъде по-точен, но може да се озовете в мъртва точка, където никой не може да види какво се случва.
Аз от време на време виждам "грешка Джурасик парк" в регистрите на събития. Помислете за устройство, което записва изключително събитие в дневника. Налице е ограничено пространство за съхраняване на събития, например, е създаден с 30 записи в регистъра. Всеки запис - структура, която съдържа данни за вида на събитието, време, а може би и текущите настройки на устройството. Дневникът съдържа пълните 30 събития. Въпреки това, ако има 50 събития, списанието на тяхната воля все още да е 30, така че истинският брой на събитията са скрити. В този случай, проблемът може да бъде облекчено чрез използване на крайния низ, който съдържа номера на незаписани събития. Докато този метод няма да ви помогне да се знае подробности за събитията, поне ще знаете, че нещо липсва. По време на употреба, този брояч ще ви насочи към нещо, дали стойността е вградена в по-голям обем на пространството дневник за съхранение на данни.
Има много други видове "грешки Джурасик парк". След като на няколко пъти, претърпени в резултат на тази грешка, аз съм по-малко склонни да се сложи на стойността на определен максимален размер. Аз предпочитам да се определи срок, където мога да кажа, че системата ще се провали, ако се превиши пределната стойност.
Един от моите колеги работи по шах, който се използва, за да се увери, че актуализираната копие на софтуера ни зарежда без да се повреди. Като един от етапите на тестване, той отбеляза, стойността на всяка контролна изпълнима програма. Един ден той дойде при мен и каза, че е разбрал - че това, което си мислеше, че може би е грешка компилатор. Тъй като съставител е много грешки, ние не сме много изненадани.
Поддържахме кодовия номер версия. В някои от нашите проекти, този брой се актуализира автоматично с всяка част на системата и следователно две компилации не биха били идентични. В този проект, броят се променя само когато на програмиста да редактирате ръчно файла. В този случай, тя не е била променена и не може да бъде причина за промени в шах.
Ние сме използвали поддържали () макроса. Макросът използва вграден компилатор макроса __ __ LINE, който е равен на текущия ред на компилиран файл. Ако сме се променили номерата на редовете, __ линия стойност __. използвана от всеки поддържали (), би било различно, и тези стойности се съхраняват в оригиналната програма.
Нийл Мърфи "Как да се избегнат често срещаните грешки на фърмуера"
с определени цикли от време са построени по такъв начин, че да се елиминира възможността от изходната променлива на възможния обхват.
т.е. такъв цикъл, в който променлива се променя от 0 до 10, а ние се сравни състоянието на A = 10. ако изведнъж, по някаква причина, променливата А ще отиде отвъд 10, че ние се извърши тази операция, докато неразбираем колко пъти променливите прелива и броенето започва от нулата. Ако ние проверихме състоянието на А => 10? не успее в този цикъл ще бъде по-кратък и не критичен провал, но отново зависи от конкретните условия.
Последната ситуация - много интересно и поучително случай. Всичко останало - е тривиално и е известно, дори и за учениците.