[zltigo 2]

Дошло дело до программатора, идею BSL не понял вообще.

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

пробовал собрать FET, с первого раза не получилось.

...

STK200 для AVRки сразу получился,

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

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

И это в чипе который дороже AVR mega16.

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

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

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

Вся информация собрана вместе, это я и называю грамотно построенная документация.

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

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

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

[dxp 65]

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

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

 

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

И это в чипе который дороже AVR mega16.

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

 

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

 

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

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

 

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

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

 

Ну допустим хочу я найти как настроить клок.

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

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

 

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

 

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

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

 

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

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

 

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

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

 

Вас же не удивляет, что есть отдельная дока на компилятор, на ассемблер, на линкер, на язык С, на язык С++, на 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, другого способа нет), то байтик из фифо теряется. Завел временную переменную-буфер, в которую этот байтик читается при сбросе флага, с нее уже в процессе в буфер пакета и складывал.

 

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

 

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

 

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

 

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

 

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

Пользователю не надо искать ничего больше.

С 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 между чипами, в которых он применяется, тоже нет. Все на месте, все стабильно и предсказуемо.

 

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

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

 

TI / ADI компании которые как бы это сказать "на своей волне". Для меня они не показатель. Точнее показатель того как делать не надо.

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

 

Не надо строить документацию на МК на подобие документации к DSP.

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

[_Pasha 0]

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

Аргумент против:

Когда осиливал dspic30f2010, то под рукой у меня всегда были такие доки:

1. Собсна datasheet

2. Last rev of errata

3. Programming guide

4. DSPIC family reference manual

 

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

[dxp 65]

У TI нормальная документация только на продукцию BurrBrown, и то потому что ее писала BurrBrown, а не TI.

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

 

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

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

 

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

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

 

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

 

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

 

В программной модели разницы все же практически нет. MMU да кеш, вот и вся разница.

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

 

Идеология написания ПО, инструментарий (по крайней мере если пользовать RV) одинаковый. Так чтааа...

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

 

 

Естессно меньше.

135 это нечто между m8-m16 ($0.9-$1.7 в виакоме).

149 - нечто между m325-m64 - ($2.2-$3.2).

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

 

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

[zltigo 2]

Аргумент против:

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

[Alex B._ 0]

Аргумент против:

...

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

Ну и правильно. Мухи отдельно, котлеты отдельно. А что, вы хотите еррату тоже в даташит включать? имхо такие "аргументы" говорят только о квалификации разработчика... =(

[defunct 0]

Только попытку выдать баг(чрезмерную разномастность AVR) за фичу(вот вам все-в-одном флаконе). Я спрашиваю - что будем делать потребуется другой AVR чип осваивать?

Осваивать-то ничего не понадобится. Останется только найти "5" отличий о чем dxp выше раз 5 отметил.

 

И найти эти 5 отличий разобравшись с одним чипом не так уж сложно. Да малость неприятно, но разве это смертельно? или как-то влияет на скорость освоения первого МК?

 

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

И да и нет. Бутлоадер который непонятно как использовать, без нормального к нему софта вещь бестолковая и ненужная. С SAMBA хоть программу ясно где взять. А TI посылает на softbaugh :))

 

Ок - можно потратить время на поиски third party софта, но я просто отмечаю те нюансы которые тормозят освоение.

 

Как я понимаю, это и послужило причиной всего нижеизложенного

Да конечно. Мой личный опыт освоения MSP, на грабли - наступил, почему бы не описать? ;>

 

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

На сайте TI про фичи чипа было написано - ADC Slope, UART timer. Когда первый раз знакомишься с семейством не уделяешь много внимания на приписки к знакомым фичам.

Не передергивайте - у TI не один документ на все MSP430 - у них документы по семействам.

Вот по этому документу и выбирал свой первый чип, т.е. фичи меня полностью устраивали, но как мне знать, что ADC slope - это значит "возможность построения АЦП на компараторе?!", а UART timer относится только к BSL?

 

Я спрашиваю - что будем делать потребуется другой AVR чип осваивать?

Тупо перенести код от старого, некоторые фичи заработают сразу, некоторые не заработают. Далее открывается даташит на новый чип и читаются разделы тех фич которые не заработали. Максимум час и программа от старого чипа, села на новый.

 

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

 

 

dxp: Сорри отвечу позже.

[zltigo 2]

С SAMBA хоть программу ясно где взять.

На их-же сайте. Брать SLAA096D и приложения к нему. Все лежит даже более открыто, чем SAMB-а по поискам которой здесь переодически вопросы задают :).

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

 

 

 

 

 

Тупо перенести код от старого, некоторые фичи заработают сразу, некоторые не заработают...

