Спасибо. Этот вариант "проходит", просто не является оптимальным по максимальной частоте вывода в порт по сравнению с его потенциальной альтернативой (интерлив кода). Моя задача скорее R&D'шная и не требует наискорейшей реализации. Поэтому я могу себе позволить "семь раз отмерить".


Где в документации, в таком случае, искать такты для нужного конвейера нужной ревизии LPC2103? Я знаю только про общий армовский Instruction Set... Существующие счётчики тактов тоже далеко не точны, получается? Т.е. одна из сложностей задачи - нет чёткой информации о таймингах конкретных конвейеров?


Данные идут в R-2R, т.е. такой себе дешевый тупой аналог DDS.

О-да! В принципе это можно сделать ручками. В этом плане ARM7 лучше чем суперскалярные процы с кэшами. В них вообще предсказывать количество тактов дело неблагодарное. Я например уже исследовал скорости выполнения некоторых команд на LPC2132. Команды и их параметры делятся на классы и потом у каждого сочетания этих двух-трёх классов на реальном железе определяется кол-во тактов. А вот подозрения об ускорении новых ревизий у меня возникли когда давно я измерял скорость вывода в порт на LPC2138 rev- получил 8 тактов, потом ещё мерил на процах LPC2132 revC и получил 7 тактов. Возможно я ошибся, но все-таки никто ничего не гарантировал. Предполагаю только что конвейеры у одинаковых ревизий процов, появившихся более-менее в одно время должны быть одинаковыми.

Обратите внимание, что количество тактов для входа в обработчик прерывания (в частности в FIC) документировано (контроллер прерываний используется от ARM Company, описание соответственно...). Процедура сброса контроллера прерывания и длительность процедуры возврата тоже не является секретом фирмы. Затраты на махание ножкой - тоже известны. Длительность прерываемых команд - зависит от того, какие лично Вы собираетесь использовать. Вопрос - чего Вам не хватает для ответа на вопрос?

ИМХО вы не по делу "трогаете" конвейер(ы) ядра, думаю что во всех чипах на ARM7TDMI-S ядро одинаковое. Длительности исполнения команд ядром расписаны АРМ-ом, НО....
Дальше в дело вмешивается некий контроллер памяти (внешний для ядра), именно он может вставлять вэйтстейты, именно он может иметь возможность отложенной записи (некоторой глубины и/или разной по разным адресам), именно он может разбивать одно обращение к памяти на несколько (в случае невыровненных данных и/или менее разрядной памяти).

И в обшем случае невозможно определить время выполнения конкретной команды на конкретном камне не зная предистории выполнения других команд (тут влияет как состояние самого ядра, так и состояние внешней по отношению к ядру обвязке), не зная "а по какому адресу эта команда полезет в память" (одна и та же команда в внутреннюю RAM пишет за такт, а в порт в/в за N тактов, а в внешннюю RAM за M тактов), и т.д.

в ряде случаев псевдокод

будет выполняться за тоже время что и

За 2 такта.Это было бы в идеально сделанном проце, но в LPC это скорее всего не так. Кажется я это проверял. Однако всю малину могут испортить команды с неопределённым во время компиляции/конвертации количеством циклов. Вообще, подводных камней в конвертере будет много, но идея всё-равно интересная. Если б мне на работе это потребовалось сделать, я бы с удовольствием занялся.

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

Пока неизвестны характеристики выходного сигнала с R-2R ничего конкретного предложить не могу. Да и алгоритм супер секретный

В конкретном случае с LPC2103 мы можем допустить, что подобным образом может "проказничать" MAM, ведь внешнего RAM'а нет, да и внутренний всего 1 банк в 8 кб? И тогда, отключив MAM, выполняя код из RAM и читая/записывая короткими словами, можно побороть эту проблему?


Видимо, речь идёт о выводах MATx.y? К сожалению, этот метод не подходит, нужен честный вывод с 12-битным квантованием. Что касается алгоритма вывода, то есть область памяти с данными, их-то и надо слать в порт (16-битный, нужны 12 бит). Всё просто, как видите, за исключением маниакального желания обогнать способ вывода по прерыванию таймера.

Ну вообще-то речь идёт о честном 30-битном квантовании, но нет так нет. Всё-равно никто его не знает, иначе уже сказали бы.Ну да, так чуть-чуть можно ускорить прогу т.к. после смены PC меньше тактов ожидания будет теряться, однако LPC хорош тем, что он даже из внутреннего флэша исполняет большинство команд за такт. Экономия будет только на переходах и на чтении констант из флэш. Наверное это действительно контроллер памяти и внутренних шин AHB и VPB вносят лишние циклы ожидания.

Может я что-то пропустил в обсуждении, но я бы реализовал такую задачу на стандартном порту SSC или SPI, дополнив ARM десериализатором на любой мелкой ПЛИС. При использовании буферизации потока (DMA) и синхронизации вывода (а SSC и SPI и так синхронные интерфейсы) джиттер будет минимальным. Ну и для фоновой задачи в 16-раз больше времени будет оставаться.
P.S. Извиняюсь, если не совсем в тему.

Можно воспользоваться готовой микросхемой parallel<>SPI например MCP23S17 (Microchip) 16бит скорость 10мбит/сек

Господа-товарищи!
Я тоже сначала подумал об SSP, но даже если он был бы в LPC2103, то максимально возможная скорость вывода на нём равна Fosc/32, что меньше чем в простейшей проге с использованием FIQ, хотя и без джиттера. Да ещё и схема снаружи нужна.

В любом режиме или только в режиме мастера с тактированием изнутри кристалла?

Скорость вывода бита = 2 такта. Чтобы вывести 16 бит потратится 32 такта. Это в самом-самом идеальном случае. У меня под рукой нет мануала на LPC2103. Короче, если бы в 2103-ем был SSP как в 213х-ом.

Попытался накидать прогу. Оказывается для данного применения мой алгоритм не подходит. Жаль. Он может увеличить амплитудное разрешение, а не временное.

Могу только предложить алгоритм полного избавления от джиттера во время FIQ в ущерб скорости вывода. Возможно скорость упадёт до Fosc/32.

В 2103-м на SSP тоже нельзя добиться нужной скорости, это точно. К тому же, есть неприятная errata на этот случай, можно нарваться: "Initial data bits/clocks of the SSP transmission are shorter than subsequent pulses at higher frequencies. ... At high SSP frequencies, it is found that the first four pulses are shorter than the subsequent pulses.".


С интересом выслушаю ваши предложения...

Я точно не анализировал, но может быть этот алгоритм уменьшит скорость в два раза.

кол-во NOPов тоже нужно подобрать получше. Вобщем я обрисовал только идею. Возможно этот пример нужно немного доработать.