как-то это ВЕРНОЕ утверждение противоречит Вашим-же 'страшилкам':

Вы кого запугать пытаетесь? Себя? Не надо!

Ну не надо напрягать ASMом не надо! Знать "со словарем" - надо. Уметь писать несколько десятков команд надо, а напрягать мозг писанием на ASM c последующей муторной отладкой с помощью (%:?%* не нужных при нормальной системе программировния) внутрисхемных отладочныз средств - НЕ НАДО.

Помилуйте! Да какое дело Вам до того, как процессор внутри устроен и насколько он сложен?
Я со времен 486 перестал понимать, как устроен и работает много более сложный x86, ну и что ? Пользуюсь и не боюсь

Чего проиграем? ;О) "гораздо больше"? Это не та сущность, чтобы беспокоиться. А руковоцтво, как раз, весьма умное. Работающую вещь ломать надо только по большой нужде.


Именно. Поэтому я пользуюсь тем, что меня полностью устраивает. ;О)

Смысл предельно прост:

1) зачем закладывать на задачу современного "монстра", если в фирме уже есть охрененный набор наработок на "мелочёвке"? тут экономика проста: в проект быстро заложили уже готовые и проверенные решения, не потратив лишних денег и главное времени на разработку.

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

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

Гы... Ну, типа, в устройстве м128 околачивает около 30% машинного времени(в самом тяжёлом случае). Я поставлю АРМ, который будет околачивать 80-90%. И что, я этим застрахуюсь от неприятностей? Контору из вашего примера, скорее всего, сгубило не то, что они использовали процессор не 100 мипс, а 10, а несколько другое, к реальной электронике имеющее косвенное отношение. ;О) Поставить 100мипсовый МК вместо 10мипсового, много ума не надо.

На уровне исполнителей контору сгубило то, что исполнители под чутким прямым руководством изо всех сил тянули 8085 и 51 на ASM в тех местах, где конкуренты уже лет пятнадцать 32bit по полной програме использовали, продвигали, задавали новые и новые планки функциональности и навороченности на фоне мощного снижения стоимости. А когда мудрое руководство сказало, точнее не сказало, а спросило "а почему мы это еще не сделали?"...., то полтора десятка лет застоя компенсировать уже, естественно, принципиально невозможным оказалось на всех уровнях, в том числе и на, якобы, банальном переходе на другие контроллеры.

А я обо што? ;О) Ребята забили на функциональность. И при чём здесь конкретный МК? Ну делали бы они свою убогость на АРМах или Тигровых Шарках каких. Или на повер Писях...Это бы их спасло? Смогли бы отни реализовать развитую функциональность "за один день и одну бедственную ночь", даже сидя на 1000мипсах? Точно так-же нет. Бо портировать имеющееся с 51 на АРМ, ППЦ, х86... неделя работы. А написание с нуля... ;О) Губит людей не пиво...

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

Губит людей сидение в болоте и самоуверенность, что они кропают что-то сложное на ASM под 8bit контроллер и могут жить кропая это дальше. А потом, вдруг, оказывается, что все снаружи изменилось и нужно создать систему, которая вроде и такая - же, но совсем другая. Как автомобиль Запорожец - ну ничем от Автомобиля не отличется - колеса, руль, двигатель, радиоприемик, но не Автомобиль.
P.S.
Давайте завязывать с очередным ответвлением от темы.

Да ланна, речь то не о сотнях мегабайт и не светодиодах. Проблема с МК там самое малое, что может случиться. Если нет этих мегабайт, то никакой МК не спасёт от цугундера. А если есть эти мегабайты, то крутиться им приходится на адекватном МК уже сейчас.
Т.е. если изначально не развивалась функциональность, то не было потребности в мипсах. Раз не нужны мипсы, то не нужен толстый МК. Всё логично. И то руководство облажалось не на дохлом МК, а на совершенно другом.
PS. Это, ИМХО, как раз очень важное ответвление, которое резюмирует адекватность инструмента решаемым задачам. ;О) И приоритету задач над инструментом.

