|
быстрый тайминг GPIO для LPC |
|
|
|
Jan 6 2008, 20:16
|
Участник

Группа: Участник
Сообщений: 32
Регистрация: 26-11-07
Пользователь №: 32 699

|
Есть такая задача: реализовать быстрый синхронный 16-битный вывод в GPIO-порт для LPC2103 (через FIO). При этом ещё должна выполняться фоновая задача. Проблема в том, что вывод в порт необходимо делать стабильно, через равные интервалы времени, с как можно большей частотой. Скорость выполнения фоновой задачи при этом не принципиальна, но она не должна задерживать основной вывод в порт.
Первое и самое простое, что приходит на ум - использовать прерывание по таймеру для вывода в порт. Но очевидно, что максимума скорости так не добиться, хотя бы из-за избыточной работы по обслуживанию прерываний. По той же причине, видимо, не годятся и RTOS-надстройки.
Если же просто перемежать вызовы команд этих двух задач, то не понятно, как при этом обеспечить стабильный тайминг вывода в порт - ведь подсчёт тактов для пайплайна задача непростая... Есть ли какой-то инструментарий для подсчёта тактов выполнения команд на LPC? Чтобы можно было с учётом этого написать на асме код фоновой задачи так, чтобы вперемешку с ним выводить в порт данные строго каждые N тактов?
Какие ещё существуют способы решения данной задачи?
|
|
|
|
|
Jan 6 2008, 20:50
|

Знающий
   
Группа: Свой
Сообщений: 723
Регистрация: 29-08-05
Из: Березовский
Пользователь №: 8 065

|
Цитата(ГУ-49А @ Jan 7 2008, 01:16)  Какие ещё существуют способы решения данной задачи? А вообще о каких скоростях вывода в порт идет речь? Т.е. Сколь раз в секунду требуется выкидывать данные. Как-то давным давно у меня возникла подобная задача: что-то там делать в реальном времени. Я это "дело" навесил на обработчик прерываний от таймера. А что бы понять, сколько времени у меня реально занимает процесс, я не стал заморачиваться подсчетом тактов, а сделал по-простому. При входе в прерывание устанавливал единичку на свободной лапке микроконтроллера, а перед выходом из прерывания -- нолик. На осциллографе наблюдал прямоугольник. Скоп был хороший (LeCroy) и позволял собирать статистику -- min и max значения. Я задал ему наблюдать длительность импульса. Я запустил эту дело, пошел пить кофею, а когда вернулся уже имел и минимум, и максимум. Далее осталось только прикинуть сколько времени остнется фоновому процессу. Я понимаю, что все это решалось очень по-крестьянски, но оцените эффективность такого решения. А достоверность результатов? Думаю, имеет смысл Вам проделать такой же эксперимент. А там, получив результаты, сориентируетесь.
--------------------
Хочешь рассмешить Бога -- расскажи ему о своих планах!
|
|
|
|
|
Jan 6 2008, 21:10
|
Участник

Группа: Участник
Сообщений: 32
Регистрация: 26-11-07
Пользователь №: 32 699

|
Цитата(zltigo @ Jan 6 2008, 22:45)  Конкретных способов решения абстрактной ("делать стабильно, через равные интервалы времени, с как можно большей частотой") задачи (с неназванными временами) не существует  Некоторые способы я перечислил. Меня устроит, если вывод в порт будет происходить, скажем, каждые 10 тактов. Если получится быстрее - отлично; если можно только медленнее - надо видеть, насколько. За каждый выигранный или проигранный такт я хочу побороться. Если самый лучший по скорости вывода способ будет напрямую зависеть от конкретных команд задачи (как в случае с вышеупомянутым методом интерлива кода), то, само-собой, кроме меня никто мою задачу решать не будет. Но в таком случае я хотел бы получить ответ на ранее заданный вопрос: Есть ли какой-то инструментарий для подсчёта тактов выполнения команд на LPC? Какова вообще методика расчёта таймингов, ведь кто-то наверняка уже это делал? Или всё-таки можно сделать по-другому? Цитата(zhevak @ Jan 6 2008, 22:50)  А вообще о каких скоростях вывода в порт идет речь? Т.е. Сколь раз в секунду требуется выкидывать данные. Речь идёт о попытке достижения теоретического максимума на данном железе и задаче. Т.е. порядок цифр - мегагерцы. Цитата(zhevak @ Jan 6 2008, 22:50)  Как-то давным давно у меня возникла подобная задача: что-то там делать в реальном времени. Я это "дело" навесил на обработчик прерываний от таймера. А что бы понять, сколько времени у меня реально занимает процесс, я не стал заморачиваться подсчетом тактов, а сделал по-простому. Повесить на таймер и измерять скорость осциллом - это начальный вариант для такой задачи, спасибо. Каких частот вам удалось достичь, скажем, для простого "дёргания ногой"? Как вы считаете, насколько можно превзойти этот метод?
|
|
|
|
|
Jan 6 2008, 21:46
|

Гуру
     
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244

