Телесистемы
 Разработка, производство и продажа радиоэлектронной аппаратуры
На главную   | Карта сайта | Пишите нам | В избранное
Требуется программист в Зеленограде
- обработка данных с датчиков; ColdFire; 40 тыс.
e-mail:jobsmp@pochta.ru

Телесистемы | Электроника | Конференция «Микроконтроллеры и их применение»

Как по мне, то "помехоустойчивое ПРОГРАММИРОВАНИЕ" это нонсенс.

Отправлено Vit 20 июля 2008 г. 14:14
В ответ на: Помеха это бага? Почитайте например вот первое что нашол. Раздел 9. Реинициализация отправлено <font color=gray>VasilyS</font> 20 июля 2008 г. 12:33

Методики по ссылке более параноидальные, чем имеют теоретическое и практическое обоснование, но это дело их применяющих. Я не о способах (хотя по мне они ВСЕ спорны), а о посыле. Если в данных условиях (наличии неких помех) позволительно разрушаться содержимому неких областей ПАМЯТИ, то можно бороться за восстановление содержимого памяти (и известно как), но не устройства восстановления, если тем более оно выполнено по той же технологии, что и сами ячейки памяти и находится в тех же условиях. Внешние же сигналы (не какие-то помехи) имеют свои характеристики и либо эти характеристики учитываются, либо нет. Т.е. если разделить методы борьбы с разрушением данных (или программы - ведь не всегда всё из ПЗУ, да и его каким-нибудь способом можно тоже подпортить) и методы обработки входных сигналов, подверженных воздействию помех, то это уже как-то подлежит оценке. А определённые оценки могут приводить к определенному появлению сигналов ошибок (для которых даже кто-то придумал stderr). Вот только если всё может поломаться, то никакое программирование не спасёт. Кратковременные случаи тотального разрушения ОЗУ/регистров при воздействии, например, некоего мощного внешнего э-м излучения с некоторой вероятностью отлавливаются работой сторожа, а вот работа в условиях, например, плохой разводки, останавливающегося кварца, "плохооткрытых" оптопар, подключенных без триггера Шмитта, несогласованных линий синхронных интерфейсов и т.п. это случаи, с которыми нужно бороться не программированием.
Я уже как-то рассказывал, как сознательно заложил ошибочно большие резисторы в подтяжку I2C, надеясь на некоторое общее снижение потребления девайса, о чём спокойненько предупредил программера. В результате вместо того, чтобы мен сообщить о некорректной работе шины, эту шину тупо задалбывали многократным чтением и мажорированием. В результате потребление было дохрена больше и надёжность конкретно ниже, а после того как обнаружилось, посыпались рассуждения о том, что шина сама по себе ненадёжна, особенно при помехах;), и потому меня не беспокоили;) - типо программно надёжность повысили;)))


Составить ответ | Вернуться на конференцию

Ответы


Отправка ответа
Имя*: 
Пароль: 
E-mail: 
Тема*:

Сообщение:

Ссылка на URL: 
URL изображения: 

если вы незарегистрированный на форуме пользователь, то
для успешного добавления сообщения заполните поле, как указано ниже:
введите число 38:

Перейти к списку ответов | Конференция | Раздел "Электроника" | Главная страница | Карта сайта

Rambler's Top100 Рейтинг@Mail.ru
 
Web telesys.ru