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

[ГУ-49А]

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

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

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

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

[zhevak]

Боюсь нарваться на скандал, но все же скажу, ибо истина дороже синяков.

Уважаемый, если у Вас стали возникать такие вопросы (типа "повставлять NOPы для выравнивания скоростей"), то мне кажется Вы на ложном пути. Вам нужно либо взять проц по-быстрее, либо в корне пересмотреть парадигму построения вашей системы. При Вашем подходе малейшее отклонение в сторону дискредитирует Вашу систему. И Вы будете вынуждены начинать все сначала. На фоне рилтайм-процессов, у системы совсем нет запаса по выч. мощности. Опасная игра, однако!

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

Хотя, я вот сейчас подумал, что наверное Вы сделали действие с точностью до наоборот: сначала прикупили железо, а сейчас думаете, как из него выжать по максимуму. От сюда и пошли Ваши проблемы.

[ГУ-49А]

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

Вы совершенно правы. Речь идёт о том, чтобы решить эту задачу на уже существующем железе, и при том, что, очевидно, существуют более подходящие для этого аппаратные решения. Большинство концептуальных недостатков подобной реализации мне, увы, известны, и я благодарен вам за понимание тех трудностей, с которыми я столкнулся. И задачка эта, мне кажется, по-своему интересна, хоть и в таком извращённом виде.

Если готового инструментария для подгонки тактов нет, то посоветуйте, хотя бы, хороший инструментарий для подсчёта тактов для команд написанной программы, без необходимости её компиляции и пошаговой прогонки. Или, может, мне стоит написать такой инструментарий самому?

[zhevak]

К сожалению, ни готового решения, ни совета я Вам дать не могу.

Выше люди уже предлагали использовать FIQ. Почему не проходит этот вариант?

Вы уже почти сутки пытаетесь теоретически определить способность системы решать Вашу задачу. Думаю, за сутки можно было одновременно и на форуме поговорить со спецами и накидать пилот-проектик для FIQ. Посмотреть осциллографом скорости, оценить джиттер. Т.е. опробовать идею. Джиттер (дрожжание) обязательно будет, т.к. в системе присутствуют модуль MAM, система не мгновенно отрабатывет прерывание, ... да, много, много всего может "случится между ложкой и ртом".

Да, поможет Вам практика! Сотня-другая циклов стирания-программирования не сильно износят ресурс микроконтроллера. Зато Вы четко будете ориентироваться в том, что Вы делаете, и в каком направлении Вам "пилить" дальше.

Удачи!