|
Цитата(ГУ-49А @ Jan 6 2008, 23:04)  вывод в порт будет происходить, скажем, каждые 10 тактов Задача для LPC2000 решения не имеет. Порядка 4 тактов только вывод через FastGPIO причем это тупая загрузка содержимого регистра по адресу содержащимуся в другом регистре. При этом нужно еще подтаскивать поток в 12 мегабайт в секунду  Ну и кто-то там еще про "фоновые задачи"  ..... Цитата Или всё-таки можно сделать по-другому? 12 МегаБайт в секунду это скорости совсем других контролеров + аппаратная поддержка для обеспечения синхронного порта. Цитата(ГУ-49А @ Jan 6 2008, 23:10)  Каких частот вам удалось достичь, скажем, для простого "дёргания ногой"? Ознакомьтесь с документацией - узнаете предел.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
Jan 7 2008, 10:25
|
Участник

Группа: Участник
Сообщений: 32
Регистрация: 26-11-07
Пользователь №: 32 699

|
Цитата(zltigo @ Jan 6 2008, 23:46)  Задача для LPC2000 решения не имеет. Значит, будем искать решение задачи для более низких граничных частот. Цитата(zltigo @ Jan 6 2008, 23:46)  Ознакомьтесь с документацией - узнаете предел. Обратите внимание, что вопрос касался выдачи в порт по таймеру, причём на фоне другой задачи. Цитата(GetSmart @ Jan 7 2008, 11:43)  Думаю можно достичь скорости вывода до Fosc/25 (меандр Fosc/50) или около того. Если в основной проге не будет длинных команд LDM и STM. Спасибо. Я готов переписать фоновую прогу наиболее короткими командами в рамках возможного. Но как, тем не менее, обеспечивать стабильность по частоте вывода? Как компенсировать разное время выполнения команд фоновой проги? В связи с этим вынужден повторить свой вопрос: есть ли готовый инструментарий, который, как минимум, для линейного кода на асме проставляет такты (для данного ядра), и, как максимум, может дополнять команды до нужного кол-ва тактов командами-пустышками либо усложнять команды (без изменения алгоритма)?
|
|
|
|
|
Jan 7 2008, 12:46
|

Знающий
   
Группа: Свой
Сообщений: 723
Регистрация: 29-08-05
Из: Березовский
Пользователь №: 8 065

|
Боюсь нарваться на скандал, но все же скажу, ибо истина дороже синяков. Уважаемый, если у Вас стали возникать такие вопросы (типа "повставлять NOPы для выравнивания скоростей"), то мне кажется Вы на ложном пути. Вам нужно либо взять проц по-быстрее, либо в корне пересмотреть парадигму построения вашей системы. При Вашем подходе малейшее отклонение в сторону дискредитирует Вашу систему. И Вы будете вынуждены начинать все сначала. На фоне рилтайм-процессов, у системы совсем нет запаса по выч. мощности. Опасная игра, однако! Если у Вас так жестко с реальным временем, то, будь я на Вашем месте, я бы наверно отказался бы от фоновых процессов совсем. Вынес бы их на другой микроконтроллер. (Не зная точно задачу, можно так-акого насоветовать!...  ) Хотя, я вот сейчас подумал, что наверное Вы сделали действие с точностью до наоборот: сначала прикупили железо, а сейчас думаете, как из него выжать по максимуму. От сюда и пошли Ваши проблемы.
--------------------
Хочешь рассмешить Бога -- расскажи ему о своих планах!
|
|
|
|
|
Jan 7 2008, 13:37
|
.
     
Группа: Участник
Сообщений: 4 005
Регистрация: 3-05-06
Из: Россия
Пользователь №: 16 753

|
Цитата(ГУ-49А) Спасибо. Я готов переписать фоновую прогу наиболее короткими командами в рамках возможного. Но как, тем не менее, обеспечивать стабильность по частоте вывода? Я имелл ввиду вызов FIQ по таймеру. При этом без всякого гемора будет стабильная частота и небольшой джиттер. По поводу подсчёта тактов, вроде бы отладчик в ИАРе умеет их считать. Однако не знаю насколько он умный, т.к. в разных режимах ускорения или предвыборки после смены PC тратятся дополнительные "пустые" такты. Вообще, идея интересная. Но, думаю, подобных инструментариев нет и всё придётся делать ручками. Предворительно вызубрив наизусть длительность всех команд и их вариантов. Предворительно перед этим выяснив все тонкости конвейера и прочие нюансы архитектуры ARM7-LPC. Если всё это закончится успехом, то можно достичь теоретически предельной скорости вывода, равной сумме тактов самой длинной используемой команды, плюс 5 тактов (3 на чтение из ОЗУ и 2 на запись в порт). Возможно это будет Fosc/10.
--------------------
Заблуждаться - Ваше законное право :-)
|
|
|
|
|
Jan 7 2008, 13:41
|
Участник

Группа: Участник
Сообщений: 32
Регистрация: 26-11-07
Пользователь №: 32 699

