Бих искал да попитам има ли голяма разлика между Atmel AT91SAM7 / NXP's LPC когато става дума за "прости",въвеждащи в АРМ7 проекти. Питам от гледна точка на това,че един човек имащ желание да захване АРМ платформата под една или друга степен кое ще е по-добре да избере. "Сложни" проекти окачествявам такива с няколко хиляди перфиферни устройства ( CAN / UART / USB / Ethernet ) - неща, които поне в началото няма да са ми необходими. Шумоустойчивост примерно няма да е важна ( поне в началото ),защото това,което се реализира няма да влезе в голяма употреба,освен усвояването на АРМ-а. Линукс със сигурност е нещо като Еверест - мечта на много,но трудно постижимо. Енергопотреблението също няма да от значение.

Насочил съм се към LPC2378 или AT91SAM7S256,защото има (поне на сайта) развойни платки от Олимекс, с които човек може да се занимава.


АРМ-а наистина ли е толкова труден ? Изчетох доста мнения из форума, има няколко "лагера" - атмелски,за продукти на NXP и тук-там някои ST. На някои места се споменават проблемите на едните или другите,коментират се възможностите,недостатъците на АРМ платформата като цяло. Но имайки предвид липсата на опит с АРМ-а не мога да преценя едни такива проблеми трябва ли да се вземат под внимание от образователна гледна точка.

Примерно в началото може да ми се наложи да подкарам двигател да се върти там...да има ЛЦД,тривиалните неща. Един такъв "проект" може да се реализира спокойно и с PIC / AVR ,но целта ми е ако се усвои АРМ-а да има и по-сложни проекти в бъдеще.

Чета,че LPC серията и май АРМ като цяло "страдат" от намалено бързодействие,когато се работи със I/O - някои може ли да даде конкретен пример какво се счита за бързо и какво за бавно при АРМ система с честота 50Mhz. Докато някои модели на LPC имат I/O с повишено бързодействие и би трябвало да се елимират някои от проблемите.

Примерно DAC-а на ЛПЦ2378 достатъчно добър ли е за непретенциозна употреба ? Бях чел из форума,че АДЦ-то при някои серии може да дава достатъчно голяма грешка,непозволяваща да се използва в някои приложения.

Въпросите ( ако може да се нарекат такива ) звучат доста объркано. Имам желание да захвана АРМ,но не знам от къде точно да започна. Имам известни познания върху тази материя,но са от малко по-старо поколение неща ( НС11 ).

Като цяло посочените модели на АРМ фамилията ( LPC2378 или AT91SAM7S256 ) подходящи ли са за въвеждащо запознаване или са прекалено сложни и не си заслужават усилията ?
Ако някои може да даде по-конкретна насока на един заблуден човек,бих се зарадвал

HC11<-> ТУ Пловдив. Захващай АРМ то и не се замисляй няма значение колко е бързо и/о то или ЦАП а все е по добре от НС11

LPC2378 не е подходящ в твоя случай. Особено като се има в предвид че има няколко съществени бъга. Например този на външната шина, която на практика е неизползваема. В момента се очаква да излезе нова ревизия с отстранени основните бъгове.
Ако ще е LPC като за начало по-добре LPC2138 или още по-добре LPC2148.

Atmel е с по бързи I/O-та ако това ти е определящо може да стъпиш на него. За начало може да стъпиш на АТ91SAM7S64 да кажем,има го наличен в Футурел и не е скъп. Може лесно да си спретнеш платка за него.
На Philips нещо IOтата им не са читави. На моята платка от Olimex с LPC2124 имам вече 10 тина умпрели I/O та. Това досега не ми се е случвало на друг процесор а съм работил с доста платформи. Не знам как е с по новите nxp но съм я зачеркнал тази фирма от списъка на производители на процесори оттогава
На ST процесорчетата не са лоши също. Най стабилно и бързо с тях работи комбинацията IAR - H-JTAG - Wiggler.
Иначе за управление на двигатели и подобни приложения на Texas Instruments АРМ7ците са много добри но се навлиза по трудничко да се работи с тях. Малко им е специфична периферията.

