Можете ли да препоръчате ARM7 микроконтролер.
Критериите са:
- честота 20-40МХц
- 30-50 входа/изхода
- ниска цена/лесен за намиране
- безплатен (евтин) софтуер
10х!

Не мисля че това са някакви критерии - повечето ги покриват в един или друг смисъл.

Ако говорим за масови, това са две фамилии - AT91SAM7 на Атмел и LPC на NXP (philips).
Между тях има сериозни разлики, които обаче не могат да се определят еднозначно като предимства или недостаци.
Разликите са:
1) Всички SAM-ве са на една платформа с еднакви по тип периферии, т.е. код за един чип с лекота се прехвърля на друг. Всички периферии са еднакви, т.е. има само една версия на UART/SPI/TWI и т.н. и само се копират от чип на чип с copy&paste. Даже бъговете са еднакви
При LPC не е така - има различни серии, има разлики. В началото не ми харесваха първите LPC-тa, но сега ги променят и от чип на чип задобряват. Докато Атмелската платформа беше по-добра, но не идеална и лошото е че не подобряват почти нищо.
2) Основната разлика в перифериите всъщност е че Атмел от самото начало тръгнаха с ДМА-та, докато LPC бяха FIFO-базирани.
Това даваше огромно предимство на Атмел в някои приложения, защото един SAM спокойно може да си поддържа няколко периферии на 10Мбит/с без сериозен cpu usage, а без дма всичко над 4Мбит/с утрепва процесора. Сега новите LPC им слагат вече DMA-та.
3) Като цена LPC-та принципно са по-добри. Но и Атмел вадят добри цени понякога, примерно предлагат ARM9 под 10$.

Нещата между двете фамилии са на кантар, въпрос на вкус. По-добре да ги огледаш и двете за да видиш коя фамилия ще ти допадне. Надявам се че не избираш АРМ само за един конкретен проект - това би било грешка. Затова няма смисъл от подробности относно конкретен проект. Но все пак обикновено се движат проекти в една близка област, така че може да се съобразиш какви периферии ще ти трябват повече. Примерно Атмел са много зле от към I2C, но SPI и UART долу-горе стават.

За ATMEL не мога да кажа нещо лошо, но за LPC мога да напиша роман на който резюмето би било... "Никога не им се доверявай напълно!"

Няма какво да пишеш романи - просто изброй проблемите. Така ще си ни полезен. Не сме политици, а инженери, все пак.

мнението ми се припокрива с това на miro_atc
при NXP има прогрес който се вижда хората започнаха от нула преди 3 години и първите чипове бяха доста дървени но доста последователно си чистеха бъговете и най-важното слушат какво потребителите им връщат като обратна връзка и вкарват в новите чипове
LPC2148 има много по-добра концепция за USB engin-a отколкото SAM7 например
Атмел правят АРМове от много отдавна но веднъж направят ли една периферия не я променят (за съвместимост) и нещата не могат 10 години все да са актуални а и никой не прави перфектен чип/периферия от първия опит
общо взето и NXP и Atmel нямат FAEs или съпорт за България но поне NXP има чудесна Yahoo група където има над 3000 инженера които са готови да ти помогнат за сравнение AT91.com няма и 1/10 от трафика на LPC2000 групата и повечето въпроси си стоят там и никой не им отговаря
не се вързвай на kiiid LPC нито имат повече нито помалко бъгове от всеки друг микроконтролер

