Эт вряд ли.

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

? Не понял

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

Я отнюдь не агитирую за использование достаточно монстральных операционнок логика развития которых давно уже подчинена исключительно маркетинговым идеям с закосами к десктопам.
Однако, обе помянутые операционки на IBM/PC, как минимум, с успехом используются в качестве платформ для написания и отладки 'приложений' котрые уже переносятся на целевую платформу имеющую сходные системные сервисы. Да и для отладки перефирийного железа уже зачастую тоже, ибо периферийные железки далеко тоже уже не светодиоды и вешаются не на GPIO а на, например, PCI. Разбирательство и покупка чужого кода тоже неизбежна - время мануфактур в программировании проходит. Да, естественно будут какие-то нишевые работы типа вырезания статуэток из эбенового дерева на потребу туристам. Но в общем тенденции аналогичны общепромышленной революции 19 века.

А как же секреты мастерства ? Я, к примеру, уже несколько однотипных проектов сделал на смеси С и ASM. Быстрые процессы на ASM в прерываниях, а медленные на С последовательно. Может быть из-за этого несколько задержался на 18-х PICах.
А на чистом ЯВУ Вы, пожалуй, и смены платформы не заметите...
Все остальное, питание, таймеры, АЦП и проч. - оно же у всех одинаковое, за редким исключением. Где же тут новизна и острота ощущений?
Другое дело смена концептуальной модели программирования или разработка собственного хитрого алгоритма.

DMA там тоже есть, несколько штук. Кстати, там ещё и full speed USB есть. И пространство памяти программ можно "переливать" в пространство памяти данных.

И вот не надо здесь насчёт работы ума. Некрасиво сравнивать 8-разрядную машинку с 16-разрядной. Кстати, а что ж это микрочипы остановились на 40 МГЦ? А теперь давайте я вдруг вспомню, что есть АВР32! Ну и где будет ваш дспик?

Совсем не плохой КПД, согласитесь!

Оталось посмотреть на "таблицу с ARMами" и подумать почему это


Лично меня радует сегодняшний день и богатый выбор ARM7/9 всех ценовых категорий и не уступающиx им по стоимости DSP.
А грусти по 51/PIC/AVR уже нет. Попадется задача попроще под что-то совем мелкое выберу безпристрастно и использую.

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


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


С удовольствием повырезал бы статуэтки... Ну их, эти операционки...

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






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

Дык, и в dsPIC это все есть, куда-ж без этого? И USB, думаю, будет. AC кодек есть, CAN есть, даже блок расчета CRC есть.


Я думаю, что с dsPICом все будет в норме. А AVR32 есть только в мечтах. До моего Мухосранска он еще не добрался. Вот когда доберется, тогда и посмотрим...
Да и вообще, лично мне Ангстремовский 1878ВЕ1 нравится, только я его готовить не умею бо не на чем . Кроме шуток, посмотрите, если найдете время.

Там-же, где AVR32 по сравнению с любым 300-400MHz DSP 10 долларовой категории за которым стоит многолетний опыт специализирующихся на сигнальной обработке фирм.

Дык, откуда ж денег взять столько? Я же сам по себе.


А я первое лично на себе попробовал. Никому не советую.


Про операционки полностью согласен.
Насчет ПЛК - обратите внимание на ПЛК100/150/154 (не сочтите за рекламу). После этого, заниматься разработкой ПЛК считаю бессмыссленным. Тем более в одиночку. Лучше уж резьба по дереву .

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

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

Ещё одно соображение по дспику. Потребление на 40 мипсах 90мА*3.3В=300 мВт, печка получается. Уж я лучше поставлю TMS320F2801, на 40 мипсах он будет потреблять 78*1.8=140 мВт. Да еще есть огроменный запас и по памяти, и по мипсам, и по ногам, и по периферии. Так что дспик тоже запоздал появиться на свет. Что привлекает - малое количество ног...Сделать подарок для радиолюбителей - какой-нибудь цифровой приёмник Морзе с фильтрацией, хорошей динамикой плюс RTTY плюс PSK31 и т.д. и т.п.(:-).


