Добрый день.
Сегодня получили платку от Analog devices на ADuC7026 + адаптер jtag под кейл. До этого я работал с ad dsp, а там в pure asm , ну и с pic, конечно, но и там - pure asm. Хочется попробывать их (ARM) поизучать, а там, возможно и попременять, как более продвинутые контроллеры, чем pic , попутно и молодость вспомню, на С попишу . Кстати, почитал я немного доку на их ассемблер - могу выразить свой респект, грамотно сделали процессор(ARM). Ладно, поставил пакет - Keil uVision3 - ругается на ограничение в 16 кил на код. Это как я понимаю, лечится? Еще вопрос: там же на компакте был IAR, но он не ставится, требует license #. Этот license берется на iar.com, как я понимаю, а вот потом его полечить мона? Еще вопрос: адаптер jtag ulink будет работать в IAR? Или надо wigler собирать? И как мнение народа, в чем лучше работать в keil или в IAR?

Если дочитали до сюда, то мой
А если еще и ответите, то 2x

Не лучший выбор, однако. TMS470 выглядят приятнее.
Практически все известные компиляторы для ARM есть хорошо вылеченные.
Ulink под IAR наверняка работать не будет.
Зато Wiggler под Keil известно как заставить работать.
Keil безусловно более мощный инструмент чем IAR. Его компилятор дает самый быстрый код, а его симулятор единственный который симулирует всю периферию известных семейств на ARM7TDMI и работает почти в реальном времени и даже в некоторых случаях быстрее. Плюс Keil можно перенастроить под использование компиляторов RealView или ADS 1.2.

Я понимаю, что ADUC не лучший выбор, но для знакомства с ядром ARM я думаю, что хватит. TMS470 помойму еще не выпускаются, или выпускаются, но не понятно для кого и где их покупать. Wiggler под Keil мне не нужен - у меня родной кейловый ulink есть в комплекте . У меня есть вопрос по поводу компиляторов: в свойствах проекта есть выбор из трех компиляторов: самого кейла, gcc и какой-то arm works или что-то похожее (пишу по пямяти, сейчас глянуть не могу), так вот какой из них более быстрый? Или это однозначно на реальном проекте проверять надо?

Смотря для какой цели. AD дают ЦАП и АЦП - по 12 бит, чего нет у TMS470 и LPC.
Здесь http://forum.electronix.ru/index.php?showtopic=2631&hl= посмотрите, ставьте пока karm v.1.5
Keil с Вашим Ulink-ом работает на ура.

Если не пускает по ссылке, то придется стать своим, много проблем отпадут сами собой.

Для знакомства хватит и симулятора на Keil.
Вижу большие трудности с ЦАП и АЦП у которых нет DMA.
Либо вам придеться вернуться к asm-у и забыть про преимущества RTOS, либо вам придеться забыть ADuC, если вы действительно хотите использовать точность и скорость этих ЦАП/АЦП
Если вам не нужна многозадачность, ваши приложения просты, вы не портируете чужие исходники, ваши проекты маленькие по объему и вас не волнует быстрота компиляции, то можно успокоиться и на Keil с IAR.
Но серьезные вещи с расчетом на перспективу без MULTI2000 или ADS не сделать.

К стати на сайте у KEIL-а есть сравнительная таблица с другими компиляторами. Там KEIL выходит почти абсолютным победителем.
Я тоже проверя whetstone в KEIL и тех компиляторах, получил почти те же соотношения.

А вот по моему мнению IAR код генерит поплотнее чем Keil
Хотя и под Keil можно писать. Оч удобный программный симулятор
Практически на нем отладил генератор синуса по методу DDS
При загрузке в кристалл заработал сразу. Тут и JTAGи никакие не нужны.

Меньший код чем у других часто свидетельствует о рискованных оптимизационных манипуляциях.
Не раз наблюдал как после максимальной оптимизации по размеру в IAR программы переставали работать. Я юзал IAR для MSP и для PIC18 и везде те же симптомы. Плюс IAR не хочет учитывать errat-ы на чипы выпускаемые производителем.
Также наблюдал как Tasking давал меньший размер кода чем KEIL, оказалось что делал он это за счет того что не делал корректного приведения типов а прибега к разным трюкам. И в нем тоже в конце концов приходилось бороться с оптимизацией.

Ох, и намучался я с этим кейлом сегодня. Пытался собрать и запустить uC/OS 2. В конце концов все кончилось на том, что компилятор GNU не понимает extern из асма, конечно, с этим можно разобраться, но помойму проще на IAR соскочить ;-) Кроме того, не так уж и безглючно у меня работает jtag адаптер - время от времени отваливается, приходится его из usb втыкать/вытыкать. ДМА лично мне в нем не нуно, там где оно нуно bf стоят, а если их не хватает, то и ts мона поставить. А вот контроллер с ОС РВ для всякого рода управления, опрашивания клавиатур, вырисовывания всякой чепухи на lcd, комуникационных задач и т.д. очень даже подойдет.

Хотелось бы все таки узнать у народа, с чьим пакетом лучше работать?

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

Ну с GNU в любом случае нужно соскакивать.
А вот для для так называемой ОСРВ, напрмер, важно быть уверенным в реентерабельности используемых функций. Так в IAR об этом кажись даже понятия не имеют. (еще ему один минус )
А Wiggler-ов не слышал чтоб было много. У меня например работает самый примитивный на двух 244-х буферах. Ни одного сбоя при загрузке не замечал ни в IAR ни в CW ни в KEIL пока. А клок в JTAG с LPT порта идет с частотой 1 Мгц по кабелю 1 м.

Т.е. IAR так оптимизирует код,что в случае ОСРВ, где код может крутится по кругу для одной задачи, может глюкаво работать?
Кстати, про кейл - на моей win2000 его ассемблер AA.EXE делает неповторимую ошибку и будет закрыт ;-) .

