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

Похоже будем Посмотрите на множество тем в 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) конечно...