"Пикоманы" начали сравнивать 8-битный авр с 16-битным дспиком, не, ну так нельзя! Где у них совесть спрашивается? Вот в ответ на это я и начал вспоминать, что есть авр32...

Надо по справедливости сравнивать. Я ж не сравниваю пик18 и атмегу по производительности, а только по машинным циклам, ну так, пусть и они сравнивают пик18, а не пик24 или дспик...

Ф точку! Искусства программирования как такового всё меньше и меньше, осталась (тупая) работа для (тупых) кодеров...
Вот поэтому и люблю возиться с ассемблером, аккуратно всё оптимизировать вручную и применять нестандартные подходы. Мне это душу греет...



Вопрос имхо спорный. Товарищи предлагают изучить их систему, языки и привыкнуть полностью к их методу написания ПО для их девайсов. Какому же разработчику хочется загружать свою голову ещё и чужими тараканами, когда своих хватает? Опять упираемся в "разбирательство с чужой писаниной". Дали бы прямой доступ к программирования того самого ARM7/9, который внутри, глядишь и количество желающих увеличилось бы. ARM для многих знакомый, как-никак. Да и минуя интерпретатор, удалось бы повысить скорость реакции на внешние события (в паспорте стоит цифирь 1 мс, что совсем не фонтан при ядре 200 МГц).
Однако, наиболее успешным решением имхо будет являться создание такого ПЛК, для программирования которого можно будет взять любого PC-кодера с улицы. Нужно сам ПЛК сделать на базе компьютерной платформы. Всё равно овеновцы просят за своё изделие не менее 300 енотов, так что от ценовой конкуренции с пром.компьютерами они практически не защищены, а фактор подготовки (переучивания) специалистов весьма дорогостоящий.

Спасибо, посмотрел. Привлекает CAN, он то мне и нужен.
Для того, чтобы попробовать PIC, нужно решить вопрос с компилятором и отладкой.
ICD2 то где-то валяется, это не проблема.
А вот с компилятором ... Привык к IAR, придется разбираться с новым. Буду собирать инфо, если есть практические советы, буду рад.

IAR поддерживает PIC 16/17/18/24/dsPIC рекордов, особых, скорее всего не ставит, но код генерит. Год назад пробовал тупо в старой железке на PIC16 вместо разборок с ASMовкими исходниками все заново написать - получилось

Да у меня тоже получилось, даже для PIC12. Но мне показалось, что IAR бросил этот компилятор сопровождать, настолько отстало выглядел по сравнению с AVR и MSP.
Сейчас снесен на этом компе. Я не помню, там есть поддержка отладки через ICD2?

Вы даже не представляете, как я в начале 90x любил возиться с ASM (причем уже после вполне приличного овладения Fortran/С/C++) используя в качестве контролера массовые на то время 286 и высасывая их 12MHz доcуха и потом из 25MHz 386sx все вытягивал. И проект разрастался до нескольких сот килобайт ассемблерного кода... Сейчас это крутится, как минимум, на вполне пристойных 300MHz Geode. Да я конечно прицепил позднее возможность подгружать писаные на С оверлейчики, но все равно не то .
И как мне теперь этот все еще к сожалению, живущий по дурости заказчика проект кровь периодически портит - и переписывать бессмысленно, и пересертифицировать невозможно, и сопровождать многомегабайтные исходники тоскливо.


Возможно, но компиляторы у IAR для разных PIC, естественно, разные - для свежих - посвежее.

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

>> Но, согласитесь, - это уже некрасиво.
>> Просто повышать частоту. А где же работа ума?.

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

Но тем не менее, даже PIC24H 48-МГц AVR покроет...

Мне вот ARM вообще не нужен. Только в несколько проектов заскочил LPC2148, потому как есть USB, а у микрочипа пока только в PIC18. В остальном - ничего особенного. Единственное преимущество ARM по скорости - это наитивная работа с float, бо 32-битный. Но я float-ы только по лени использую =) Ну и с U32 на арме тоже будет конечно веселей...