А что вы можете сказать про mulri2000 и ads?

Почему? Проект в несколько сотен тысяч строк кода - работает. И как показывает опыт -
дело обычно не в компиляторе, а в быстронаписаных удобных средствах отладки - "Hello, world!" - махом и на ура, а как что серьезное - тормоза и падучесть.

Касательно вигглера - какой отладчик дает на TCK такую частоту?
Выше 300 кГц еще никого не видел - т. е. задаю длинную операцию (чтение массива из памяти) и измеряю на пине.

P.S. Работаю в линуксе - это по поводу GNU

Может это - http://www.caxapa.ru/echo/arm.html?id=21206



Извечный вопрос - что лучше
Честно, сам еще не определился что лучше. Сегодня нравиться ИАР вчера кросворк, а завтра ?

Скорее всего это зависит от задачи - а точнее от комплекса задач, стоящих перед разработчиком. И одной средой на все случаи жизни обойтись иногда можно, но почти никогда не нужно. CrossWorks понравился обилием сервисов, компилятор вроде как GNU,
не понравилось как раз отход от стандартной технологии - нет make-а, библиотеки целиком свои. Но быстро попробовать какую-нибудь идейку, слепить-запустить тестик - самое то.
А вот попытка перетащить серьезный большой проект окончилась крахом - бысторо начинает тормозить (но это бы еще пол-беды, пишу все равно под slickedit-ом), и падать -
причем без вариантов, рушится и все. Multi в свое время тоже понравился, есть у него еще замечательное свойство - не в нем собранные ELF-ы грузит/запускает/отлаживает без вопросов - иногда нужно. Но совместимость с GNU в нем только сравнительно недавно декларировали, хотя по структуре библиотек, компилятору - явное подобие со старыми GNU.

Может Микрософт что-нибудь предложит ? Что-то вроде VS NET под АРМы ?

А если серьезно - проблема выбора софта под АРМы одна из основных:
1. Являюсь первопроходцем по АРМам на фирме (все шишки мои).
2. Нет серьезного проекта который можно портировать на АРМ и заценить софт.
3. (вписать свое)...

Использую Iar для AVR - никогда такого не наблюдал
Все ошибки что были - из головы

Скачал вчера IAR, получил по емейл ключик, поставил. Но проекты не компилятся - говорит, что время действия ключа истекло, ладно, значит не судьба пока ;-) . Поставил karm v.2.0 . Пытаюсь собрать ядро uC/OS2 с использовнием кейловского компилятора. Пока - выходит с попеременным успехом. Самое смешное, что на те конструкции, на которые gcc не ругается, кейловый компилятор обкладывает ошибками. Есть ли кто-нибудь, удачно переживший данную процедуру?

Если только "кажись", то зачем же сразу минус?
У меня IAR при максимальных оптимизациях (что по размеру, что по скорости) с ARM (LPC, Samsung) и uC/OS работает на ура.
Как сказал NickB - все ошибки из головы, особенно в плане реентерабельности кода (в этом у IAR огромный плюс).

Вылез еще один интересный глюк: при компиляции os_cpu_a кейловый ассемблер (тот который aa.exe) вылетает с сообщением, что memory could not be read ;-). Весело. Причем, не только у меня на машине, пробывал под разными осями и на разных машинах.

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

Здравствуйте! Мы тоже собираемся использовать ADUC в своей разработке, получили инженерные образцы. Так как это первый арм, с которым собираемся работать, у меня вопрос (не ругайтесь если глупый) - как правильно подключить внешнюю RAM 16битную к адуку? Со смещением адреса
(A1aduc->A0ram) или без? В даташите на отлад плату они подключены(по схеме) один к одному, но сказано что надо в регистре поставить бит.
Подскажите плиз. а то запутался.
ЗЫ. делаем отлад. плату сами, максимально под проект.

Хе-хе.. Еще раз протестировал IAR, KEIL и CW на Whetstone.
Код из IAR 4.20A работает медленее чем из CW 1.3 на 25%
и медленнее чем из KEIL 2.0 в 3-и раза!!!
У нас один парень в KEIL-е умудрился сделать DTMF декодер по алгоритму Герцеля в реальном времени на LPC2106 с использование float point!

И еще. Если найдете место в документации IAR где расписано какая функция реентерабельная, а какая нет, то буду вам очень благодарен.

Я вот никак в толк не возьму как Keil может быть быстрее
Может быть все дело в библиотеках?
Как пример вот короткий листинг
И еще - по кр мере в демо нет библиотек double - <_<

Например здесь поищите слово reentrant.
И немного истории.
В ранних версиях библиотек (для AVR по крайней мере) действительно была не реентерабельная функция _formatted_write, применяемая в printf. Но в последних версиях этот недостаток исправлен, о чём имеется явное указание в заголовках соответствующих файлов.
Кроме того, есть ещё функции, работающие с глобальным кодом ошибки, но они не реентерабельны по определению и поэтому не обсуждаются.
Что касается продукции для ARM, то там всё реентерабельно по умолчанию.
Для скептиков.
С целью убедиться в правоте вышеизложенного можно просмотреть исходники библиотек.

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

IAR даже хуже оказался чем я о нем думал.
Протестировал только что Whetstone из MULTI 2000 v4.0.2, так он в 2-а раза быстрее выполняеться чем из IAR.
Не странно ли, что на сайте IAR нет бенчей по быстродействию?
Теперь понятно почему их там нет.

1. http://www.iar.com/FilesPublic/EW/001876/E...-benchmarks.pdf.
2. Не достаточно ли скоропостижной критики?

А бенчи-то по размеру.
И вообще, народ имеет право знать правду!