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



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

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

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

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

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

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

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

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



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



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



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



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



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




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




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


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

спасибо, не знал. тем не менее, Renesas внедрял все это в начале 90-х а Microchip 10 лет позже.

Я так понимаю, что Вы говорите о Mitsubishi, потому как тогда это был их контроллер. По-моему всякому овощу - свое время. Microchip потому и выигрывает, что постоянно угадывает в какое время, что понадобится. А всем японцам вместе взятым пришлось делать Renesas, ввиду загадочной системы рекламы и продаж.

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

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

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

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

оффтоп, но может обясняете в чем микрочип выйгрывает ? в россии да, но россииски рынок в мировом маштабе сильно много не влияет. реалная ситуация такая:
http://www.reed-electronics.com/moversands.../CA6344026.html
лично мое мнение, чо трудно идет внедрение " в массы " dspic и также трудно будет идти с pic24.
кому производительность нужен, смотрит ARM7, где множевcтво изготовителеи , а не какои то pic24, Zneo, CP3000 или M16C, если они не "application specific". у японцев свои ниш отработан годами; так как бoльшинство фирм высоко ценит накопленный опыт и время, на новое ядро переидут только по краиней необходимости.

Сообщение отредактировал proba - Nov 25 2006, 22:50

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



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



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

Хорошо, зайдем с другой стороны. А откуда у Микрочипа взялись деньги на покупку определенного числа фирм?
Рынок DSP Микрочипу вообще не нужен. Это просто приятная дополнительная возможность к обычному МК и все. При цене 5 - 6 $ за микросхему в розницу - это вообще сказка.
Теперь о составляющих успеха Микрочипа:
1. Бесплатная среда разработки с вполне пристойным интерфейсом.
2. Фактически бесплатный компилятор С для всех типов вычислителей (PIC18, dsPIC и PIC24).
3. Легко доступные для самостоятельного изготовления средства эмуляции. А для особо ленивых предлагаются сии девайсы по цене около 70$.
4. Куча всякой сопровождающей ерунды типа CAN и TCP/IP контроллеров, а так же операционников, источников опорного напряжения и т. д.
5. Исчерпывающая документация и примеры.

В принципе любой желающий может начать производить лепнину на Микрочипе ни у кого не воруя софт и при минимальных затратах на железо.
Во всех остальных случаях, кроме ATMEL с их AVR и может быть MAXIMа c их MAXQ Вам придется либо украсть софт, либо выложить достаточно круглую сумму (>500$).
А это важно не только для России.

Теперь о японцах. Имею дело с их электроникой в виде PLC от OMRON. ПлАчу...
1. Все крайне дорого. При этом софт настолько кургузый, что не совсем понятно, за что деньги плочены.
2. Отвратительнейшая документация. Логика, в основном, японская. Кто имел с ней дело, тот меня поймет. MPLAB или AVRStudio - просто шедевр по сравнению с этим.
3. Что касается МК. Посмотрел я в сторону NEC. Даже не смешно. Все за деньги, причем немалые.

Объясните зачем мне напрягаться, платить деньги, если мне и так все разжуют и в рот положат, причем на халяву? А серийный PIC24H и так уже имеет 40 MIPS при достаточно продвинутой RISC системе команд и регистровым массивом оперативной памяти в 8 K. Тут еще бабушка надвое сказала кто кого по реальной скорости.

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

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;
}

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

Да, у меня события - это ситуации, может и вызванные исходно прерываниями, но первично обработанные. Например, генерация кода нажатой клавиши evKey (дребезг давится, автоповтор генерируется). В обработчике напрямую меняются только состояния простейших автоматов (например, поддержка последовательного интерфейса).
В принципе это позволяет расположить все функции обрабоки каждого процесса как двумерный массив RunProcess[status,event], но я отказался уже от такого решения по соображениям, что логика выполнения одного состояния одного процесса должна быть прописана более компактно. Я все делаю для того, чтобы текст программы читался легко.
Проекты тянутся долго, и слишком сложны именно из-за сложных алгоритмов, которые должны достаточно быстро корректироваться.

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