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

да все они примерно одинаковые. Только однократки - устойчивее, чем флешовые - это да...

>> В ближайшем будущем проведу исследования (может уже
>> существует???) всех наиболее распространненых марок
>> контроллеров на их ЭМС.
Что вы подразумеваете под "исследованиями"?

А ты собрался в космос?

Посмотрите в сторону фирмы RENESAS. Был на семанаре, который они устраивали. Очень хвали как раз в плане надежности флеш.

По моему скромному мнению, наиболее устойчивыми к ЭМ являются МК, установленные в PLC и в частотных инверторах. Они, собственно, для этого и предназначены - для работы в условиях большого количества ЭМ помех в промышленном оборудовании, вместе с двигателями, грелками, тиристорами и пускателями.

Может человек работает в области энергетики
по себе знаю что такое электро подстанция....
страшное дело :-)

Да ну. ;>
Если использовать нормальные помехоустойчивые протоколы обмена с повторами и т.п.. Грамотно применить возможности WDT. (не тупо в одной точке программы делать сброс WDT, а тестировать все возможные места с потенциальным зависаловом, и только после этого сбрасывать WDT).
Платы - в металлический корпус,
корпуса в отдельный металлический шкаф.
Все это дело заземлить, и будет работать стабильно.
У нас куча оборудования работает на подстанциях на AT89S (флешевые) и AVRках и никаких проблем в плане вылета флеша либо сбоя из-за ЕМ обстановки за много лет не замечено. Отдельные случаи бывали, когда что-то вылетало, но это такие случаи как - прямое попадание молнии в линию связи.

Безусловно, но что там с реальным временем?

Естественно, но всегда выход на ноль безболезнен?

И потолще...

На отдельный контур :-)

То естественно получим вполне тепличные условия для работы.

Да, а линии связи, естественно в стальную трубу и медную оплетку не забыть, но лучше оптику....

Ну а молния в линию связи дело для нас, связистов, дело не редкое :-( - держим зачастую без последствий.

Тяжело там, на самом деле вблизи силовых вещей, да еще работающих в аварийных режимах.
Тяжело :-(.

События в энергетике происходят редко, поэтому главная задача - гарантировать доставку и достоверность данных. Реальное время решается встроенными RTC в каждый отдельный блок и временными метками каждого события, т.о. фактическое время доставки пакета не играет большой роли.


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

Тяжело, поэтому доп средства для создания тепличных условий либо сравнимы по цене с применяемой электроникой либо обходятся много дороже. А уповать на то, что renessas или какой-то другой чип сможет без этих средств обойтись - вероятно не стоит.

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



Сделано следующим образом. Скорость в канале до 12 Мбит/с (PROFIBUS/DP), а общий такт системы фиксирован и составляет 10 мс.



Сделано в точности, как Вы говорите. Толщина металла шкафов (в большинстве случаев - это дюраль) 1,5 - 2 мм. Не так уж и тонко. В подавляющем большинстве случаев платы находятся в экране из пермаллоя или подобного материала. А если это не так, тогда сама плата разведена соответственно.



Все электроустановки должны быть заземлены обязательно. Иначе будете иметь дело с Госэнергонадзором, да и для помехоустойчивости лучше.



Я бы сказал не тепличные, а нормальные.



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

Не замечал разницы между n-МОП и КМОП 51-ми. Да и не должно ее быть. Устойчивость к помехе по входу зависит только от уровней лог "1" и "0" и быстродействия, а также от входного сопротивления. Что же касается наиболее опасных помех по питанию и особенно по земле - то они могут "снести крышу" у любого устройства, содержащего хотя бы один триггер даже на 155-й серии и борьба с ними только одна - правильный дизайн платы, подключений, экранировки итп. Теоретически несколько меньшая помехоустойчивоть может быть у МК с отдельным низким напряжением питания ядра, но это не касается 8-ми битных МК

Какая ирония? Никакой! Просто если все так правильно сделано, то особо о помехоустойчивости конкретно контроллера говорить не приходится.

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

Тогда извиняйте. Видимо я чего-то не так понял.
А еще я хочу добавить, что дело тут вовсе не в МК как таковом, а в методике его программирования. Есть ряд достаточно простых правил, использование которых помогает обходиться без WDT вообще и обеспечивать минимальный отклик системы на внешнее воздействие. И широко распространенный язык С не всегда годится...



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

буду опиратся на данные своего личного опыта..
подстанция в нашем родном метро...
связь по rs485 длина кабеля 25 метров скорость 50кбпс
кабель проэль экран...
из 100 пакетов(в 12 байт) в среднем приходят 50-70...
или такой случай..
из того же метро.. был произведен анализ 380в напряжения
обнаружено в момент пуска эсколатора 13 гармоника была больше 1й...
нормально???
и какая например система СИФУ или любая другая система фазоуправления с традиционными детекторами нуля тут вообще будет иметь место...
поэтому действительно начинаешь пережеивать что день грядущий нам готовит????
конечно предпринимаешь все возможные методы страховки: грамотная разводка печати , программные защиты...
я неговорю что все это безбожно сбоит... но отношение к этому должно быть немного более продуманным...
когда общаешься с людьми которые расказывают о помехах от сотовых телефонах или там дрель ктото включил... сразу приходит цитата из х.ф
"Перестаньте Лейстрейд, что вы понимаете в кражах" :-)

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

Никто не говорит о непригодности С или другого ЯВУ в прямом смысле этого слова. Тут Вы правы - это смешно и глупо.
Речь о другом. С и С++ - вещи универсальные. На них можно написать мат. модель транзистора, а можно и базу данных. Но в каждом из этих случаев все-таки лучше пользоваться своими специализированными средствами.: 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льшинство фирм высоко ценит накопленный опыт и время, на новое ядро переидут только по краиней необходимости.

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



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



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

Хорошо, зайдем с другой стороны. А откуда у Микрочипа взялись деньги на покупку определенного числа фирм?
Рынок 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], но я отказался уже от такого решения по соображениям, что логика выполнения одного состояния одного процесса должна быть прописана более компактно. Я все делаю для того, чтобы текст программы читался легко.
Проекты тянутся долго, и слишком сложны именно из-за сложных алгоритмов, которые должны достаточно быстро корректироваться.

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

