Здравствуйте. AVR достаточно освоил, но уперся в потолок производительности. Надо расти дальше, но стою на перекрестке - не знаю что выбрать.

Хочу спросить мнение профессионалов, которые реализовали множество проектов на разных микроконтроллерах (ARM).

Что выбрать Atmel (SAM3) или STM какие плюсы и минусы в них имеются? Задача - не критичная к скорости, но критичная к стабильности работа в локальной сети (Ethernet + PHY, на микросхемах физического уровня).
Главное хочу услышать не предвзятое мнение, а то обычно кто что использует - то и хвалят.

Сам выяснил одну вещь: Atmel труднодоступнее и немного дороже чем STM. Так ли это? И что касается остального: подключение (минимальная обвязка), программирование (среда разработки и язык), прошивка - как с этим обстоят дела?

1) Забудьте про Atmel что-бы он не пытался делать. Вечный догоняющий пытающийся держать на игле своих авр-щиков. Посему забудьте навсегда.
2) Если иделие штучное - сделали и забыли, то все равно. Если предполагается долгая жизнь - начните с NXP.

ST в настоящий момент контролирует больше половины мирового рынка "флешевых" ARMов, лучше ориентироваться на них. Если у Вас специфические задачи завязанные на Ethernet то можно посмотреть и в сторону TI (семейство Tiva c Ethernet PHY на борту)

zltigo а почему NXP? Какие у них плюсы по сравнения с контроллерами от STM, TI или Freescale?

В свете слияния NXP и Freescale непонятно, что там дальше будет. Может случиться, что сольют всю линейку LPC.
В этом плане ST пока не в зоне риска
Ну и я бы посоветовал STM32 не потому, что сам его использую (не его одного, кстати, сейчас делаю проект на LPC4370), а потому, что его многие здесь используют, поэтому могут помочь советом. Ну и вообще обширное семейство, всё там есть, работает нормально (с учётом еррат, но это у всех надо учитывать).


Нет такой проблемы "стабильность работы в сети" на уровне МК. Может быть кривой Ethernet MAC, но это должно быть написано в еррате (у STM32 в этом плане всё в порядке, ЕМНИП). Есть проблема кривых софтов. В форуме народ постоянно пишет, что мол, взяли этот пресловутый Куб, а у них потом что-то не работает. Как будто не догадываются, что все эти кубы - индусский говнокод. Что тут можно сказать? Учите язык Си, пишите хорошие софты.

Кстати, про софты: тут один участник форума постоянно нахваливает MQX, который идёт в комплекте с Kinetis от Freescale. Якобы этот софт вовсе не кривой, и всё там есть. Но тут та же неопределённость в связи со слиянием NXP и Freescale. Если бы меня попросили погадать, я бы поставил на то, что LPC сольют в пользу Kinetis.

Я работал и с Kinetis и с LPC23/24/17. Ну и ещё LPC11 с CAN на борту.
Сомневаюсь что линейка LPC будет слита. У LPC, как мне кажется, много поклонников и потребителей т.к. это качественные и надёжные процессоры.
Кроме того Kinetis и LPC сильно различаются по структуре. При освоении MKL15 я думал мозг сламаю, пока разберусь что там и как друг с другом взаимодействует и что от чего зависит. LPC на порядок проще на начальном этапе освоения.
Буду считать плюсом слияния двух компаний, если Freescale сможет наладить выпуск Kinetis в Европе, или хотябы обеспечит их безпроблемную доставабельность.

Но тема топикстартера всёже не про слияние Freescale и NXP, а про выбор процессора.
LPC17 - хороший выбор для освоения и использования в серийных проектах. Простая структура, много литературы, много примеров, надёжны, доставабельны.
Kinetis - сложны для старта, но имеют отличное потребление в режиме глубокого сна (mkl15, LLS, 0.44 uA).
STM32 - тоже хороши для освоения, просты внутри. Но их портит навязывание STM своих библиотек, мешающих понять структуру и принцип работы периферии. Если забыть о существовании библиотек, то при освоении оставляют хорошее впечатление. Также поражает их цена - сейчас сам смотрю на STM32F0x стоимостью чуть больше 1$ в розницу. В нашей фирме в серийных проектах STM32 не используются (предпочитаем более надёжные на наш взгляд LPC или низкопотребляющие Kinetis), но для своих одиночных проектов с успехом применяю STM32F100/103.
Ещё упоминался Atmel - с тех времён, когда AT91SAM7S внезапно подскочил в цене и стал тяжело доставаем, ими не пользуемся, но в целом ARM7 процессоры были не плохи, думаю CORTEX тоже не стали хуже, но связываться с Atmel я бы не советовал из-за цены.

