ARM7 с нуля

[Satyr]

Это на 8 битном шлаке только что и можно ногами подрыгать, тут задачи обычно поинтересней.
Собно, GPIO используется не так чтоб сильно часто. У этих контрллеров хватает стандатных интерфейсов.
Могу сказать, где этих 72мгц недофига какбы - раскодирование и масштабирование jpeg файлов. Делал я GPS трекер с сканированными растровыми картами.
шифрование, ЭЦП - там тоже с 72мгц результаты отнюдь не фантастические.
Мелкие карманные осцилографы с анализом сигналов. генераторы сигналов сложной формы, системы управления с множеством входных и выходных параметров, типа ЭБУ двигателем в машинах.
И т.д. и т.п., где есть какие то вычисление, а не чисто дергание одной ножкой по появлению сигнала на другой ножке -))

Вот, очень жду LPC1850... Cortex-M3, 150Mhz

[ARM7]

номер пина - просто число ( и для переключения состояния пина это число выводится либо в IOCLR, либо в IOSET порты)

- переделывал исходник с CVAVR, вот не знаю как это переписать- PORTC.0=cmd; ,вот и возник вопрос.

[ChipKiller]

переделывал исходник с CVAVR, вот не знаю как это переписать

... так ведь принцип управления другой - у ARM 4 регистра на бит порта, а у AVR 3.

[SII]

У ARM не 4 регистра на бит порта, а сколько угодно в разумных пределах: у разных производителей периферийные контроллеры, в том числе и GPIO, реализованы по-разному (иногда -- очень по-разному). Может быть и дюжина регистров, и больше.

[ChipKiller]

У ARM не 4 регистра на бит порта, а сколько угодно ...

... речь именно о GPIO (IOPIN,IOSET,IOCLR,IODIR)

[Satyr]

У ARM не 4 регистра на бит порта, а сколько угодно ...

... речь именно о GPIO (IOPIN,IOSET,IOCLR,IODIR)

Да ну? Вот тыкаю наугад в первый попавшийся ARMовский контроллер TI и не находу ни одного из этих регистров ? Как же так ? -)))
Не забывайте - ARM лицензирует в общем случае только процессорное ядро. Есть у него вприницпе и еще некоторые куски на продажу, типа там контроллера внешней шины и подобного. А вся периферия, включая GPIO, у каждого производителя контроллеров на ARM ядре своя.

[ChipKiller]

А вся периферия, включая GPIO, у каждого производителя контроллеров на ARM ядре своя.

... это понятно - непонятно причем тут TI, с первого топика речь идет о LPC2xxx

PS соглашусь что название ARM7 с нуля не очень удачно .....

[Errorkpi]

Вот возникла задача реализовать что-то действительно сложное и АВР для этого уже нехватает. Решил все таки освоить ARM. Я как сильный приверженец Atmel решил стартонуть с процессора AT91SAM7X128. Основное из-за чего он выбран - наличие Ethernet.

Вот хочу попросить совет:
1) Как его шить (к сожалению LPT порта у меня нет. Наиболее предпочтительно что-то USBшное)
2) Какая среда разработки наиболее удобна и стабильна
3) Есть ли какие-то глобальные проблемы с ARM.

[SII]

У ARM не 4 регистра на бит порта, а сколько угодно ...

... речь именно о GPIO (IOPIN,IOSET,IOCLR,IODIR)

Да ну? Вот тыкаю наугад в первый попавшийся ARMовский контроллер TI и не находу ни одного из этих регистров ? Как же так ? -)))
Не забывайте - ARM лицензирует в общем случае только процессорное ядро. Есть у него вприницпе и еще некоторые куски на продажу, типа там контроллера внешней шины и подобного. А вся периферия, включая GPIO, у каждого производителя контроллеров на ARM ядре своя.

Ну да. Вот, беру даташит по ATMEL AT91SAM7Xxxx и вижу, что для тамошнего контроллера ввода-вывода (именуется PIO, но имеет ровно то же назначение) цельных 29 регистров на каждый порт (три из них, правда, управляют выбором "хозяина" ног -- то ли это будет PIO, то ли какой-либо из других периферийных контроллеров). На других АТМЕЛовских АРМах та же история.