Не аргумент. К качеству продукции это имеет очень опосредованное отношение. Откуда у Micro$oft деньги на скупку тучи фирм, писавших более качественный софт?


Еще как нужен! Ведь это мультимедиа и телекоммуникции - одно из наиболее востребованных от электроники направлений. Просто этот рынок ему не по зубам.


Это какой это dsPIC стоит 5 баксов в розницу? И скока стОит аналогичный по ресурсам МК других производителей?


Не удивили. Этого добра полно и для других МК, только оно часто и даром не нужно.


Фактически бесплатный - это тот, для которого есть "лекарство от жадности"? Для AVR и MSP430 (я буду приводить примеры для них, т.к. знаю их лучше других) есть не фактически, а во всех смыслах бесплатные компиляторы - GCC. Причем, если AVR-GCC немного уступает коммерческому IAR'у в плане качества кодогенерации, то MSP430-GCC очень даже на высоте - фоннеймановская архитектура проца очень хорошо коррелирует с GCC, что и не удивительно, учитывая корни MSP430 в PDP-11.


Это какие такие средства эмуляции имеются в виду? ICD2? Это даже не эмулятор. Для сравнения, в MSP430 на борту JTAG эмулятор, для работы с которым требуется копеечный адаптер на основе 74НС244. Эмуляторы есть также и во всех МегаАВР. И где их только нынче нет? А тут всего лишь дебаггер. Не удивили.


И ровно то же самое можно сказать про MSP430. И про AVR. И про ARM. И про МВ9х от Fudjitsu. И еще много про какие МК.


См выше. Список можно продолжить.

P.S. Прошу прощения за офтоп, не удержался.

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

2dxp
Относительно микрочипа вы не в курсе =)

>> Еще как нужен! Ведь это мультимедиа и телекоммуникции
>> - одно из наиболее востребованных от электроники
>> направлений. Просто этот рынок ему не по зубам.
Не нужен =) Ему нужен рынок энергетики, управления двигателями, источники питания, активные датчики, обработка голоса (не мультимедиа в общем плане) и т.д. и т.п. Это што касается dsPIC. PIC24 - контроллер без DSP ядра (MAC, модульная и бит-реверсивная адресация, два адресных генератора и т.п.), соответсвенно и область применения

>> Это какой это dsPIC стоит 5 баксов в розницу? И скока
>> стОит аналогичный по ресурсам МК других производителей?
dsPIC33FJ128GP706-I/PT - 6 USD в Тритоне от 1 штуки - 128к Flash, 16К ОЗУ, 2 12-битных АЦП x 18 каналов, 2 CAN, 64 ноги, по два UART, SPI, I2C, куча таймеров, модулей захвата и сравнения ....
Аналог за 6 баксов?

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

