Совершенно верно, именно так - разбираюсь. Проблема (не моя а производителей тормозных по нынешним временам восьмибитовиком по цене заметно более шустрых 32битовиков ) только в том, что для восьмибитовиков со стоимостью более 3-4 баксов задач, на которые их имеет смысл ставить уже пожалуй нет.
Чего уж тут не понятного?
Ну а конкретно у меня таких задач вообще нет. Даже если по цене проходит и по производительности с возможностью написания портируемого кода все более, чем хорошо, то использовать какой-нибудь восьмибитовик я не буду. Его с легкостью (особенно у некоторых фирм, которые всякие разные и среди них свои безальтернативные контроллеры производят) могут снять с производства. В моем случае еще частенько требования к софту в течении срока эксплуатации могут изрядно повысится и заниматься upgrade железа себе в убыток совсем не хочется.

Кстати! Все как то дружно забыли что у ATMEL есть 94 серия. 99 года разработки! ИМХО по прежнему очень достойный кристалл. (где только систем десигнер взять?)

Ну это уж через-чур сильно сказано,имхо.Таки пока есть еще.

вообще то было бы интересно знать, как это по Вашему мнению Atmel ( или Microchip, Freescale, NEC, Renesas ) просто скажут, все би&%#¤!, больще от нас ничего не получите ? в реалии все подготовят алтернативныи продукт и лищ после нескольких лет могут снять с происводства то или иную схему. при этом я ( Вы ) сам(и) лично даже не обязан(ы) следить за этим, поставщик посылает и-маил о том когда выпуск сокращается и до какого числа принимают заказы.
также хорошо не понимаю как Вам удастся ARM в любое устроиство ставит, но если требуется 16PWM то просто нет алтернативы SH , или если энергетика всего несколько mA.

Именно так. Либо не получите, либо подстроитесь преработав железо и/или софт или будете платить в разы большую цену. Филантропов среди производителей нет.

Любые исключения возможны. Если сочтете за труд ознакомиться с веткой, то я не призываю всегда и везде ставить ARM. Я призываю не ставить всегда и везде восьмибитовики только по привычке, что согласитесь, совсем другое. А альтернативы есть всегда и везде. Для микромощных это, напрмер, MSP430, кстати, не восьмибитовик .

да нет у zltigo таких задач. Все это для него "уникальная периферия". Ну дайте же мне АРМ с драйвером сегментного ЖКИ! Хочу АРМ с EEPROM. Нужен АРМ с потреблением с слипе 0,2 мкА и RTC 2-3 мкА. Так же не отказался бы от АРМ-а с честным motor-control PWM (аппаратный fault, dead-time, триггер АЦП с произвольным сдвигом фазы относительно периода ШИМ и т. д. и т. п.). Кроме того, хотелось бы АРМ в QFN 2x3мм корпусе о 8 ногах. И неплохо бы АРМ с 12битным АЦП, каналов 18 минимум с 100 ksps.

И еще вот опять же никак не врублюсь по поводу портируемого прозрачного кода. Что мешает так же писать на 8, 16-битниках? Да ничего, объемы SRAM и Flash внутри сейчас уже это позволяют. АРМ почему-то выступает как панацея - типа одно ядро - много вендоров. ИМХО для меня ядро не самое главное, с ARM асмом хорошо ознакомился недели за две листая листинги со словарем инструкций. Самое главное периферия.


>> Именно так. Либо не получите, либо подстроитесь
>> преработав железо и/или софт или будете платить
>> в разы большую цену.

ну х.з. тот же микрочип до сих пор поставляет древние однократки, и даже выкидыш PIC14000 (впрочем довольно удачный). И не собирается снимать их с производства. И вообще, чего то не припомню, чтобы микрочип пугал dead-time-ом на контроллеры. На RFID - да, на последовательную EEPROM - да (с адекватной заменой), на RF-приемники - да. Но не на контроллеры.