Ну, приоритет спорный
Да в том то и дела, что не овладев инструментом, ты не способен решить новые задачи. Мне лично жалко смотреть на людей, которые 15 лет просидели на asm 51. Задачи то есть, да извилины уже окостенели. А скоро будем смотреть на поколение просидевших 15 лет на asm AVR :-) ( Ну или на C AVR - про себя )
Голова - главный инструмент, а инструмент затачивать нужно, даже на ущербных PICах

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

Похоже будем Посмотрите на множество тем в AVR - начинаются они одинаково ЕСТЬ AVR КОНТРОЛЛЕР. Дальше могут быть совершенно разные задачи от светодиода, сжатия потокового видео,
управления летательным аппаратом,......, но главное - контроллер уже выбран и ни тени сомнения.
Его-же 'все' и 'везде' используют...., продают в DIP на ближайшем углу..., фирма прилагает некий софт с 'библиотеками' и кнопочками на которые нажал и получил 'результат'...., и т.д......
Поколение 51, на первый взгляд несколько другое, но по сути болезнь одна

Виноват. Там я хотел написать следующее:


А в каком месте я там неправ?
Есть, правда, RIDE с компиляторами Ассемблера, компоновщиком и симулятором, но это конкретно под ST заточено.


Хорошо, объясните в кратце тогда как надо.



Дык, никто и не ставит x86 на ответственное оборудование, по крайней мере в чистом виде. А те, кто ставит утверждают, что полностью перелопатили Кернел в используемой Винде именно на микроуровне. Иными словами отчетливо представляют себе, как все это устроено внутри.

Чего тут спорного? Откручивать гайку плоскогубцами или гаечным ключом забивать гвоздь, уродство, ИМХО. Есть огромное кол-во задач, с которыми лехко справляются 4-битные процессоры. И рынок этих процессоров огромен. И там работают не самые тупые люди.
;О) А чего, освоить другую платформу, это сверхзадача какая-то? Уважаемый zltigo убеждает, что это как два пальца об асфальт. И я с ним согласен.
И ваще, какая нахрен разница, "окостеневать" под ПИКом или под АРМом? Если ты в состоянии решить задачу, то решишь её формально и на 51, и на АРМ, и на ППЦ. А в конкретной реализаццыи возьмёшь подходящую платформу. Главное - решаемая задача. Именно она диктует выбор класса платформы: "не хуже ****".

В том, что аппаратные отладочные средства для ARM по стоимомости абсолютно сравнимы cо стоимостью
железок для 8bit. Халявные для LPT стоят примерно 'ничего', оригинальные 250-300, клоны 70.
Более того, они под ARM вообще а не под чип фирмы Atmel c отладочным интерфейсом XXX и памятью в килобайт. Для отладки контроллера с 4K - купите другой . Или сразу покупайте дорогой, но мы не гарантируем, что завтра не выпустим конроллер с отладчным интерфейсом YYY требующий MK3 версии железного отладчика. Я в чем-то не прав в 'обзоре' ситуации с отладкой?

Мне показалось, что объяснял . Писать на C/C++ и не заморачиваться системой команд в 99,99%.
Изредка при портировании залезая в платформеннозависимые куски, разбираясь с компиляцией узких мест или написав руками кусочек наирекорднейшей производительности.

Бред. Ставятся - целый пласт одно-двух чиповых PC индустиального и армейского исполнения. Специализированные контроллеры со 186 и 386 ядром еще выпускаются.

А причем тут Win к контроллеру?



Нет не "два пальца" - любое дело, если его делать хорошо требует времени на освоение приемов и инструментов. Я когда на ARM переползал, имея уже за плечами немалый опыт, до Hello World и портирования простенькой своей операционки со 186 дошел за два выходных дня. Но момент, когда я смог сказать, что я освоил ARM, причем только в его LPCшном варианте наступил не менее, чем через пол года.
Да я не занимался все время этим делом, но времени потратил многие стони часов. Да и сейчас продолжаю.

