[Jhohn 0]

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

 

В моей орг. сейчас создается концепция протокола. Один вариант адресный протокол: программист дает на "верх" адреса. То есть по протоколу приходят адреса. Внутри контроллера не проверяется валидность пришедших данных (каждого параметра).

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

[Паф 0]

1) В мк параметры проверяем на равенство 0XFF (0xFFFF и т.п.) - дефолтное значение чистого EEPROM/FLASH. В зависимости от логики можно записать дефолтные параметры, заданные отдельно в памяти программы.

2) ПО верхнего уровня пишет конфигурационные данные по протоколу с проверкой CRC. Плюс считывает статус записи в устройство.

3) Устройства проходят калибровку и верификацию. С неправильными параметрами они отбракуются.

4) Error handling устройства построен с большим количеством проверок промежуточных и конечных вычислений.

---

Как то так в упрощенном виде. Вообще на вкус и цвет...

[zhevak 0]

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

 

1.

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

 

* по каждой переменной, например, переменная (параметр, установка, уставка и т.д.) укладывается в допустимые пределы.

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

 

* так и на предмет того, что переменные, находясь каждая в своем диапазоне допустимых значениях, в совокупности тоже не нарушают какие-то правила.

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

 

 

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

 

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

 

3. Определитесь с тем, откуда ожидаете "приход помехи". Я имею ввиду -- это будет человеческий фактор:

3.1. Оператор, конечный пользователь ввел не то значение

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

 

либо это будет аппартный сбой:

3.3. На вход поступили данные, которые явно не укладываются в заданные рамки. (Например, измеряем напряжение и ожидаем получить от 0 и максимум до +5.5 В, а придурок Вася сунул наш вольтметр в розетку. Ничего не сдохло, но на вход АЦП пришли та-а-акие данные, что непонятно что с ними дальше делать.)

3.4. Через МК прошла космическая частица с высокой энергией и изменила ячейку в памяти. Данные исказились.

 

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

 

В первом случае, проверка нужна обязательно. Нужно производить проверки при каждом вводе пользователя.

Во втором случае, нужно тоже производить всяческие проверки. Но когда отработка программы закончится, то в release-версии нужно удалить все проверки.

Третий случай -- тут проверка нужна обязательно. Причем только в этом месте (бороться с помехой в месте ее возникновения).

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

 

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

 

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

 

[zombi 0]

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

 

Надеяться на то что кто-то там правильно все проверит ?!

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

 

"Не верь никому и никто тебя не обманет" - это мой принцип.

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

[Jhohn 0]

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

 

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

 

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

 

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