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

[dmmos]

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

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

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

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