Само да вметна, че на NXP кортексите също не са за изпускане.
Незнам как сте с тях, но аз лично нямам от какво да се оплача(говорим за М0 М3)

Да, най-ценното ми се видя тоталната свобода на конфигуриране на пиновете. Не знам обаче дали е за всички серии. Само силабс са близко с crossbar-а, но NXP-то е по-гъвкаво.

За NXP съм казвал и преди, че политиката им е да правят малки фамилийки и които не са обвързани с другите им фамилии. Мен това ме бърка защото за да подкарам един чеп трябва да му подкарам периферийките, драйвери ала-бала. Това е труд и време. И ако при Atmel, ST, TI напиша драйвер знам че тоя драйвер ще бачка на около 100 чепа. Докато при NXP ще бачка само в рамките на фамилийката и не е ясно дали ще бачка за другите им чепове.

Но това са си мои грижи... ако някой ползва готови библиотеки няма да има този проблем. И факта че NXP не гонят съвместимост им позволява да вкарват подобрения във всеки нов чеп/фамилийка, така от тая гледна точка след време да имат по-качествени джелеза.

Не съм съгласен, че Атмелските cortex-М контролери са издържани технически. Има големи изненади. Само ще дам за пример DMA-то им, така нареченият Peripheral DMA Controller (PDC) - няма режим кръгов буфер. Трябва на всеки TC (transfer completion) да имаш прекъсване и да стартираш отново DMA трансфера. Което е брутално както и да го гледам, особено ако имаш бърз трансфер.

Дори за нещо тривиално като генериране на константен сигнал (форма, такт на дискретизация) става страшно. Имах да генерирам 40kHZ @ 1.8MSPS. Имах си един масив със семпълите отразяващ един период на сигнала (45 точки) и 'просто' трябва човек да го пусне през DMA към DAC в кръгов буфер.

А при SAM4S и подобните му имаш единствено възможност да зададеш текущ и следващ трансфер. Викам си "окей, пак е нещо". Поне ще правя прекъсване на два периода, не на един, макар че можеше да сложат един бит/опция, който/която при сетване да повтори последният трансфер, но не би.

И така всяка секунда процесора влиза 20000 пъти в прекъсване само заради DMA-то. Отделно имах USB device, ADC, обработка и т.н. Естествено USB-то и ADC-то също имаха прекъсвания. С една дума: смених контролера.

Това дали са перфектни и ти харесват е съвсем различно нещо от това дали са по-добри от Луминари, СТ и Фрийскейл...

Значи при класическите атмели имаш един бит да разрешиш ДМА-то, пишеш указател, пишеш дължина и воала толкоз! Няма нужда да четеш даже дейташит, 3 записа са, като само бита е на различно място в регистрите на периферията, иначе дма регистрите са на един същ офсет във всяка периферия. Просто и ефикасно.
За сравнение при Луминари за да подкараш каквото и да е ДМА трябва да заделиш 1К РАМ, да попълваш един куп глупости и на всичкото отгоре имаше и един куп бъгове, за щастие обаче перифериите им имат ФИФО-та така че си реших проблема генерално - нито едно ДМА на нито една периферия. Просто НЕ СТАВАТ за ползване. Сега новите тиви ще видя ако са оправили проблемите може и да ги ползвам, не знам...
При ST за да подкараш ДМА първо трябва да изчетеш чаршафите и между чаршафите и пак не е гранция. То са едни заявки, отделни вектори за прекъсване, коя периферия кой канал може да ползва, съответно трябва да се съобразяваш дали някой друг не го ползва по същото време... В крайна сметка не можеш гарантирано навсякъде да го ползваш, нямаш и фифо така че не винаги може да избягаш генерално... и резултатът е че за всеки драйвер се налага да правя опция с ДМА и без ДМА, което раздува кода. Да не говорим че за малки трансфери овърхеда е огромен, ама карай... А конфигурацията пък е силно зависима от конкретната периферия, отделно че трябва да се съобразяваш дали е на AHB или APB на колко да си цепи бърстовете, пък как да си подрежда байтовете, с какви приоритети да е, пък как се флъшват ако последния трансфер е по-малък от бърстта. А отделно колко бъгове има в ератите...
При Фрийскейл Цецо ще ти обясни как стоят нещата... той в една друга тема е обяснил вече де. Просто няма такова малоумие като тяхното, първо да си пръснеш данните в паметта и между всеки байт да вмъкваш команди за ДМА-то...

Тъй че хайде подкарай още някой пък после ела да се оплакваш от Атмел

Между другото в по-новите си серии вече имат някакъв евънт мениджмънт и може без ЦПУ намеса да навързваш периферии и ДМА-та и глупости, ама не съм ги ползвал още тия щуротии...

+1

С event системата мога да го подкарам, АКО заделя ЦЯЛ таймер да генерира TRGO, което да пуска DMA-то.

Иначе за Атмелските контролери - ATxMEGA е страшно гъвкав, единствено е с не много високо бързодействие / MIPS. Но там DMA-то, прекъсванията и event системата са страшни. От любопитство бях докарал ЕДИН И СЪЩИ пин да ми генерира IOC прекъсване, да мери през него ADC-то и го бях вързал към EVENT системата с един таймер да меря период Откачена работа, но факта е, че работеше. Ползвах ATxMEGA128A1, ако не бъркам, беше върху на Олимекс dev платка. А и също МНОГО ми хареса, че портовете са обособени ! Не съм сигурен дали беше точно така, но примерно: PORTA - Analog I/O for ADC, PORTB - Analog/Digital I/O for Timer modules, PORTC,D,E,F,G,H - Digital I/O + Comm. Interfaces.

Писал съм и на atmega168/128 - също добре организиран.

Но да се върна на темата за Cortex-M контролерите на Atmel. Много недомислени неща има. Може да имаш съвместимост между сериите, но аз лично във всеки проект си оставям свободни ресурси: ROM, RAM, GPIO, поне един UART/I2C/SPI, така че тази серия, кооято съм избрал да свърши работа дори и при обновяване, подобряване, допълване на проекта Досега не се е случвало да съм бил изненадан да не мога да добавя нещо поради ограничени ресурси на контролера Всъщност като се замисля май само веднъж ми се наложи на един PIC16F884 да вкарам програма писана за 886. Което си бе приключение, защото разликата във Flash и RAM паметта бе доста. Но се справих де Много оптимизиране както от мен, така и от компилатора и го събрах на 94% от паметта