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

Баг зависил от времени исполнения какого либо куска ( о том, что он раз в неделю проявляется, при неудачном расплоложении звезд на небе у встречной стороны вообще молчу)
Дальнейшие действия?

Простите, а кто "ставил условия" - для консолей интерфейсов нет и не будет? Отлаживаться будем через JTAG причем стоя в гамаке через Wiggler.

Кстати, я об этом и писал

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

то есть все Ваши проги умирают от снижения производительности на 10% ?
огласите пожалуйста список того что Вы делали и что не нужно покупать (шутю)

Вы не внимательны, условие не жесткое, если заработал модбас по уарту то "консоль"(вывод отладочной инфы)
уже туда.

Ой Ой Ой, меня скоро уволят)))).....а вообще интересная тема, у меня прога хуже работает после того как я ставлю все галочки в разделе оптимизация, хотя по размеру становится меньше в 2 раза(оптимизация то с приоритетом на скорость). Где можно что то почитать типа IAR C++ Compiler Efficient coding? а то вы еще будете долго спорить))

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

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

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

Ага, значит CCS не поддерживает MMU... Оч забавно. А ведь базовый адрес таблицы трансляции лехко читаеться, не сложнее чем кэш заинвалидить.
Кстати RealView поддерживает компиляцию для DSP от TI в платформе OMAP совместно с кодом для ARM.
А б рекомендовал бросать этот CCS и переходить на RealView.
И как там, ССS поддерживает ARM Cortex-A8 для BeagleBoard на OMAP-е?





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

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


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


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


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


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


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

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

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

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

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

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


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

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

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

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


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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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



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

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

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

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

+1

Я думаю что тут задачи у всех разные. Поэтому отношение несколько различается. Похоже обсуждаются уже не краски, а оттенки.

Я не исключаю возможность использования ассемблера, как такового. Сам давеча использовал, но всёже рассматриваю такие вещи как форсмажор, в проекте, который не предполагает дальнейшего развития. Либо локально законченный кусок, не предполагающий внесения изменений. На ассемблере не сложно писать - прогу на нём сложно поддерживать.

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

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