Вот осенью будут образцы PIC24F серии GB с USB OTG, тогда армы у меня вообще отпадут. Останется только старший AVR32 и то для факультативных задач =)

Разработчики они ведь разные - есть разработчики технологического оборудования - какому разработчику, например, конвеера захочется еще голову забивать.... ну Вы поняли чем

А какие проблемы - стираешь прошивку и 'творишь'

Свежо


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

А он, типа, к Вам уже 'пришел', 'освоился' и теперь ему только 'остаться' осталось

>> Ну 'особенного' нет, а плохого чего

когда я писал "ничего особенного" я имел в виду то что имел. Нет ни конкретных засад, ни чего-то сверхъестественного, как по периферии, так и по ядру. Мне, например, не хватало программного сброса. Можно конечно WDT не сбрасывать, что и делал.

>> Смысл был после освоения возвращаться к микрочипу и ожиданию

Смысл простой - не расширять номенклатуру на складе и номенклатуру поставщиков. Если вам плюс-минус полбакса - да наплевать - мне нет.
Я что где-то написал, что жду? Я сказал, что когда будет, филипс отпадет из рассмотрения. А с учетом того, что у микрочипа линейка намного обширней, выбирается контроллер не избыточный, под задачу, что всегда на цене сказывается.

По поводу многообразия - да по сути среди мелких ARM7 его и нет - NXP и ATMEL. Ну может ST сейчас с кортексом подтянется...

>> А он, типа, к Вам уже 'пришел'

Я не про урезанные UC3A/B

Так его и сделали приблизительно это время назад. После чего благополучно плюнули и забросили. Ни тебе компиляторов пристойных, ни IDE, ни бортовой переферии. Вот это по нашему...
А задумка была хорошая - PDP11 в RISK варианте. Жаль, что не сложилось...


Полностью солидарен. В конце концов, не в платформе как таковой дело, а в ее наполнении.

Да никакой это не PDP-11, а самый настоящий RISK-I. И хорошо, что не сложилось. Без нормального компилятора такое программировать - увольте.

А Вы в курсе, что в промавтоматике применяются исключительно языки стандарта МЭК 61131-3. С Вашим (и моим тоже) С или еще хуже С++, а так же со всякими АСМами Вас туда на пушечный выстрел не подпустят.
Насчет разбирательства с чужой писаниной. Да, все языки упомянутого стандарта - в общем-то не очень.
Но на нашем производстве в случае необходимости (поломка, небольшая модернизация) этим делом занимается обыкновенный наладчик, как раз с помошью вышеупомянутых языков. А кодер с улицы здесь не нужен, потому как не отличает реле от гайки, в отличие от наладчика.
Насчет ПЛК на основе компьютерной платформы - все уже сделано до нас, причем неоднократно и со всеми извращениями, типа доступа к ядру процессора . Результаты здесь. К стати, OWEN - это один из результатов.
И к слову, настоящий пром. компьютер начинается от 1500 еврорублей. Так, что конкуренции там не будет и переучивать никого не надо, потому, как на производстве все это давно есть само по себе, со времен стоек типа S5.


Не в терминах дело. А в том, что у нас ни одно дело не доводят до логического завершения. Ядро сносное, но все остальное... Кто мешал написать нормальный компилятор, пока было время?
И потом, я пробовал его программировать на тех дровах, что давались к нему на сайте. Ничего сложного не обнаружил. Не хуже соотв. PICа или AVR.

Термины - это AVR и PIC. А PDP-11 и RISK I - это такие совсем разные архитектуры.


Мда. А использование регистровых окон руками оптимизировал? Спасибо, я не хочу.

Да не также он это выполнит!

Ваш код при равном количестве циклов PIC/AVR, выполнится в два раза медленнее на PIC с ядром на 40 Mhz чем на AVR с ядром на 20Mhz.

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


Несоглашусь.

Так как - где же в пиках работа ума?
PIC18 с PLL, ядро на 48Mhz, по производительности что AVR на 12MHz.
Что мы сравниваем-то?

Не от большого ли ума в PIC машинный цикл выполняется за 4 такта?
Почему не 1 как в AVR?

