Дэбаг непрерывного процесса?, IAR 4.41A, AT91SAM7S256 Опции

[coolibin]

Есть участки программы, где я не могу поставить брейкпоинт, т. к. нарушу процесс приема/передачи данных, но все равно хотелось бы посмотреть, что там происходит, например, в программе на Win32 я бы все вывел в лог файл. Как быть с ARM'ом? Вводить дополн. переменные для дебага?

[SM]

Не вижу для отладчика возможности заинвалидить кэш иным способом чем выполнить тем же процом принудительно несколько команд с через ICE

Ясное дело, просунуть нужные инструкции, выполнить, и вернуть состояние на место. Я тоже другого пути не вижу.

Тут уж местный эффект будет по полной. А драйвера в ССS если позволяют себе инвалидить кэш делают медвежью услугу.

А у них выбора нет - пользователь должен видеть все так, как ядро, и никак иначе. И наоборот. Хотя я, конечно, не уверен, что нет других путей это обеспечить, там у них еще ICECrusher-ы всякие есть, и еще кое какой хлам.

Но это не все, есть еще буфера на запись и не только встроенные в ядро, но и прилепленные на AHB производителями непосредственно чипов.

То, что не встроено в ядро, и у чему доступ изнутри ядра через отладку - никого не волнует, оно априори видится точно также, как и из ядра, потому что оттуда и видится.

Ага, значит CCS не поддерживает MMU... Оч забавно. А ведь базовый адрес таблицы трансляции лехко читаеться, не сложнее чем кэш заинвалидить.

Так дрова-то поддерживают все что угодно, считать позволяют. Это сама среда туповата.

И как там, ССS поддерживает ARM Cortex-A8 для BeagleBoard на OMAP-е?

Да, армы 7,9,11 и кортексы M, R, A. Со всеми там ETB, айскрашерами, дапами, жтаг-маршрутизаторами и всем сопутствующим, включая все сопроцессоры.

Прога останавливаться на брекпойтнах не будет и накладные будут меньше чем насиловать JTAG цепочку ICE, особливо если они там реально кэш и буфера инвалидят на каждом чихе.

Не-не, не на каждом далеко. При обмене данными через дебаговый майлбокс ничего не инвалидатится, естессно. Да и я как раз-то ни на что не жалуюсь, ни на скорость, ни на качество, ни на удобство... Не вижу причин менять, тем более что никакой реалвью не поддерживает XDS-ов, необходимых для работы с DSP. Ну его в баню, меня всем пока CCS устраивает, учитывая мой доступ ко всем данным (включая исходники дров) по отладке всего того, что CCS умеет. Плюс к тому ИМХО аналога его PDM нет ни у кого, чтобы отлаживать впараллель несколько разных процессоров, АРМов и ДСПов.

[coolibin]

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

[SM]

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

Если не стоит точек останова, в т.ч. условных, и не используются майлбоксы обмена процессор<=>JTAG<=>хост - то не тормозится.

[SasaVitebsk]

А я вообще в максимальной оптимизации и пишу и отлаживаю. Не вижу особой разницы. Это уж совсем для начинающих - оптимизацию в 0 выключать при отладке. Зачем? Чем она мешает? Ну в некоторых местах остановиться нельзя, ну кое-где не туда прыгает, ну так отлаживают же не по шагам. Приостанавливают в нужный момент и смотрят как процесс протекает. Я, собственно, не непрерывно в отладчике сижу. Это уж слишком. Это сколько же отладка такая времени занимает?

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

[defunct]

Долго смеялся

Смех без причины... Может пора остановиться?

Не вижу для отладчика возможности заинвалидить кэш иным способом чем выполнить тем же процом принудительно несколько команд с через ICE
http://infocenter.arm.com/help/index.jsp?t...222b/index.html

Другой способ и не нужен.

Вопрос в том зачем кеш "инвалидить"? Не надо ни инвалидить ни клинить, пока не пересели на SMP систему. Отладчик обращается к памяти через проц, поэтому и видит ровно то что видит проц.

[zltigo]

Т.е. Вы считаете программу, которая на разных уровнях оптимизации ведет себя по-разному НОРМАЛЬНОЙ? Я бы программиста с таким мнением уволил бы неглядя...

Заодно тогда и сразу можно уволить всех писателей компиляторов, которые зачем-то пишут опримизирующие компиляторы. Зачем они, если все программисты, которые не умеют писать программы одинаково хорошо работаюшие и без оптимизации будут Вами уже уволены.
Я ведь четко написал, что поплывет время исполнения. Это существенный параметр.
А Вы тут, очевидно, не читая, пытаетесь обьяснить мне, что программа вегда должна 2+2=4 всегда считать.

Смех без причины... Может пора остановиться?

Может пора научится читать и думать?

А я вообще в максимальной оптимизации и пишу и отлаживаю. Не вижу особой разницы.

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

[defunct]

Я ведь четко написал, что поплывет время исполнения. Это существенный параметр.

А FPGA у Вас зачем используется если не секрет?
Обычно то, что "может поплыть" кладется на FPGA уж коль она есть. А ARM работает себе в пакетном режиме.
Ни за что не поверю что на проц никак нельзя снизить нагрузку, да хотя бы ту же UART консоль отрубить полностью - и покроется то самое "уплывание" времени. (если уж там и правда все взахлёб работает под >98%). С другой стороны, система где проц занят на 98% - спроектировна неверно (проц подобран неверно).