А я бы посоветовал даже более широко, начните с ядра Кортес-М3 или М4, АРМы то разные бывают...

А в этой группе я бы выбирал между STM32 и LPC.

при сравнимой производительности и корпусе






По внутренним ощущениям СТМ очень агрессивно рвут рынок, и не успевают за сами же собой по качеству, процессоры выходят каким-то недоделанными что ли, не ощущаю я лично надежности. LPC же как то сделало проц и гонит его таким какой он есть, у меня нет с ними чувства что что-то пойдет не так. Если брать что-то типа LPC1768 - так там вообще все работает как написано в мануале, а если что-то работает не так, то не правильно прочли. Они как-то более предсказуемы, но более скучны с точки зрения периферии и перекидывания ножек.

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

С кубовскими библиотеками я постоянно нарывался на то что идешь по ним шаг за шагом, вроде все хорошо, но потом обнаруживаешь что у них по их логике функция завершения опроса АЦП имеет таймаут 3 секунды сделанный на while, и получается что либо меняй всю идиологию, либо заплатки ставь, и думаешь что быстрее было бы сразу все самому написать, чем тут ковырятся. А так получается пол проекта на кубе, а пол в заплатках и своих функциях не то не се.

Спасибо всем за советы (еще принимаются). Думаю пересяду на STM (честно говорят до сегодняшнего дня не хотел с Atmel уходить).
А что касается физики Ethernet (PHY) - цена я так понял что не сильно отличается, реально нет разницы $2 или $5 (если производство не серийное на 1000 штук).
Поиск на этом форуме показал, что люди нахваливают эти микросхемы: KSZ80XX, LAN87XX, RTL82XX, DP83838, и Micrel (модели не знаю) - что можете посоветовать?

Правильно мыслите. Freescale дает гарантию на производство своих чипов в течении 10 лет.



Просто для знакомства с Kinetis можете почитать вот это - http://habrahabr.ru/post/256611/

У Freescale действительно лучшие прикладные открытые библиотеки.
Если вы не чистый схемотехник, то должны понимать их значение.

В последней версии SDK под Kinetis сразу даются порты 4-х RTOS с исходниками самих этих осей: uCOS-II, uCOS-III, FreeRTOS и MQX.
Это еще не считая проект mbed.org где Kinetis играет большую роль.

Кстати MQX в последнее время штатно идет с TCP стеком с SSL (все с исходниками).
Также там скорее всего первым появится и полнофункциональный IPv6

У меня KSZ8081. Выбирался самый дешёвый вариант. Работает - а что ещё надо?

На данный момент они не сняли с производства ни один из даже самых первых ARM контроллеров. Это было к вопросу о времени жизни изделия.

Принцип отсева простой:
1. Начните с обзора того, что вы можете купить у местных поставщиков.
2. тут у вас важное решение: единственный критерий дальнейшего отбора - цена или же некий баланс.
3. Если выбрана цена, то просматриваете по диагонали список ошибок(errata) и переходите к п. 5
4. По списку ошибок и цене смотрите какой из МК слеплен из ...а, а какой приемлемый.
5. Оснащение и порог вхождения. Оцените во сколько обойдётся зажечь светодиодик. Обычно у АРМ'ов есть UART и USB загрузчики, т.е. можно отделаться конвертером.
5а. Если есть деньги на отладочные комплекты, то смотрите во сколько обойдётся оборудование для отладки.


и этот тред не исключение))

и немного оффа

тут таже ситуация - за цену одного SAM'а ведро не SAM'ов дают.
если бы не список выше, то я бы выбрал архитектуру MIPS - нравится их ассемблер; и продукцию Микрочипа, у которого одни из лучших ценовых предложений по инструментарию(программатор, отладчик).
Но с компиляторами ЯВУ у них был просер да и п.1 имеет место
http://kosmodrom.com.ua/prodlist.php?page=...%EA%EB%E0%E4%F3

