реклама на сайте
подробности

 
 
3 страниц V   1 2 3 >  
Reply to this topicStart new topic
> быстрый тайминг GPIO для LPC
ГУ-49А
сообщение Jan 6 2008, 20:16
Сообщение #1


Участник
*

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



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

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

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

Какие ещё существуют способы решения данной задачи?
Go to the top of the page
 
+Quote Post
zltigo
сообщение Jan 6 2008, 20:45
Сообщение #2


Гуру
******

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



Цитата(ГУ-49А @ Jan 6 2008, 22:16) *
Какие ещё существуют способы решения данной задачи?

Конкретных способов решения абстрактной ("делать стабильно, через равные интервалы времени, с как можно большей частотой") задачи (с неназванными временами) не существует smile.gif


--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post
zhevak
сообщение Jan 6 2008, 20:50
Сообщение #3


Знающий
****

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



Цитата(ГУ-49А @ Jan 7 2008, 01:16) *
Какие ещё существуют способы решения данной задачи?


А вообще о каких скоростях вывода в порт идет речь? Т.е. Сколь раз в секунду требуется выкидывать данные.

Как-то давным давно у меня возникла подобная задача: что-то там делать в реальном времени. Я это "дело" навесил на обработчик прерываний от таймера. А что бы понять, сколько времени у меня реально занимает процесс, я не стал заморачиваться подсчетом тактов, а сделал по-простому.

При входе в прерывание устанавливал единичку на свободной лапке микроконтроллера, а перед выходом из прерывания -- нолик. На осциллографе наблюдал прямоугольник. Скоп был хороший (LeCroy) и позволял собирать статистику -- min и max значения. Я задал ему наблюдать длительность импульса. Я запустил эту дело, пошел пить кофею, а когда вернулся уже имел и минимум, и максимум. Далее осталось только прикинуть сколько времени остнется фоновому процессу.

Я понимаю, что все это решалось очень по-крестьянски, но оцените эффективность такого решения. А достоверность результатов? Думаю, имеет смысл Вам проделать такой же эксперимент. А там, получив результаты, сориентируетесь.


--------------------
Хочешь рассмешить Бога -- расскажи ему о своих планах!
Go to the top of the page
 
+Quote Post
Rst7
сообщение Jan 6 2008, 21:01
Сообщение #4


Йа моск ;)
******

Группа: Модераторы
Сообщений: 4 345
Регистрация: 7-07-05
Из: Kharkiv-city
Пользователь №: 6 610



Цитата
Скоп был хороший (LeCroy) и позволял собирать статистику


Не могу не отметить, что наличие хорошего скопа не есть необходимое условие. Берем китайский мультиметр и меряем напряжение на ножке. CPUload=100*Uножки/Uпитания в процентах.

Пардон за оффтоп.


--------------------
"Практика выше (теоретического) познания, ибо она имеет не только достоинство всеобщности, но и непосредственной действительности." - В.И. Ленин
Go to the top of the page
 
+Quote Post
ГУ-49А
сообщение Jan 6 2008, 21:10
Сообщение #5


Участник
*

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



Цитата(zltigo @ Jan 6 2008, 22:45) *
Конкретных способов решения абстрактной ("делать стабильно, через равные интервалы времени, с как можно большей частотой") задачи (с неназванными временами) не существует smile.gif

Некоторые способы я перечислил. Меня устроит, если вывод в порт будет происходить, скажем, каждые 10 тактов. Если получится быстрее - отлично; если можно только медленнее - надо видеть, насколько. За каждый выигранный или проигранный такт я хочу побороться.

Если самый лучший по скорости вывода способ будет напрямую зависеть от конкретных команд задачи (как в случае с вышеупомянутым методом интерлива кода), то, само-собой, кроме меня никто мою задачу решать не будет. Но в таком случае я хотел бы получить ответ на ранее заданный вопрос: Есть ли какой-то инструментарий для подсчёта тактов выполнения команд на LPC? Какова вообще методика расчёта таймингов, ведь кто-то наверняка уже это делал?

Или всё-таки можно сделать по-другому?