@kiiid, не само LPC имат проблеми. И двете фамилии са сравнително трудни за подкарване и всичко зависи колко мини ще настъпиш. Проблемите произтичат не толкова от бъгове в силиция - бъговете общо-взето са известни и може да се заобикалят.
Основните проблеми са в сложността на ядрото и перифериите. За всяка периферия има огромен брой регистри и няма един единствен начин как да се ползва периферията. Често давам примера с GPIO, ако за един 8-битов контролер имаш 2-3 бита с които управляваш дали съответния пин е вход/изход или с високо/ниско ниво, то при един АРМ имаш някъде около 30-на бита за управлението на един пин. Всички периферии са сложни, ако при един 8-бит контролер UART си е прост UART, то тука може да имаш синхронни/асинхронни режими, ISO7816, манчестер кодирания, DMA-та и какво ли още не...
Съответно всеки потребител прави нещата различно от останалите и като обърка някой бит в някой регистър на практика няма кой да му помогне, защото другите го правят по друг начин.
Затова и форумите не са толкова полезни. Особено за Атмел - там по принцип концепцията на перифериите е по-сложна и по-засукана и на всичкото отгоре документацията на Атмел не предлага идея как точно да се ползва софтуерно периферията. Верно, имат някакви библиотеки, ама те са толкова некадърно написани че аз лично изобщо не ги използвам...
Мисля че в тая насока Атмел осъзнаха грешката си, вече по форумите се появяват хора от Атмел, освен това наскоро отвориха съпорта си (http://support.atmel.no)

Абе доста трябва да се внимава когато се избира... Мисля си че за по-спешни и по-прости проекти може би LPC е по-добре. Иначе аз лично съм фен на Атмел и бих ги препоръчал, но човек който се хваща с тях трябва да разполага с малко повечко време и нерви.
Знам че някои ще кажат че бъдещето на филиповци е по-добро... да, атмел имат си имат и вътрешно-фирмени проблеми, не променят концепцията си, докато филиповци постоянно усъвършенстват концепцията си за АРМ...
Няма как просто един ден LPC категорично да не е по-добро от SAM.... Така беше и с 8051 - Филипс направиха най-добрия 8051-базиран процесор - XA фамилията. Супер процесор, ама го направиха прекалено късно...
Дано да не се мотат толкова време и с LPC, защото наистина имат шансове да направят добра фамилия. Като я направят ще мина в техния отбор, но не и преди това

За TMS470 на TI какво ще кажете?

върха са ако се казваш Нокиа, Бош, и разни такива даже ако нещо не ти харесва по чипа ще ти го пре-правят
иначе не очаквай да получиш дори up-to-date дейташиит (май тези дето са на веб-а са от 97 или 98 година)
мисля че за OMAP-a май не даваха и дейташиит ако пишеш че проекта е под 100К чипа годишно а отделно имат и много чипове които не са си направили труда даже да ги сложат на web-a

Погледни и STR71x на STMicro

И то май с това се изчерпват общодостъпните ARM контролери... (ST, NXP, Atmel)

абе не е баш тъй... чипове се намират всякакви - OKI, Samsung, Toshiba, Sirrus, Analog devices и т.н. Обикновено не ги споменаваме заради липсата на съпорт или по-тромави с доставките.

То не че пък съпорта на Атмел (филипс) е голямо цвете, ама поне сме повече хора дето сме се набутали и чат-пат може да си помагаме

Не е евтин и развойните средства за него не са безплатни. Няма DMA. Иначе е

Ами... тъй като всички дружно скочихте срещу мен по един или друг начин, ще се опитам да се защитя малко. Първо и най-важно, това, което аз изказвам като мнение винаги си е лично мое мнение и не насилвам никого да го поддържа.
Сега за LPC - фирмата ми от около 2 години разработва два мащабни проекта базирани на LPC2292 които се търкалят по хеликоптери. Тъй като почти целия хардуер и софтуер са минали през мен, мога да споделя какво не ми допадна (а като че ли ги харесах в началото):
1. Така и не проумях защо този иначе сравнително голям микро има само 16К RAM! Сложили му 256К флаш и сума ти периферия, а нещо са попренебрегнали рама. Какви ли не магарии въртях във фърмуера даже се наложи допълнително да закачаме външен сериен рам за да се съберат оперативните данни. Голяма грешка на Филипс според мен!
2. Само 2 серийни порта. Е на контролер със 144 пина можеха да бъдат поне 3, нали? Примери колкото искаш. Е, наложи се един порт да го правя софтуерно...
3. Серийните портове не поддържат "idle line". Е, още един чип отвън ама няма как, нали е LPC все-пак...
4. Лошо реализиран VIC. Не знам доколко сте задълбавали с него, но я опитайте да сменяте динамично активния фронт по който се генерират EINT! Да не говорим, че при достатъчно често възникващи EINT от повече от един вход, някои прекъсвания понякога просто забравят да "възникнат".
5. Флаш на Spansion така и не тръгна на 16-битова външна шина дори и след седмица борба на всички инженери. Иначе на 8 бита няма проблеми.
6. A/D не е особено точен както изглежда. Понякога разликата достига до 0.1V от реалността.
7. RTC... е, за истински RTC тук и дума не може да става. Иначе уж има.
8. Тук нямам особено голяма почва за доказателство, но лично на мен ми се струва, че общата производителност като цяло не е особено добра, и специално в случаите, когато ядрото е натоварено с много прекъсвания. Пак повтарям това е само впечатление.

Сега не се сещам, но мисля че имаше още доста проблеми с LPC. Като тук става дума за хардуер и софтуер, който се прави от няколко инженери и програмисти с минимум 7-8 години опит т.е. случайностите са практически изключени.

Лично аз едва ли бих избрал това микро за нещо друго. За съжаление не съм го избирал първия път, иначе и тогава доста бих си помислил...

kiiid, проблеми има навсякъде, ако мислиш че при Атмел няма недомислици - грешиш
Но като цяло SAM си струват парите и постигат неща които малко контролери могат. Аз поне бих ги заменил само срещу по-добро ARM решение. Всъщност и сега ако се разтърся сигурно ще намеря по-добри ARM-ве и единственото което ме спира е че SAM стана доста богата фамилия и с лекота мога да избирам - ако не ми хареса размера на паметта, мога да сложа по-голям или по-малък чип в същия корпус. Има и прилично разнообразие в набора от периферии...
Пак казвам - зависи какво търси човек... Ако е само за един проект, наистина можеш да използваш какво ли не. Но ако движиш разлнични проекти не върви всеки път да се тормозиш с нов чип и всяка периферия да е различна.

Нищо никой не споменава за софтуера... а там е най-големия гърч
Аз в момента тукмо смятам да започвам да прехвърлям нещата си на open source - Eclips+GCC и не ми се мисли какво ме чака....

@kiiid В това което си написал къде е резюмето "Никога не им се доверявай напълно"
1. Защо само 16К RAM? Ами ценови съображения може би. LPC2000 има и с 32К и с 64К и нагоре. Освен това LPC2292 нали има външна шина.
2. и 3. Това е въпрос на избор на контролер съответстващ на приложението.
4. VIC в LPC2000 е разработка на ARM. Но тук въпросът не е за него а за EINT(външните прекъсвания). Точно този контролер, който сте използвали има бъг в конфигурирането на EINT. Чети ератите при избор на контролер.
Този бъг е отстранен при новите ревизии и следващите представители от LPC серията. Бързината с която ARM7 влиза в прекъсване и възможностите за пропускане на събитие или получаването на лъжливи прекъсвания са проблем за всички ARM7. Това трябва да се знае от самото начало.
5. Тука проблема не е в контролера. При мен външната шина на LPC работи и в 8 и 16 битов режим.
6. Проблема най-вероятно идва от особеността на АЦП-то на LPC2000 че за точно мерене трябва да резервираш всичките осем канала да конфигурираш пиновете като такива и неизползваните да ги вържеш към земя. Щото иначе неизползваните или използвани за други функции канали разбозяват измерванията. Това е известно от самата поява на тази серия и също трябва да се знае от самото начало.
7. RTC си е истински RTC само дето първите представители на LPC2000(в това число влиза и LPC2292) спират клока му когато заспиват. Това го няма като проблем при следващите. Написано е недвусмислено в документацията му.
8. Тука си прав, но сравнявал ли си го с друг ARM7? Прекъсванията са слабо място на ARM7, но след като си избрал ARM7 трябва да живееш някак си с това.

kiiid според мен проблемите ви са били заради прекалено големи очаквания, които в последствие не са били оправдани.
В проектите където ползвам LPC2000 всички тези точки от 1 до 8 са ми били известни още при излизането на предварителната документация на процесора. И за всички тях съм предвиждал хардуерни или софтуерни "патерици".
Не казвам че LPC2000 са "върха", но за приложенията за които ги ползвам са точно на мястото си.

За развойна среда ползвам YAGARTO. Има всичко което ми е необходимо. Дебъгера има доста трески за дялане, но с малко изобретателност се хващат всякакви бъгове.