Хочу сказать, что исследование Hitachi практически полностью повторяет аргументы zltigo. Они утверждают что на рынке со временем останутся 8-ми битники (которые захватят часть рынка принадлежащих 4-ёх битникам) и 32-ух битники (которые захватят часть рынка 8-ми битников и 16-ти битники полностью). Правда они вывод другой делают. Что надо переходить на Hitachi где это единое семейство 8/32 с общими отладочными.

Если в целом доверять такому исследованию, то отсюда следуют такие выводы, к которым, в принципе склоняется большенство спорящих.
1) Нельзя зацикливаться на одном процессоре/семействе. Необходимо внимательно следить за рынком.
2) Совершенно необходимо писать программу так, чтобы максимально легко было переходить с камня на камень.
3) Выбирать для проектирования многоплатформенные продукты. (Для компиляторов IAR/GCC к примеру)

Но из этого отнюдь не следует, что необходимо обязательно переходить на ARM как единственно возможную 32-ух битную альтернативу 8-ми битникам. Здесь я больше поддержу CD_Eater.
1) Малоцелесообразно переходить с одного 8-ми битника на другой.
2) Более простой переход на 32-ух битники этого же семейства.

Хотя я вполне понимаю аргумент zltigo, что использование независимых ядер обеспечивает возможность более широкого, гибкого и максимально независимого от производителя выбора. Поэтому Atmel разработал свои AVR32 которые, заметьте, тоже двумя ногами залазят в нишу их же восьмибитников. Microchip выпускает свой 32-ух битник. Hitachi, Сименс и Митсубиши и т.д. и т.п.

Использование нескольких МК - распределённые вычисления - тоже очень грамотный подход. Это не только уменьшает стоимость системы в целом, но и повышает надёжность системы, упрощает её разработку и обеспечивает лёгкость развития. По этому пути идут уже не только системы но и микропроцессоры. Уже идёт разговор о том что внутри МП связь м/у некоторыми блоками будет осуществляется по последовательным каналам. Да собственно и внутри одного МП программа, в большинстве случаев представляется как несколько независимых процессов (можно представить как МП). Что фактичкски предполагает использование ОСей или их заменителей.

Может время подумать о графике ? Ну с сегментным ЖКИ - MSP430 и микромощный и не восьмибитовик

Использую внешнюю на I2C. Масштабируемо в зависимости от задачи. Крайне недорого.

Это просто другая ниша.

c RTC есть.

То, что вы назвали, это просто специализированны чип у которого еще есть контроллер в качестве бесплатного приложения к железной реализации функции управления приводом. Возможно кто-то и выпускает/выпустит. Как уже выпускаются специализированные комуникационные 32bit контроллеры (в том числе с ядром ARM) нужными мне, но похоже c абсолютно Вам не нужными синхроными интерфейсами, HDLC контроллерами ....
Вероятность того, что кт-то находящийся 'в теме' возьмется выпускать узкоспециализированные чипы на готовом лицензируемом ядре мне представляется большей, нежели чем то, что за это возмется фирма выпускающая контроллеры общего назначения.

И что у Вас будет делать ARM? Мигать шестью светодиодами? Это просто совсем другая ниша.

У кого, говорите, встроен хоть один честный 12bit ADC? Интересно. Мне как-раз, вероятно придется один старинный девайс модернизировать на древнем дорогущем AD c внешим ADC. Вполне обойдусь и без реалтаймовой обработки и 8 Ks/s мне хватит. Ну а про 18 каналов - смотрите ответ про привод.

Уже 'наезжали'. Отвечал. Перечтите.

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

Все верно. Кроме этого:

Редчайшие исключения. Одно я знаю на своей шкуре и этот переход очень условен - все равно рано или поздно все менять приходилось. Второе гипотетически. Третьего не знаю. И уж точно это не переход с AVR на AVR32 .

Ага, графику в счетчик электроэнергии (объемы выпуска в России за сотню тысяч по месяцу) или газа. Ну не смешите уж... Или в комбинацию приборов от Автоваза, графику, ага.

Часто дело не в цене, а в габаритах

Да каждый контроллеры под свою нишу. Не надо низкое потребление оправдывать нишей.

