Вопрос к автору.
Что Вы хотите сделать ?
Варианты :
- генератор сигналов произвольной формы
- систему регулирования какого-то параметра.
В зависимости от ответа на этот вопрос, решение будет различным.

Ответ: Вариант 1-й, т.е. генератор сигналов произвольной формы (на фоне выполнения другой менее приоритетной задачи).
Повторюсь, интересуют программные, а не аппаратные решения.


Идею уловил, спасибо.

Понятно.


Самым лучшим вариантом Вашей задачи является программно-аппаратное решение (это мое мнение).

Попытался применить код, который я тут запостил и нашёл в нём некоторые недоработки. Во-первых прибавлять к PC (R15) нужно смещение, умноженное на 4. Остальное в коде:
PS. Странно, что никто другой не заметил.

Попробывал применить этот алгоритм в своём генераторе сигнала. Оказалось от джиттера полностью не избавиться. Оказалось что либо команда чтения таймера (или периферии вообще) занимает разное число тактов, либо перенос инфы из таймера происходит в разные моменты исполнения данной команды. Вобщем очень забавные аномалии происходят в данном коде. Хотя с виду он выглядит идеально. В AVR он точно работал бы идеально.

Точнее так: с момента чтения таймера и до вывода чего-то в порт (после NOPов) всё равно проходит разное количество тактов. Очень может быть что и команда вывода в порт исполняется за разное кол-во тактов.

Процессор LPC2132 revA. Процедура прерывания во флэше. Частота 59 МГц, MAM = 2 (full).

А если MAM=0?

Частота 5 МГц, PLL off, MAM=0, MAMTIM=1. Прерывание во флэш.
Ощущение такое, что джиттера не стало. Однако как это проверить "на коленке" я пока не знаю. Цифрового осциллографа под руками нет. У меня сейчас программа формирует меандр от ШИМа на одном пине, а в прерывании я программно устанавливаю другой пин как бы синфазно с шимом и на лету могу корректировать сдвиг программного пина с точностью до такта. На древнем осциллографе с полосой 5 МГц (!) еле-еле видна иголка, которую можно уширять, можно убрать или перенести вниз изменяя сдвиг буквально на такт. Вроде всё красиво.

Частота 59 МГц, прерывание в RAMe, MAM = 2, MAMTIM = 3.

Джиттера нет. Скорость изменения уровня на пине не менее двух тактов.

Видмио ограничена мощностью выходного каскада и собственной ёмкостью пина.

Позвольте изложить некоторые результаты по открытой мной теме.

1. Удалось реализовать метод интерлива кода вывода в порт (16 бит) и фоновой задачи.
2. При простых командах (см. ниже) фоновой задачи удалось достичь частоты дискретизации 14 МГц (!), без джиттера (LPC2103, 70 MHz), т.е. за 5 тактов.
3. При большинстве сложных команд частота дискретизации = 7 МГц, без джиттера (за 10 тактов).

Теперь подробности.

1) Реализация подобного вывода в порт реальна, если код выполняется из RAM (ramfunc). В этом случае тайминг команд становится предсказуем, т.е.:
- простая арифметика и логика = 1 такт;
- запись в память и в FIO-порт = 2 такта;
- чтение из памяти, команды перехода = 3 такта, и т.д.
Как видим, это соответствует заявленным таймингам для данного семейства ARM7TDMI-S. К сожалению, вызов более сложной функциональности LPC2103 требует существенно большего количества тактов, например:
- запись байта в регистр SSP = 7 тактов;
- чтение слова данных из ADC (независимо от режима) = целых 8 тактов.
(Кстати, скажем, отправку по SSP/SPI в некоторых случаях можно выполнить программно - работает не хуже, и тайминг команд остаётся 3 такта вместо 7-ми.)
2) Использование встроенного таймера позволяет с точностью до такта определять тайминги участков кода и проверять результат.
3) Общее правило подсчёта максимальной частоты дискретизации при таком методе:
Fs = Fclk/(Cycles_max + 2),
где Cycles_max - длительность самой медленной команды, в тактах (но не менее 3 тактов).
4) Инструментарий писать не стал, по 2-м причинам:
4.1) В общем случае ldr/str может обращаться к каким угодно спец.регистрам периферии, и тайминг будет существенно меняться. Отследить это можно только при эмуляции прошивки, что неоправданно усложняет задачу.
4.2) Для простых же команд тайминги вычисляются слишком просто, нопы вставлять для выравнивания (align) тактов тоже просто - польза от такой утилиты в моём случае неочевидна.