Невероятно. Нет смысла "сливать" свою линейку, которую пестовали и по отношению к котрой проводили политику "до последнего потребителя".
Ну купили они кого-то, ну и что? Как жили те, так и будут. Вот я сейчас работаю на купленном ими-же Jennic. Он на самом деле живет своей жизнью в котрой самое отвратительное, через 3-4 года снятие с производства предшественника .


Практически да.

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



Ну а теперь о NXP расскажите что они сняли из ARM. Короче - будут жить оба.

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

Какие есть варианты с микросхемой (PHY) физического уровня Ethernet? Предпочтение корпусам TQFP/LQFP (48)

Ознакомьтесь

Wiznet же!
На одном кристалле 8051 + аппаратный стек Ethernet или Cortex + аппаратный стек Ethernet
http://www.wiznet.co.kr/product/
http://www.efo.ru/doc/Wiznet/Wiznet.pl?494#1

англоязычное комюнити неплохое http://wizwiki.net/wiki/doku.php?id=start

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

Мои железки простые в плане алгоритмов (на вроде тех же торговых автоматов и мелких наколенных поделок), но вот скорости может когда-то и не хватить
Глянул на AtXmega - как-то не впечатлило, хотя бы из-за доставаемости и отладки.

Приглянулись STM32, но выплывают как технические, так и психологические проблемы после x51, PIC и AVR оные просто "ну ваще другие"

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

Если не будут сворачивать, как обещано, до последнего потребителя, то что тогда называть "сливом линейки"???



Пользовал только однажды - Stellaris 6965. Причина была в том, что встроенный PHY был на удивление экономичен, а требования по питанию были очень жесткиею А так не вижу особого смысла во встроенных.




Запихните эту радиолюбительскую поделку для радиолюбитей ... ну в общем подальше.

Это уже спор о значении слов, не очень интересно. Можно придумать разные степени слива:
1) Прекратить развитие линейки
2) Остановить ещё и тех. поддержку (мне по барабану, ни разу не пользовался)
3) Снять с производства
Я не предсказамус, не буду зарекаться. Свои опасения высказал, а там будем посмотреть.


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

камни stm32 действительно мутноватые. нет, они вполне рабочие но без вникания в индусский говнокод в либах их поднять тяжко.
lpc чуть попроще, начните лучше с них, причем с младших lpc11*
Или kinetis те кторые на cortex-m0. Они в россии непопулярны но судя по дш чипы неплохие.



4) Продать маски фирме Holtek (или закрыть глаза на то как они [CENSORED]).

ну, английский может быть разный В даташитах Атмела - сносный (для меня, конечно!), в Микрочип - понятный, а вот корейские и китайские даташиты - %%%!
Да и на Си можно по-разному писать.

начинал с Pic на ассме, потом AVR на асме, наш разработчик невольно подсадил меня на Pascal (на заводе всё на нём писалось: от ПК и спец.станков до МК). На 2006 год Паскали для АВР были голимо говёные. Перешли на FastAVR - нечто между Паскалем и Бейсиком. Потом как-то плавно на Bascom (чистый Бейскик). Крайне редко правил что-то чужое на Си (обычно CodeVision). Си читаю, если простое - понимаю, но ойные черточки и галочки крайне плохо понимаю. По мне проще почти англицкий, чем черточки

ps
щас меня обкидают какашками и начнётся очередной халивар. Придёт Ксения и забанит всех по самый неболуйся ))

Как же я их поднимаю, не трогая индусский говнокод совсем и всего лишь читая мануал? Это сейчас не модно?

Если тянет на говнокод, может стоить искать проблему в себе?
По-моему - так даже смотреть в говнокод противно. Только если поржать....
По себе: в последнее время сделал по одному проекту (с параллельным освоением этих новых для меня линеек) на MSP430, STM32F100, Tiva TM4C129, ADuCM360 ни разу не заглянув ни в один пример чужого кода. Исключительно даташиты и юзермануалы.