Насчет dsPIC согласен, не того поля ягода чтобы его с AVR сравнивать.

Не люблю аналогии, но всё-же:

Дискуссия один в один похожа на: "AMD vs Intel. Какой проц лучше?".

Есть интересное мнение что AMD и Intel не конкурируют, а наоборот сотрудничают. Пока пользователи будут с пеной у рта доказывать что одно лучше другого можно не снижать цены ни на одно ни на другое. В проигрыше только сами пользователи!

Ну разве только..

Тогда уже точно не следует забивать склад и сидеть ограниченном круге поставщиков, не правда-ли?
А вот тут уже к счастью, возможны варианты. Тем более с ходом времени еcть изменения.

Сразу вот так авансом .

Ну полный список:
• Actel
• Analog Devices
• Atmel
• Cirrus Logic
• Freescale
• Hilscher
• Intel
• Luminary Micro
• Micronas
• NetSilicon
• NXP
• OKI
• Samsung
• Sharp
• STMicroelectronics
• Texas Instruments
• Winbond

А из Cortex мелких Luminary уже развернулся.
Кроме того какой Ваш самый массово используемый PIC? Он что, только на Баксовые Cortex тянет?

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

А если не будут спорить (спорит не более 1%) то цены снизятся чтоль ?

С чего ?

да и не только, та же Гамма и то и другое сразу поставляет. Думаю, что ей всё-равно, что продавать



думаю автор поста указал тех, кто ARMы уже давно производит и соответственно имеет большой опыт в разработке кристалов данной архитектуры. В данном случае, для определённого круга задач - это действительно Atmel и Philips (NXP). Почему определённого? да потому что можно ли сравнивать круг задач, решаемых например LPC2101 и каким-нибудь кристаллом от Samsung-а? Думаю - нет

А почему именно 2101?
LPC22xx-LPC28xx перекрывают все самсунговские чипы с головой.
Что самое интересное почти каждый второй телефон от самсунг, построен на LPC.

Перед знакомством с МК я довольно тесно сталкивался с ассемблером под х86 - потому мне довольно легко было разобраться и с 51-й серией, и с AVR... пробовал разбираться с PIC - система комманд очень непривычна, да и цены, мягко говоря, пугающие - в "моем селе" 16С84/16F84 стоит сравнимо с ATMega16, если не дороже, и это - при его-то функциональности так что - выбор очевиден.

вот именно поэтому
у NXP линейка АРМовская широченная, потому как рассчитана на широченный круг использования в различных областях электроники
а у Самсунга линейка на кого направлена?
вот и ответ

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

Похоже на наличие перекоса в сторону избытка ума за счет дефецита вежливости.
Претворим бред в реальность.
0. Если суслика не видно, это не значит, что его нет. Так же и глюки.
1. Как подвесить TWI у Меги8/16/32 ( я думаю и другие также):
а)создать прецедент ошибки - можно просто не впаивать слэйв.
б)Сгенерировать старт-условие и передать адрес.
в)При этом модуль, есс-но выдаст ошибку, которую мы, закурировав до дыр даташит, пытаемся
сбросить, сгенерировав стоп-условие.
г)Если не подождать примерно 12-15 мС, и попытаться опять выйти на шину, модуль навечно
зависнет условии старт-стоп. Если подождать указанное время, то модуль отвисает, и с ним можно работать.
Теперь о том, как разряженная батарейка завешивает систему.
PCF8563, в отличии от PCF8583 умеет работать на 400 кГц. Но в схему вкралась ошибка, ирезуки поставили для скорости 100кГц, т.е 10 или 15к, создав тем самым прецедент для ошибок. Ситема была построена следующим образом: PCF вырабатывает для проца внешнее прерывание 1/64 сек, а проц считывает по шине данные. При считывании данных ошибка не обрабатывалась. После считывания данных анализировался флаг валидности данных и, в случае обнаружении сбоя данных ( что означало бы, что был сбой по питанию), производилась попытка проинициализировать PCFку. В этом месте анализ ошибки производился и, в случае ее возникновения, производились прописаные в даташите действия и повторная попытка записи. В этом месте все остальные действия притормаживались, поскольку залить 16 байт на скорости 400кбит не должно было быть заметно.
Результат:
На шине периодически возникали ошибки но, поскольку повторное старт условие генерировалось не чаще 15 мС, то модуль успевал отвисать и ошибка не проявлялась. Ошибки могли возникать( и, скорее всего возникали) в процессе запуска первого и наладки последующих. Но эти ошибки не были перехвачены - при запуске проги, если прога повисла, это нормальная ситуация, а наладчики, может пару раз и удивились, но включив-выключив устройство пару раз PCFка инициализировалась и зависоны прекращались. После того, как у пользователей разрядилась батарейка, после каждого включения потребовалась инициализация со всеми вытекающими.

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

