Устойчивый к ЭМ помехам МК Опции

[Woodoo]

Может кто достаточно хорошо знаком не с одним-двумя типами МК, а с побольше. Может кто сможет рекомендовать контроллер, который стоит использовать в системах с жесткой ЭМ обстановкой? Может какие-нибудь военные или для космических разработок или еще что.
В ближайшем будущем проведу исследования (может уже существует???) всех наиболее распространненых марок контроллеров на их ЭМС.
Нехорошее у меня предчуствие, что малопотребляющие современные контроллеры (AVR MicroPower, MSP и др) намного менее устойчивы к ЭМ помехи чем старые, более токопотребляющие МК.

[Dog Pawlowa]

Может кто достаточно хорошо знаком не с одним-двумя типами МК, а с побольше. Может кто сможет рекомендовать контроллер, который стоит использовать в системах с жесткой ЭМ обстановкой?

Я работал с микроконтроллерами и микропроцессорами порядка 10 типов и абсолютно устойчивых не встречал. Рекомендовать можно соблюдение правил, наиболее близко к моим они изложены в известной статье на Сахаре.
Зависимость устойчивости к помехам от типа технологии моим опытом не подтверждена.
Про непригодность языка С (да и любого ЯВУ) смешно слушать.
Про достаточно простые правила других было бы интересно прочитать.

[Прохожий]

Про непригодность языка С (да и любого ЯВУ) смешно слушать.

Никто не говорит о непригодности С или другого ЯВУ в прямом смысле этого слова. Тут Вы правы - это смешно и глупо.
Речь о другом. С и С++ - вещи универсальные. На них можно написать мат. модель транзистора, а можно и базу данных. Но в каждом из этих случаев все-таки лучше пользоваться своими специализированными средствами.: PSpice в первом случае и SQL во втором (просто для примера).
Так вот, для программирования задач управления на МК, по моему скромному мнению, нужен свой, в некотором смысле специализированный ЯВУ.

Про достаточно простые правила других было бы интересно прочитать.

Вот несколько из них, позаимствованых из практики применения PLC:
- программный цикл один,
- ссылки назад недопустимы, т. е. программа может выполняться только в одном направлении в пределах цикла,
- как следствие, операторы цикла do{ }while( ); for( ; ; )( ); while( ){ } недопустимы.
Вообще то, это вопрос более серьезный и, чтобы полностью изложить сей подход надо бы собраться с мыслями...

[Petka]

Вот несколько из них, позаимствованых из практики применения PLC:
- программный цикл один,
- ссылки назад недопустимы, т. е. программа может выполняться только в одном направлении в пределах цикла,
- как следствие, операторы цикла do{ }while( ); for( ; ; )( ); while( ){ } недопустимы.
Вообще то, это вопрос более серьезный и, чтобы полностью изложить сей подход надо бы собраться с мыслями...

Могу предположить, что ТАК можно описать только набор конечных автоматов (КА). Согласен, КА очень устойчивы и очень легко отлаживаемы. Могу так-же предположить, что как только задача становится сложнее "управления одной заслонкой", то автоматный подход становится тяжеловесным, непонятным.

[Dog Pawlowa]

Так вот, для программирования задач управления на МК, по моему скромному мнению, нужен свой, в некотором смысле специализированный ЯВУ...
..Вообще то, это вопрос более серьезный и, чтобы полностью изложить сей подход надо бы собраться с мыслями...

Могу предположить, что ТАК можно описать только набор конечных автоматов (КА).
.. как только задача становится сложнее "управления одной заслонкой", то автоматный подход становится тяжеловесным, непонятным.

Широко использую автоматы, при наличии проблем c ESD особенно - очень просто организовать продолжение работы устройства при сбросе от помех. Думаю, что Прохожий это и имел ввиду. Циклы тем не менее есть, но это те циклы, которыми можно пожертвовать- задержки, чистка массивов и т.д. Организовывать и задержки как состояние автомата не выглядит красиво.

Становится ли этот подход тяжеловесным при усложнении задачи? Я бы сказал - "неоптимальным". При наличии похожих состояний вижу, как расходуется программная память на повторение похожей логики в каждом состоянии, а сделать ничего не могу. Для лучшего понимания помогает правильная организация массивов - каждое состояние имеет не только номер, но и имя (его всегда в моих приборах можно прочитать по интерфейсу, не заглядывая в исходники) ну и система названий.

Про заслонку. Любой прибор можно представить, как "набор заслонок". Во всяком случае я к этому стремлюсь :-)

Ну и ЯВУ. Скорее это оффтопик, но ни в одном из последних моих проектов за пять лет нет ни строчки ассемблера. Меня на нем клинит :-) А компилятор IAR С, например, и есть такой "специализированный ЯВУ", являсь при этом универсальным. Кстати, сейчас один из проектов эмулируется на PC под Visual C - экран, кнопки, последовательные интерфейсы, работая по тем же исходникам с использованием условной компиляции при необходимости.