По своему опыту: после аврок пересел на атмел САМ7 и САМ3. После них на стм32ф4. Там где раньше в изделии стояло два САМ7, можно обойтись одним САМ3. Где глючил САМ3 - ставишь стм32ф4. У САМ3 плохие часы - батарейный отсек если питать от лития - зависает, если подавать питание по нажатию кнопки - проц запускается порядка двух секунд. Плюс генерация на внешнем часовом кварце АРХИ слабая - от щупа осцила садится и не восстанавливается без перезапуска! После перевыпуска изделия на стм32ф4 - просто не нарадуюсь. Прямо до сих пор балдею - неужели "с таким щастьем и на свободе". Многие хают преднаписанные либы - а я кайфую. Функции хорошо задокументированы. Входные парамерты понятно названы - можно даташит не читать и все понимать что делает та или иная функция. Куб не юзал - руки не доходят. А то что есть в либах - ошибок пока не встречал. Если нужен какой то быстродействующий код - открываю даташит, смотрю чего надо выставить в конкретном регистре, беру код из либы, убеждаюсь что он все делает как написанно в даташите, убираю лишние проверки и макросы, профит. Возможно мне конечно повезло с ерратой - юзаю очень узкий круг стм32ф4 последних ревизий. Критического для себя не ловил.

сдается мне что сменив подход
вместо этого

надо будет писать ставишь самый маленький пик и все летает.....


У вас вообще времянки жесткой что ли нет? Или вы гирлянды на СТМ делаете? Там в их библиотеке столько лишних движений и проверок, такие таймауты могучие, да и волатайлов нехватает на оптимизацию выше 0. И как вы с этим всем живете? Переписываете?

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

Была такая версия использования, но при этом в проект затягивается толпа файлов и он уже компилируется не так бодро.

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

Я по сути про тоже.

а я делаю так:
задача посылать по скоростному SPI произвольные блоки данных через ДМА:
1. Один раз инициализирую ДМА и SPI при помощи SPL,
2. Запоминаю значения регистов в SPI и ДМА, ПЕРЕД запуском всего этого.
3. При повторном запуске другого блока данных с другим размером - восстанавливаю значения регистров, и меняю только адрес с размером и запускаю при помощи SPL ДМА.

Оформлено это всё в красивую отдельную либу с приятным "сахором" в виде одной функции spi_dma_send(addr, size);
и не знаю проблем ни с досканальным изучением регистров, ни скоростью запуска отправки блока, и написано всё на понятном SPL а не дрочь с битами в регистрах и последующим чтением "а чего это там за EN бит в CR1 записывается". И всё изучение регистров ДМА и SPI сокращается до нахождения адреса и размера посылаемых данных + общий порядок запуска всего этого дела (а по сути всегда это однотипно: настроить всё неважно как и дать отмашку уже важно в какой последовательности)

круто!

Ребят, а что касается микросхем Ethernet (PHY) - что посоветуете? Желательно корпус LQFP.

Чукча не читатель?

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

Использовал KSZ8041, KSZ8051, KSZ8081. Никаких проблем не возникает.

Из всего многообразия возможностей DMA (работы связным списком, flip-flop, комбинации этих режимов, возможности прямой работы со сложными структурами данных типа кольцевых буферов и N-мерных массивов одной транзакцией и много другого что взбредёт в голову) Вы оставили куцый обрезок в стиле memcpy() и сидите радуетесь этому? Мне Вас жаль....

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

+100500
Ув. товарищ перфекционист в соседней теме изобретает невозможный чудо-макрос на все случаи жизни. Всем понятно, что и без этого макроса хорошо, а всё равно руки чешутся
Решение абстрактных задач - это неплохо и забавно, в том числе в качестве разминки для извилин. Но следует понимать, что с решением насущных задач это, как правило, ничего общего не имеет. Пустая трата рабочего времени.

Да ладно - в насущных задачах перфекцинист пользуется тем, что есть. Но стремится к лучшему
А вот насчёт использования всякого рода сторонних библиотек как раз и считаю это пустой тратой рабочего времени... на ловлю багов потом.

Да и о чём тут (на форуме) ещё общаться? Только чайников учить? Скучно

Именно так.

Хм... Линуксописатели тихо смеются в сторонке, ибо там-то точно без библиотек не написать ничего

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

Кроме того что вылавливаются еще важно чем вылавливаются.
Важно насколько среда заточена для вылавливания.
Если хотите GUI в исходниках переходите на eGUI под Kinetis-MQX - http://gargy007.github.io/egui_doc/

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

Ну это Вы за всех не говорите.

Умиляет. Типовой дерьмокод содержит такое количество потенциальных ошибок и написан с таким количеством заплаток, на ошибки котрые вылезли при минимальной работе в паркетных условиях, что ловить там уже НЕЧЕГО.


