Вопрос новичка о выборе семейства МК Опции

[dmmos]

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

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

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

[Dog Pawlowa]

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

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

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

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

[MrYuran]

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

[dmmos]

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

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

[Сергей Борщ]

Можно ли как-то сузить круг рекомендаций?

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

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

[dxp]

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

[dmmos]

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

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

[MrYuran]

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

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

[dmmos]

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

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

[dxp]

Да, только QFP в домашних условиях не любой распаяет (не говоря о плате).

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

Хотя есть вроде и в соике, но они какие-то мелковатые (по функционалу)

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

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

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

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

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

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

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

[GetSmart]

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

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

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

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

Сообщение отредактировал GetSmart - Apr 24 2008, 14:54

[dmmos]

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

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

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

[dxp]

Зачем брать дорогой MSP если дешевле и мощнее LPC-ARM от NXP ?

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

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

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

[zltigo]

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

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

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

[MrYuran]

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

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

[dxp]

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

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

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

[GetSmart]

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

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

Сообщение отредактировал GetSmart - Apr 25 2008, 12:08

[SIA]

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

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

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

[dxp]

Начать программить на АРМе не составляет никаких трудностей. Достаточно знать самый минимум Си.

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

У меня в активе под десяток семейств процов, не считая древней экзотики, поэтому думаю, что важнее не изучать процессор как таковой, а изучать методы решения задач, т.е. построение и реализацию алгоритмов. Этому можно учиться и на РС, причем именно на ней это легче всего, особенно если есть старый комп и на нем DOS .

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

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

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

[uriy]

Так получилось что первым контроллером у меня был 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.

[zltigo]

Ну, по этой логике надо начинать с x86, мэйнстримнее некуда.

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

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

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

.AVR - дешевы, функциональны, распространены, простой программатор, удобный компилятор.

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

Вобщем с IAR у меня лыжи не катят.

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

[SIA]

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

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

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

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

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

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

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

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

[dmmos]

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

[zltigo]

Для ARM7 на 74HC244 тоже можно программатор сделать?

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

Я так понимаю, основные претенденты - это MSP430 и ARM7.

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

[SIA]

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, но в основном для общего развития.

[uriy]

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

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

[zltigo]

ISP принято иметь среди всех микроконтроллеров.

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

[MrYuran]

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

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

[zltigo]

Программатор от LPT в моём исполнении состоял из DB25, BLS4 и трёх проводков.

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

[MrYuran]

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

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

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

[rezident]

Интересно, а ИСП от АРМа каким местом в комп совать?

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

[dxp]

MSP430 не претендет вообще, ибо нишевый продукт.

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

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

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

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

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

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

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

MSP430 не претендет вообще, ибо нишевый продукт.

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

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

[migray]

Потом NEC 8 и 32 разрядные

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

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

IAR (будь он неладен, до сих пор душа к нему не лежит).

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

[dmmos]

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

[dxp]

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

[SIA]

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

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

[defunct]

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

Да что Вы заладили, 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:

Главное преимущество ARM7 - его низкая цена при приоизводительности среднего уровня.

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

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

[uriy]

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

[dxp]

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

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

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

[dxp]

Да что Вы заладили, MSP да MSP. Ну что в нем такого?

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

FET на коленке не собирается, придется пошаманить,

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

все же не 5 проводков и риск спалить МК сразу - есть.

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

LPT уже отмирает

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

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

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

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

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

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

Стоит MSP дорого, производительность невысокая (8-Mhz в сравнении с 50-100Mhz ARM7 - это почти 0).

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

Требователен к питанию, палится на раз.

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

Периферия построена криво. Без бубна в некоторых моментах не разобраться. Да и какой смысл переплачивать за чип основная фича которого (микроэнергопотребление) не нужна?!

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

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

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

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

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

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

- легально бесплатный компилятор C/C++.

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

- качественное и бесплатное ПО от производителя (IDE - совмещающее отладчик, транслятор с ассемблера, симулятор, программатор, редактор исходников и мастер создания проектов на C/C++.)

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

- большая подборкой примеров и готовых решений.

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

- нетребователен к питанию (диапазон питающих напряжений 1.8..6V, выдерживает крактовременные пульсации до 10V). (для человека привыкшего работать с аналоговой частью этот критерий важен).
- дешевизна и доступность.

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

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

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

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

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

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

ARM и MSP на мой взгляд по сложности освоения одинаковы,

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

PPS:

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

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

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

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

[MrYuran]

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

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

[zltigo]

Лично собирал на макетной плате за полдня.

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

Документация сделана замечательно.

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

С ARM7 сравнивать не надо - когда АРМ научиться столько же потреблять энергии, тогда и посравниваем.

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

А то давайте ваш АРМ7 сравним с Blackfin'ом? И по скорости, и по потреблению.

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

Про кривизну периферии - в студию...

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

По сравнению с AVR так мспшная просто образец.

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

Насчет энергопотребления - это только одна из фич.

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

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

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

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

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

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

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

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

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

[zltigo]

Объемы продаж определяются не крутизной х51, а длинной его историей - у данной платформы богатое наследие.

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

[dxp]

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

затевать самоделки - себе дороже - один инструментарий чего стоит сделать.

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

[defunct]

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

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

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

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

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

Это миф. Ни разу ничего не палил.

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

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

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

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

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

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

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

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

Все эти вещи - общие на все семейство, и при желании использовать другой процессор из этого-же семейства, не надо снова изучать сотни страниц.

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

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

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