Беру для интереса NXP LPC24xx. Для выбора функций ног у того служит 22 регистра на все пять портов, а вот для собственно работы с каждым портом -- по 4 регистра в "унаследованном" режиме (legacy), в коем могут работать только два порта, и по 5 регистров в расширенном режиме, в котором могут работать все 5 портов.

Так что неправы Вы. Количество и назначение регистров у любого из периферийных контроллеров, как и у контроллера прерываний, зависит от конкретного семейства и может различаться даже у продукции одной и той же фирмы. У той же NXP, если память не изменяет, у семейства LPX22xx тот же GPIO работает только в унаследованном режиме и имеет только 4 регистра на порт.

Те же самые различия, только с меньшей степенью разброда, касаются и собственно процессорных ядер. Нельзя просто сказать "ARM" и предполагать, что там есть, а чего -- нет. Различается даже выполнение ряда команд у процессоров разных семейств. Например, у ARMx4T (ядра серии ARM7 с буковкой T) команды типа MOV и LDR не могут выполнять переход от системы команд ARM к системе команд Thumb, а в ARMv5T (семейства ARM9 с буковкой T) и более поздние -- могут.

[SII]

1) Как его шить (к сожалению LPT порта у меня нет. Наиболее предпочтительно что-то USBшное)

Лично я советовал бы использовать SEGGER, клоны которого выпускаются много кем. Можно, например, заказать у Стартеркита (JetLink вроде там называется). Есть и у самой ATMEL (только не уверен, сможет ли АТМЕЛовский шить другие контроллеры, не этой фирмы; стартеркитовский точно шьёт и атмеловские, и НХПшные).

2) Какая среда разработки наиболее удобна и стабильна

Удобств, близких к, например, Visual Studio или Delphi, не ожидайте: с этим достаточно погано. Я использую KEIL: она мне показалась куда более вменяемой, чем IAR. До определённого размера программы (32 Кбайта) она бесплатна, выше -- надо платить, строго говоря, но сами понимаете...

3) Есть ли какие-то глобальные проблемы с ARM.

Что под этим Вы подразумеваете?

[Errorkpi]

Лично я советовал бы использовать SEGGER

Да. В принципе подходит.
Каким софтом шить? напрямую из KEIL или какоето стороннее.

Я использую KEIL

Какой язык программирования поддерживается. Если С, есть ли возможность ассемблерных вставок.

Что под этим Вы подразумеваете?

Глобальные косяки, которые могут усложнить жизнь.
Ну например несовместимость уровней на портах с ТТЛ логикой, огромнейшее количество элементов минимально необходимой обвески (свыше 200 шт.), жесткие рамки по модернизации готовых проектов и адаптации програмного кода для ARM различных версий.

[Errorkpi]

Какой язык программирования поддерживается. Если С, есть ли возможность ассемблерных вставок.

С этим разобрался вопрос снят.

[Satyr]

Лично я советовал бы использовать SEGGER, клоны которого выпускаются много кем. Можно, например, заказать у Стартеркита (JetLink вроде там называется).

+1
самые недорогие из хороших.
У меня есть их J-link Pro и J-link ultra - работают отлично.

а если просто тупо залить - достаточно просто конвертера уровней RS232-TTL. у всех ARM контроллеров сейчас есть USARTотвый бутлоадер.

Есть и у самой ATMEL (только не уверен, сможет ли АТМЕЛовский шить другие контроллеры, не этой фирмы; стартеркитовский точно шьёт и атмеловские, и НХПшные).

Есть у меня и такой -)) Родной сеггеровский синий для атмела - кроме атмела ничего не шьет, хотя видит.

Я использую KEIL: она мне показалась куда более вменяемой, чем IAR. До определённого размера программы (32 Кбайта) она бесплатна, выше -- надо платить, строго говоря, но сами понимаете...

KEIL на визуальную студию куда больше похож -)) Во всяком случае там какие то виззарды и окошки настроек есть.
Но есть ли у кого компилятор лучше IARа - вопрос требуемый изучения. Да и если приходится делать мультиплатформенные проекты или разными архитектурами сразу - целесообразней IAR, т.к. есть почти под все и как то привычней.

[SII]

Лично я советовал бы использовать SEGGER

Да. В принципе подходит.
Каким софтом шить? напрямую из KEIL или какоето стороннее.

KEIL сам шьёт. Правда, сначала приходится немного поколдовать с настройками (зависит от типа процессора), но потом работает без проблем.

Какой язык программирования поддерживается. Если С, есть ли возможность ассемблерных вставок.