Методом тыков, втыков и ошибок :( Не нравится мне такой подход к делу совершенно, как и использовние каких-нибудь мутных неведомо кем писанных "библиотек"...

[defunct 0]

Методом тыков, втыков и ошибок :( Не нравится мне такой подход к делу совершенно, как и использовние каких-нибудь мутных неведомо кем писанных "библиотек"...

Не того рода тыки и втыки.

Периферия у AVR'ов практически одинаковая. Если не пользовать asm и цифры вместо названий бит, то "скрытые" глюки невозможны, просто некоторые модули не откомпилятся, вот там и смотреть почему.

Да и никто не заставляет Вас прыгать между AVR чипами, выберите совместимую линейку типа m48-88-168, m8-16-32, m64-128 и пользуйте только ее.

 

C NXP ведь то же самое :)

[rezident 0]

Беседа плавно перетекает в очередной римейк виртуальной войны "AVR vs other MCU". Господа, вам не надоело еще? :laughing:

[defunct 0]

Беседа плавно перетекает в очередной римейк виртуальной войны "AVR vs other MCU". Господа, вам не надоело еще? :laughing:

Нет Боже упаси, никакой войны! :) Молчу также про other МК.

Ничего не имею против того чтобы начать с C51 - здорово дисциплинирует, или с ARM7 - наилучшее соотношение цена/производительность и очень перспективен (относительно прост в освоении если не поскупиться на средства отладки). И к одному и ко второму есть чудесная отладочная среда - Keil.

[zltigo 2]

Периферия у AVR'ов практически одинаковая.

"Чуть-чуть беременная :(", отличается, но самую малость.... и так далее.

и цифры вместо названий бит, то "скрытые" глюки невозможны

Это конечно святое, только вот откуда эти буквы вместо цифр взять? Взять от производителя конкретного компилятора и попасть к нему в зависимость, или самому описать переносимо и независимо?

Если второе, то придется САМОМУ вычитывать.

и пользуйте только ее.

Ну очень дельный совет :). Все стало на свои места - используйте один еслинственный контроллер и проблем с изучением документации на другие простот не будет :)

C NXP ведь то же самое :)

В заметно меньшей степени, но да. Что не делает ему чести.

 

 

Беседа плавно перетекает в очередной римейк виртуальной войны "AVR vs other MCU".

Речь идет о достаточно серьезном вопросе - с чего начинать работу с контроллерами сегодня. Подчеркиваю СЕГОДНЯ, а не вчера или в прошлом веке.

[defunct 0]

"Чуть-чуть беременная :(", отличается, но самую малость.... и так далее.

Ну не знаю переносил один и тот же код между добрым десятком МК, основные проблемы - наличие/отсутсвие порта "X", наличие/отсутсвие таймера "X", наличие/отсутсвие второго уарта, настройки WDT, настройки внешних прерываний, определение статуса сброса. С остальной периферией (OSCCAL, TWI (i2c), SPI, ADC, AC, EEPROM) - никаких вопросов.

 

Это конечно святое, только вот откуда эти буквы вместо цифр взять? Взять от производителя конкретного компилятора и попасть к нему в зависимость, или самому описать переносимо и независимо? Если второе, то придется САМОМУ вычитывать.

Для AVR - первое. В тех двух компиляторах которые можно отнести к правильным инструментам, есть буквенные названия бит, совпадающие с названиями в ДШ. А когда два независимых производителя предоставляют поддержку буквенных имен - проблем нет, всегда есть возможность сравнить.

 

Ну очень дельный совет :). Все стало на свои места - используйте один еслинственный контроллер и проблем с изучением документации на другие простот не будет :)

А что с MSP не возникает проблема наличия/отсутсвия периферийных блоков в пределах семейства?

[zltigo 2]

А что с MSP не возникает проблема наличия/отсутсвия периферийных блоков в пределах семейства?

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

[vesago 0]

Выскажу и я свое мнение. Я работал в следующей последовательности PIC-51-LPC2000-AVR-MSP430. Имхо наиболее приятные в освоении LPC2000. Понравилась документация, с программированием гемора нет. Работает все в точности как и написано. В общем недостатков не нашел. Крайне дружелюбные. Придется правда раскошелиться на мтлинк за $70. От авр тоже приятные впечатления. Сейчас ставлю его везде - цена подкупает и удобство использования. Недавно сотряпал пару-тройку приборов на MSP430. Постараюсь их применять только в крайнем случае - если критично будет энергопотребление. В данном случае подпишусь под каждым словом defunct. Имхо старт с данного семейства может убить энтузиазм в освоении uC. Документация мне понравилась.