|
Цитата(zhevak @ Jan 7 2008, 14:46)  Боюсь нарваться на скандал, но все же скажу, ибо истина дороже синяков. ...сейчас думаете, как из него выжать по максимуму. От сюда и пошли Ваши проблемы. Вы совершенно правы. Речь идёт о том, чтобы решить эту задачу на уже существующем железе, и при том, что, очевидно, существуют более подходящие для этого аппаратные решения. Большинство концептуальных недостатков подобной реализации мне, увы, известны, и я благодарен вам за понимание тех трудностей, с которыми я столкнулся. И задачка эта, мне кажется, по-своему интересна, хоть и в таком извращённом виде. Если готового инструментария для подгонки тактов нет, то посоветуйте, хотя бы, хороший инструментарий для подсчёта тактов для команд написанной программы, без необходимости её компиляции и пошаговой прогонки. Или, может, мне стоит написать такой инструментарий самому?
|
|
|
|
|
Jan 7 2008, 13:58
|
Участник

Группа: Участник
Сообщений: 32
Регистрация: 26-11-07
Пользователь №: 32 699

|
Цитата(GetSmart @ Jan 7 2008, 15:37)  Я имелл ввиду вызов FIQ по таймеру. При этом без всякого гемора будет стабильная частота и небольшой джиттер. Согласен, этот запасной вариант у нас уже есть. Теперь давайте попробуем подумать над более сложной альтернативой: Цитата(GetSmart @ Jan 7 2008, 15:37)  По поводу подсчёта тактов, вроде бы отладчик в ИАРе умеет их считать. Однако не знаю насколько он умный, т.к. в разных режимах ускорения или предвыборки после смены PC тратятся дополнительные "пустые" такты. С отладчиком в IAR'е, как и с Протеусовским эмулятором в этом плане довольно сложно работать. Нужно каждый раз "ходить" по программе, считать дельту счётчика тактов, одним словом - неудобно это для такой тонкой оптимизации. Куда удобнее было бы для каждой команды из программы сразу посчитать кол-во тактов, для неё необходимых. Цитата(GetSmart @ Jan 7 2008, 15:37)  Вообще, идея интересная. Но, думаю, подобных инструментариев нет и всё придётся делать ручками. Предварительно вызубрив наизусть длительность всех команд и их вариантов. Предварительно перед этим выяснив все тонкости конвейера и прочие нюансы архитектуры ARM7-LPC. Если всё это закончится успехом, то можно достичь теоретически предельной скорости вывода, равной сумме тактов самой длинной используемой команды, плюс 5 тактов (3 на чтение из ОЗУ и 2 на запись в порт). Возможно это будет Fosc/10. Именно это и представляется мне на данный момент. Вопрос только в том, можно ли как-то облегчить себе труд. Например, можно написать парсер кода, который проэмулирует конвейер ARM7TDMI-S ровно настолько, чтобы посчитать количество тактов и выдать их мне. Просто меня удивляет, что такой утилиты, судя по всему, нет?
|
|
|
|
|
Jan 7 2008, 14:06
|
.
     
Группа: Участник
Сообщений: 4 005
Регистрация: 3-05-06
Из: Россия
Пользователь №: 16 753

|
Вы бы ещё пояснили подробности такого нестандартного вывода из процессора. Что за данные и в какое устройство перегоняются? Это связано с управлением светодиодами? Цитата(ГУ-49А) Например, можно написать парсер кода, который проэмулирует конвейер ARM7TDMI-S ровно настолько, чтобы посчитать количество тактов и выдать их мне. У LPC и SAM7 одинаковое ядро ARM7TDMI-S, но конвейер разный. Так что всё это будет конкретно привязано к конкретному процессору. Даже к конкретной его ревизии (ревизиям!). Так как никто не обещал, что улучшений в сторону ускорения работы процессора в новых ревизиях не предвидится.
--------------------
Заблуждаться - Ваше законное право :-)
|
|
|
|
|
Jan 7 2008, 14:12
|

Знающий
   
Группа: Свой
Сообщений: 723
Регистрация: 29-08-05
Из: Березовский
Пользователь №: 8 065

|
К сожалению, ни готового решения, ни совета я Вам дать не могу.
Выше люди уже предлагали использовать FIQ. Почему не проходит этот вариант?
Вы уже почти сутки пытаетесь теоретически определить способность системы решать Вашу задачу. Думаю, за сутки можно было одновременно и на форуме поговорить со спецами и накидать пилот-проектик для FIQ. Посмотреть осциллографом скорости, оценить джиттер. Т.е. опробовать идею. Джиттер (дрожжание) обязательно будет, т.к. в системе присутствуют модуль MAM, система не мгновенно отрабатывет прерывание, ... да, много, много всего может "случится между ложкой и ртом".
Да, поможет Вам практика! Сотня-другая циклов стирания-программирования не сильно износят ресурс микроконтроллера. Зато Вы четко будете ориентироваться в том, что Вы делаете, и в каком направлении Вам "пилить" дальше.
Удачи!
--------------------
Хочешь рассмешить Бога -- расскажи ему о своих планах!
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|