Есть программа, вот с такой функцией main:
void main()
{
Init();
while(1) ;
}

Вся остальная программа выполняется по срабатыванию прерываний от ножек процессора и таймера, работающего на частоте 500 Гц. Вопрос: как определить, например в процентах, какая часть процессорного времени уходит на выполнение кода, кроме while(1) в main'е.

В кейловском симуляторе (если есть возможность запустить в нем) можно посмотреть процент выполнения модулей и отдельных функций.

Если длительность прерывания таймера вполне поддаеться просчету,
то все остальное будет зависеть исключительно от внешних событий.
А вообще существуют такие программы - профайлеры, которые просчитывают скорость исполнения различных фрагментов кода и позволяют выявлять узкие места.

Можно осцилографом, на глаз? если есть свобожная нога
только чуть изменить хлостой цикл

и сразу будут видны места где проц работатет в прерываниях

второй вариант в начале каждого прерывания устанавливать ногу в 1 ( SetTestPin()
а в главном цикле всегда сбрасывать

Я бы не именя никаких отладочных средств просто при входе в прерывание кидал бы ногу, допустим, в 1, а при выходе опять в 0. А потом в работе мультиметром посмотрел бы напряжение на этой ноге.

iit, от симулятора не будет толка, потому что выполнение программы зависит от внешних условий.

beer_warrior, функция тамера вызывается 500 раз в секунду, но время её выполнения зависит от внешних факторов.

Интересует не просто врем выполнения программы и, как было сказано, выявление узких мест, а именно на реальном процессоре в реальных условиях постоянно мониторить занятость процессора (как в таск баре в windows)

Вот светодиод и повесь на ногу.

KRS, Alechek, а если без внешних приборов? Чтобы была некоторая переменная, изменяющаяся от 0 до 100 и обозначающая загруженность проца?

Завести с этой ноги на вход АЦП??

Alechek, не думаю, что АЦП в этом случае правильно будет работать. Он или остановит весь проц, выдав 1023 или 0. Или, производя преобразования по мере включения/выключения ножки, выдаст полную лажу. Просто светодиод (т.е. глаз человека) и вольтметр - инертные приборы.

У меня есть такой вариант: отключить все прерывания, а в while(1) сделать счётчик, скажем, до 1 000 000. Посмотреть сколько времени (в тиках процессора например) выполняется миллион пустых итерация while(1) (ну и счётчика внутри).

При 100%-й загруженности проца другими функциями, функция main должна как бы "зависнуть", т.е. время выполнения = бесконечности. Т.е. время выполнения 1000000 тиков обратно пропорционально загруженности проца, но при 0-й загруженности уходит не в бесконечность, а в некоторую константу. Т.е. формула типа:
t = A / (100 - cpu_usage)
где (A / 100) - время выполнения 1000000 итераций незагруженного проца.

Как вам такой вариант? Мои рассуждения вообще логичны или нет? Или такой алгоритм не будет правильно работать?

Сообщение отредактировал Pasha 111 - Jul 21 2006, 08:47

Абсолюно бесполезная рюшечка - толку Вам будет от такого индикатора показывающего, что
в течении времени интеграции доступного к наблюдению человеком (сотни миллисккунд-секунды) процессор был загружен на 0 челых хреен десятых процента, если он при этом реально захлебывался несколько тактов таймера.
Практическое значение в такой системе, как Ваша (сужу по вечному циклу вместо операционной системы могущей как-то разбираться с нехваткой ресурсов) похоже может иметь только наличие фатальной нехватки времени, например (ну не сочли нужным Вы сообщить подробности) можете запрограммировав счетчик таймера на "ручной" сброс и читая/cбрасывая его в обработчике прерывания можете получить величину на которую "перетянули" остальные обработчики таймерное прерывание.
Задаете допустимые с Вашей точки зрения отступления от "временной оси" и ругаетесь на превышение.
Это явно работать будет при отсутствии ввложенных прерываний и нижайшем приоритете таймерного. В других условиях думайте сами, или формулируйте правила игры.

Можно попробовать использовать таймер
при входе в прерывание, останавливать таймер, при выходе опять запускать
(можно не при выходе а в главном цикле всегда разрешать)

И потом раз в секунду например (нужен еще один таймер), можно узнать загрузку по содержимому 1 таймера (который останавливался в перываниях)

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

Сообщение отредактировал KRS - Jul 21 2006, 09:15

zltigo,
программа работает так: инициализируются прерывания на изменение уровня на ножках процессора, к этим ножкам подключаются энкодеры (от моторов). Т.о. при вращении двигателя возникают П-образные сигналы, и прерывание, отвечающее за обработку этих ножек, увеличивает или уменьшает счётчики (смотрит на ножки, соответствующие каналам А или Б энкодеров).
Т.о. скорость вызовов функции-обработчика прерываний всё время разная, но не меняется скачками, и моментов, когда процессор загружен на 100% в течении очень короткого времени, а в остальное на 0 с чем-то, быть не может

Параллельно с этим, работает таймер на частоте 500 Гц. Функция обработки прерываний этого таймера смотрит на переменные, изменяемые энкодерами, и в зависимости от этого выполняет некоторые действия (слудящая, блок принятия решений и т.д.)

На самом деле в функции main() в дальнейшем должен появиться некоторый код , так вот мне интересно, сколько ресурсов жрёт следящая, и хватит ли моего at91sam7s на выполнение той проги, которую я в main'е напишу.

P.S. И ещё параллельно с этим функция таймера отправляет данные по uart'у и вызываются прерывания переполнения буфера dma контроллера.

KRS, а это не эквивалентно тому, что я выше написал? Просто так проще и таймер лишний юзать не надо.

Сообщение отредактировал Pasha 111 - Jul 21 2006, 09:21

Предлагаю такую вариацию решения (если есть 1 свободный таймер)
имеем один 32 бит таймера
конфигурим его так чтоб он инкрементировался по каждому такту.
при входе в прерывания его включаем при выходе выключаем. На это потребуется всего 2 такта, что можно либо учесть или забить если код прерываний большой (првда че это за прерывания тогда )
Через 2^32/Fтакт секунд смотрим отношение числа в счетном регистре таймера к числу 0xFFFFFFFF, это и будет процент загрузки.

Ой, не советовал бы я энкодеры на прерывания вешать, особенно если они на моторах стоят и точность отслеживания позиции нужна на всем времени работы аппарата (в ЧПУ зануление один раз за смену обычно принято делать) и этих энкодеров несколько. Нет возможности точно указать максимальную чстоту следования импульсов, при которой не будет наблюдаться их пропусков.