Как вы думаете, нужно ли проверять конфигурационные данные в устройстве? Мне кажется, что нет. Я думаю можно сделать файл который, допустим, я даю программисту "верхнего" уровня (программисту конфигуратора) и он перед отправной проверяет не вылез ли он там куда-нидь не туда и т.п. Это я так думаю.

В моей орг. сейчас создается концепция протокола. Один вариант адресный протокол: программист дает на "верх" адреса. То есть по протоколу приходят адреса. Внутри контроллера не проверяется валидность пришедших данных (каждого параметра).
Второй протокол: параметры в микроконтроллере сформированы в структуры, и необходимо проверять пришедшие данные структуры на валидность, помимо этого приходят команды. В МК создается таблица вида: соответствия команды и адреса структуры, в таблице так же содержится: количество параметров, типы данных: целое или строковое, параметр только для чтения. Каждый параметр предполагается проверять. Конфигуратор пишет наша контора. Лично мне и другим программистам микроконтроллеров второй вариант представляется диким. И тем не менее, что Вы думаете по этому поводу? (прошу писать тех у кого устройства выходят тыс. партиями)

1) В мк параметры проверяем на равенство 0XFF (0xFFFF и т.п.) - дефолтное значение чистого EEPROM/FLASH. В зависимости от логики можно записать дефолтные параметры, заданные отдельно в памяти программы.
2) ПО верхнего уровня пишет конфигурационные данные по протоколу с проверкой CRC. Плюс считывает статус записи в устройство.
3) Устройства проходят калибровку и верификацию. С неправильными параметрами они отбракуются.
4) Error handling устройства построен с большим количеством проверок промежуточных и конечных вычислений.
---
Как то так в упрощенном виде. Вообще на вкус и цвет...

Вопрос до конца не ясен. Вы слишком мало дали информации по проблеме. Тем не менее я попробую поддержать дискуссию.

1.
Проверка данных может производится как:

* по каждой переменной, например, переменная (параметр, установка, уставка и т.д.) укладывается в допустимые пределы.
(Пример из электроники -- допустимый ток коллектора транзистора не может превышать 10А).

* так и на предмет того, что переменные, находясь каждая в своем диапазоне допустимых значениях, в совокупности тоже не нарушают какие-то правила.
(Пример из электроники, Ток коллектора транзистора не превышает 10А, напряжение на коллекторе -- тоже не превышает заданных 60В. Но в совокупности эти два параметра задают рассеиваемую на коллекторе мощность (10А * 60В = 600Вт), которая превышает допустимую мощность транзистора (100Вт))


2. Опять же из радиотехники. Произвольный или непроизвольный выход параметра за допустимые пределы -- это, в некоторой степени можно считать, что параметр подвергся искажению какой-то помехой. Так вот, согласно радиотехническому правилу, бороться с помехами надо в местах их возникновения, а не по всему свету, где их можно принять. Так будет и легче и дешевле.

В контексте вашей проблемы это следует понимать так -- проверять валидность параметров нужно там, где они могут измениться, а не размазывать их проверку по всей программе.

3. Определитесь с тем, откуда ожидаете "приход помехи". Я имею ввиду -- это будет человеческий фактор:
3.1. Оператор, конечный пользователь ввел не то значение
3.2. Программист-разработчик ошибся при инициализации переменной или написал бажный код, который вычисляет параметр не правильно.

либо это будет аппартный сбой:
3.3. На вход поступили данные, которые явно не укладываются в заданные рамки. (Например, измеряем напряжение и ожидаем получить от 0 и максимум до +5.5 В, а придурок Вася сунул наш вольтметр в розетку. Ничего не сдохло, но на вход АЦП пришли та-а-акие данные, что непонятно что с ними дальше делать.)
3.4. Через МК прошла космическая частица с высокой энергией и изменила ячейку в памяти. Данные исказились.

Рассмотрим по порядку:

В первом случае, проверка нужна обязательно. Нужно производить проверки при каждом вводе пользователя.
Во втором случае, нужно тоже производить всяческие проверки. Но когда отработка программы закончится, то в release-версии нужно удалить все проверки.
Третий случай -- тут проверка нужна обязательно. Причем только в этом месте (бороться с помехой в месте ее возникновения).
Четвертый случай особый. Тут одной проверкой не обойтись. Дело в том, что частица может прошить не только ячейку памяти с параметром, но она может пройти через ячейку памяти, где записаны границы допустимых значений параметра. Тогда получится, что при правильных данных, система будет работать не правильно. Значит нужно делать не просто проверку, а делать дублирующую систему.

В своих изделиях я руководствуюсь изложенными выше принципами. Но это совсем необязательно, что я поступаю только так, а не иначе. Жизнь очень сложная, и заранее сказать что и как правильно следует делать -- очень сложно. Чтобы советовать что-то дельное, нужно "быть в теме". Форумными наскоками большую сложную проблему вряд-ли можно устранить.

В любом случае -- удачи Вам!

Надеяться на то что кто-то там правильно все проверит ?!
Дать кому-то возможность путем передачи заведомо не правильных данных влиять на работоспособность изделия ?!

"Не верь никому и никто тебя не обманет" - это мой принцип.
Поэтому я проверяю все,везде,всегда и чем больше тем лучше, а если присутствует человеческий фактор вопрос о необходимости проверки даже не возникает.

Спасибо всем, и в особенности zhevak

3.2. Программист-разработчик ошибся при инициализации переменной или написал важный код, который вычисляет параметр не правильно.

Это я имел ввиду под проверкой данных в МК.

Ответ получил, спасибо.