да собственное потребление RTC уже абсолютно не интересует, если ядро в слипе 15 мкА кушает

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

При чем тут светодиоды? Пример уже был - устройство аварийного оповещения (программный I2C + ADPCM). Ну или датчик дыма, если хочется еще. Все это опять же выпускается большими тиражами.

Что есть честный? Честность это какая цифры INL и DNL?
http://www.microchip.com/ParamChartSearch/...n&pageId=74
http://www.microchip.com/ParamChartSearch/...n&pageId=75
http://www.microchip.com/ParamChartSearch/...n&pageId=75
http://www.microchip.com/ParamChartSearch/...n&pageId=75

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

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

Великолепно. Я спрашивал зачем там ARM? Ответа не получил. Типичная меньшебаксовая мелочевка.
Похоже что-то заcтит Вам глаза и Вы не хотите видеть, что я 'покушаюсь' исключительно на целесообразность применения тех восьмибитовиков стоимость которых превышает на сегодняшний день 3-4USD. Про чипы со специализированной периферией тоже писал буквально в предыдущем посте.

Если не трудно, сразу PDF с документироваными параметрами 12bit ADC а не экскурсию по сайту микрочипа. Буде такой будет, остальные походящие я и сам подберу.

Отвечал. Повторяю - написанное относилось именно к писанию на ASM под маломощные контролеры.

Простите, но не могу признать, что все остальные кроме меня занимаются счетчиками газа, комбинациями приборов для ВАЗ(он еще жив?) или БелАЗ(хотя для БелАЗ похоже уже в сторону более солидного функцилнала смотрят), датчиками дыма или на худой конец электроприводами. В то, что все остальные работают с исключительно миллинными тиражами тоже верю слабо. Не берусь точно описать постcоветский эмбеддерский mainstream, но то, что он не такой, как описан Вами, это точно.

Есть и для них ниша - КСД (телемеханика).
Любой контроллер потянет, т.к. поток данных там не более 10kb/мин.
Соотношение цены железо/софт примерно 1 к 100 если не 1 к 1000.

8-ми битник за больше 3-4USD - пригоден к расширению, не требует 3.3/1.8 питания, не требует внешнего супервизора, не требует доп памяти, не требует внешней eeprom, с задачей справляется. Железо предельно простое следовательно и надежное (DC/DC, "одинокий" AVR или PIC, и пара драйверов).

в каком то другом топике эти же слова присвоили к Техас. Hitachi ( ныне Renesas) никак не может публиковать такои чуж, т.к. ои являются самим крупным поставщиком 16 битных мк. и вообще за таким выводом подразумывается 16 битное адресное пространство, что деиствительно будущего не имеет. 16 битные останутся еще на доло , вот Renesas только начинал разработку нового 16/32 ядра.
http://www.renesas.com/fmwk.jsp?cnt=/cisc....rotating_newcpu

Ага, у меня на работе товарищ напихал во все датчики (пожарка) PIC16CE625... И уволился... А я проклял тот момент, когда пришлось все на 16F628A переделывать... Причем, именно на А, там внешний RC-генератор используется, пришлось ждать, пока 628 станет 628А (в 628 не было внешнего RC, только R)...

Хотя, если честно, тут больше сам проспал... Надо было начинать переделку именно тогда, когда первый раз звоночек прозвенел (когда мелкочип объявил о dead), а не когда ОМТС сказал "не могу купить"...

И, кстати, по датчикам (в частности, дымовым)... У меня сейчас используется ATTiny26, причем ее дифференциальный усилитель отлично используется в качестве предварительного усилителя сигнала с фотодиода... В результате ВСЯ аналоговая часть оказалась в проце... Вот буду на ATTiny25 переделывать потихоньку, а вот альтернативы с пичком - нету, да и MSP - тоже, надо ставить снаружи операционник или два-три транзистора... на десятках тысяч - вполне приличная сумма набегает...

Ну прально. У вас нет, а у кого-то есть. Если некая функция выполняется микросхемой за $5, какая разница, что это за микросхема? ;О) А задачи есть всякие. И много.

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