Какой контроллер выбрать, Выбор микроконтроллера для дальнейшего развития Опции

[vepex]

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

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

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

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

[Golikov A.]

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

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

[Porty]

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

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

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

[jcxz]

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

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

[Porty]

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

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

[scifi]

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

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

[Porty]

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

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

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

[jcxz]

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

Это Ваша реальность - это реальность базара? Где лишь-бы продать кое-как сделанную халтуру, а там хоть трава не расти, хоть заказчик сразу выкинет ваше барахло, зарёкшись в следующий раз связываться с таким продавцом.
А Вам видно никогда не приходилось:
- ездить по объектам заказчика с вашим оборудованием, которое установлено не на столе в тёплой комнате возле кофейного автомата и улыбчивой девочки-секретарши, а где-нибудь в тайге, в холодной подстанции, когда при -50 градусах пальцы примерзают к клавишам ноутбука, а на железном полу не спасают даже валенки с двумя шерстяными носками. А если летом - сопровождающий советует не отходить вооон на тот край территории даже пописать, так как там утром видели мишку, забор вон помял, и вообще лучше по территории лишний раз не шляться, мало ли что;
- не приходилось перешивать ваше устройство, подключенное к силовым проводам, без его отключения, но с разборкой его (работающего!) чтобы воткнуть кабель программатора внутри шкафа,
где в нескольких сантиметрах толстенные шины на 10кВ. Потому что если отключить щкаф, то остановятся насосы качающие раствор, а для их перезапуска, нужно много времени, а за это время раствор в трубах замёрзнет (на улице-то температура ниже 50), порвёт эти трубы и тогда страшно будет подумать о сумме ущерба, вашей конторе дешевле будет вообще закрыться;
- вашей конторе не приходилось снимать с текущих работ всех кого можно в авральном порядке и засылать их на объекты заказчика, с оплатой проезда, проживания, аренды вертолётов для доставки
к объектам, куда иначе никак не добраться;
- вашей конторе не приходилось разбираться с заказчиком, который выставляет штрафные санкции, размером в тысячи Ваших месячных окладов, за ущерб нанесённый ему вашим повисшим оборудованием или потерей данных по вине этого оборудования;
- вашей конторе не приходилось слышать после этого от вашего многолетнего заказчика, что для следующего проекта, для следующей группы своих новых объектов, он предпочитает купить оборудование
другого производителя, так как у него хоть и гораздо дороже, зато надёжнее.

А всё потому что пришёл очередной "эффективный манагер" к вашему коллеге за соседним столом и сказал ему "заткнись и напиши этот грёбанный код за неделю..."
А коллега и прогнулся, скачал откуда-то "библиотеку" и вляпал её в код.
А ведь писавший её индус не подумал протестить свой код, работающий с RTC-часами (например) не только для текущего года, но и на другие даты, в будущее. Он же не знал, что кто-то додумается его
творение включить в ПО, работающее на нефтяной скважине с дебитом в тысячи тонн в сутки в глухой сибирской тайге. Или работающее на силовой подстанции, питающей несколько таких кустов нефтедобычи.
Манагеру то что - он просто пойдёт искать новое место, где нужно окучивать олухов. А вот контора влетит на хорошие бабки и ещё и репутацию у своих заказчиков сильно подпортит.

- не горели сроки
- не сталкивались с тем что разработка сделанная кое-как за пол года приносит 90% прибыли

И горели и сталкивались. Но достаточно было пару раз хорошо обжечься, когда убытки от халтуры и траты на устранение её последствий многократно перекрывали потом эти 90% прибыли, чтобы понять одно простое правило:
НЕ ВСЕ ЗАКАЗЧИКИ == ОЛУХИ