Не просто это, НО НАДО!!!

Вы не внимательны или я не совсем полно высказался. Я когда разрабатывал - поставил m88. На ней же выполняю доводку если такая требуется. А в серии идёт m8. Я просто уточнил, что это серьёзное удобство. Все ноги заняты, а я могу выполнить внутрисхемную отладку. Используя разъём программирования к тому же. Это уже аргумент! И весомый для меня. Это даже удобнее JTAGа в некотором смысле. Как минимум для таких кристаллов.


Такие опросы существуют. Например в виде графика выложены на Сахаре. Делать такой опрос в ветке AVR - бессмысленно.

Конечно это НАДО, осваивать новые МК.(чем я последнее время упорно занимаюсь)

Тока Вы забыли, что есть класc устройств в которых принципиально другие требования.
Ну например всякие мобильные девайсы с необходимым продолжительным сроком
работы от батарейки/аккамулятора, ну или например устройства которые
ОБЯЗАНЫ питаться от батарейного питания в силу их специальной применимости(безопасность итд)
Там применение новейших(быстрейших) контроллеров (ARM например) не то что не нужно, а даже
и вредно.
Есть еще класc задачек например связанный с управлением
питанием (там рулят младшие пики например, ну и всякие другие маленькие контроллеры,
названий просто не знаю).
А есть еще класc задач где нужно на большом проце собирать инфу/управлять кучей
входов/выходов аналоговых/цифровых(там как раз живут авр с пик), доверять это большому
процу нет смысла, потому как там жесткий реалтайм и использование чего-нить
сложнее автоматной модели просто невозможно, а большой проц в такой ситуации
будет просто простаивать.

Так что как говорил один известный герой, жизнь она слоями, как луковица


Согласен полностью. Правда мне дают срок месяц (full time)
Правда выливается это в 2 месяца минимум

Совершенно согласен. Есть и будут ещё длительное время ниши которые пригодны для 8-ми битников. И никуда от этого не денешься (и это не только мои наблюдения а например исследования фирмы Hitachi).

Приведу незначительный пример. Предложили сделать прибор. Одно из требований CAN. Я предложил на выбор несколько камней. В том числе PIC, AVR, и LPC2119. На последнем особенно настаивал. Так как на мой взгляд прибор имеет тенденцию к развитию. А перспектива всё таки на стороне ARM. Выбрали at90can128. При том что он дороже! Но есть один нюанс. Там необходимо 24 выхода с 5V 20ма для шаговых движков. Для LPC (И PIC24 кстати) требовалось ставить дополнительные буфера 3 корпуса. И вообще обвески больше оказалось. Прибор мелкий. Но тираж планируется значительный.

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

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




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

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

Как-то непревычно по отношению к МК. Но подумать стоит.


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


Имеются в виду так называемые SoftPLC (пример - CoDeSys от 3S).

Дык это в любом случае просто такая игра между работником и работодателем
Работодатель должен как можно жостще ограничить работника по времени(в разумных пределах),
а работник должен смочь объяснить работодателю почему данная работа
была выполнена в 2-3 раза большие сроки чем хотел работодатель
При этом, при разумном подходе с обеих сторон, все останутся довольны

А знания, они да, останутся и при неразумном работодателе.

P.S. и немного OFF
Как человек который на этом уже собаку сьел, посоветуйте с чего начать:
Собственно есть проц, avr32(ну или Renesas SuperH какой-нить) (все это кстати просто
лежит на моем столе)
Есть линух для этих платформ.
Хочу максимально быстро получить результат на задачках типа замены промПЦ, то есть
нужна некоторая реалтаймовость, типа реакция 10мс(но лучше 1мс, можно и намного хуже, но нужна
некоторая стабильность)
нужно обслуживание кучи всякой переферии (MODBUS(rs485, tcpip), i2c, spi, lcd, итд)
собственно, интересуют любые ссылки на эту тему.

Это и есть "как два пальца".

