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

[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 - экран, кнопки, последовательные интерфейсы, работая по тем же исходникам с использованием условной компиляции при необходимости.

[Прохожий]

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

Да, я имел в виду автоматный метод программирования.
Циклов надо избегать при любых обстоятельствах. Лучше перейти на более скоростной вычислитель, незначительно удешевив конструкцию, чем допустить присутствие циклов. Правило есть правило. Я даже при программировании на PC в BC++B стараюсь поступать так же.

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

Почему не можете? Наверняка похожии ситуации можно оформить в виде отдельных функций и в качестве параметров передавать только изменяемую часть. Можно использовать вложенные автоматы и так далее. Проблема, на мой взгляд, здесь не в подходе, а в языке.
На С по-любому все это будет выглядеть достаточно громоздко. И этот язык начинает терять преимущества перед Ассемблером. Это, кстати, одна из причин, по которой в пром. автоматике до сих пор используются примитивные релейно-лестничные схемы (LD) или функциональные диаграммы (FBD), однозначно переводимые в псевдоассемблер (IL) и друг в друга.

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

Абсолютно верно. Полностью поддерживаю. А иначе кирдык. Но опять же, заметьте, это проблема средств реализации автоматного подхода, а не его самого.

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

Я бы назвал кусок кода, обсуживающий элементарную заслонку "процессом". При этом процесс может обслуживать не только заслонку, но и внутренний АЦП МК, к примеру, или USART. Процесс строится как автомат. При отсутствии прерываний процессы просто располагаются в памяти один за другим, последовательно.
А вот когда в это дело вносится событийность, реализованная через прерывания, то все резко меняется, поскольку состояния в процессах могут изменяться в обработчиках прерываний. И тогда может получиться так, что состояние процессов АЦП и USART могут изменяться в обработчике прерываний от таймера, к примеру. Получается "рваный" код.

Ну и ЯВУ. Скорее это оффтопик, но ни в одном из последних моих проектов за пять лет нет ни строчки ассемблера. Меня на нем клинит :-)

Это просто аллергия на кропотливую и нудную работу. Сам болею. В данном случае лечится алкоголем в умеренных дозах в приятном обществе .

А компилятор IAR С, например, и есть такой "специализированный ЯВУ", являсь при этом универсальным.

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

Кстати, сейчас один из проектов эмулируется на PC под Visual C - экран, кнопки, последовательные интерфейсы, работая по тем же исходникам с использованием условной компиляции при необходимости.

И, попутно, вопрос. А с чем связана потребность в такой эмуляции?

про Renesas.
чипы M16C и R8C деисвительно довольно устоичивые, кому интересно, можeт смотрет с renesasinteractive.com . кроме помехоустоичивости стоит смотреть на такие своиства ( которых в ряде других дешевых mk не наидете ) :
-автоматическая переключение на внутренныи rc генератор при остановке основного кварцевого,
-8 уровневая система прерывании,
-до 64 софт прерывания,
-прерывания на undefined instruction, address match, overflow
- запись и стирание flash memory возможно только после ввода password'a. т.e исключено случаиное или преднамеренное стирание чипа посторонними лицами.

Не хочу в теме про AVR говорить о PIC-ах, но не могу удержаться. Все это добро присутствует как в dsPIC30/33, так и в PIC24.

про Renesas.
чипы M16C и R8C деисвительно довольно устоичивые, кому интересно, можeт смотрет с renesasinteractive.com . кроме помехоустоичивости стоит смотреть на такие своиства ( которых в ряде других дешевых mk не наидете ) :
-автоматическая переключение на внутренныи rc генератор при остановке основного кварцевого,
-8 уровневая система прерывании,
-до 64 софт прерывания,
-прерывания на undefined instruction, address match, overflow
- запись и стирание flash memory возможно только после ввода password'a. т.e исключено случаиное или преднамеренное стирание чипа посторонними лицами.

