Уважаемые форумчане, хочу помимо своей основной специальности (аналоговая эл-ка) научиться работать с МК. Опыта почти нет, только в институте 8 лет назад немного программировал PICи на ассемблере. Есть два вопроса:
1. Какое семейство МК выбрать для изучения
2. С чего начать, что почитать для самообучения.

Мои приоритеты критериев выбора семейства в порядке убывания важности:
1. Универсальность применения
2. Перспективность развития
3. Простота освоения
4. Широта возможностей, вычислительная мощность.

Всем заранее спасибо за внимание.

Универсальных семейств не бывает.
Я советую начать с AVR ATmega 16/32, программирования в среде IAR C и отладкой с под JTAG ICE.
После этого будет легко работать с MSP430.
Но если в ближайшей перспективе быстродейстующие устройства с вычичлительной мощностью , советую dsPIC/PIC24.
ARM без освоения C cмысла не имеет.

Из своего личного опыта скажу, что освоение ради освоения большой пользы не принесёт.
Ставьте задачу и исходя из неё выбирайте.
Если для себя, то лучше наверно начать с AVR.
Очень много информации и продаются на каждом углу.
Мне оччень msp430 нравится, а если новый - я бы SiLabs поизучал, очень интересно.
Или к примеру системы на кристалле (не помню как называются) - это мк+программируемая аналоговая обвязка на одном кристалле.

Всем спасибо за советы. Задачи возникают непредсказуемо и чаще не в связи с деятельностью моей фирмы, т.е. полупрофессиональные. Например, сейчас для меня актуальна такая задача:
midi клавиатура
еще планирую в ближайшее время сваять контроллер бесщеточного мотора. С другой стороны, научиться сопрягать цифровой вычислитель с аналоговой обвязкой -тоже очень привлекательно.
Можно ли как-то сузить круг рекомендаций?

AVR. Любой. Для начала помахать ногой, дальше пойдет легко и сами выберете конкртный, подходящий под вашу задачу кристалл из семейства. Железо программатора - на 74HC244, софт программатора - avreal (гугль найдет). Язык документации - английский. Язык программирования - С, компилятор - avr-gcc, бесплатный, (под винду - в виде пакета WinAVR), можно в комплекте со средой Eclipse или любым любимым текстовым редактором. Это чтобы начать буквально за полчаса и 50 рублей, без всяких эмуляторов.

После AVR переход на практически любой процессор (например, на поминавшиеся здесь MSP430 или ARM) будет проходить легко. Нужно вам будет переходить или нет - решите сами, почитав на досуге документацию на них. Когда у вас будет хоть какой-то опыт, вы будете знать - какие именно разделы документации для вас важны и по каким критериям процессоры надо сравнивать для ваших задач.

MSP430. Архитектура проще (фон Нейман vs Гарвард), чем у того же AVR. Ядро продуманней. На асме опять же писать короче и приятнее. И на 74НС244 получается уже не только программатор, но и эмулятор.

Спасибо за Ваше мнение. Насколько я знаю, под AVR есть множество ценных аппноутов, в частности для управления бесщеточным двигателем, что для меня актуально. Там дается уже готовая программа. А как с этим делом у MSP430?

Да, только QFP в домашних условиях не любой распаяет (не говоря о плате).
Вот я чё подумал.
Хотя есть вроде и в соике, но они какие-то мелковатые (по функционалу)

Распаять - не проблема, у меня на работе есть все необходимое оборудование, да и плату сделать - не проблема.

Не так страшен зверь... Легко паяется, главное для этого - флюс хороший. И паяется обыкновенным паяльником. Конечно, немного дольше, чем микроволной, но вполне приемлемо.


Для освоения МК вполне вариант.

P.S. Автор темы уже сообщил, что распаять QFP для него не проблема, тогда лучше и брать что-нить типа F169, в нем всего вдоволь, можно разнообразно потренироваться. И для аппаратной отладки тоже хорошо - целых 8 точек останова.


Под MSP430 тоже всякого добра хватает. Гугл сразу дает массу ссылок по MSP430 brushless drive. Сам конкретно этой тематикой не интересовался, но помнится, что у TI есть сборник апликух, где в том числе и эти вопросы освещаются.

Вообще, для написания программы нужен не столько чей-то исходник, сколько сам алгоритм и понимание оного алгоритма. Если вы этим владеете, то написание программы под тот или иной МК для вас не будет проблемой. Особенно, если писать на С, а именно к этому и надо стремиться хоть на MSP430, хоть на AVR.

По периферийным наворотам MSP430 AVR'у точно не уступает. В частности, у того же F169 можно организовать аппаратный трехфазный ШИМ с "мертвыми зонами", как раз для управления двигателем. По вычислительной мощи MSP430 тоже поинтереснее будет AVR'а. Не хочется тут разводить очередной флейм MSP430 vs AVR, спорить не буду. Работал несколько лет на AVR, затем несколько лет на MSP430, сравниваю по своему опыту. MSP430 легче в освоении, к нему многократно дешевле средства эмуляции (можно сказать, копеечные, изготавливаемы на коленке), по основмым возможностям не уступает AVR, во многом превосходит. Есть несколько моментов, где AVR имеет преимущество - это, прежде всего, скорость программного ногодрыгания, наличие EEPROM, толще флешка у старших, хотя сейчас уже, вроде, порог в 64к преодолен на MSP430 (не работаю в настоящее время с МК уже года три, не слежу пристально). Больше навскидку не вспомню.

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

Зачем брать дорогой MSP если дешевле и мощнее LPC-ARM от NXP ?
ИМХО только в одном случае такое требуется - при жёсткой экономии питания, а в остальном напрасная трата времени на изучение проца. Бесперспективно.

LPC2xxx однозначно подходит под такие требования.

Плюс ещё:
5. Низкая цена.
6. Хорошая периферия.
7. Быстрый ногодрыг.
8. Много рамы (гораздо больше чем в AVR и MSP вместе взятых )
9. Много флэша (гораздо больше чем в MSP)