На конкретный чип есть Data sheet, который по объему небольшой и в нем описаны конкретные моменты, присущие данному кристаллу (объем памяти, какие периферийные модули содержит, электрические характеристики, разводка пинов и т.д.).

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

Для сравнения возьмем ваш любимый AVR. У него на каждый кристалл идет полная Data sheet, в которой описано фсе!

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

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

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

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

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

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

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

С ARM7 сравнивать не надо - когда АРМ научиться столько же потреблять энергии, тогда и посравниваем. А то давайте ваш АРМ7 сравним с Blackfin'ом?

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

И по скорости, и по потреблению. Фин его порвет тут лехко.

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

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

Но я не считаю это основанием полагать, что Blackfin лучше, чем ARM7. Это разные процы и у них разные ниши.

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

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

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

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

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

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

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

А разница между ARM7 и ARM9 куда больше, чем между ARM9 и каким-нибудь шустрым DSP. У ARM7 и ARM9 общее только название.

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

135 - для маленьких и дешёвых проектов (3-4$ в компэле)
149 - для остального (4-5$)
Интересно для сравнения, сколько стоят аналогичные по параметрам меги?
Думаю, что не меньше.

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

[zltigo]

Дошло дело до программатора, идею 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]

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

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

Решил испытать как работает АЦП. Мамочки, а его оказывается надо программно на компараторе делать! Вот тебе раз. 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 между чипами, в которых он применяется, тоже нет. Все на месте, все стабильно и предсказуемо.

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

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

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

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

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

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

[_Pasha]

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

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

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

[dxp]

У 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]

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

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

[Alex B._]

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

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

[defunct]

Только попытку выдать баг(чрезмерную разномастность 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]

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

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

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

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

[defunct]

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

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

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

[rezident]

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

[defunct]

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

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

[zltigo]

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

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

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

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

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

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

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

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

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

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

[defunct]

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

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

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

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

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

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

[zltigo]

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

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

[vesago]

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

[GetSmart]

От авр тоже приятные впечатления. Сейчас ставлю его везде - цена подкупает и удобство использования.

AVR or LPC ?

[vesago]

AVR. В моей местности по цене ему нет конкуренции.

[SIA]

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

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

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

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

Примерно та же фигня, кстати, и на ARM-ах :-( Кто во что горазд. Зато много и дешево.

[defunct]

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

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

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

Купил самых мелких 1101 или 1101A.

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

Да в этом что-то есть. Но меня интересовали не столько фичи толстых чипов, сколько основная фича - микропотребление. Отсюда и выбор - самый мелкий МК. Спросите что же я надеялся получить от мелкого чипа за $2? Ну хотя бы то, что есть в самом мелком из AVR за 0.3$. А ведь и того нет.

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

Спасибо за guide по документации TI, может пригодится.
Но я все равно останусь при своем мнении - "нормальный подход" не есть "удобный для освоения подход". Возможно "нормальный подход" удобен для миграции, но его удобство для быстрого старта сомнительно.

Думаете, это мой фантазии? Нисколько. Рассказываю про грабли, на которые я сам наступал.

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

Странно как-то построена у вас обработка.
Прочитав UDR я бы не наделся на то, что он каким-то чудом сохранит свое состояние на неопределенный период времени. Точно также как я бы не надеялся на то, что SPDR сохранит свое значение после вычитки. Это не только к AVR относится.

Потом пришлось мигрировать на мегу16.
...
skip
Потом уже заподозревал сам МК, стал его фишки проверять. Нашел. Оказывается эти деятели в Атмеле
...
Я тут хотел просто продемонстрировать миазмы этого подхода атмеловского: другой чип - другая документация

Не убедили. Открыл даташит на m163 (чип под который изначально был писан Ваш код) - там ни слова о том, что повторное чтение из UDR даст тот же результат. Уж больно надуманный случай описываете.
Как можно читать volatile регистр и надеяться на то, что он сохранит свое состояние?!
А если там действительно все гладко, то FIFO m16 никак не повлияло бы.

Другой чип - все, бери читай всю доку полностью и внимательно[/b]. Иначе, лови преведы вроде вышеописанного.

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

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

nevermind, почему-то запало, что под BF имеется только некая смесь ASM с C подобным синтаксисом.

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

по производительности рвать собирался запараллелив несколько ARM'ов в MPP. ;>
Потребление мне правда неважно - в энергетике на потребление никто не смотрит.
Но вот с освоением за счет того, что C/С++ компиляторы под BF таки есть, то рвать сложнее получается.

Да и по удобству тоже не фонтан. Не знаю, в них дело или в самом МК, но доступно всего 2 аппаратных точки останова.

Всегда было 4. Может где старые точки остались?

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

Ясное дело проще, отсортировано все и сведено на нет число Run-time багов связанных с исполнением кода из RAM. Сразу ясно где RAM, где ROM, где EEPROM.

А вот с общим адресным пространством надо помнить какая память с какого адреса начинается, обходить дыры...

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

Я с этим знаком, и оно меня нисколечки не волнует. Как-то делает и хорошо, на то он и компилятор.

Правда? А мне говорили, что ARM7 - это архитектура von Neumann, а ARM9 - Harvard. Мелочь, конечно.

да нет что-то вам переврали..
Пересел с 7-ки на 9-ку, потом на 11. Не заметил особой разницы.
Первоисточник тут