>> Фактически бесплатный - это тот, для которого есть "лекарство
>> от жадности"?
Фактически бесплатный - это у которого после 60 дней оптимизация высоких уровней отключается. C30 - тоже GCC - исходники доступны - собирай, пользуйся. Но - оптимизатор в GCC не входит, поэтому для нормальной работы нужно покупать естестно. Что то около 700 USD.

>> А тут всего лишь дебаггер. Не удивили.
Ну и? Что вы понимаете под эмуляцией и дебаггингом? У ICD2 до 4 аппаратных точек останова и все могут быть условными (типа запись-чтение по определенному адресу), есть аппаратный счетчик инструкций, можно гибко задавать последовательность событий для останова (типа сначала 1 точка, потом 2, потом работаем 100 тактов и стопоримся). И что, есть такое в "эмуляторе" MSP430?

У меня вот в столе валяются отладки для LPC2124, 2148 и 2103. Типа, ориентировался на АРМ. Потом серийно запустился PIC24 - так они и будут валяться до тех пор, пока мне не нужно будет больше 32 к ОЗУ. Потому что PIC24 ARM на целых числах рвет, а на флоатах всего в 2-3 раза медленнее (при максимальных тактовых обоих). Это 16-битник. Про DSP фичи я вообще не говорю, вы же прекрасно знаете, что такое два адресных генератора, MAC с предвыборкой за один такт, ДСП-шные методы адресации и т. д.

Какой интересный оффтопик получается. Может, не зря в свое время ICD2 купил :-)
Где можно подробнее про среду и прочее узнать ? Может, пора собирать все в кучу.

>> Где можно подробнее про среду и прочее узнать ?
На сайте microchip.com =)
А вообще, если интересно, заводите топик, задавайте более конкретные вопросы - отвечу.
Если знакомы с PIC18 - почитайте вот это
http://gamma.spb.ru/download/PIC18F_to_PIC...gration_RUS.pdf

Еще вот это:
http://www.gamma.spb.ru/products.info.php?...;s=12&i=389
http://www.gamma.spb.ru/products.info.php?...;s=12&i=391

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

И что у него (этого нового pic'а) в плане системы команд?

Нужен. Фирма занимается бизнесом и любое поле деятельности, где она может получить прибыль, для нее привлекательно. На рынок мультимедиа и телекоммуникаций они не лезут, потому что там им нечего ловить на фоне АД, ТИ, Моторолы и других спецов. Будь у них процы класса Blackfin, C55xx, C6x, 21xxx, тигрошарка, то и ломились бы они туда. А так - ядрышко у dsPIC'а - это почти один в один ADSP-21xx, которому сто лет в обед. Да и это ядро Микрочип рожал столько времени, что почти все перспективы успели протухнуть. Лично я ждал, когда они выпустят проц, был какое-то время на перепутье, но не дождался. Мое мнение - Микрочип слишком затянул с выходом dsPIC, за это время вызезла туча АРМов, оттянувшая на себя потребителя, которого теперь не так-то просто вернуть. Грамотнее был бы ход: сначала выпусти просто МК, а потом уже довешивай его ЦОС ядром. Т.е. сперва бы им лучше было выпустить PIC24, а уж потом dsPIC. Очевидно, сегодня они и сами это понимают - промашка вышла с этими ЦОС МК - простым микроконтроллерщикам в первую очередь нужен МК, а уж потом DSP. Поэтому и выпустили PIC24, который поначалу и не планировался. Тут их не осуждаю, задним умом все крепки. Но факт есть факт.


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


За 6 не знаю. Но если ориентироваться, например, по ценам Digikey (имхо, более объективно отражающий положение дел источник, нежели рынок России), то похож TMS320F2806. Флеши, правда, там поменьше, зато тактовая выше и разрядность данных шире. И по ЦОС тоже не сравнится.


Вот именно, если. Поскольку для нормальной работы среда как таковая не нужна (она нужна только для быстро посмотреть вначале, для быстрого старта), то и весомым аргументом я это не посчитал.


На прошлой работе был купленный. Потом еще дали лицензию на два пакета за хорошее поведение. А что? Причем тут это? Не было бы возможности пользоваться IAR'ом, пользовался бы GCC да и все. Наличие "почти бесплатного" компилятора от фирмы-производителя никак не может быть сурьезным аргументом в пользу доминирования этой фирмы. Всегда есть альтернативы. Которые часто не хуже.


Ну вот, сами все прекрасно объяснили: для нормальной работы надо либо покупать, либо ломать. В отличие от того же MSP430 или AVR, для которых GCC генерит вполне оптимальный код.


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


А вы не при равных тактовых сравнивайте, а при равном энеропотреблении. Это будет честнее.

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

>> Скажите а почему PIC24 рвет ARM на целых числах и почему
>> отстает на плавающей точке?
Дык потому что float IEEE-754 - 32 бита =) Естественно, что 16-битник будет курить на float'ах рядом с 32-битником при прочих равных.
На целых числах - рвет - это я сильно выразился, неправильно. Скажем так - на
16-bit int рвет
http://benchmarks.caxapa.ru/?test=13
на 32-bit int опять же по тактам ARM быстрее. Но если активно работать с памятью, результат будет примерно одинаковый, потому что АЛУ микрочиповских 16-битников может работать напрямую с памятью.