Цитата(zhevak @ Jan 6 2008, 22:50) *
А вообще о каких скоростях вывода в порт идет речь? Т.е. Сколь раз в секунду требуется выкидывать данные.

Речь идёт о попытке достижения теоретического максимума на данном железе и задаче. Т.е. порядок цифр - мегагерцы.
Цитата(zhevak @ Jan 6 2008, 22:50) *
Как-то давным давно у меня возникла подобная задача: что-то там делать в реальном времени. Я это "дело" навесил на обработчик прерываний от таймера. А что бы понять, сколько времени у меня реально занимает процесс, я не стал заморачиваться подсчетом тактов, а сделал по-простому.

Повесить на таймер и измерять скорость осциллом - это начальный вариант для такой задачи, спасибо. Каких частот вам удалось достичь, скажем, для простого "дёргания ногой"? Как вы считаете, насколько можно превзойти этот метод?
Go to the top of the page
 
+Quote Post
zltigo
сообщение Jan 6 2008, 21:46
Сообщение #6


Гуру
******

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



Цитата(ГУ-49А @ Jan 6 2008, 23:04) *
вывод в порт будет происходить, скажем, каждые 10 тактов

Задача для LPC2000 решения не имеет. Порядка 4 тактов только вывод через FastGPIO причем это тупая загрузка содержимого регистра по адресу содержащимуся в другом регистре. При этом нужно еще подтаскивать поток в 12 мегабайт в секунду smile.gif Ну и кто-то там еще про "фоновые задачи" smile.gif .....
Цитата
Или всё-таки можно сделать по-другому?

12 МегаБайт в секунду это скорости совсем других контролеров + аппаратная поддержка для обеспечения синхронного порта.


Цитата(ГУ-49А @ Jan 6 2008, 23:10) *
Каких частот вам удалось достичь, скажем, для простого "дёргания ногой"?

Ознакомьтесь с документацией - узнаете предел.


--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post
GetSmart
сообщение Jan 7 2008, 09:43
Сообщение #7


.
******

Группа: Участник
Сообщений: 4 005
Регистрация: 3-05-06
Из: Россия
Пользователь №: 16 753



Думаю можно достичь скорости вывода до Fosc/25 (меандр Fosc/50) или около того. Если в основной проге не будет длинных команд LDM и STM.


--------------------
Заблуждаться - Ваше законное право :-)
Go to the top of the page
 
+Quote Post
ГУ-49А
сообщение Jan 7 2008, 10:25
Сообщение #8


Участник
*

Группа: Участник
Сообщений: 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.

Спасибо. Я готов переписать фоновую прогу наиболее короткими командами в рамках возможного. Но как, тем не менее, обеспечивать стабильность по частоте вывода? Как компенсировать разное время выполнения команд фоновой проги? В связи с этим вынужден повторить свой вопрос: есть ли готовый инструментарий, который, как минимум, для линейного кода на асме проставляет такты (для данного ядра), и, как максимум, может дополнять команды до нужного кол-ва тактов командами-пустышками либо усложнять команды (без изменения алгоритма)?
Go to the top of the page
 
+Quote Post
zhevak
сообщение Jan 7 2008, 12:46
Сообщение #9


Знающий
****

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



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

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

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

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


--------------------
Хочешь рассмешить Бога -- расскажи ему о своих планах!
Go to the top of the page
 
+Quote Post
GetSmart
сообщение Jan 7 2008, 13:37
Сообщение #10


.
******

Группа: Участник
Сообщений: 4 005
Регистрация: 3-05-06
Из: Россия
Пользователь №: 16 753



Цитата(ГУ-49А)
Спасибо. Я готов переписать фоновую прогу наиболее короткими командами в рамках возможного. Но как, тем не менее, обеспечивать стабильность по частоте вывода?
Я имелл ввиду вызов FIQ по таймеру. При этом без всякого гемора будет стабильная частота и небольшой джиттер.

