Несколько вопросов по lpc176x Опции

[vallav]

1. Почему у него такая странная распиновка выводов?
На 100 ногах нашли место только для 70 gpio, причем ни одного целого 32х битного регистра, всего один целый 16 битный а разбросаны
и перемешаны они - мама не горюй! Наследие тяжелого прошлого?
Как красиво с этим у ST32 - 5 16 битных регистров и почти все ножки в ряд.

2. 12 тактов входа в прерывание и 12 тактов выхода из него ( обязательных ) преподносится как достижение.
Вроде достижением было у ADSP 218x - полтора такта до первой команды в прерывании и 1 такт на выход.

3. Меня интересует, в lpc176x ПДП такое же тормозное....
Правда, по слухам, до кортексов у АРМа с этим было еще хуже.

Причина редактирования: Дублирование вопроса в разных темах

[sonycman]

Можно под шумок спросить знатоков - сколько тактов уходит у LPC17xx на обращение к регистрам периферии?
К примеру, к регистрам таймеров?

Уважаемый Zltigo даже старается заменить такие обращения работой с простой ОЗУ...

[vallav]

Можно под шумок спросить знатоков - сколько тактов уходит у LPC17xx на обращение к регистрам периферии?
К примеру, к регистрам таймеров?

Уважаемый Zltigo даже старается заменить такие обращения работой с простой ОЗУ...

Встречал, что, если код написан на ассемблере, внешней ногой можно дрыгать с тактовой частотой.

Вопрос риторический? Или как? Если или как, то видимо Вас забыли спросить, как и по каким критериям им проектировать чипы. Думаю, что Вам следует немедленно связаться и направить на путь истинный.

Вы не поняли. Меня интересовало - зачем такая разводка сделана.
И еще одно - почему нет сигнала о том, что с ног значения прочитались или значения на ногах изменились?
Или gpio в данном проце просто так, для красоты?

Отличный результат. А как ADSP за полтакта, например, в стек регистры запихивал? Нет? Тогда может стоит для начала банально зайти не на gaw.ru а на arm.com и так сказать приникнуть к первоисточнику. Там все по тактам расписано.

Вот так и запихивал. Но не за полтакта, а за такт.
Правда я ошибся - от асинхронного сигнала первая команда прерывания начинает исполняться через 2.5 такта.
Метостабильность давить надо.
От внутреннего ( таймера ) через 1 такт.

Вы банально на arm.com заходили?
Ссылочку на файл, аналогичный приведенному мной, но про lpc176x не приведете?
Про общие описания ядра cortex-M3 ссылки приводить не надо.
Интересует конкретная реализация lpc176x у NXP и ее отличия ( в тактах ) от других компаний.
Странно конечно, что искать это Вы на АРМе предлагаете, но Вам виднее...

Реализация DMA контроллера и M3 ядро, равно и как ARM7 ядро вещи разные. Слухи в другом месте, пожалуйста, обсуждайте.

Я в курсе.
По заданному вопросу что либо ответить сможите?
Сколько тактов занимает передача по ПДП от gpio в ОЗУ?

Сообщение отредактировал vallav - Apr 13 2010, 05:08

[sonycman]

Встречал, что, если код написан на ассемблере, внешней ногой можно дрыгать с тактовой частотой.

С тактовой частотой - это, к примеру, с частотой 100 МГц?
Сильно в этом сомневаюсь

Аппаратно ещё может быть достигнута частота в районе 50 МГц, но программно реальная цифра - около 10 МГц.
Имхо.

Вот так и запихивал. Но не за полтакта, а за такт.

Cortex-M3 при входе в прерывание аппаратно сохраняет на стёке 8 32 битных регистров.
Соответственно, при выходе - их восстанавливает.
Отсюда такая задержка.

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

[vallav]

С тактовой частотой - это, к примеру, с частотой 100 МГц?
Сильно в этом сомневаюсь

Аппаратно ещё может быть достигнута частота в районе 50 МГц, но программно реальная цифра - около 10 МГц.
Имхо.

Частота естественно не 100 а 50 мгц ( при 100 - тактовой ).
Сам я не пробовал, читал в конфе - на С++ не получается ( много мусора вставляется ) а на АСМ
импульсы длительностью 10 нсек на ноге - вполне.

Cortex-M3 при входе в прерывание аппаратно сохраняет на стёке 8 32 битных регистров.
Соответственно, при выходе - их восстанавливает.
Отсюда такая задержка.

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

Дык он этого и не делает.
Далеко не во всех прерываниях нужно столько регистров.
Он сохраняет в стеке только самое необходимое - адрес возврата и состояние ядра на момент прерывания.
А какие именно регистры обработчик будет портить - те пусть сам и сохраняет/восстанавливает.
Вроде для контроллера откликнуться на воздействие через 3 такта важнее, чем несколько лишних комманд в сложном
обработчике.

Ха!

Даже смеяться не буду.

И Вам советую. Контроллер прерывания у Cortex-M3, отличие от напимер ARM7, в ядре и про "12 тактов" можете смело читать.

Да? К чему тогда был опус с тем, что "до кортексов у АРМа с этим было еще хуже", если Вы были "в курсе", что от ядра и соответственно от компании ARM это не зависит?

Вы когда насмеетесь, попробуйте все же хоть что либо осмысленное написать.
Или Вы только острить и хихикать умеете?

А что, у NXP есть чиста конкретная реализация ядра Cortex-M3? Я всегда думал, что NXP и другие компании просто купили и "вставили" в свои МК "готовое" IP-ядро - процессор Cortex-M3, в состав которого входит и NVIC... И поэтому тут пофиг чей микроконтроллер - NXP, ST, Luminary... "Миландр" . А временные характеристики относительно обработки прерываний и у них будут одинаковыми.
Или вы хотите сказать, что каждая компания, купившая у фирмы "ARM" IP-ядро процессора Cortex-M3, потом его напильником дорабатывает?

Вот... Все, что касается CPU Cortex-M3 - искать на arm.com, как на первоисточнике. Все остальное, что не относится к CPU Cortex-M3 - для каждого производителя микроконтроллеров это специфичные вещи.
Или я не прав?

P.S. Как-то слишком резво вы на NXP набросились.

В том то и дело, что дорабатывают и довольно нехило.
Не само ядро, а то, что ядро окружает.
Такты на операцию при этом получаются другими.
Да и сами операции по другому проводятся.
Например, в каналах ПДП у lpc176x есть буфера FIFO, а у ST32 - их нет.
И при закрытии канала ПДП нужно следить за очисткой этих буферов.
Есть надежда, что ПДП у lpc176x из за их наличия пошустрее работает по сравнению
с ST32.
Все, что касается ядра Cortex-M3 - можно искать на arm.com, а вот про конкретные особенности реализации
конкретного контроллера на этом ядре - полагаю там искать бесполезно.

В чем именно Вы увидали резвость?
В том, что удивился их распиновке gpio?
Полагаете, она у lpc176x - вполне обычная?
Или в том, что поинтересовался тем, за сколько тактов операции в нем свершаются?
Полагаете, этим интересоваться не очень этично?