Для начала, стоит подумать, нужен-ли там Linux . Что-то я среди перечисленного не заметил крутого IP и крутой графики. Для всего остального использование массовых монстральных операционок нужно крепко обдумывать, особенно учитывая достаточно неопределенное качество открытых портов Linux под не десктопные процессоры. Ну а я Linux только на индустриальных PC в окружении периферийных контроллеров использую, посему по реалтаймовым вещам квалифицированно советовать не могу.

Во многом согласен с zltigo по взглядам :D

Как истинный асемблерщик полез сразу смотреть систему команд и ядро.Даже беглый взгляд ,
впечатление - фигасе Мне на АВР такое даже не снилось.И ведь поверте дело даже не в скоростях,
или "жирности" ,а в эффективности команд.
Естественно там где нормально справляеться АВР ,АРМ ставить нечего,я даже не ставлю мегу16 туда где можно поставить мегу8,но ведь рано или позно появятся задачи с которым АВР не сможет справиться .У меня такие задачи давно на очереди стоят ,например работа с цветным графическим ЖКИ или ТФТ,сбор -хранение-обработка или передача большого обьема данных-сигналов,в АВР я всегда испытывал недостаток РАМ.
Цена и доставабельность -уже не проблема
Остается для многих, особенно любителей, проблемой сделать плату с таким мелким шагом,хотя с приходом фотоспособа и это уходит на задний план.
Боюсь что АРМы уже крепко наступили на хвост старшим мегам и пикам.

Задача такая, на пальму влезьть и кое чего себе не ободрать
Нужен ли линух, пока не понятно, справится ли он...
У линуха есть куча фич которые можно нахаляву использовать (tcpip, SDCard, итд)
Но вот насчет того что он справится есть сомнения...
Тогда перефразирую вопрос, в какую сторону стоило бы посмотреть для
реализации некоторой реалтаймовости, и при этом не иметь больших проблем с портированием
TCPIP стеков, обслуживанием SDCard, ну и реализацией MODBUS(over 485 & tcp) конечно...

Ну я в подобном случае опираюсь, естественно, на операционку - для точки отправления года три назад была выбрана FreeRTOS, как максимально соответствующая моему предыдущему опыту собственных систем и относительно бескомпромисная (и соответствующая ARM по весу) среди мелких осей. Обращаюсь, правда, с ней вполне вольно - изменений много, некоторые вещи, типа менеджера памяти вообще заменены на 100%. Добавлена дюжина системных вызовов.
IP стек 'свой' - начинался в 90x из Waterloo - рос, развивался.... Привык я к нему, очень неплохую отладку в него встроил, вот и портирую с тех пор. Файловая система на SD - с минимальнешими изменениями FatFS. На AT45 - своя простенькая, ни с чем не совместимая, но зато максимально быстрая и некоторым закосом в надежность. Само-собой консолька на RS232. Все остальное уже индивидуально по месту.

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

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


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

P.S.
Давайте попробуем держаться к выросшей теме. Для Ваших вопросов желательно создать отдельную тему, естественно перед этим поискав на форуме.

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

В принципе здесь я как раз стоял на стороне работодателя. Да его кругозор подвёл или он текущие вопросы поставил выше задач длительной перспективы.

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

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

Да, выпирает Однако, то, что и его обозначили в этой ветке это тоже правильно.

Надо! Так жизнь интереснее, разнообразнее и движется вперед, да и самого себя, как минимум, уважать надо.

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

Да пока не в этой они ценовой нише, вот в чем дело! Пока площадь кристалла будет играть решающую роль в стоимости контроллера, 8-битники будут дешевле. Ну, допустим есть LPC2101 за 2 бакса, но много вы там напишете "прозрачного, сруктурированного, сопровождаемого, развиваемого и портируемого кода" в 2 кБ ОЗУ и 8 кБ флеши?