З.Ы. А сравнивать PIC24 или dsPIC33 с АВРами, по моему, некорректно - железяка совсем другого уровня. Как и ARM. PICи больше подходят для работы с сигналами, у них для этого все есть, а АВРы и ARMы хороши для применений в UI - здесь они даже удобнее PICов.

Лет 5 писал для ПИКов на асме, после чего пишу почти 10 лет в основном на Си, и разве что иногда асемблерные вставки делаю.

На АВР сразу начал писать на Си.

Возникали ли у вас какие-нибудь трудности, которые были на AVR и которых не было на PIC и наоборот?

Уважаемый, о чем Вы здесь говорите, если Вы показали нам исходник в котором
просто некорректно обслуживается TWI_BUS_ERROR!
Цитирую даташит специально для Вас:
Status 0x00 indicates that a bus error has occurred during a Two-wire Serial Bus transfer.
A bus error occurs when a START or STOP condition occurs at an illegal position in
the format frame. Examples of such illegal positions are during the serial transfer of an
address byte, a data byte, or an acknowledge bit. When a bus error occurs, TWINT is
set. To recover from a bus error, the TWSTO Flag must set and TWINT must be cleared
by writing a logic one to it. This causes the TWI to enter the not addressed Slave mode
and to clear the TWSTO Flag (no other bits in TWCR are affected). The SDA and SCL
lines are released, and no STOP condition is transmitted.

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


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

2 oran-be Ну и зачем так многа букаф?Вы утверждали,что у AVR кривой модуль TWI,а теперь са-
ми признаетесь в кривизне реализации.
Теперь насчет

Очередной бред.Откуда эти данные?Результаты долгих экпериментов бессонными ночами.?Тогда вы да
ром теряли время.
У меня есть система многоточечного котроля температуры в зале с мощными TV и FM пердатчиками.
Хост контроллер,связанный через RS-485 с 2 периферийными контроллерами на Мегах8.На каждой из
Мег висит на I2C по 8 датчиков температуры DS1621.В полную параллель,без экранированных про
водов-на плоском 4-х проводном шлейфе.Единственно,скоость TWI выставленно минимальная-што-то около 10кгц.Никакой паузы в 12-15 мС при NASK нет и в помине,все пашет без сбоев уже больше
3 лет.

Кстати вот интерсно, вот помотрел я ПЛК по Вашай ссылке, и совсем не впечатлился,
у меня мега8 успевает сделать несколко больше, и при этом, один из вариантов конфигурации,
когда она работает на внутренних 8Mhz все равно дает больше возможностей.
Может я чего не так понял ?

Я думаю, что Вы не поняли, что Овеновский ПЛК может быть установлен и настроен тупым монтажником, не знающим ни С, ни тем более ассемблера. В этом цимус ПЛК Или у Вас Мега8 тоже может отдаться такому монтажнику?

ну во-первых в моих исходниках асемблера нет вобще, кроме
команд типа asm("wdr"); asm("sei"), и то чисто по привычке
Во-вторых, моя мега8 могла бы отдаться и такому монтажнику, если он конечно читать умеет
Я конечно не спорю что для ПЛК там стараются упростить как можно больше,
но все-таки TTX девайса не должен кардинально страдать.

