быстрый тайминг GPIO для LPC Опции

[ГУ-49А]

Есть такая задача: реализовать быстрый синхронный 16-битный вывод в GPIO-порт для LPC2103 (через FIO). При этом ещё должна выполняться фоновая задача. Проблема в том, что вывод в порт необходимо делать стабильно, через равные интервалы времени, с как можно большей частотой. Скорость выполнения фоновой задачи при этом не принципиальна, но она не должна задерживать основной вывод в порт.

Первое и самое простое, что приходит на ум - использовать прерывание по таймеру для вывода в порт. Но очевидно, что максимума скорости так не добиться, хотя бы из-за избыточной работы по обслуживанию прерываний. По той же причине, видимо, не годятся и RTOS-надстройки.

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

Какие ещё существуют способы решения данной задачи?

[ГУ-49А]

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

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-буфера - расскажу и покажу.