>> что у него (этого нового pic'а) в плане системы команд?
Не совсем понятен вопрос...
Около 80 инструкций, большинство с возможностью косвеной адресации и модификацией аргументов, типа
mov [W0+W1], [++W3]
Прямая адресация к первым 8 кБ ОЗУ. Размер опкода - 24 бита.
Программный стек с аппаратным контролем (очень удобно стеки задач в rtos-ах контролировать), выделение стекового фрейма под локальные переменные.
Аппаратное смешанное умножение, работа fixed point Q.15, итерационное смешанное деление 32/16 за 18 тактов, сдвиг с переносом и без на произвольное количество бит.
Аппаратный повтор инструкции (цикл REPEAT), в dsPIC до кучи аппаратный цикл блока кода с возможностью аппаратной же вложенности.
DSP: MAC (и его варианты) за один такт с предвыборкой по указателям и их модификацией и сохранением результата из аккумулятора (если нужно) в ОЗУ. Модульная и бит-реверсивная radix-2 адресация.

>> Нужен. Фирма занимается бизнесом и любое поле деятельности,
>> где она может получить прибыль
Согласен, я вообще говорил про нынешний этап развития микрочипа

>> Поэтому и выпустили PIC24, который поначалу и не планировался
Однозначно так, микрочип этого и не скрывает.

>> Круто. Смущает только то, что цена это только в Тритоне.
>> В других местах, если верить ефайнду, почему-то вдвое выше.
Это не демпинг и не акция - посмотрите цены на сайте Microchip'а. efind-у я давно уже не верю. Тритон - это по сути представительство официального дистр-ра микрочипа Гаммы СПб в Москве.

>> то похож TMS320F2806
ну да, только два питания и 35 портов GIO в 100 выводном корпусе.

>> Вот именно, если. Поскольку для нормальной работы среда
>> как таковая не нужна
А дебажить в коммандной строке? =)

>> для нормальной работы надо либо покупать, либо ломать.
700 долларов это не много за нормальный компилер. Опять же можно спокойно использовать его же бесплатно с низким уровнем оптимизации - я не думаю, что код будет сильно хуже чем у полностью открытых других портов GCC

>> При этом, от самого проца не нужно никаких дополнительных
>> ресурсов - все общение по JTAG.
В случае ICD2 от проца тоже ничего не нужно, BackgroundDebugModule есть в каждом чипе. JTAG у них кстати тоже есть - для граничного сканирования функционирует, спецификацию программирования и отладки по JTAG микрочип обещал в начале 2007 года.

>> А вы не при равных тактовых сравнивайте, а при равном
>> энеропотреблении. Это будет честнее.
Согласен, только получается, что LCP2xxx на 60 МГц (будем считать максимум) - 55 мА, PIC24H - 60 мА на 80 МГц (40 MIPS - max). Вот и все сравнение. До кучи - потребление мне важно только в батарейном девайсе, для остального - ехало-болело...

>> якобы, Микрочип занимает какие-то исключительные позиции
>> на мировом рынке микроконтроллеров
Конечно, согласен.

Спасибо.
В рамках этого топика хочу пояснить и заодно спросить.
У меня был один небольшой проектик с управлением двигателем постоянного тока. Я, начитавшись про особенную устойчивость PIC к помехам, и реально столкнувшись с влиянием помех на MSP430, (особенности правильного проектирования сейчас не обсуждаем, хорошо? ) сделал этот проектик на PIC12F630. Влияния помех действительно не заметил, но непростота проектирования на PIC несколько смутила. Делал на IAR PIC, так как в архитектуре контроллера и особенности системы команд не было ни малейшего желания, а функции были просты.
Так вот, в плане этого топика мой вопрос - насколько оправданы дополнительные сложности с проектированием для PIC улучшением помехоустойчивости? Особенно если грамотный специалист найдет, как защитить любой микроконтроллер.
И в заключение "я не пытаюсь наезжать на микрочип и его продукцию" (с)