Если интересно, как можно за 5 тактов и в порт выводить 16 бит из памяти, и фоновую программу по 3 такта выполнять, с контролем оверрана DDS-буфера - расскажу и покажу.

Конечно интересно! Думаю даже не мне одному

Это интересно.

Можно сделать, например, так:



Как видим, между каждыми вызовами FIOBUF_5 мы вызываем команды фоновой задачи, сгруппированные ровно по 3 такта. Например:

При этом, условные переходы легко учесть, если сразу в начале метки перехода будет стоять макрос вывода в порт, а после команды - 2 нопа для компенсации тактов. Однотактные команды с условиями (напр. subeq) тоже можно спокойно использовать. А вот многотактные условные команды придётся преобразовать в отдельную проверку и условный переход.

Легко заметить, что при каждом вызове FIOBUF_5 читаются сразу 2 32-битных слова из буфера. Поэтому нужно в код фоновой программы вставлять дополнительные проверки для реализации цикличности буфера. Размер буфера может быть произвольный! В конце буфера нужно сделать "запас" из, скажем, 16 семплов (скопировать начальные семплы и выровнять до 32-бит), поскольку мы не можем делать частые проверки - и потом из текущего указателя вычитаем размер буфера при превышении:


Как я уже писал, если у вас есть команды больше 3-х тактов, то подобный метод необходимо соответственно адаптировать. Чем за большее кол-во тактов идёт вывод, тем красивее становится код.

Напоминаю, что код надо размещать в секции для копирования в RAM, тогда тайминги команд будут точными. Также не учитываются фоновые прерывания.
Метод хоть и не универсальный, но позволяет сделать полноценный синтез периодических сигналов с точным контролем частоты и формы. Например, табличный синус по этому методу на осциллографе выглядит весьма симпатично.
Спасибо за внимание!

Очень даже неплохо получилось. Можно сказать что это экстремальное программирование! Я такие вещи очень люблю. Жаль только, что весь проект при таком подходе нужно будет писать на асме. И по прерываниям будущий автор будет скучать

Можно вопрос? Почему скорость программного SPI была 60 тактов на бит? Вроде бы в Вашей программе можно параллельно с 16 бит основными данными по двум программным линиям выдавать SCK и MOSI со скоростью 10 тактов на бит. То есть "плевать" в GPIO порт сразу 18 бит данных.

Увы, нельзя совместить основные данные с данными SPI, т.к. у них разный период повторения. Данные SPI выводятся по 8 бит, а затем делается большая пауза (порядка 1 мс, поэтому мне скорость вывода через SPI не так важна), а вывод основных данных продолжается всё время (и период повторения может быть любым, с точностью до сэмпла). Кроме того, при наиболее экстремальном способе основного вывода каждые 5 тактов можно успевать доставать только 16 бит за раз, а ведь MOSI1 лежит в верхнем полуслове. Поэтому и получалось у меня 60 бит:

Конечно, если подумать, то можно сделать и поменьше - за счёт битовых сдвигов и т.п. Хм, возможно...

Если же можно было основной вывод делать, например, за 8 тактов, то тут уже другая картина. FIOBUF_8 будет занимать всего 5 тактов вместо 17-ти, и скорость вывода в SPI будет уже 24 такта/бит. Ну а если за 9 тактов, то можно спокойно уже через аппаратный SSP выводить.

P.S. Пардон, что немного сумбурно излагаю...