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

[dmmos]

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

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

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

[GetSmart]

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

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

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

[dxp]

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

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

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

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

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

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

[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 да и все остальные здесь названные.

[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, что никак не может представить АРМ как универсальную и полноценную альтернативу им.

[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).

[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? Где эта четкая граница?

[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. Не заметил особой разницы.
Первоисточник тут