>> Делал на IAR PIC
реальные пацаны используют для PIC16 HI-TECH. Компилятор у IAR чисто для галочки.

>> дополнительные сложности с проектированием для PIC
>> улучшением помехоустойчивости?
Я вот что-то никаких особых сложностей не замечаю. А про помехоустойчивость - тут же терли не однократно... Узнать бы еще, как измерить "помехоустойчивость" =)

>> "я не пытаюсь наезжать на микрочип и его продукцию"
дык и я не пытаюсь защищать микрочип и его продукцию =)

Каждый пользуется тем, чем ему нравится. Охотно верю в б'ольшую помехоустойчивость PIC, но и с AVR у меня не было с этим проблем. Насчет сложностей проектирования с PIC ничего особенно сложного я не нахожу. Есть опреденные неудобства, но по-другому и быть не может. Архитектура очень уж простая. Народ пользуется HT Си компилятором, который сглаживает все острые углы PIC. У PIC, конечно, есть свои достоинства. Видимо поэтому он и пользуется успехом у многих.

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

Сейчас, я не знаю что у микрочипа. Были случаи, отказывал кварц и весь девайс переставал дышать. это было. В нормальных контроллерах, в таких случаях идет переключение на внутренний генератор.



А вообще устойчивость зависит в основном от уровня схемотехника, программиста, конструктора. Только потом идет технология CMOS, NMOS, p-/n-MOS...

В космосе, АЭС, рентгеновских аппаратах и т. п. нужно использовать контроллеры с EPROM (OTP)! Flash при первой же вспышке обнулится.

где идет шум ВЧ/СВЧ - там по-выше уровни логики, по-больше токи, ставятся фильтры, развязка с внешним миром. И т. п. и т. п.

и если все грамотно сделать, то можно и i8080 на марс отправить.

А просто взять микросхему и припаять провода питания, повесить несколько светодиодов и облучать радиацией 1000 рентген и одновременно засунуть в никроволновку и сказать вот.. именно он! не знаю.

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

А по ЭМ судят в основном готовые изделия/системы. Это мое мнение. (Оно может быть у каждого свое.)

На этом и порешим

Интересно узнать Ваше мнение про это Это. Если, конечно, Вы найдете время. На мой взгляд, вполне пристойная основа для языка автоматного программирования МК.

От лукавого этот Рефлекс.

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


В контексте контроллеров, неужели так сложно написать модуль который будет заниматься тем, что вызывать требуемые функции тогда когда надо? Это в буквальном смысле займет 2 (от силы 3) экрана текста на C. Зачем для этого язык изобретать-то? Про средства описания связей с датчиками, гм.. это уже уровень АРМов.. Тока всяко проще применить систему, GUI которой позволяет мышкой все связывать, чем учить язык нового веяния с модным названием.

>> чем учить язык нового веяния с модным названием.
тем более что компиляторов и трансляторов для него нет и наверное не будет

Согласитесь, это не самое главное. Тем более, что есть английский вариант того же самого. Главное там в другом. Там есть понятия "процесс" и "состояние". Конечно, в предложенном варианте оно еще далеко от совершенства и для МК в чистом виде не подходит.




Операции с временными интервалами мне тоже не нравятся. Тем более, что в контексте PLC их просто нет. Временные булевы переменные там организуются точно так же, как и все остальные.
Если говорить о МК, то описание его конфигурации на ЯВУ, на мой личный взгляд, не такая плохая вещь.
Насчет "связывать мышкой". Тот же Микрочип одно время включал в свой МПЛАБ визуальный конфигуратор с мышкой, картинками, выходным кодом и т. д. В последней версии МПЛАБА этого нет. Почему?
В AVRStudio, я этого вообще не видел. Правда, может быть плохо искал?




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

Мне самому было бы интересно Времени нет, а по поверхности не хочется плыть.

Одно важное обстоятельство. У меня заказчик импортный. Я отправляю ему исходники, утверждая, что все написано на обычном ЯВУ и любой студент, закончивший европейскую high-school, разберется и подправит в случае необходимости, если меня грохнут где-то в дороге. Оба делаем вид, что верим, что в этом можно разобраться Учат ли ЭТО в университетах Германии, я не знаю, но догадываюсь

>> В последней версии МПЛАБА этого нет.
не удержался - есть там все. VDI называется.

Виноват, недосмотрел. И как часто Вы его применяете? Я лично -практически никогда. Поэтому особо и не искал.