Май всеки минава през тези терзания, когато трябва да избере нова платформа .
Бих казал, че чиповете на NXP никак не са лоши. В последните ревизии на LPC213x и LPC214x са оправени почти всички бъгове.
Що се отнася до I/O-то, при старото поколение (LPC2114 и т.н.) обръщението към порт на процесора отнема 7 цикъла. При новите варианти - вече 2. Тук не искам да правя сравнение с PIC, HC11 или някой друг процесор - подобрението в производителността като цяло от използване на ARM-ядрото е несравнимо.
А изгорелите пинове - това е цената за "5V tollerant" изводите - просто няма защитни диоди към 3.3V, които биха ограничили по-високите напрежения. Впрочем, същият е и проблема с AHC, VHC и пр. логически фамилии - относително безобидни сигнали могат да повредят входа. Изводът е - не разчитай на вградена защита (защото няма), а си постави сам такава на изводите, които са свързани с външния свят.

АЦП и ЦАП - те са толкова добри, колкото могат да бъдат върху един кристал заедно с процесорно ядро, препускащо на 60MHz. Без никакъв проблем могат да се използват за управление на двигател, мониторинг на напрежения или температури и др., но ако е необходима по-висока точност, най-добре е да се използва външен чип, който е подходящо опроводен.

В момента присъстваме на второто раждане на LPC2378 след сериозните бъгове, които бяха открити в него. Затова съм съгласен със Zdrav, че е по-добре да се изчака докато премине периода на "детската смъртност".

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

А освен на ARM7-ядрото може да обърнеш и внимание на Cortex M3 - то е доста по-близко като концепция до програмния модел, който ни е познат от микроконтролерите, а има и редица преимущества, що се отнася за embedded системите. В момента единствено Luminary Micro продава процесори с това ядро (и то доста скъпо), но ST също обявиха фамилия чипове с него на цени между 1.5 и 3.5 долара. Нищо чудно и NXP скоро да ги последва.

Изобщо не съм съгласен с че това с I/O тата им е цената на 5V толерантноста. Има и други процесори които са толерантни към 5V a са на по ниско напрежение и не са ги лишили от диоди. Просто не са свързани към захранване а към точка в която предполагам с ценер ограничават напрежението. Тъпо решение от страна на Philips си е да ги оставят хвърчащи.
Но щом казваш че са оправили много неща в новите NXP може и това да са се оправили.

Ето и моито 5 ст. по отношение на избора:

АРМ или друг CPU/MCU
ARM е странна птица. По самата архитектура имам доста забележки и честно казано не мисля че това е възможно най-добрата. Ядрото има доста предимства, както и доста недостъци. Но това което го прави уникално е че това ядро е изпипано и доведено до ниво на стандарт. Това означава, че който и АРМ да вземеш няма да намериш нито един бъг в самото ядро. Поне на мен не ми е известно някой някога да е откривал подобен бъг. Въпреки че някой неща приличат на бъгове, примерно изискването за NOP след зареждането юзер регистрите, но тия неща са заложени още при създаването на архитектурата - така че не се броят
На практика ядрото е средна работа. Разбира се, има много по-слаби и калави 8/16 че и 32-битови ядра от АРМ. Но тъй като има много евтени и достатъчно нискоконсумиращи АРМ-ве на практика ако владееш АРМ в много много много редки случаи би ти се наложило да ползваш по-слабо ядро.
Разбира се има и по-мощни ядра. Но пък има и достатъчно мощни АРМ-ве на по 500MHz че и нагоре, както и често срещани комбинации ARM+DSP в един корпус.
С други думи ако си решил да ползваш само една платформа, то АРМ е много добра и ти позволява да покриеш много широк спектър от приложения.

Масов ARM или не
АРМ-ве има много - може би над 100 производителя. Обикновено LPC и SAM са двете фамилии които се броят за достатъчно масови, лесно достъпни и т.н. По средата може би са STR и TMS740. В края са разните специализирани OMAP-и и т.н. които нито може да си доставиш лесно, нито читава документация нито съпорт (освен ако не се казваш Nokia).
Има и още една група като OKI, Samsung и други жълти които все пак са доставими, но пак е зор документацията и съпорта.
Естествено ако започваш тепърва с АРМ бих те препоръчал масов LPC или SAM, че да има кого да питаш като закъсаш. Ако започнеш да копаш някое полезно изкопаемо ще трябва сам да копаеш...