Спасибо большое, после таких ответов гораздо отчетливей понимаешь, как надо жить

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

С ARM'ом же вопросы начинаются уже с того, какого производителя пользовать (Atmel, NXP, ST, AD, TI и т.д.) и до сих пор на этом форуме к единому мнению не пришли. Очень это кстати для начинающего изучать процессоры, который пока даже основые фичи оценить не может по причине отсутствия всякого опыта.

P.S. Автору темы: универсального процессора не существует. Каждый чем-то лучше или хуже. В каждом случае надо конкретно смотреть. Часто области применения перекрываются и тут выходят на сцену другие факторы, как то: перспективность данного МК, удобство и возможности отладки, доставабельность и т.д. Но для изучения с нуля считаю MSP430 одним из лучших (если не лучшим) из доступных на сегодняшний день - классическое процессорное ядро, нет заморочек с различными адресными просранствами, ортогональная работа с регистрами и т.д. Кстати, ARM7 в этом смысле тоже хорош, но несколько посложнее будет. Есть много случаев, когда MSP430 лучше подходит к использованию, есть много случаев, когда предпочтительнее будет ARM7, есть много случаев, когда не годятся оба. Начните знакомство с MSP430 (рекомендую именно его потому, что с ним проще начать во всех смыслах) - соберите на 74HC244 FET адаптер и погоняте простенькие программки. Получив первый необходимый опыт, сможете уже сами адекватно оценивать преимущества и недостатки тех или иных МК относительно к вашим задачам. Успехов.

Вот именно по этой причине и НАДО начинать с ARM. Нынешний mainstream и этим все сказано.

То, с чего НЕ НАДО начинать, это 51, младшие PIC, AVR8.

51 тоже разные бывают.
Я вот не против SiLabs попробывать, которые якобы по 16-разрядной математике опускают MSP по самое не могу
Но у нас уже мсп-шки используются как единая универсальная платформа для всего, а следующий апгрейд будет скорее всего на жеод или чё-то в этом роде

Ну, по этой логике надо начинать с x86, мэйнстримнее некуда. Начинать надо с того, подо что задачи лучше подходят. У меня и сегодня ARM7 никуда не приткнуть при всем желании. Контроллерные задачи прекрасно на MSP430 ложатся, и поскольку критично потребление, то и ничего тут АРМ не даст, кроме проблем. А где надо производительность, там Blackfin, АРМу там тоже нечего ловить. Такшта...

Но речь, напомню, шла о том, на чем лучше изучать процессороводство. И тут мне ничего лучше MSP430 в голову не приходит.

Начать программить на АРМе не составляет никаких трудностей. Достаточно знать самый минимум Си. Можно будет уже подрыгать светодиодом, что приводит в "безумный" восторг польшинство начинающих ембеддеров Си изучить гораздо проще любого асма. В моём окружении используются и армы и мспшки, причём где применяются мспшки очень часто возникают проблемы с недостатком быстродействия, недостатком рамы и флэша, хотя главный критерий их применения было низкое потребление. Всё зависит от задач. Но в перечисленных пожеланиях автора нет экономии потребления, так что АРМ без вопросов. Есть в кормпусах 8*8 мм, да и на любой вкус. Можно работать даже на низкой рабочей частоте с потреблением 10 мА если потребуется и в любой момент моментально переключиться на предельную скорость и поработать на ней с потреблением ~70 мА. Да и есть АРМы с одним питанием 3.3в.

Вобщем осваивать его одно удовольствие, ИМХО.

У меня в активе под десяток семейств процов, не считая древней экзотики, поэтому думаю, что важнее не изучать процессор как таковой, а изучать методы решения задач, т.е. построение и реализацию алгоритмов. Этому можно учиться и на РС, причем именно на ней это легче всего, особенно если есть старый комп и на нем DOS . А дальше уже выбирать проц. Если задачи типа управляющих, быстро дрыгать ножками - недурны быстрые 51-вые от Silabs, жрут они немного, примерно как MSP, и АЦП/ЦАП на борту отличные. Если считать надо побольше - ARM, если считать еще больше - для автономных устройств идеальны MIPS, а когда потребление некритично (есть розетка) - практичнее PC (x86) ничего не придумано, готовых плат за разумные деньги вагон.
Все программится на С, ассемблерные кусочки выносятся в отдельные процедуры.
АVR особого смысла не имеют ввиду довольно бедной периферии и неадекватных цен (выше, чем на гораздо более мощные ARM, где есть конкуренция).
MSP на деле хороши только удобством программирования на ассемблере, но сегодня это (писание на асме всего кода) для почти любой реальной задачи становится непозволительной роскошью. Развитие 430-тых у TI - далеко не приоритет, поэтому и идет оно медленно, никакого сравнения с Silabs, к примеру.

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


Не надо путать и мешать в кучу изучение методов программирования и изучение собственно процессора (для embedded применений).



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

Так получилось что первым контроллером у меня был PIC16F84, затем перешел на atmel 51 ядро (AT89S8252). Программировать начинал и те другие на асме, С тогда просто напросто не знал. Тут я понял как ущербны пики. Потом NEC 8 и 32 разрядные и IAR (будь он неладен, до сих пор душа к нему не лежит). Потом AVR - комилятор только CodeVision. MSP430 не впечатлил, буду их использовать только если очень будет напряжно с потреблением. Щас осваиваю ARM (AT91SAM7S). И все же пока предпочтение отдаю AVR - дешевы, функциональны, распространены, простой программатор, удобный компилятор. В настоящее время при освоении ARM опять плевался с компилятором IAR. Для программатора SAM-BA нужен файл bin. Написал программу моргания светодиодом. IAR компилил в bin целых 33 килобайта (!), а в hex 1 килобайт. Как такое может быть? Не понимаю. Вобщем с IAR у меня лыжи не катят. Попрбовал Keil, тот же исходник bin файл 620 байт. Никаких проблем. Программа работает.
Мои предпочтения к компиляторам в порядке их убывания: VisualDSP -> Keil -> CodeVision -> ... Самый последний IAR.

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