Не хочу в теме про AVR говорить о PIC-ах, но не могу удержаться. Все это добро присутствует как в dsPIC30/33, так и в PIC24.

[Dog Pawlowa]

Спасибо за подробные комментарии. Совпадений в подходах скорее больше, чем разногласий. Даже термин "процессы" совпадает
Немного несогласен по поводу ассеблера , но это скорее личное

По технологии - скоростные события стараюсь исключать, все быстрые процессы у меня фоном в прерываниях. И вообще стараюсь лишние события не создавать - только клавиатура, интерфейсы (избранное) и таймеры. Это позволяет снять напряженку с временем для быстрых процессов и исключить лишний перебор событий.
Эмуляция потребовалась по двум причинам - 1) распараллеливание работ 2) презентация интерфейса пользователя удаленному заказчику без пересылки железа.

В устойчивость других типов микроконтроллеров не особенно верю, например, по моим оценкам, прерывание по несуществующей инструкции произойдет с вероятностью не более 50% (скорее одна инструкция заменится на другую существующую). Защита флэш? Слишком все сложно, чтобы сказать однозначно.

Что касается тяжеловесности автоматного подхода, то как раз сейчас должен добавить последовательность калибровки прибора с использованием встроенного дисплея, хотя та же функция уже предусмотрена по последовательному интерфейсу. Тяжело и весит! Общие куски выделяю функциями, и все равно душа не радуется. Но зависит ли это от использования автоматов? - скорее нет.

[Прохожий]

По технологии - скоростные события стараюсь исключать, все быстрые процессы у меня фоном в прерываниях. И вообще стараюсь лишние события не создавать - только клавиатура, интерфейсы (избранное) и таймеры. Это позволяет снять напряженку с временем для быстрых процессов и исключить лишний перебор событий.

Немного недопонял про фон и прерывания. Лично мне казалось, что прерывание - это событие. Его надо обслужить. Тогда вопрос. Что в Вашем понимании является событием? И что в этом случае представляет собой обработчик этого события?

В устойчивость других типов микроконтроллеров не особенно верю, например, по моим оценкам, прерывание по несуществующей инструкции произойдет с вероятностью не более 50% (скорее одна инструкция заменится на другую существующую). Защита флэш? Слишком все сложно, чтобы сказать однозначно.

Да все они приблизительно одинаковы. Дело не в контроллере как таковом. Впрочем тут уже про это было...

Что касается тяжеловесности автоматного подхода, то как раз сейчас должен добавить последовательность калибровки прибора с использованием встроенного дисплея, хотя та же функция уже предусмотрена по последовательному интерфейсу. Тяжело и весит! Общие куски выделяю функциями, и все равно душа не радуется. Но зависит ли это от использования автоматов? - скорее нет.

Дык, работать оно везде тяжело... Хочешь, чтобы было надежно, придется пахать. Это закон. Мне лично он не нравится , но деваться некуда.

[Dog Pawlowa]

По технологии - скоростные события стараюсь исключать, все быстрые процессы у меня фоном в прерываниях. И вообще стараюсь лишние события не создавать - только клавиатура, интерфейсы (избранное) и таймеры. Это позволяет снять напряженку с временем для быстрых процессов и исключить лишний перебор событий.

Немного недопонял про фон и прерывания. Лично мне казалось, что прерывание - это событие. Его надо обслужить. Тогда вопрос. Что в Вашем понимании является событием? И что в этом случае представляет собой обработчик этого события?

Прерывания обслуживаются автоматически в функции прерывания, а событием я называю ситуацию, требующую реакции процесса. Например так:

void fWaiting(void)
{ switch (event)
{
case evNew:
InitLcd();
RestartBacklight();
Restart500ms();
Old();
break;

case evFn:
status= stAirDeleting;
break;

case evRemoteService:
status= stRemotePin;
break;

case evUpDn:
status=stLocalPin;
break;
}