Может пора научится читать и думать?

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

[Dog Pawlowa]

Т.е. Вы считаете программу, которая на разных уровнях оптимизации ведет себя по-разному НОРМАЛЬНОЙ? Я бы программиста с таким мнением уволил бы неглядя...

Совершенно сознательно недавно понатыкал индексированных заинлайненых сервисов в прерывание.
Естественно, все работает только при оптимизации. Рутинный метод.

И еще раз на тему отладок процессов. Ну делаются специальные версии программ. Например, в коммуникации - зеркала на разных уровнях и проч.
Для тех, [кто в танке] у кого нет интерфейсов - отладка идет по рабочему интерфейсу

[zltigo]

А FPGA у Вас зачем используется если не секрет?

Например, для работы с сотнями синхронных каналов.

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

Я хоть когда-то говорил, что лично у меня есть какие-то пробоемы с проектированием систем? И написанием программ?

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

Честно говоря, я даже первый раз не хотел отвечать на столь дикие сентенции, но, как мне казалось, достаточно доходчиво объяснил.

[SM]

Я ведь четко написал, что поплывет время исполнения. Это существенный параметр.
А Вы тут, очевидно, не читая, пытаетесь обьяснить мне, что программа вегда должна 2+2=4 всегда считать.

У меня однозначный подход к проектированию, который я требую и с других:
Код на ЯВУ должен корректно работать при любом уровне оптимизации, и от этого никакие времянки существенно плыть не должны.
Места, где времянки существенно зависят от кода, а не от железа, прерываний, и т.д. должны быть написаны на ассемблере, чтобы не зависить от уровня оптимизации и от примененного компилятора.
Под словом "существенно" понимается уплывание за пределы допустимого.

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

[defunct]

Например, для работы с сотнями синхронных каналов.

Стандартно.. ARM естессно имеет доступ к FPGA по шине памяти и работает на пакетном уровне. Что и куда может поплыть?
Да ничего и никуда не должно плыть, пока MIPS'ов хватает. А если не хватает с какой-то опцией оптимизации - тогда это проблема проца, а не программы.
Но и здесь все решается банальным урезанием денсити на время отладки - обрабатывать на пару десятков каналов меньше (из сотен имеющихся)..

Я хоть когда-то говорил, что лично у меня есть какие-то пробоемы с проектированием систем? И написанием программ?

Нет, но в этой ветке какая-то несуразица пошла.
Чем отличается ситуация 2 + 2 != 4 от "поплывет время". Ведь и в том и в другом случае результат одинаков - нерабочая программа.
А если я правильно помню, в других темах, Вы же лично говорили о том, что результат программы не должен зависеть от выбранного параметра оптимизации.

Честно говоря, я даже первый раз не хотел отвечать на столь дикие сентенции, но, как мне казалось, достаточно доходчиво объяснил.

дык, провоцируете... может терминология неудачно выбрана? Плывет время, обычно там где сплошь и рядом понатыкано всяких сомнительных "delay_ms".

[Dog Pawlowa]

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

В ущерб пониманию, системному подходу и скорости написания программы?
Не согласен. Увольняйте

[SM]

В ущерб пониманию, системному подходу и скорости написания программы?

Скорости написания, да, в ущерб, за счет улучшения качества. А с остальным - категорически не согласен. Качественно комментированный асм код не менее понимаем и никакого ущерба в системный подход не вносит. Зато весь системный подход не валится к чертям от смены компилятора (или хотя бы его версии) или от дебаг-режима
и априори гарантирует отсутствие описываемых тут, в этой ветке, проблем при отладке, чем значительно ускоряет ее.

[zltigo]

У меня однозначный....

Глупый поход и неразумеые требования.

Да ничего и никуда не должно плыть, пока MIPS'ов хватает.

В очень и очень широком спектре задач ресурсов ВСЕГДА не хватает. Вся телекоммуникация это есть деление ограниченных ресурсов и утойчивая работа в условиях в том числе и пиковых нагрузок.

А если я правильно помню, в других темах, Вы же лично говорили о том, что результат программы не должен зависеть от выбранного параметра оптимизации.

Результат 2+2= и подобные безвариантно. Но не ВРЕМЯ получения результата. Добавлять попугаев, как Вы пропагандируете, или переписывать на ASM есть глупость и непрофессионализм. Надо просто нормально писать программы, предстваляя что делаете и сколько это исполняяется, пользоваться всеми возможными способами, как ручной, так и компиляторной оптимизации. И НИКОГДА не писать левой ногой и еще НИКОГДА не отключать оптимизацию, дабы это отладить.

дык, провоцируете... может терминология неудачно выбрана? Плывет время, обычно там где сплошь и рядом понатыкано всяких сомнительных "delay_ms".

Плывет время и ПОЛЕЗНОЙ ВЫПОЛНЯЕМОЙ РАБОТЫ. Отключив оптимизацию, ну, например, софта какого-нибудь роутера вы неизбежно получите падение его производительности и попадете в другие условия работы, нежели в момент, ДО ТАКОЙ ОТЛАДКИ. Если Вы считаете, что меня волнуют вопросы отладки "контролера светодиода" мигающего по "delay_ms", то это не мой круг интересов.

[SM]

Глупый поход и неразумеые требования.

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