Все восьмибитники не дороже 2x баксов? Нет? Почему? Что скажете про восьмибитники за 4-6-8...18 баксов и их конкурентоспособность c тем-же 128K + 32K RAM LPC2105 за 5 баксов против Atmega128 c 128 + 4K RAM поядка 10 баксов? Или 2138 с 512K Flash за 7USD? Кстати, 2101 реально полтора бакса. Это изначально 'толстые' ARM. Изначально мелкие Luminary Cortex еще дешевле на пол бака-бакс за те-же размеры Flash/RAM. Ценовая категория уже давно одна, хотя 8bit продукция Аtmel уже зачастую подороже будет

Как ни странно в 8K LPC2xxx в THUMB моде с оптимизацией по размеру для С кода довольно много - у меня в 6,5K Bootloader, загрузчик во Flash (AES/HEX), консолька отладочная для Exceptions, ну и еще по мелочи. При этом подавляющее количество исходников просто отпротировано с других платформ (в частности с AVR и PC), все вполне читаемо, модифицируемо и развиваемо.

Забыли добавить 4 таймера (16\32) ,2 УАРТА,2 И2С ,2 СПИ и 70Мгц ,хотя по идее восьмибитники полюбому должны быть дешевле ,если не будут ,их через пару лет покупать никто не будет
Вообще у АРМ есть предложение для тех кто шугается 32бита , THUMP называется ,система команд практически индентична 16-ти битовой АВРовской

До кучи RTC и 8 входов ADC.

Ну этого нет и не надо

ИМХО, THUMB(16 бит) в арм пользьзуется мало кто, если хотите
большую плотность кода, то смотрите в сторону Renesas SH2-A или AT32AP7000.

Думаю ,что плотность задает компилятор , щас смотрю пока в сторону Филипсов и кейла ,потренирусь
может гляну на что нибудь другое
Сам кейл по умолчанию дает компиляцию программы в 16 бит ,а прерывания в 32 бита ,хотя можно разбивать чуть ли не каждую функцию на свой лад разрядности.

У m128 есть шина, и периферия более подходящая для ряда задач. Плюс защита в M128 сделана на порядок лучше. 5V мощные выводы, правильный PWM.

У меня на столе лежат два устройства-близнеца, m128 + 64k SRAM + rtl и LPC2106 + плиска + rtl.
Задача девайсов следующая - NAT роутер не сильно большого потока трафика (до 2kpps (2Mbps peak)) + звуковое оповещение.

И mega прекрасно справляется с задачей и lpc.
Самое веселое то, что базово в устройство закладывали LPC, но потом решили переделать на m128 из соображений безопастности и после оценки производительности, порт на M128 занял ровно 1 час. (поудалять непотребное ногодрыганье, и работа с rtl как с внешней памятью + изменение пары define'ов - определяющих типы для ARM'а все что можно вплоть до bool - U32, для меги - где можно U8, где U16, где нельзя U32).

Кода для LPC в ARM режиме получилось ~63k
Для меги - 60k


Я не вижу как прозрачность/структурированность/сопровождаемость/развиваемость и портируемость кода может зависеть того выполнен проект на 8-ми битном МК или на 32-х битном.
Все вами названное зависит только от проектировщиков и разработчиков, а уж никак не от МК под который пишется проект.

Ну это вы погорячились. ;О) Ровно вдвое. В розницу.

Не о том! Речь о противопоставлении писания крутых программ в пару килобайт написанию тех самых прозрачных и т.д. программ на C у которых есть один недостаток - они больше и немного медленнее. Вы же за час не с AVR ASM портировали на LPC? Так в чем непонимание?

Кстати о размерах - при портировании одного куска с AVR тоже получил крайне незначительное увеличение кода на ARM по сравнению с AVR. Помню довольно сильно удивился.






Не знаю о чем это Вы, но LPC в России я покупаю в MT-System за означенные цены, а Atmega128 глянул на efind и выбрал самую низкую цену, хотя там и по 20USD встречались. Так о чем мы это? О том, что 32 и 8 не в одной ценовой категории?