Спасибо ,хоть ко мне это не отнеслось


а) Понятное дело
б) Если читаем ,старт потом адрес (получаем первый НАСК) ,ячейка (получаем второй НАСК) ,рестарт и адресс (получаем третий НАСК) .Есть такая пословица ,1 раз - случайность ,2 раза - совпадение ,3 раза - закономерность
в) Естественно ,если трижды не дошло
г) Да ,есть такое дело ,тоже как то уперся рогами ,ни одного упоминания тоже тогда не смог найти ,помог простой анализ ,дело в том что после стопа флаг TWINT не проверяется ,и все что нужно было сделать ,так это ввести тупую задержку равную 1 такту CLK .Многие как правило "случайно" обходят эту проблему ,так как часто между стартом и стопом идет выполнение программы большее этому периоду или при записи допустим в ЕЕПРОМ все равно нужно делать значительную задержку .
Мне немного повезло больше ,я это обнаружил на "заре"освоения TWI

Вопрос по теме ПИК или АВР
Стоит ли менять шило на мыло ?
По мне если уж и осваивать новую архитектуру ,то уже сразу типа АРМ-ов.
Кстати про них потихоньку почитываю ,могу сказать очень солидненько ,
понравилось ,что все команды могут быть условными,хотя кое что на мой взгляд ,тоже сделано через одно место

Причем тут ПДП-11? Если мне память не изменяет, "Тезей" это не сильно удачная попытка скопировать (в добавками) 84-й ПИК.



Трудности с писаниной? Да вроде нет. Вообще - какая разница под какой проц писать? Как и какой проц осваивать? Когда это 1-й или 3-й - это еще может, когда их второй-третий десяток пошел - это уже без разницы.
Любой новый проц - 2 часа на чтение даташита, остальное - "в процессе". Чуть больше может уйти на освоение незнакомой до тоо среды программированияя и/или особенностей компиляторов.

В целом же - выбор проца и т.п., это не техническая проблема, поэтому меряться пи..ками как тут все время происходит - совершенно бессмысленно. В 90% случаев проц выбирают совсем под другим соображени, чем "сколько мипсом на 48мгц".

Да какая нафиг разница, сколько у него мипсов, если AVR и PIC16F819 не могут обеспечить достаточную для работы UART'a (или чего подобного) точность внутреннего тактового генератора в диапазоне -20 +100, а ST7Lite09, PIC16F88 или F690 - могут ?

И это еще более-менее техническая проблема, в основном на выбор влияют как я уже говорил - не технические.

Превосходно знаю этот камень, даже активно в своё время использовал в своих разработках, но при всей его уникальной и в чём-то достаточно удобной архитектуре считаю его... редкостным г. - сначала по качеству (процент брака в партиях доходил до 10%), затем и по отсутствию какого-либо развития, абсолютно мёртвой поддержкой, и информацией об изменениях в кристаллах... этот 1878ВЕ1, кстати, до сих пор выпускается с абревиатурой "ОП" А последний "осиновый кол" в этот контроллер "забили" с момента жуткого повышения отпускных цен на него - дешевле стало переработать изделия, чем закупать ВЕ1.



Ещё как тут говорят некоторые трезвые головы: сравнивать 8-и, 16-и и 32-х разрядные мк и дсп абсолютно бессмысленное занятие - это принципиально иные платформы/понятия/методы, отсюда совершенно разная производительность, которую мипсами ("попугаями") без всякого принципа не корректно мерять. Пример: три года назад переносил проект управления 5-ю ШД написанный на чистом C с PIC18F452 на TMS320LF2406A с удвоением числа ШД - результат меня по началу ввёл в некоторый ступор: если на пике проект откровенно был "затолкан ногами" как по коду, так и по производительности, и в некоторых местах откровенно "тормозил", то на тмс'е с удвоенным колличеством ШД это занимало всего порядка 25% от его производительности. При этом из внешних аппаратных возможностей в обоих проектах использовал только USART и SPI. И всё это при четырёхкратной разнице в "попугаях" и на мой взгляд не самом удачном решении USART'а на тмс'е.

