[syv 0]

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

 

Никто не говорит о непригодности С или другого ЯВУ в прямом смысле этого слова. Тут Вы правы - это смешно и глупо.

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

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

 

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

 

Вот несколько из них, позаимствованых из практики применения PLC:

- программный цикл один,

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

- как следствие, операторы цикла do{ }while( ); for( ; ; )( ); while( ){ } недопустимы.

Вообще то, это вопрос более серьезный и, чтобы полностью изложить сей подход надо бы собраться с мыслями...

[Petka 0]

Вот несколько из них, позаимствованых из практики применения PLC:

- программный цикл один,

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

- как следствие, операторы цикла do{ }while( ); for( ; ; )( ); while( ){ } недопустимы.

Вообще то, это вопрос более серьезный и, чтобы полностью изложить сей подход надо бы собраться с мыслями...

 

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

[DogPawlowa 0]

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

..Вообще то, это вопрос более серьезный и, чтобы полностью изложить сей подход надо бы собраться с мыслями...

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

.. как только задача становится сложнее "управления одной заслонкой", то автоматный подход становится тяжеловесным, непонятным.

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

 

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

 

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

 

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

[proba 0]

про Renesas.

чипы M16C и R8C деисвительно довольно устоичивые, кому интересно, можeт смотрет с renesasinteractive.com . кроме помехоустоичивости стоит смотреть на такие своиства ( которых в ряде других дешевых mk не наидете ) :

-автоматическая переключение на внутренныи rc генератор при остановке основного кварцевого,

-8 уровневая система прерывании,

-до 64 софт прерывания,

-прерывания на undefined instruction, address match, overflow

- запись и стирание flash memory возможно только после ввода password'a. т.e исключено случаиное или преднамеренное стирание чипа посторонними лицами.

[syv 0]

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

 

Да, я имел в виду автоматный метод программирования.

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

 

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

 

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

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

А компилятор 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.

[proba 0]

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

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

[syv 0]

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

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

 

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

[DogPawlowa 0]

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

Немного несогласен по поводу ассеблера ;) , но это скорее личное

 

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

Эмуляция потребовалась по двум причинам - 1) распараллеливание работ 2) презентация интерфейса пользователя удаленному заказчику без пересылки железа.

 

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

 

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

[proba 0]

Microchip потому и выигрывает, что постоянно угадывает в какое время, что понадобится. А всем японцам вместе взятым пришлось делать Renesas, ввиду загадочной системы рекламы и продаж.

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

http://www.reed-electronics.com/moversands.../CA6344026.html

лично мое мнение, чо трудно идет внедрение " в массы " dspic и также трудно будет идти с pic24.

кому производительность нужен, смотрит ARM7, где множевcтво изготовителеи , а не какои то pic24, Zneo, CP3000 или M16C, если они не "application specific". у японцев свои ниш отработан годами; так как бoльшинство фирм высоко ценит накопленный опыт и время, на новое ядро переидут только по краиней необходимости.

Изменено 25 ноября, 2006 пользователем proba

[syv 0]

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

 

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

 

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

 

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

 

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

 

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

[syv 0]

Microchip потому и выигрывает, что постоянно угадывает в какое время, что понадобится. А всем японцам вместе взятым пришлось делать Renesas, ввиду загадочной системы рекламы и продаж.

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

http://www.reed-electronics.com/moversands.../CA6344026.html

лично мое мнение, чо трудно идет внедрение " в массы " dspic и также трудно будет идти с pic24.

кому производительность нужен, смотрит ARM7, где множевcтво изготовителеи , а не какои то pic24, Zneo, CP3000 или M16C, если они не "application specific". у японцев свои ниш отработан годами; так как бoльшинство фирм высоко ценит накопленный опыт и время, на новое ядро переидут только по краиней необходимости. и умеют они ( jap) новые более производителные чипы делать, тот же M16 имеет образцы на 64MHz ( < 64 mips). честно говоря мне не понятно Bаше ( и многих других ) отрицательное отношние к японскои электронике и MK, особенно если вероятно вы их некогда даже не попробовали.

 

Хорошо, зайдем с другой стороны. А откуда у Микрочипа взялись деньги на покупку определенного числа фирм?

Рынок 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. Тут еще бабушка надвое сказала кто кого по реальной скорости.

[DogPawlowa 0]

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

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

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

 

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;

}

[syv 0]

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

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

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

 

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), если я не ошибаюсь. Поправьте, если это не так.

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

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

В некоторых вырожденных случаях основная программа представляет собой пустой бесконечный цикл, а все действия выполняются по прерываниям.

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

[DogPawlowa 0]

...Спасибо. Понял. Т.е. события у Вас существуют в явном виде, приблизительно как в Windows. Процесс эквивалентен потоку (Thread), если я не ошибаюсь. Поправьте, если это не так.

..

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

...

Событие в моем понимании - это само прерывание. Оно может привести к смене состояния одного или нескольких процессов-автоматов напрямую непосредственно в обработчике этого прерывания. Т. е. для каждого МК набор событий фиксирован и определяется набором возможных прерываний.

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

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

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

[arttab 0]

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