По поводу подсчёта тактов, вроде бы отладчик в ИАРе умеет их считать. Однако не знаю насколько он умный, т.к. в разных режимах ускорения или предвыборки после смены PC тратятся дополнительные "пустые" такты. Вообще, идея интересная. Но, думаю, подобных инструментариев нет и всё придётся делать ручками. Предворительно вызубрив наизусть длительность всех команд и их вариантов. Предворительно перед этим выяснив все тонкости конвейера и прочие нюансы архитектуры ARM7-LPC. Если всё это закончится успехом, то можно достичь теоретически предельной скорости вывода, равной сумме тактов самой длинной используемой команды, плюс 5 тактов (3 на чтение из ОЗУ и 2 на запись в порт). Возможно это будет Fosc/10.


--------------------
Заблуждаться - Ваше законное право :-)
Go to the top of the page
 
+Quote Post
ГУ-49А
сообщение Jan 7 2008, 13:41
Сообщение #11


Участник
*

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



Цитата(zhevak @ Jan 7 2008, 14:46) *
Боюсь нарваться на скандал, но все же скажу, ибо истина дороже синяков.
...сейчас думаете, как из него выжать по максимуму. От сюда и пошли Ваши проблемы.

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

Если готового инструментария для подгонки тактов нет, то посоветуйте, хотя бы, хороший инструментарий для подсчёта тактов для команд написанной программы, без необходимости её компиляции и пошаговой прогонки. Или, может, мне стоит написать такой инструментарий самому?
Go to the top of the page
 
+Quote Post
GetSmart
сообщение Jan 7 2008, 13:53
Сообщение #12


.
******

Группа: Участник
Сообщений: 4 005
Регистрация: 3-05-06
Из: Россия
Пользователь №: 16 753



Цитата
Или, может, мне стоит написать такой инструментарий самому?
О!!! А вот это хорошая идея. Это будет проще всего. Если проект серьёзный, то я бы на вашем месте потратил недельку-другую на некий конвертер, который любой файл, скомпиленный например ИАРом сконвертит и навставляет в код команд вывода. У АРМа совсем немного команд. Нужно только зарезервировать пару регистров чтоб ИАР их не использовал, и избегать условных команд с переменым кол-вом тактов. А в остальном ничего сложного. Правда в полностью автоматический конвертер не получится, остальное придётся опять ручками. Но это реальный вариант.


--------------------
Заблуждаться - Ваше законное право :-)
Go to the top of the page
 
+Quote Post
ГУ-49А
сообщение Jan 7 2008, 13:58
Сообщение #13


Участник
*

Группа: Участник
Сообщений: 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 ровно настолько, чтобы посчитать количество тактов и выдать их мне. Просто меня удивляет, что такой утилиты, судя по всему, нет?
Go to the top of the page
 
+Quote Post
GetSmart
сообщение Jan 7 2008, 14:06
Сообщение #14


.
******

Группа: Участник
Сообщений: 4 005
Регистрация: 3-05-06
Из: Россия
Пользователь №: 16 753



Вы бы ещё пояснили подробности такого нестандартного вывода из процессора. Что за данные и в какое устройство перегоняются? Это связано с управлением светодиодами?

Цитата(ГУ-49А)
Например, можно написать парсер кода, который проэмулирует конвейер ARM7TDMI-S ровно настолько, чтобы посчитать количество тактов и выдать их мне.
У LPC и SAM7 одинаковое ядро ARM7TDMI-S, но конвейер разный. Так что всё это будет конкретно привязано к конкретному процессору. Даже к конкретной его ревизии (ревизиям!). Так как никто не обещал, что улучшений в сторону ускорения работы процессора в новых ревизиях не предвидится.


--------------------
Заблуждаться - Ваше законное право :-)
Go to the top of the page
 
+Quote Post
zhevak
сообщение Jan 7 2008, 14:12
Сообщение #15


Знающий
****

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



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

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

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

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

Удачи!


--------------------
Хочешь рассмешить Бога -- расскажи ему о своих планах!
Go to the top of the page
 
+Quote Post

3 страниц V   1 2 3 >
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 18th July 2025 - 12:51
Рейтинг@Mail.ru


Страница сгенерированна за 0.014 секунд с 7
ELECTRONIX ©2004-2016