LPC или SAM
Тук нещата са въпрос на вкус. Особено ако целта ти е само запознаване с нещата.
Аз лично смятам че за момента Атмел са по-добри поради една единствена причина. Това е че чиповете им през последните 10-15г се базират на едни и същи периферии. Тук трябва да отбележа че перифериите са доста по-трудни за научаване от самото ядро и изобщо не са стандартизирани и почти всички са доста бъгави.
Като се има предвид че и LPC и SAM предлагат може би стотици различни чипове, за хора които днес правят един проект утре друг не е без значение колко лесно могат да изхвърлят един чип и да го заменят с друг. Точно това е предимството на Атмел - днес пускам UART, но същия код и алгоритми бачкат на всички SAM7 (ARM7) и дори на SAM9 (ARM9), че дори частично и на AVR/AVR32. Ако знаеш един знаеш всички...
От друга страна перифериите им имат проблеми и някой ден ще се наложи да зарежат съвместимостта.
При LPC съвместимостта не е на такова ниво и всеки ден пускат чипове които са по-добри и с нови неща, за съжаление и с нови бъгове
Но ако вървят така нещата и LPC се изшлайфат няма начин да не надминат Атмел, но все пак мисля че двете фамилии ще останат рамо до рамо и разликите ще останат по-скоро вкусови...

ARM и проблемите
Вече споменах проблема с перифериите - доста сложнички, понякога има стотина регистъра за една периферия и един бит да объркаш нищо не работи.
Като цяло идеята на АРМ е по-скоро като процесор - да върти таскове, да прави сметки и т.н., а не да клати пинове. Затова почти всеки АРМ си идва с достатъчно солидна и сложна периферия.
Няма как сложната периферия да не е проблем за един програмист... къде къде по-лесно е да клатиш пинове

Друг изключително сериозен проблем, който според мен ЗАКОПАВА АРМ ТОТАЛНО са средите за разработка.
Първо са невероятно скъпи - с цени от 4-5к$ и нагоре за IDE+компилатор, отделно JTAG емулатори и т.н. Второ са доста засукани, може би заради особеностите на АРМ но не става да почнеш на С, да напишеш един main() и да постигнеш много... То трябва да поназнайваш малко асемблер, да пишеш линкерски скриптове и изобщо много по-голям гърч е отколкото да кажем при един 8-битов процесор.
Ако АРМ са вече много повече от 10г. на пазара, едва сега се появяват читави GNU тулсове. И това е много относително казано, защото ако не си на ти с Linux и GNU, забрави за лесно и безболезнено ползване на GCC, GDB и прочее... Ще ти излязат доста по-скъпи и от най-солената комерсиална среда

Друг проблем са операционните системи. Ако на един 8-битов хич не ти трябва ОС, то тук е бая зор да минеш без ОС. Ако тръгнеш с някоя сложна, няма бързо да потеглиш. Ако тръгнеш с проста, няма да стигнеш далеко...

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

Да попитам нещо относно това,което miro_atc засегна.
За компилаторите - понеже свалих няколко ( Keil,IAR, Crosswoks, ARM RealView Dev Suite, Eclipse Europa + GNU ) изникнаха няколко въпроса относно употребата им.
Има сносен туториал за Eclipse + ГНУ версията,който следвах и успях да закарам донякъде.
Но чета в нета мнения от сорта,че платените ( и по-специално IAR ) превъзхождали откъм възможности open source решенията.И въпроса ми е свързан точно с тези "детайли" - в какво се изразява това подобрение при използването на платените. Предполагам е и така,но не мога да си обясня какво представляват тези "оптимизации".
Реших да използвам Eclipse + GNU заради добрия tutorial,който има в нета за подкарване и основни операции с него. Срещат се естествено и проблеми от сорта на това,че някои примерни кодове са за "платените" версии и имам известни трудности с подкарването,но се решават.

Реално има ли "най-добър" ? Или е повече до лични предпочитания.

В yahoo LPC групата се намират и интересни мнения,че под линукс може да се направи много добра конкурентна на платените продукти развойна среда ( естествено с необходимото познаване на linux ).

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