Я наверное не трезвый - я сравниваю. Естественно по самому важному параметру - целесообразности применения. Приведенные Вами PIC и TMS по цене отличаются незначительно и в ценовой категории помянутого PIC буквально тесно от 32 битников.
Так почему-бы и не сравнивать честно, без оглядки на "особые условия" в виде восьмибитовости. А то получается, что-то типа - автомобиль жигули самый лучший, но среди российских .

эээ... либо я выразился не совсем точно, либо мы немного недопоняли друг-друга: я хотел сказать, что сравнивать совершенно разные мк с точки зрения разрядности/архитектуры в рамках мипсов-"попугаев" далеко не корректно. Насчёт приведённых PIC и TMS замечу, что это сейчас тесно от разных интересных предложений в их ценовом диапазоне, а три года назад там было слегка пустовато, да и упомянутый PIC уже давно имеет более интерсные аналоги.

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

Жызнь поворачивается щас таким боком, что затраты на инструментарий становятся реальным фактором. Конечно, 3-4-5Куе на рабочее место для какой конторы и не деньги, но всё-же... Если задача решается на мелком ядре с бесплатным инструментом, есть соблазн пользоваться этим. И пользуются. И считают такую возможность реальным плюсом некоей архитектуры. Например, для АРМ, ни один из производителей такого не сделал. И понятно, почему. ;О) А пользоваться ворованым становится опасно.
Да и созданная инфраструктура под мелкие контроллеры тоже стоит времени и денех. Поэтому я, например, буду пользоваться мелочью до упора. И в новых разработках, в том числе. Кидаться на новый супер-пупер чип раз в пол-года, слишком расточительно. ;О)

Разум говорит о том, что надо применять ARM. Плюсы, в общем-то, очевидны:
1. Широкая номенклатура, выпускаемая х. тучей разных фирм.
2. Вполне пристойные цены.
3. Большое количество соратников, готовых поделиться информацией в особо трудных случаях.
4. Огромное количество готовых решений, включая различные ОС.
5. В принципе, не очень дорогие средства отладки.
6. Все яйца в разных корзинах (если завтра кто-то из производителей, чей МК ты используешь прекратит их выпуск, то послезавтра можно найти пристойную замену).
Ну и вообще, по нынешним временам, ARM - это нечто, аналогичное архитектуре i486 в PC-строении.

Но все остальные чувства возражают в пользу dsPIC(PIC24) и иже с ним.
1. Пристойные средства отладки для ARM требуют денег или лекарственных препаратов. Первое практически невозможно, а второе преследуется по закону и вообще гемор. В случае с dsPic, все это бесплатно.
2. Наличие нормальных (DIP18, DIP28, SOIC18, SOIC28) корпусов, которые лично мне необходимы для отладки и ручной сборки, как наиболее дешевой.
3. Нет необходимости напрягать мозг при изучении достаточно путаной и непрывычной системы команд ARM. Одна возможность условного перехода из любой команды чего стоит.
4. Не очень удачная финансовая обстановка, сложившаяся вокруг ARM. За малейший инструментальный пук в сторону ARM, его произведший хочет немеряных денег.
5. Ну и еще некий неосознанный страх перед общей монстроидальностью и необозримостью (в техническом плане) такого девайса как ARM.

Иными словами, если ты контора с деньгами и хочешь на этом заработать как следует, то тогда ARM и ничего иного.
А если ты слесарь одиночка без мотора, к каковым отношу и себя, то тут есть два варианта - либо бросить все, либо PIC, AVR, MAXQ2000, eCog1k, eCog1x и т. д., кому что нравится больше. Похоже за бесплатные радости надо расплачиваться ценой на сам девайс.

Чушь. ;О) Вполне "с деньгами" контора часто и густо пользует бесплатное. И мелкие чипы. И прекрасно себя чувствует.

Нет я все понял , но намеряно перевел сравнение в другую плокость подальше от попугаев и битовости. Все нормально!





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

Искрене жаль.

Расточительно свое время тратить неэффективно, все остальное в общем-то не имеет значения.

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