Си а ассемблер. Я только на ассемблере пишу -- Си ненавижу и использую только под страхом смертной казни. Когда дело дойдёт до сложных расчётов и т.п., т.е. того, что на ассемблере реализовать действительно намного сложней, чем на ЯВУ, буду использовать Аду (входит в состав GCC) или Фри Паскаль.

Глобальные косяки, которые могут усложнить жизнь.
Ну например несовместимость уровней на портах с ТТЛ логикой, огромнейшее количество элементов минимально необходимой обвески (свыше 200 шт.), жесткие рамки по модернизации готовых проектов и адаптации програмного кода для ARM различных версий.

Ну, косяки есть практически в каждом процессоре. У NXP их явно больше, чем у ATMEL (с другими производителями АРМов не сталкивался пока), причём нередко очень неприятных, хотя тем или иным способом можно почти всё победить.

Кто касается собственно программирования, то при использовании ЯВУ особых проблем быть не должно. Единственное, про что слышал, -- это неспособность GCC сгенерировать в некоторых случаях правильный код для ARMv4 (ARM7): какие-то проблемы с одновременным использованием систем команд ARM и Thumb. Если же писать на ассемблере, то многие вещи надо учитывать своей головой, но это обычно не проблема (если в голове, конечно, извилины имеются, но без оных программированием лучше вообще не заниматься).

[Westbam]

Си а ассемблер. Я только на ассемблере пишу -- Си ненавижу и использую только под страхом смертной казни. Когда дело дойдёт до сложных расчётов и т.п., т.е. того, что на ассемблере реализовать действительно намного сложней, чем на ЯВУ, буду использовать Аду (входит в состав GCC) или Фри Паскаль.

Да ты крут мэн, далеко не у каждого хватит пороха кодить на асме под ARM.

[neonix]

Да уж для ARM на асме писать, это уже перебор имхо. Цель какая ? Оптимизация ? Так на кой фиг она нужна, если у проца и так производительности хватит для большинства задач, на крайний случай функции в оперативке разместить да пусть даже чуть медленнее работает. Зато время разработки на Асме и на Си несравнимо различаются, и явно не пользу первого варианта... При переходе на кортекс будете заново систему команд учить ?

[Satyr]

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

[SII]

Си -- сплошной рассадник ошибок, вызванных идиотскими правилами языка. На ассемблере я делаю этих самых ошибок на порядок меньше, чем на Си, хотя и больше, конечно, чем на нормальных языках вроде Паскаля или Ады, где случайные глюки вроде == вместо = невозможны в принципе (на асме подобных ошибок по невнимательности я практически не делаю; вероятно, сказывается более низкий уровень самого языка, требующий постоянного внимания к деталям). То, что я проигрываю на кодировании программы, я с лихвой компенсирую на её отладке. Так что, если для меня лично скорость разработки на асме и Си и различается, то отнюдь не в разы. Что ж касается до изучения других систем команд... Когда работал на дюжине ассемблеров, выучить ещё один не представляет абсолютно никакой сложности.

Ну и ещё раз. Если речь зайдёт о создании программы, которую реально сложно писать на ассемблере (сложные вычисления и т.п.), я её буду писать на Паскале или Аде, но ни в коем случае не на Си. Невозможность прямой отладки такой программы в операторах исходного языка (за отсутствием вменяемых средств разработки) является намного меньшим злом, чем лёгкость совершения на Си случайных ошибок, не отлавливаемых (или плохо отлавливаемых) компилятором. Кроме того, постоянное использование спецсимволов для всего подряд и неудобный синтаксис объявления сложных типов серьёзно ухудшают читаемость программы на Си, что также не способствует качеству разработки.

[SII]

Да ты крут мэн, далеко не у каждого хватит пороха кодить на асме под ARM.

Ничего особо крутого в этом нет, если привык на нём работать. Да и кодирование -- самый лёгкий этап создания программы, куда сложней её проектирование (если, конечно, создаётся что-то посложней, чем ХеллоВорлд), а оно абсолютно от языка не зависит.

[Zheleznjakov]

из усбишных можно посмотреть в сторону конструкций на ft2232
я когда сменил лптшик, вот на эту
http://www.ethernut.de/en/hardware/turt ... index.html
(или похожее
правда немного переделал и добавил для аврок (AVreal)
пашет по сей день.