Сега, конкретно IAR не смятам че е най-доброто от платените... и специално за оптимизациите изобщо не го смятам за по-добър от GCC. Има известни разлики в кода, но като цяло нищо което да си струва парите.
Ако търсиш компилатор с дълбок анализ погледни примерно Greenhils.
По принцип много компилатори започват от много буквално транслиране на сорса. Най-лесно това се вижда при GCC като му изключиш оптимизациите - генерират се стек фреймове и един куп простотии които ти даже не си си представял. Дефакто първоначалния код е твоя код със всичките глупости които си правил плюс още един куп глупости добавени от компилатора.
Грубо казано първите нива на оптимизации махат излишните неща, без да променят логикат която си задал. Това според мен си е задължително и не бих го нарекал точно "оптимизация".
Високите нива на оптимизация вече променят логиката - разместват код, могат да разгъват цикли, да заместват функции и т.н. С други думи опитват се да разгадаят алгоритъма ти и да го променят така че да стане по-бърз или пък с по-малко код.
Под GCC имаш много флагове за разрешаване или забраняване на един или друг вид оптимизация, ако ги разгледаш ще разбереш...



Повечето от тези примери са от сорта на helloworld... изобщо са само да те запознаят а не да ги ползваш в краен продукт.
Наистина за GCC има по-малко елементарни примери и това е разбираемо според мен, защото за да научиш GCC добре ти трябват месеци и едва ли ще хвърлиш толкоз труд за да мигаш един светодиод след това...
Като напреднеш обаче ще почнат да ти трябват далеч по-сложни неща - протоколи, стекове, файлови системи и т.н. Тогава ще видиш че има изобилие от подобни неща които са опен сорс, докато с "платените" нещата загрубяват, особено ако я караш на кракнати и "дърпнати" оттук-оттам неща...
Е разбира се, ако имаш пари... ще си купиш и ОС и драйвери и стекове и ще дойде със съпорт и при най-малкия проблем ще има кого да ругаеш. Това никак не е лош вариант също


Моят съвет (разбира се субективен) е:
1) ако идеята е само да се побъзикаш с АРМ ще ти е по-лесно с някой платен (ИАР е най-масов може би).
2) Ако ще бачкаш сериозно и ще изкарваш пари, но не искаш да инвестираш 10-20к$ GNU е по-добро
решение.
3) Ако можеш да си позволиш неограничени инвестиции, първо инвестирай в едно проучване на платените продукти... Може да пропуснеш IAR и Crossworks в това проучване

Можеш ли да кажеш от къде си изтеглил tutorial-а, аз нещо не успявам да го подкарам тоя еклипс.

Ако става дума за писанията на Джеймс Линч, тоя пич постоянно бълва нови версии и ги пуска къде ли не... (предимно форуми).
Няма пари човека явно да си спретне един сайт и никога не знаеш това дето четеш дали му е последната дума
Най-добре пробвай чичко гугъл с "Using Open Source Tools for Cross Development pdf"... Имай предвид че има "for AT91SAM7S" има и за други платформи, в някои версии е описано по един начин с едни jtag емулатори и т.н. Така де, като дръпнеш 5-6 варианта ще почнеш да се ориентираш.

Ако имаш някакъв конкретен проблем - кажи...

Еми дайте да се съберем, да видим кой какви процесори има и да сглобим някво IDE на база Еклипс и ГНУ.

А защо въобще ви е IDE

GCC за ARM се ползва лесно, остава само всеки да си реши как иска да си сипва кода/данните в контролера. JTAG/UART е една добра комбинация, която работи добре и под Linux.

Ами искам да имам удобен workbench за разработка. Билдването и ъплодването на кода е по-малкия проблем, аз съм свикнал да слагам брейкпойнти в кода (ако са къндишънъл - още по-добре), да си имам отделно Watch прозорче, където да си гледам стойностите на променливите, callstack прозорче и т.н. екстри.

Е не знам, аз съм динозавър дето не употребява workbench-ове.

Но за случая на ARM имам някакъв мъглив спомен че дори за Linux имаше някакво IDE дето предлага такива шарении. GDB имаше и графичен интерфейс, който си ползваше Wiggler, че дори и на друг компютър през TCP/IP.