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

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

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

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

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

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

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

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

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

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

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

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

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

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

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



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



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

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


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


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

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

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

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


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


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

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



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



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

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

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

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

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

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

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

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

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