Добрый день. Не знал куда запостить тему, посему пусть тут повисит.
Итак, во время очередной затяжной отладки программы я понял что чего-то мне не хватает в этой жизни для полного счастия. Я понял, что считать быстродействие функций по тактам это зло. Я понял, что следить за переменными ставя точки останова по всей программе это от лукавого. Я понял, что отлавливать вхождения одних функций в другие по загоранию светодиода это тоже не очень хорошо. И я в конце концов пришёл к выводу, что мне нужен хороший профайлер. Единственное что я пока обнаружил - это avr-gprof.exe тихо спящим в папке bin моего WinAVR. Вот пока копаю в эту сторону и что-то оно меня пока не впечатляет.
Посему вопрос знатокам - а есть ли в природе альтернативы этому чуду? Что бы мог указать зависимость вызовов функций, что бы мог указать время выполнения каждого куска кода, что бы мог сказать где и как переменные используются, что и зачем храниться в стеке и т.д. И при всём при этом что бы он имел хоть какой-нибудь графический интерфейс...
Полная версия этой страницы: Профайлер
Порой создаётся ощущение, что когда люди задают вопрос, то предварительно не осмысливают его. Это не в обиду.
Представьте себе, что вам поставили такую задачу. Сделать такое вот програмное средство. Попробуйте осмыслить эту задачу и прикинуть реализацию.
Я думаю что вы поймёте, что для выполнения даже части из поставленных вами задач, придётся внести спец участки прямо в код вашей программы (то есть в МК). Более того, эти части должны где-то собирать данные и как-то передавать инфу в головную программу. При этом желательно чтобы они не занимали место во флэш (например ваш код составляет 90% от макс. объёма), не занимали место в памяти (то же) и не влияли на производительность МК (иначе вы не получите объективного результата). Кроме того, они должны вмешиваться в вашу прогу и, в тоже время, не должны влиять на её работоспособность.
Прикинули задачку? А теперь реализуем её для мега48 к примеру?
Существуют для крупных камней спец аппаратные приблуды типа AVR ONE со стоимостью ~ 1000$. Вроде там такое частично реализовано аппаратным способом.
==============
С другой стороны, ничего из вами перечисленного, я, практически, не применяю. Прогрес идёт вперёд. Камень закладывается со значительным запасом (благо разница в цене несущественна и явно выглядит убедительней "затяжной отладки"). Фраза "... отлавливать вхождения одних функций в другие по загоранию светодиода ..." у меня вызывает изумление.
Может поясните, на конкретном примере, а мы попробуем вам предложить альтернативу. Все же отлаживают в конце концов...
С уважением ....
Представьте себе, что вам поставили такую задачу. Сделать такое вот програмное средство. Попробуйте осмыслить эту задачу и прикинуть реализацию.
Я думаю что вы поймёте, что для выполнения даже части из поставленных вами задач, придётся внести спец участки прямо в код вашей программы (то есть в МК). Более того, эти части должны где-то собирать данные и как-то передавать инфу в головную программу. При этом желательно чтобы они не занимали место во флэш (например ваш код составляет 90% от макс. объёма), не занимали место в памяти (то же) и не влияли на производительность МК (иначе вы не получите объективного результата). Кроме того, они должны вмешиваться в вашу прогу и, в тоже время, не должны влиять на её работоспособность.
Прикинули задачку? А теперь реализуем её для мега48 к примеру?
Существуют для крупных камней спец аппаратные приблуды типа AVR ONE со стоимостью ~ 1000$. Вроде там такое частично реализовано аппаратным способом.
==============
С другой стороны, ничего из вами перечисленного, я, практически, не применяю. Прогрес идёт вперёд. Камень закладывается со значительным запасом (благо разница в цене несущественна и явно выглядит убедительней "затяжной отладки"). Фраза "... отлавливать вхождения одних функций в другие по загоранию светодиода ..." у меня вызывает изумление.
Может поясните, на конкретном примере, а мы попробуем вам предложить альтернативу. Все же отлаживают в конце концов...
С уважением ....
SasaVitebsk, вот как раз из-за того, что прогресс шагает и шагает я и предложил что такая утопия уже воплощена в каком-либо объёме. На самом деле я не написал ничего экстрасложного, разные части уже реализованы для того или иного языка программирования/интегрированной среды/etc. Многое из того, что я перечислил можно вообще получать на этапе компиляции.
Но раз уж такая постановка задачи не нравится, то перефразирую её - "А есть ли в природе ещё профайлеры кроме gprof?".
С другой стороны - система системе рознь и проектирование для каждой (по крайней мере у меня) существенно различаются подходы. Отлаживать программу всем форумом - это глупо
Скажу просто - есть достаточно громоздкая система с кучей функций. Декомпозиция проведена не очень хорошо и надо это дело оптимизировать. Профайлер gprof может сказать сколько времени выполнялась та или иная функция и зависимость вызовов функций. Всё. Но порой этой информации мало. Описывать конкретнее в двух словах у меня всё равно не получится, да и потом выглядеть такое описание будет как глупая абстракция...
В общем вот...
Но раз уж такая постановка задачи не нравится, то перефразирую её - "А есть ли в природе ещё профайлеры кроме gprof?".
С другой стороны - система системе рознь и проектирование для каждой (по крайней мере у меня) существенно различаются подходы. Отлаживать программу всем форумом - это глупо
Скажу просто - есть достаточно громоздкая система с кучей функций. Декомпозиция проведена не очень хорошо и надо это дело оптимизировать. Профайлер gprof может сказать сколько времени выполнялась та или иная функция и зависимость вызовов функций. Всё. Но порой этой информации мало. Описывать конкретнее в двух словах у меня всё равно не получится, да и потом выглядеть такое описание будет как глупая абстракция...В общем вот...
Цитата(UniBomb @ Sep 28 2009, 16:47) 
Посему вопрос знатокам - а есть ли в природе альтернативы этому чуду? Что бы мог указать зависимость вызовов функций, что бы мог указать время выполнения каждого куска кода, что бы мог сказать где и как переменные используются, что и зачем храниться в стеке и т.д. И при всём при этом что бы он имел хоть какой-нибудь графический интерфейс...
Есть. Intel ® VTune ™Подумайте - как он это вытворяет и почему такое для AVR не пойдёт. И почему на AVR и с jtag что-либо похожее не выйдёт.
Для AVR спасёт
- Полновесный аппаратный эмулятор, но это дорого и такие вещи что-то в последнее время не делаются
- Хороший программный симулятор с возможностью навешивать скрипт-хуки на всё, что шевелится - это будет виртуальный vtune.
Но к нему надо адекватные модели "окружающей среды" понаписывать и "testbench"
Здесь уже неоднократно обсуждалось сообществом кто и как определяет "быстродействие функции". В основном - всё самопально. Обычно упоминают два варианта: "по осциллографу" и "по таймеру". Я, к примеру, использую "по таймеру", с расчётом максимального и среднего занчения.
Если бы у меня стояла такая задача очень остро, то, наверное пришлось бы написать свою библиотеку для данных целей. Результат профиллирования размещал бы в озу и смотрел бы доступным мне образом. Например ч/з JTAG.
Готовых програмных сред я не встречал. Мне кажется, что причина - высокая сложность и малая востребованность.
Если бы у меня стояла такая задача очень остро, то, наверное пришлось бы написать свою библиотеку для данных целей. Результат профиллирования размещал бы в озу и смотрел бы доступным мне образом. Например ч/з JTAG.
Готовых програмных сред я не встречал. Мне кажется, что причина - высокая сложность и малая востребованность.
Цитата(SasaVitebsk @ Sep 29 2009, 17:05)
Результат профиллирования размещал бы в озу и смотрел бы доступным мне образом. Например ч/з JTAG.
Консоль можно поднять...
Используйте симуляторы и не парьтесь.
Например HAPSIM или AVR Simulator IDE.
Например HAPSIM или AVR Simulator IDE.
Цитата(UniBomb @ Sep 29 2009, 14:34)
Скажу просто - есть достаточно громоздкая система с кучей функций. Декомпозиция проведена не очень хорошо и надо это дело оптимизировать.
Вообще-то правильный путь думать, что творишь до и во время написания, а не после. Много эффективнее отладчиков, профайлеров....
Проверено
А вот про IAR Systems WorkBench никто и не вспомнил. Понятно, что не всё из перечисленного там есть, но работать с профилировщиком там достаточно удобно. Хоть и симулятор, но представление о работе управляющей программы даёт. В принципе, когда работал ещё в DOS-е, то пользовался профилировщиком для "вылизывания программы". Только баловство всё это.
Цитата(zltigo @ Sep 30 2009, 14:31)
правильный путь думать,
Проверено
Проверено
Это очень , трудный путь
Проверено
RA3WUM, за HAPSIM спасибо, не знал о такой примочке))) А вот второе... Я не программирую на бейсике по религиозным причинам....
zltigo, да я сам проповедую такой подход, просто ситуация такая сложилась. Поставленную задачу я решал впервые, опыта проектирования программ подобного рода у меня мало да и решить задачу требовалось в самые кратчайшие сроки. Сейчас вроде всё работает, но мне жутко не нравится реализация. Чувствую сопровождать такую программу будет очень сложно. Сейчас пока времени более-менее хватает и пока я ещё помню что и зачем я делал я решил улучшить качество кода...
sitafern, он платный ):
В общем я так понял, что искомого мне не найти... Жаль. Поставил себе в блокнотик в разделе "долгосрочные задумки" заметку "сделать что-то подобное", авось у меня что-нибудь получится...
zltigo, да я сам проповедую такой подход, просто ситуация такая сложилась. Поставленную задачу я решал впервые, опыта проектирования программ подобного рода у меня мало да и решить задачу требовалось в самые кратчайшие сроки. Сейчас вроде всё работает, но мне жутко не нравится реализация. Чувствую сопровождать такую программу будет очень сложно. Сейчас пока времени более-менее хватает и пока я ещё помню что и зачем я делал я решил улучшить качество кода...
sitafern, он платный ):
В общем я так понял, что искомого мне не найти... Жаль. Поставил себе в блокнотик в разделе "долгосрочные задумки" заметку "сделать что-то подобное", авось у меня что-нибудь получится...
Вы знаете, я тоже редко когда доволен кодом после написания. Видимо так устроен.
Всегда найдётся что в проге улучшить. А знания приходят с опытом.
Это замечательно, если можно что-то чуть-чуть подправить. Обычно это тупиковый путь. Обычно хочется переписать всё это заново с учётом сделанного. А это, чаще - невозможно.
Зато новое изделие будет лучше предыдущего.
Всегда найдётся что в проге улучшить. А знания приходят с опытом.
Это замечательно, если можно что-то чуть-чуть подправить. Обычно это тупиковый путь. Обычно хочется переписать всё это заново с учётом сделанного. А это, чаще - невозможно.
Зато новое изделие будет лучше предыдущего.
SasaVitebsk, в моей пока ещё недолгой карьере я был доволен кодом всего один раз Прошивку для предыдущего прибора я писал довольно долго, менял методы решений, оптимизировал, сокращал и т.д. Зато когда я закончил - налюбоваться не мог (не то, что бы я бахвальством любил заниматься ). Ничего не прибавить, ничего не убавить, лепота
А так в принципе любой инженер устроен - будь то программист или схемотехник (или ещё кто). И я считаю, что это здорово когда есть желание стремится к лучшему
Прошивку для предыдущего прибора я писал довольно долго, менял методы решений, оптимизировал, сокращал и т.д. Зато когда я закончил - налюбоваться не мог (не то, что бы я бахвальством любил заниматься ). Ничего не прибавить, ничего не убавить, лепота А так в принципе любой инженер устроен - будь то программист или схемотехник (или ещё кто). И я считаю, что это здорово когда есть желание стремится к лучшему
Время выполнения куска кода замеряю просто по таймеру.
Вот таким образом:
#define PROFILE( __Descr) for ( int __toDo = ({start_profile( __Descr); 1; }) ; __toDo; __toDo = 0, stop_profile())
static const char *profStr;
void start_profile( const char *descStr)
{
if ( T1TCR)
return; // Another profiling is on the way
profStr = descStr; // Store description
T1TCR = 0; // Stop timer
T1MR0 = ~0;
T1MCR = MR0R | MR0S;
T1TC = 0;
T1PC = 0;
T1TCR = 1;
}
void stop_profile( void)
{
ulong Cnt;
T1TCR = 0; // Stop timer
Cnt = T1TC;
ulong Ticks = ((double) (1.0/F_CPU * 1E6) * Cnt) ;
fw_printf( ANSI_YELLOW"Profiling %s. About %lu ticks (%ldus)\n\r"ANSI_NORMAL, profStr, Cnt, Ticks) ;
}
Использование:
PROFILE("drawing screen")
{
draw_screen();
}
Вот таким образом:
CODE
#define PROFILE( __Descr) for ( int __toDo = ({start_profile( __Descr); 1; }) ; __toDo; __toDo = 0, stop_profile())
static const char *profStr;
void start_profile( const char *descStr)
{
if ( T1TCR)
return; // Another profiling is on the way
profStr = descStr; // Store description
T1TCR = 0; // Stop timer
T1MR0 = ~0;
T1MCR = MR0R | MR0S;
T1TC = 0;
T1PC = 0;
T1TCR = 1;
}
void stop_profile( void)
{
ulong Cnt;
T1TCR = 0; // Stop timer
Cnt = T1TC;
ulong Ticks = ((double) (1.0/F_CPU * 1E6) * Cnt) ;
fw_printf( ANSI_YELLOW"Profiling %s. About %lu ticks (%ldus)\n\r"ANSI_NORMAL, profStr, Cnt, Ticks) ;
}
Использование:
PROFILE("drawing screen")
{
draw_screen();
}
Нечто подобное под названием профайлер есть в среде VisualDSP для Blackfin(да и для остальных камней от ADI). Если уж зашла речь о прогрессе и больших контроллерах...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.