Посему средства диагностики сбоев должны быть встроены в рабочий вариант оборудования, когда всякие среды c отладчиками давно уже ушли лесом.



Да смеяться-то нечего - способ обеспечения "надежности" в линуксе весьма лобовой - сотни писателей и тысячи латателей за годы дописали и долатали до приемлимого состояния. И продолжают...

чем SPL не угодила? она только перегоняет значения из структуры в регистры простым ленейным кодом в 99% случаях.
Более того производитель наверняка именно ей тестит своё железо, а другой порядок инициализации может дать сюрприз.
И никто не говорит о библиотеках как о панацеи, если разраб в их исходники и документации вообще неразу не глянул и у него не возникли даже сомнения делает ли он всё верно, то это его вина.
А так же распростронённые ошибки есть когда в AHB инициализируются константами APB, всякие не до конца заполненные структуру, переполения стеков, да и тупое игнорирование всяких мелочек.
А потом все ноют "SPL гавно, CMSIS вообще на свалку, WINapi уничтожить, poco примитивна - ООП не используется на всю катушку, а boost вообще дебилы писали - ничего не понятно в ней и это не ООП а гавно".

Исползьую STM32. Почему то так исторически сложилось, что почти все проекты на них да и дрова под них понаписывал и ОС(хотя ОС просто под cortex-m3/4)

Лет десять назад удивлялся откуда берётся столько человек оторванных от реальности.
А потом просто понял что многим везёт что их никогда:
- не заставлял менеджер: "заткнись и напиши этот грёбанный код за неделю, и мы получим годовую прибыль с этого олуха, а тебе дадим месячную ЗП"
- не писали одноразовых проектов
- не горели сроки
- не сталкивались с тем что разработка сделанная кое-как за пол года приносит 90% прибыли и хрен ты это изменишь даже сделав более качественный вариант дешевле, на который потратил пару лет.
- не сталкивались с заказчиками-идиотами которым нужен к швабре обязательно блютуз и ретина-дисплей

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

Сначала длинно написал, а потом понял что вся суть в этом


Те кто получает 90% прибыли на проектах сделанных кое как, по моему мнению подлежат усыплению.
Сначала делаем проекты кое как, а потом говорим а чего это наш ВАЗ так фигов в эксплуатации... Стороны одной монеты!

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

А Вы просто придрались к словам, может автоваз чем то не угодил? Я например доволен, есть и i30 и шестёрка в качестве внедорожника по сёлам и ебеням, на них обоих нормально езжу и не жалуюсь.
Чего и Вам желаю

На везение полагаться не надо. Надо просто творить СВОЕ а не менеджерское. А нежели те-же "разовые проекты", котрые ну очень кому-то надо хоть как-то давай-давай, то от таких ОТКАЗЫВАТЬСЯ без сомнений. Я, например, разовых в свое врнмя делал очень много и ВСЕГДА, без ЕДИНОГО исключения ПОСЛЕ всяких сделавших "быстро". Кстати, благодаря опыту АККУРАТНОЙ работы, медленно тоже не было .




Нет, потому, что нет. Потому-же, что не украсть, не убить...

была пара случаев когда сделав очень быстро и по уродски мы получали 1-2 ЗП за несколько дней. А потом ещё по итогам года т.к. оборот фирмы увеличился мы получали повышенные премии (ещё несколько месячных зп).
да обкодившись, да "быдлокодом".

НО

менеджеры были в курсе что этот код надо будет выкинут и его следует заново переписать заложив в десятки раз больше времени.
А тот кто отвечал за поддержку и сопровождение вообще потребовал и получил в 2 раза больше ЗП.
И впредь у нас заложили такое правило - если надо писать быстро - то и надо закладывать полную переделку этих фекалий, и не только в внутренний план фирмы но и предупреждать клиента что в последствии доработки будут СУЩЕСТВЕННО ЗАТЯНУТЫ или вообще откажемся от проекта потому что решить почестному это нельзя. И не стоит бояться говорить правду - находятся те кто платят услышав её.
И естественно не следует о себе забывать:
аврал - плати, МНОГО,
хотите качество - делитесь прибылью или платите бонусы,
оставляйте резерв по времени, авралы допустимы только нештатных ситуаций типа заполучить нового заказчика быстрее конкурентов.

Как вывод: Может Вы не умеете работать с руководством?