Это уже Ваше личное "болото". Мне, например, MSP430 уже полгода приткнуть некуда - повисла разработка, ибо заказчик в помрачении разума, супротив всех "объективных" доводов тяжко задумался и не как не может отказаться от мысли о цветном графическом экране. А что - любая поганая мобилка имеет. Вот и лежат еще и наброски альтернативного варианта на LH7xx и все идет к тому, то заказчик пожертвует энергопотреблением и получит 4" цветной экранчик. А ARM у меня прекрасно уживается в связках с BlackFin и в связках с FPGA (там, где BlackFin "ловить нечего" )



Уже НЕРАЗУМНО ДОРОГИ, зачем-то нужен "программатор", хотя среди ARM-ообразных принято ISP иметь.
C отладочными средствами вечная чехарда и навязчивое желание Atmel срубить на них бабок.
"Удобный компилятор" есть бред - компилятор, это компилятор. Полагаю, ничтожно сумятице Вы имели ввиду IDE - с ней просто IDE отдельный продукт и просто НЕ НАДО ПОЛЬЗОВАТЬ на халяву прилагаемые производителями компиляторов всякие попсовые оболочки. Есть фирмы, для которых это основная работа и они делают ее ХОРОШО.

Лыжи надо смазывать,инструменты изучать. Ругаться и плеваться не надо...

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

Практика показывает, что собственно процессор изучить много легче (с этим справляется большинство младших школьников), чем фундаментальные основы программирования. Поэтому начинать стоит именно с них, а собственно процы смотреть потом, УЖЕ имея представление о типовых алгоритмах, чтобы понять, насколько конкретный проц подходит для их реализации.

И да, и нет. В управляющем коде особенно сложные структуры данных часто просто не нужны, или используются мало, соответственно неэффективность их реализации неактуальна. А шарашить по таблицам и дрыгать ножками современный 50-100 МГц 51-ый, особенно с двумя DPTR, за счет высокой тактовой может очень быстро, быстрее 430, при сравнимом энергопотреблении.

Тогда лучше либо вообще "учебный" процессор, как MIX у Кнута, либо предельно простой, но рационально спроектированный. Буржуи часто (и вполне оправданно) для этого используют MIPS. Я своих подопечных учил на курсе от PDP8, СDC160 и Eclipse до IBM360/91 и Аlpha.

Спасибо всем за мнения и комментарии. Я так понимаю, основные претенденты - это MSP430 и ARM7. Немаловажный критерий выбора - наличие хорошей литературы. Хотя читаю на английском, желательно все же на русском - некоторые термины "с нуля" проще понимать на родном языке. Что коллеги могут посоветовать из литературы для вышеобозначенных процессоров? (возможно, у нас на огороде?)
Для ARM7 на 74HC244 тоже можно программатор сделать?
И еще момент - для какого МК более удобные отладочные средства из числа доставаемых на огороде?

Повторяю - среди ARM-ообразных принято ISP иметь. "Програматоры" не нужны вооще. Не "удобные", не "не неудобные", не на "74H244" ... никакие.



MSP430 не претендет вообще, ибо нишевый продукт. Даже его уважаемому (без всяких задних мыслей уважаемому) аппологету dxp его возможностей естественно не хватает и он в основном, как я понимаю, последнее время использует BF .
Причем между даже между старшими MSP430 и младшим BF на самом деле находится здоровенная "дыра". Та самая серединка, которая, конечно не может поностью во всем тягаться с BF в числодроблении и MSP в энергопотреблении, но тем не менее покрывающая самый большой сегмент.
Кода Вам потребуется исключильно маложрущий (даже скажем так, не сколько маложрущий, сколько хорошо спящй ) контроллер, тогда и обратите свой взор на MSP430. До этого обычные, банальные, майнстримовые ARM - ARM7 или Cortex-M3.

И я о том же. Только "хороший сон" есть и у современных 51, а широта их применения и накопленного софта - много больше, чем у 430. Соответственно, тратить время на изучение 430 - нет практического смысла. Для начала - 51, потом ARM (или наоборот), плюс если повезет - MIPS. Эти три семейства процов закроют более 80% embedded задач, оставшееся - или "тяжелые" процы типа х86/PowerPС, или DSP/ПЛИС.
Можно, конечно, посмотреть на особо экономичную экзотику типа EM-Marin (смарткарточки) или Cyan, но в основном для общего развития.

Не знаю что вы имеете ввиду, мне ваши слова совершенно не понятны. Из ваших слов можно подумать, что прошивка в чип попадает силой мысли. ISP в моем понимании In System Programming, т.е. можно программировать уже запаянный чип на плате через несколько проводков, а не так чтобы толкать чип в программатор и шить по параллельной шине через пару десятков проводков. ISP принято иметь среди всех микроконтроллеров.
dmmos
ARM7 от Atmel можно шить через UART, USB и JTAG. Правда атмеловские армы почему-то многие не любят.

Только для одних требуется программатор разной степени сложности, ЗАКРЫТОСТИ, клонируемости... а для других, например, RS232 и все. Для АRM-ов вполне обычен именно такой вариант. И JTAG - ОДИН ДЛЯ ЛЮБОГО ПРОИЗВОДИТЕЛЯ ARM для отладки, а не, например, целый зверинц отладчиков даже для одного семейства Atmel-овских восьмибитовиков, да и AVR32 по этому-же пути ведут.

У АВР тоже есть ISP.
Программатор от LPT в моём исполнении состоял из DB25, BLS4 и трёх проводков.

Ну просто откровение тысячеления Годится не для всех атмеловских поделок. В следствии зкстремального упрощения экстремально глюковат. LPT мертв, и даже если он увас еще есть, то скоро Вы его этими "тремя проводками" угробите физически. А, под Vist-ой слабо "тремя проводками"? Не чувствуете разницу между подобными "программаторами", например, штатными RS232/USB/..

Висту не буду ставить из принципиальных соображений, максимум - ХР64 (и то заморочки бывают с дровами и приложениями)
Интересно, а ИСП от АРМа каким местом в комп совать?