М128 ровно 5 баксофф в ЭФО. В розницу. Речь о том, что если хватает м128, нет смысла лезть в АРМ или ещё куда. С АРМами и прочими ТМСами Блэкфиновыми геморрою малость больше. Питания разные бывают. Ещё чего. Не смертельно, конечно. Когда есть смысл с ними связываться. А когда нет, то и трепыхаться смысла нет. Лучше потратить время на улучшение функциональности. ;О)

имхо , наверно они излишки скупили. По findchips.com (а это мировые цены с небольшой натяжкой доллар не более) дешевле 9 с копейками баксов нет.

Также есть местные поставшики работающие с Китаем - 1280 предлагали за 7 евро. Потом спросили и ничего менее 10 не дали.

Это про м128? Мы примерно за эту цену берём их в течение пары лет. Начинали с 6-7, теперь вот 5. В Аргуссофте те-же, тока вид сбоку. Ну мож чуть дороже.
В ЭФО 1280 за 8,89. Не евро. Розницца.

Договорились, пусть будет по ЭФО - 5 баксов. Эти 5 баксов полностью эквивалентны 5 баксам за LPC?
Даже если да, то к чему было поддерживать такие утверждения:

Вопрос о том, что 5USD это за 8MHz а за 16MHz даже в ЭФО уже хотят от 7 баксов, а тот-же LPC 70MHz за свои 5 баксов перед истинными ценителями, полагаю, ставить бесполезно Мегагерцы им не нужны, а разницу они с удовольствием жертвуют любимой фирме.

Очень верное утверждение. Если покупают за 5, зачем продавать по 4? Хотя можно и по 3 и по 2. НХП зарабатывает на своих ЛПЦ пол-бакса-бакс, а эти за счёт площади 2-3(образно говоря). Тем более, м128 и обычная какая ЛПЦшка утилитарно не равнозначны. Количество и качество портов, наличие шины, требования к питанию и их кол-ву...Да, 50-60мипс, а они мне нужны? Вопрос целесообразности. Я-ж не зря говорю об инфраструктуре. Если при всех прочих условиях разницы я не осчусчаю, то перевешивает инфраструктура: программаторы, рабочие места. Тут кто-то про "окостеневание" писал. Дык, какая разница под чем костенеть. Развивает не камень на котором сидишь, а задачи, которые решаешь. А камень - дело наживное. ;О) Подкатилась задачка, а вот и камушек! Недельку покувыркался, а там и пошло...

Извиняюсь за оффтоп , а партия м1280 нормальной вышла? Мне штук 200 надо сейчас, правда не знаю, растоможка это головная боль - может ли ефо чтото подправить насчет цены в посылке?

Есть в этой всей дискуссии другой аспект - при усложнении устройств нет смысла делать его самому, а можно использовать что-то готовое. PDA c WIn CE, ARM c Linux, UMPC с чем оно там... Интеллектуальное реле, в конце концов :-)
Это ув. zltigo имеет и свою реализацию tcp/ip, и свои ОСи, и много еще чего. А у меня нет этого ничего и не будет, я пойду путем использования готовых устройств. Скажете, что в система будет нереального времени, так, имея столько задач, в любом случае временные параметры системы падают.
Ниша эмбеддера ограничена сверху, остается вопрос этой границы. А тут уж каждый выбирает для себя - от AVR ASM до Win Kernel, от PIC12 до BlackFin или что там

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

Да, и этим самым ниша сдвигается вниз.
Получается, что проект на той же ATmega128 или ARM может быть сделан на PocketPC + PIC12
Pocket достается "чистому программисту", а это г.... известно кому

Во-первых, покетные ПС применяют только поляки. Уважающие себя люди так не делают.
Во-вторых, на чем, по-Вашему, можно сделать девайс, определяющий ряд параметров изделия при условии что этих изделий через девайс проходит 11000 штук за 1 минуту? Я так полагаю, что PIC12XXX там не прохляет.
В-третьих, проекты "чистых программистов", как правило, не работают. Проверено. На моей памяти по крайней мере 3 машины были демонтированы именно по этой причине. ООП не проходит. Первое О уж больно ответственное.
И последнее, поясните, пожалуйста, кому достается г-но на PIC12ххх?