АВР для меня - пройденный этап, после МСП я даже смотреть на них не хочу.
МСП-рулез, БСЛ-форева. Аминь. (то есть ентер)

Обычно через преобразователь уровней RS232-TTL или с помощью моста USB-COM, но без оконечного преобразователя TTL-RS232. У нас для этих целей (интерфейс для ISP LPC21xx) интерфейс BSL MSP430 используется

Не более нишевый, чем ARM7. Как, впрочем, и почти любой другой проц.


Не спора ради, а прояснения позиции для. MSP430 (и другие мелкие и не очень МК) я не применяю в последнее время в силу специфики задач: чисто контроллерных их у меня просто нет. Много возни с потоками видеоданных, тут скорость на потоках нужна - тактовая, нормальные DMA (в том числе 2D). И в силу того, что дивайсы все больше с автономным питанием, то и потребление малое тоже востребовано. Blackfin для этих задач очень хорошо подходит, я даже не знаю, какой еще проц смог бы составить ему тут конкуренцию (ARM'ом тут точно не пахнет). Но и Blackfin используется не на видеопотоке - весь видеотракт сделан на FPGA, а Blackfin "висит сбоку", "следит" за видеопотоком и корректирует параметры видеотракта. Ну, и до кучи делает всю контроллерную работу - справляется, надо сказать, вполне достойно.

В сущности, ARM7 имеет преимущество перед Blackfin'ом в цене и наличии некоторой периферии. Цена (в пределах нескольких долларов) меня никогда не волновала - массовой продукцией, основную цену которой составляет стоимость электронной комплектации, заниматься не приходится и не приходилось. С периферией тоже вопрос неоднозначный - все от задач зависит. По возможностям ядра ARM'у у Blackfin'а ловить нечего. В том числе и по соотношению производительность/потреление.

Величина "дыры" между MSP430 и Blackfin'ом - есть величина субъективная. Для вас она велика, для меня ее и вовсе нет - они (области применения) даже перекрываются. ARM7 уступит Blackfin'у не только в числодроблении, но и в энергопотреблении (и значительно), и эффективности кода, и даже, насколько помню, в плотности кода, хотя тут разница невелика - субъективизм оценщиков мог повлиять. Главное преимущество ARM7 - его низкая цена при приоизводительности среднего уровня. Что и сделало его популярным. Ну, а дальше работает ПОС - популярнее проц-> выше тиражи -> ниже себестоимость и, как следствие, стоимость -> выше популярность и расширение модельного ряда -> ... Ничего не скажу, ход с точки зрения маркетинга очень грамотный и эффективный, да и проц, в общем, неплохой. Но вполне средний. Без "изюминки".

И хотя Blackfin я считаю совершенно замечательным процессором, рекомендовать его в качестве базы для изучения embedded программирования никак не могу - достаточно сложен, дорогие средства отладки. ARM7 лучше для обучения, чем Blackfin именно по этим критериям. И хуже, чем MSP430.

Возвращясь к самому началу поста:


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

P.S. Вот чего не надо уже изучать, так это х51. Старая архитектура, на которую очень плохо "ложится" код на ЯВУ, а это ключевой момент. Перспектив никаких, альтернатив полно... Хотя в свое время он был очень даже хорош - люди моего поколения и старше имели возможность плотно поработать с ним. Сегодня - это ностальжи по большей части, несмотря на однотактовость и прочие приятные фишки.

А можно узнать, чем эти 2 ядра не понравились? Или понравились?

Были попытки использовать компиляторы Green Hills или родной компилятор NEC?


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

Коллеги! Спасибо за обилие информации, но более актуальны для меня сейчас два вопроса:
1. Что читать (желательно на русском, хотя при отсутствии достойных текстов можно и на английском)
2. Как с доступностью и доставаемостью софта. На этапе обучения разумеется мне не хотелось бы платить за софт серьезные деньги. Если сей щекотливый вопрос стеснительно обсуждать на форуме, прошу написать мне личное сообщение или на почту: dmmosk{@}gmail.com. Скобки убрать, ес-но.
На самом деле, два вышеобозначенных вопроса тоже немало влияют на выбор стартовой точки. Кстати, мои собственные изыскания в этих двух вопросах склоняют к AVR - литературы полно.

На сегодняшний день литературы полно. По AVR сами нашли. По MSP430: в HTML формате:

http://www.gaw.ru/html.cgi/txt/doc/micros/...0/arh/index.htm

В PDF:

http://www.compel.ru/library

там найдете. Кстати, книжки те можно и в бумажном виде найти.

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

Самое смешное, про 51 я лет 5 назад сам точно так же думал. "Ну их в топку". Однако знакомство с объемами продаж х51 позволяет заключить, что они еще нас переживут! Пока даже пик не пройден - растут. Вот почему я про них и вспомнил.

Да что Вы заладили, MSP да MSP. Ну что в нем такого?
FET на коленке не собирается, придется пошаманить, все же не 5 проводков и риск спалить МК сразу - есть. LPT уже отмирает и единственная замена MSP-FET'у - USB-FET, который стоит столько же сколько и J-Link. Только разница в том что J-Link покрывает туеву кучу процессоров разных производителей, а USB-FET только MSP. Документация составлена плохо - стиль изложения сложный для понимания, такое впечатление что документацию составляли китайцы или вьетнамцы.

Стоит MSP дорого, производительность невысокая (8-Mhz в сравнении с 50-100Mhz ARM7 - это почти 0). Требователен к питанию, палится на раз. Периферия построена криво. Без бубна в некоторых моментах не разобраться. Да и какой смысл переплачивать за чип основная фича которого (микроэнергопотребление) не нужна?!

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

Мое мнение таково - если начинать разбираться, то идти Вашим путем - вначале AVR по критериям:
- грамотно построенная, правильно преподнесенная, отсортированная и ориентированная на начинающих документация от производителя.
- легально бесплатный компилятор C/C++.
- качественное и бесплатное ПО от производителя (IDE - совмещающее отладчик, транслятор с ассемблера, симулятор, программатор, редактор исходников и мастер создания проектов на C/C++.)
- большая подборкой примеров и готовых решений.
- нетребователен к питанию (диапазон питающих напряжений 1.8..6V, выдерживает крактовременные пульсации до 10V). (для человека привыкшего работать с аналоговой частью этот критерий важен).
- дешевизна и доступность.

Купив 2 Mega16 первым же проектом в освоении AVR может стать "сделай сам JTAG-ICE", итого на первом MK готово средство отладки попутно изучена базовая схемотехника этого МК, на втором - уже свой первый проект.

Если плюнуть на средства отладки, то 5 проводков от LPT без всяких адаптеров, хватить на то чтобы напрограммировать и наиграться с AVR вдоль и поперек не опасаясь за то, что что-то сгорит.


ARM и MSP на мой взгляд по сложности освоения одинаковы, поэтому если выбирать между ними (цена отладочных средств для целенаправленного человека ничего не значит, все же игрушка для себя любимого) то однозначно ARM и J-Link ибо перспективнее быстрее и "прямее".


PS: извините что несколько с опозданием, но стирать уже не буду...

PPS:

Есть еще одно неоспоримое преимущество - совместимость кода и подобие архитектуры с ARM9 / 11, а это перспектива быстрого перехода на более мощные процессоры. (полная переносимость кода снизу вверх).

Чего к сожалению нельзя сказать про тупиковые ветви "вещи в себе" - PIC, AVR, MSP и BF да и все остальные здесь названные.

defunct
Полность вас поддерживаю касательно MSP и AVR. Еще бы вместе с MSP и PIC туда же. Насчет ARM ничего сказать не могу - пока только изучаю.

Объемы продаж определяются не крутизной х51, а длинной его историей - у данной платформы богатое наследие. И выросло на нем не одно поколение (не раз встречал людей, которые выросли на нем и ничо нового видеть не желают; перепрыгивают с клона на клон, приходя в восторг от новых наворотов очередного клона), и понаделано пром. оборудования тоже ого-го. А срок жизни железяк в промышленности совсем не такой, как consumer области. Вот и потребление.

Но врядли актуально сегодня изучать и ориентироваться на х51. Разве что если сопровождением упомянутого оборудования заниматься.

Я не более заладил, чем оппоненты про AVR да ARM.


Все собирается, не нужно вводить в заблуждение. Лично собирал на макетной плате за полдня. Примерно то же самое, что и STK200, который я использовал примерно в то же время для программирования AVR через замечательный программатор AVReal. Или почти тоже, что и ByteBlasterMV. Кстати, шлейф к ним использую один и тот же.


Это миф. Ни разу ничего не палил. Ни я, ни коллеги. И впервые об этом слышу сейчас от вас.


Он уже много лет все отмирает, только вот что-то никак не отомрет. Мы про сейчас говорим, а не про светлое будущее. Сейчас и в обозримом будущем все есть.


Документация сделана замечательно. Есть, с чем сравнивать (например, AVR). Надо просто понять, как к ней подошли ее разработчики. А подошли они следующим образом: есть толстый мануал на семейство, где описаны ядро, модули периферии. Все эти вещи - общие на все семейство, и при желании использовать другой процессор из этого-же семейства, не надо снова изучать сотни страниц. На конкретный чип есть Data sheet, который по объему небольшой и в нем описаны конкретные моменты, присущие данному кристаллу (объем памяти, какие периферийные модули содержит, электрические характеристики, разводка пинов и т.д.).

Для сравнения возьмем ваш любимый AVR. У него на каждый кристалл идет полная Data sheet, в которой описано фсе! На первых AVR размер оной доки был порядка 100+ страниц. Далее объем рос. На меги типа 16 его размер уже более 320 страниц. Далее, берешь какую-нить модификацию МК и, как грицца, "найдите пять отличий" в более, чем 300 страниц почти одинакового текста!

Для сравнения - на MSP430 этого делать не надо. Общая часть вынесена в User's Guide (тот самый толстый мануал - порядка 450-500 страниц), а сами даташиты - страниц по 80, большая часть, которых занята таблицами с характеристиками. Уж что ни говорите, а ориентироваться в этой доке куда проще и легче.

Написана дока тоже хорошо. Все внятно и конкретно. Возможно, вы по AVR-ной привычке пытались из даташита понять про устройство MSP430. Если так, то это просто ваша ошибка. У многих фирм дока делается по схеме "Мануал + даташиты". Если объем больше 100 страниц, то этот способ рулит. ADI тоже на свои процы делает так - скажете, у них тоже плохая дока?


Смотря с чем сравнивать. И стоимость МК далеко не всегда доминирует при выборе. Кстати, МГц уже 16. С ARM7 сравнивать не надо - когда АРМ научиться столько же потреблять энергии, тогда и посравниваем. А то давайте ваш АРМ7 сравним с Blackfin'ом? И по скорости, и по потреблению. Фин его порвет тут лехко. Но я не считаю это основанием полагать, что Blackfin лучше, чем ARM7. Это разные процы и у них разные ниши.


Тоже миф. Ни разу не спалил ни одного МК. Горелые видел - например, недавно юный коллега спалил - подключил осциллограф, который был подключен к осветительной сети (рабочую сеть выключали, он временно переключился на осветительную, а обратно потом скоп забыл переключить), в итоге перекос по земле (полсети) пролез через МК, тот ниасилил. Но считать этот случай признаком слабости МК - неправильно. Тут любой проц имел полное право "боты завернуть". В целом перегруз держит нормально. И 5 В на вход подавали по ошибке (с ПЛИСки), и статикой в ПП било не раз, ничего фатального не случалось - максимум эмулятор отваливался, требовалось питание перекинуть.


Про кривизну периферии - в студию. По сравнению с AVR так мспшная просто образец. И по замыслу, и по возможностям - сравните хотя бы модуль USART или модуль АЦП.

Насчет энергопотребления - это только одна из фич. Я смотрю на проц в целом. Очень простой, сбалансированный и приятный в использовании процессор.



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


Про доку - см выше. Кстати, есть замечательный перевод фирменной доки на MSP430. Ссыку давал.


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


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


Это все есть, тут нечем удивить.


За 5 В питания - поинт засчитывается. Если кому актуально. Но я так уже и забыл, когда у меня было 5 В. И в округе никого не знаю, кто бы сидел на этом. Т.ч. преимущество есть, но оно сомнительно в смысле аргумента при выборе.


Да уж, видел я этот JTAG для AVR своими руками. Вот тут уж точно на коленке не сделаешь - как минимум ПП надо делать. Поглядел я не это и не вдохновился.

А уж для начинающего это устройство достаточно непростое, и начинать с него, мягко говоря, не разумно.


Да, только вот потрохов не видно. И удобство отладки, так сказать, альтернативное. Уж никак с FET'ом не сравнить. Кстати, LPT'шный FET и работает пошустрее чем дорогущий JTAG-ICE mkII. И поустойчивее.


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


Про переносимость - очередной миф. Уже одно то, что наборы периферии в ARM7 от разных производителей различны, уже никакой переносимости не получается. А если писать на ЯВУ, то и портирование между платформами ничуть не сложнее, чем между армами от разных фирм. Единственное, что дает одно и то же ядро - проще изучить МК другой фирмы, т.к. не надо изучать новое ядро. А разница между ARM7 и ARM9 куда больше, чем между ARM9 и каким-нибудь шустрым DSP. У ARM7 и ARM9 общее только название. Примерно, как AVR и AVR32.


Однако любой из них по ряду параметров уделывает ARM7, что никак не может представить АРМ как универсальную и полноценную альтернативу им.

Поддерживаю dxp.
С АВР на МСП перелазишь легко, обратно уже не тянет.
Очень логичная и продуманная архитектура.
Насчёт цены:
У нас в основном применяются 2 типа:
135 - для маленьких и дешёвых проектов (3-4$ в компэле)
149 - для остального (4-5$)

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

При этом про BSL еще не помянули - для программрования с последующей консольной отладкой самое то. Выпиливается из любого USB-COM переходника и все. Родные USB-ишные FET в виде USB брелков
в составе микроскопических отладочных наборов стоят смешые ~20 баксов. С точки зрения программаторов-отладочных средств для всего модельного ряда более дебильного подхода к делу, чем у Atmel еще не встречал. Надеюсь и не встречу.

Документация сделана нормально, подход Atmel с его "все в одном" и игрой "найди отличия" бесит чрезвычайно

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

А давайте сравним их по размерам/типам корпуса и размерам накристальной памяти? А?

Сильно заточенная под энергопотребление и автономную работу без участия ядра, но не кривая это однозначно!

По сравнению с AVR большинство решений других контроллеров смотрятся приличнее .

Давайте смотреть правде в глаза - это не одна их фич, это единственная, ради которой все и существует. Эта фича реализована ОТЛИЧНО.

По сравнению с AVR8 - да никакого сравнения! Мой опыт с MSP430 ничтожный, но уже совершенно ясно, что применение (и так достаточно редкое) мной AVR8 стало еще более маловероятным. Практически остались экстемально мелкие поделки (коими я практически не занимаюсь) и чего-нибудь с "20mA на пин" (даже не могу пока узреть на своем горизонте).

В группе 51,младшие PIC, AVR, MSP, последний несомненно является самым архитектурно простым, логичным и понятным (если не считать 20bit "развитие" ) это просто чистый идеологически выдержанный 16-битовик.

И и да и нет. Периферия далеко не всегда вся используется - у меня, например, она почти вся самодельная. А вот таскать даже Сишный код между разнобитовыми платформами с сохранением его эффективности это дополнительные ненужные хлопоты. К этому еще добавляется во мнолих случах еще и смена компилятора - еще дополнительные хлопоты. Если это С++, то смена компилятора еще более неприятна. Ассемблерные кусочки тоже иногда крайне желательно писать, а владеть на приличном уровне несколькими ассеблерами это тоже напрягает .

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

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

С такой оценкой тоже согласен.


Вот это и есть то самое наследие + куча софта.

Задач под MSP у меня не было, но в качестве общеобразовательной программы решил что надо попробовать. Интерес к этой платформе у меня был. Начитался документации, почитал про ядро, почитал отзывы на форумах. Понравилось.
Купил десяток МК, собрал макет.

Дошло дело до программатора, идею BSL не понял вообще. В чем оно работает неизвестно.
пробовал собрать FET, с первого раза не получилось.

STK200 для AVRки сразу получился,
ByteBlaster тоже.
Горе Wiggler и тот удалось подружить хоть как-то.
А вот с MSP не фарт. Почему так не знаю.

Чтобы не терять время, пошел да купил готовый USB-FET (валяется сейчас без дела).


Написал первую программку, пока отлаживал подал 5В и сжег МК.
Опять не фарт.
Взял второй. День провозился для того чтобы запустить тактирование от кварца!
Запустил, помигал светодиодами.

Решил испытать как работает АЦП. Мамочки, а его оказывается надо программно на компараторе делать! Вот тебе раз. UART оказывается тоже предлагают сделать программно. LOL.
И это в чипе который дороже AVR mega16.

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

Старшие модели чрезмерно дороги, младшие - чрезмерно убогие и при этом недешевы.


В материнках уже нет, дополнительный LPT адаптер? Ок, ну ведь тоже деньги, и не всегда есть свободный PCI.


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


Ну допустим хочу я найти как настроить клок.
В Atmel документации да и не только Atmel - берется документ на конкретный девайс, кликается на раздел System Clock and Clock Options - там расписано все о тактировании этого конкретного девайса.

В TI даташит на конкретный девайс мне рассказывает сколько много разных вкусностей есть, при этот ни слова не говоря о том как их использовать!! Я должен бродить по куче разных документов, в поисках раздела, а где же устройство тактового генератора. Найдя его я должен 10 раз убедиться а подходит ли то что я нашел к конкретному моему part'у.

Это вероятно очень удобно для начинающих. Да?



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


Это показывает, что Atmel с уважением относится ко времени пользователя. Возьмем даташит на любой компонент будь-то SDRAM чип, драйвер, или транзистор - в нем есть все про этот конкретный компонент, как его включать и как с ним работать! Почему с MK должно быть иначе?


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


См. выше. Как говорится а ХЗ, что в толстом мануале относится к чипу который мы выбрали, а что не относится.


TI / ADI компании которые как бы это сказать "на своей волне". Для меня они не показатель. Точнее показатель того как делать не надо. Не надо строить документацию на МК на подобие документации к DSP.
У TI нормальная документация только на продукцию BurrBrown, и то потому что ее писала BurrBrown, а не TI.


На потребление мне плевать. Я сравниваю по сложности освоения.
А под BF вообще можно писать на каком-нибудь нормальном языке?


Потребление мне фиолетово, как уже отметчал выше, а насчет скорости... Сдается мне, что за время потраченное на освоение BF и на написание чего-нибудь серьезного под VDSP++, можно освоить ARM, слепить на нем простенькую MPP систему, адаптировать готовые решения, в итоге порвать BF и по скорости.

Только не подумайте, что я неуважительно отношусь к DSPшникам, DSPшники это конечно respect и круто. Мои "наезды" лишь только на тёмную сторону DSP - сложность в освоении и трудоемкость в работе.


Ну тут Вы мое мнение знаете - BF - это не MK.


Если бы этой фичи в MSP не было, то круг пользователей сократился бы катастрофически. Ибо чем бы он тогда был лучше семейства M16C?


А вы работаете с тем и другим параллельно? Если нет то Вы не можете судить


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


В программной модели разницы все же практически нет. MMU да кеш, вот и вся разница. Такая же разница между ARM9 и ARM11, чуть более продвинутое MMU и чуть больше кеш. Увидеть эту разницу пересев с ARM7 на ARM9 - не составляет труда. Идеология написания ПО, инструментарий (по крайней мере если пользовать RV) одинаковый. Так чтааа...


Естессно меньше.
135 это нечто между m8-m16 ($0.9-$1.7 в виакоме).
149 - нечто между m325-m64 - ($2.2-$3.2).

А идею Atmel-овской SAMBA для ARM поняли? Если да, то какие проблемы?

Как я понимаю, это и послужило причиной всего нижеизложенного Есть масса людей которым не удалось с первого раза запрагроммировать AVR - даже этот форум полон вопросами этих "несчастных". Разве это что-либо значит???

Не знаю, что это за чип и даже семейство, то ADC более, чем приличные и очень навороченные. UART вполне минималистичен (следствие того, что это одна из функций мнгофункционального узла), но тем не менее одного поля с AVR.

Это явно удобнее для реально работающих.

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

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

С докой не разобрались просто, вот и все.


Ой, что же это вы купили-то? Поглядите на АЦП в MSP430F16x. Поглядите на USART'ы в нем же. И сравните с меговскими. Вот тогда будет LOL.

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


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


Не надо все читать. Надо читать только то, что требуется. В этом весь цимус и есть.


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


Не по куче документов. Их всего два. Один общий, где описаны модули. Модули во всех чипах одинаковые. Нужно вам клок настроить? Плиз: открываете User's Guide, нахоите описание модуля тактирования "Chapter 7 Basic Clock Module". Читаете, как оно устроено. Все подробно, внятно и с картинками. Удобнее некуда. В DS смотрите только электрические характеристики да распиновку.


Это не summary на чип. Это краткое описание имеющихся в этом конкретном кристалле модулей. Буквально по паре абзацев на каждый. Посмотрите, там при общем объеме 65 страниц, краткое описание модулей занимает страниц 7-8, из которых больше половины - это таблицы с адресами и прочей подобной справочной информацией. Это именно Data Sheet и по форме, и по содержанию. Никакое не summary, как у Атмела, которое, действительно, вещь безполезная, пару раз скачивал, потом никогда больше не качал - мусор, надо сразу брать полноценный DS.


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

Вас же не удивляет, что есть отдельная дока на компилятор, на ассемблер, на линкер, на язык С, на язык С++, на runtime библиотеку. Представьте, что в составе IAR или AVR-GCC идет офигенного размера мануал, в котором сперва описывается язык, потом рантаймная библа, потом собственно сам тулчейн. И выходит новая версия - там тот же мануал, но уже чуть другой - версия другая, изменения какие-то есть (мелкие или значительные - не суть). Попробуйте раскопать это там. Вот уж занятие для мазохистов.


От того, что вы ее так называете, она таковой не становится.

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

Была у меня плата с мегой163. Там, в частности, использовался UART. В обработчике прерываний я данные из UDR не забирал, только флаг сбрасывал, а сам принятый байт забирал уже процессе (задаче, треде), выполняющем функцию приемника пакетов. Флаг приемника UART'а в AVR как сбрасывается? Правильно - путем чтения из UDR. Все замечательно работало.

Потом пришлось мигрировать на мегу16 (причину уже не помню, давно было). Поглядел бегло, вроде почти то же самое. И совместимость заявлялась. Действительно, мега16 встала на место меги163 без проблем (ну, там переименованные I/O регистры - это обычные финты IAR'а (а может и Атмела, а IAR просто тупо делает, как в доке написано, уже не помню таких подробностей, хотя тот же IAR с MSP430 таких сюрпризов не преподносит)). Включили, все работает, кроме, как вы уже догадались, UART'а. Стал разбираться, эксперименты ставить. Ну, на чип-то ведь не подумаешь, все у себя косяки ищешь. Проискал полдня, уже шарики за ролики заезжать стали. Отладки внутрисхемной не было.

Потом уже заподозревал сам МК, стал его фишки проверять. Нашел. Оказывается эти деятели в Атмеле чуть переделали UART. Теперь у него - страшно подумать - FIFO на приемнике аж (трудно поверить) на ДВА байта!!! Ну, и, естественно, когда я в ISR сбрасываю флаг (путем чтения UDR, другого способа нет), то байтик из фифо теряется. Завел временную переменную-буфер, в которую этот байтик читается при сбросе флага, с нее уже в процессе в буфер пакета и складывал.

Я не хочу тут дискутировать на тему правильности/неправильности технических решений (как у Атмела, так и у меня), тут можно спорить, что лучше/хуже. Я тут хотел просто продемонстрировать миазмы этого подхода атмеловского: другой чип - другая документация, и не надо обольщаться насчет полной совместимости и взаимозаменяемости. Другой чип - все, бери читай всю доку полностью и внимательно. Иначе, лови преведы вроде вышеописанного.

На самом деле не открою тайны, если скажу, что Атмел так доку выпускает не принципиальным соображениям, по вынужденной необходимости. У них не было (а возможно и по сей день нет) стабильности в выпуске МК. Постоянно что-то доделывается, переделывается, уточняется. А происходит это потому, что руководит стремление как можно быстрее на рынок выкинуть продукцию и застолбить нишу. Хорошенько подумать, чтоб потом не переделывать, времени нет.

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

Вот такие они - реалии "грамотного подхода" и "уважения к пользователю".


С MSP430 все еще проще. Берете DS, смотрите на первой странице перечень фич, решаете, подходит вам данный МК или нет. Если подходит, то открываете неоднократно упомянутый User's Guide и читаете главы про интересующие периферийные модули. Например, надо вам UART - читаете "Chapter 12 USART Peripheral Interface, UART Mode", надо вам SPI - читаете "Chapter 13 USART Peripheral Interface, SPI Mode", надо вам АЦП - "Chapter 15 ADC12" (или "Chapter 16 ADC10", если в выбранном вами чипе стоит 10 битный АЦП). (Номера глав могут от свежей доки отличаться, цитировал по документу SLAU049B от 2002 года.)

Если не надо вам DMA, то про него не читаете. Если не надо вам Hardware Multiplier, то про него тоже не читаете. Если не надо вам Timer B, то и его трогать не обязательно. Словом, читаете только те главы, которые явно нужны. И сразу ясно, что нужно читать, что не нужно. И сюрпризов в особенностями работы, например, АЦП12 между чипами, в которых он применяется, тоже нет. Все на месте, все стабильно и предсказуемо.


Как это "ХЗ"? Удивительные вещи говорите! А содержимое чипа от вас в тайне, что-ли, держат? В DS посмотрите, что есть - там на первой же странице все перечислено (как и в доке на меги), и все понятно становится. А за подробностями - в User's Guide.


Аргументация что надо.


А в чем принципиальная разница между МК и DSP? И вот, например, Blackfin - это МК или DSP? Где эта четкая граница?

Аргумент против:
Когда осиливал dspic30f2010, то под рукой у меня всегда были такие доки:
1. Собсна datasheet
2. Last rev of errata
3. Programming guide
4. DSPIC family reference manual

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

Мне тоже у ADI дока на их процы больше нравится, чем у TI дока на их DSP. Но у TI подход тоже правильный.


Какой язык у вас в "нормальные" попадает? Я пишу на С++. На С тоже можно с не меньшим успехом.


Сдается вам неправильно. Старт на Blackfin@VDSP++ быстрый, как и на любой IDE такого пошиба (как на IAR, например). Если не вникать в нюансы потрохов, то можно сразу начать писать. И компилятор генерить вполне достойный код. На асме приходится писать только какие-то спец вещи, завязанные на аппаратуру, но это так в любом проце. А обычный контроллерный код пишется на С/C++ с листа и кодогенерация на высоте - на Blackfin программы с этих языков ложатся хорошо.

А вот что вы будете делать с тем фактом, что Blackfin на 200 МГц имеет потребление порядка 50 мВт, причем его мегагерцы поди поэффективнее будут чего у седьмого АРМа. Как вы этот момент рвать "собрались".

Ладно, не будем меряться пиписками - ARM7 c Blackfin никто не сравнивает - разного калибра они по производительности и в разных нишах живут. Blackfin сравнивают с более старшими АРМами - 9 и 11.


Ну, по трудоемкости освоения Blackfin уже не сильно далече от АРМа ушел. У меня коллега его осваивает, сужу по этому.


Дайте определение МК. И обоснуйте, почему Blackfin - не МК.


Что значит "параллельно"? Одновременно, что-ли? Нет, не одновременно. По очереди работал. Да и сейчас приходится. Когда с портами ОС возня идет. Могу вполне сравнить. mkII у нас несколько штук, все одинаково тормозят. Да и по удобству тоже не фонтан. Не знаю, в них дело или в самом МК, но доступно всего 2 аппаратных точки останова. У используемого мной MSP430F169 - их 8. Совсем другая пестня, знаете ли.


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

Кроме того, конкретно у AVR (я уже начинаю уставать это говорить) безобразный указатель стека (SP который), мало указателей для работы с данными (полноценных всего два - Y и Z). Если бы вы посравнивали реализацию адресной арифметики (основы работы с памятью) на AVR и MSP430, вы бы поняли, о чем я говорю - как компилятор извращается с одним указателем Z в IAR или как ему приходится городить stack frame на входе в функцию. Брр... Кроме того, у AVR медленное обращение в память для такой архитектуры. 2 такта - это неоправдано много, нужно это делать за один такт.


Правда? А мне говорили, что ARM7 - это архитектура von Neumann, а ARM9 - Harvard. Мелочь, конечно. И уж всякие MMU по сравнению с этим - вообще ерунда, не заслуживающая внимания.


Не поверите, но "идеология написания ПО, инструментарий" для, например, AVR и MSP430 - тоже одинакова. По крайней мере, если использовать IAR.



Поглядел в Digikey m64 и F169. Первая порядка 11-12 баксов, второй - 10-13. Не впечатляющая разница, прямо скажем. Предлагаю не сравнивать их фичи - они кое-где не пересекаются, поэтому сравнение будет неадекватным. Но сами по себе эти МК примерно одного калибра.

MSP430 никогда не позиционировался как low-cost МК для массовых применений. Он всегда позиционировался для индустриальных применений - у него даже никогда не было коммерческого температурного диапазона - сразу от рождения был индустриальный.

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