[megaboy 0]

Существует такая проблема, уменьшающая наглядность при отладке С кода,

скомпилированного в WinAVR - почему то курсор не хочет пошагово ходить по некоторым строкам

кода, например тогда, когда ф-ия в результате оптимизация стала инлайновой.

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

Вот, к примеру, пример:

С код

        if(pc_fifo.char_cnt)
        {
            send_sim(pop_buffer(&pc_fifo));
        }
        if(sim_fifo.char_cnt)
        {
            send_pc(pop_buffer(&sim_fifo));
        }

Дизасм окно

140:              if(pc_fifo.char_cnt)

+00000365:   91400286    LDS     R20,0x0286       Load direct from data space
+00000367:   91500287    LDS     R21,0x0287       Load direct from data space
+00000369:   1541        CP      R20,R1           Compare
+0000036A:   0551        CPC     R21,R1           Compare with carry
+0000036B:   F1B1        BREQ    PC+0x37          Branch if equal
+0000036C:   91200284    LDS     R18,0x0284       Load direct from data space
+0000036E:   91300285    LDS     R19,0x0285       Load direct from data space
+00000370:   91800282    LDS     R24,0x0282       Load direct from data space
+00000372:   91900283    LDS     R25,0x0283       Load direct from data space
+00000374:   1728        CP      R18,R24          Compare
+00000375:   0739        CPC     R19,R25          Compare with carry
+00000376:   F411        BRNE    PC+0x03          Branch if not equal
+00000377:   E0E0        LDI     R30,0x00         Load immediate
+00000378:   C023        RJMP    PC+0x0024        Relative jump
+00000379:   91E0027E    LDS     R30,0x027E       Load direct from data space
+0000037B:   91F0027F    LDS     R31,0x027F       Load direct from data space
+0000037D:   0FE2        ADD     R30,R18          Add without carry
+0000037E:   1FF3        ADC     R31,R19          Add with carry
+0000037F:   81E0        LDD     R30,Z+0          Load indirect with displacement
+00000380:   5F2F        SUBI    R18,0xFF         Subtract immediate
+00000381:   4F3F        SBCI    R19,0xFF         Subtract immediate with carry
+00000382:   93300285    STS     0x0285,R19       Store direct to data space
+00000384:   93200284    STS     0x0284,R18       Store direct to data space
+00000386:   91800280    LDS     R24,0x0280       Load direct from data space
+00000388:   91900281    LDS     R25,0x0281       Load direct from data space
+0000038A:   1728        CP      R18,R24          Compare
+0000038B:   0739        CPC     R19,R25          Compare with carry
+0000038C:   F421        BRNE    PC+0x05          Branch if not equal
+0000038D:   92100285    STS     0x0285,R1        Store direct to data space
+0000038F:   92100284    STS     0x0284,R1        Store direct to data space
+00000391:   91800288    LDS     R24,0x0288       Load direct from data space
+00000393:   7F8E        ANDI    R24,0xFE         Logical AND with immediate
+00000394:   93800288    STS     0x0288,R24       Store direct to data space
+00000396:   5041        SUBI    R20,0x01         Subtract immediate
+00000397:   4050        SBCI    R21,0x00         Subtract immediate with carry
+00000398:   93500287    STS     0x0287,R21       Store direct to data space
+0000039A:   93400286    STS     0x0286,R20       Store direct to data space
+0000039C:   93E000C6    STS     0x00C6,R30       Store direct to data space
+0000039E:   918000C0    LDS     R24,0x00C0       Load direct from data space
+000003A0:   FF85        SBRS    R24,5            Skip if bit in register set
+000003A1:   CFFC        RJMP    PC-0x0003        Relative jump

144:              if(sim_fifo.char_cnt)

А куда же делось это? :07:

{

send_sim(pop_buffer(&pc_fifo));

}

 

 

Вопрос собственно, можно ли где то настроить, либо в Студии либо в WinAVR чтобы

пошаговая отладка работала для всех строк С кода или, на крайняк, чтобы все строки

С кода отображались в окне дизасма?

Изменено 7 ноября, 2008 пользователем megaboy

[Artem_Petrik 0]

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

Именно поэтому, скажем в IAR-е, возле уровня птимизации 0 стоит пояснение "Best debug support" - это единственная причина по которой можно (нужно) отключать оптимизацию.

А уже после отладки нужно все перекомпилить с оптимизацией, благо оптимизация не влияет на работоспособность ПРАВИЛЬНО написанного кода.

[_Pasha 0]

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

Но лучше этого не делать. Иначе можно долго мучать код, а оптимайзер все равно сюрпризов мешок принесет.

[megaboy 0]

Но лучше этого не делать. Иначе можно долго мучать код, а оптимайзер все равно сюрпризов мешок принесет.

Будьте добры, п-подробнее... Результат исполнения кода с включенной и выключенной оптимизацией

может быть разный?

Ну я не учитываю разность во временных задержках типа \utils\delay.h

[Qwertty 0]

Будьте добры, п-подробнее... Результат исполнения кода с включенной и выключенной оптимизацией

может быть разный?

Ну я не учитываю разность во временных задержках типа \utils\delay.h

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

[megaboy 0]

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

Интересно, с отладкой комповых кодов в С билдере, например, дело обстоит так же?

[Artem_Petrik 0]

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

 

Все это так, да не совсем так. Действительно в некоторых случаях оптимизация может наоптимизировать так, что timed sequence сброса вачдога, записи в EEPROM, смены предделителя тактовой и т.д. перестанет работать. Или наоборот начнет. Сам с таким несколько раз сталкивался. Но специально для этого практически всегда среда разработки представляет набор (часто инлайновых) функций, использование которых гарантирует, что все будет нормально. В используемом мною IAR-е это все есть, и насколько я могу судить по обсуждениям на этом форуме - в WinAVR(GCC) тоже.

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

Конечно же сущесвует много способов написать программу которая при разных уровнях оптимизации будет выдавать различные результаты. Непоставленные в нужном месте volatile могут преподнести много сюрпризов для начинающего. Код написанный таким образом не может считаться правильным. Правильный же код работоспособен при любом уровне оптимизации. Варьируется только скорость его выполнения и размер.

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

 

Что касается watchdog-а, то включать его на этапе хождения по программе "по шагам" - вообще не самая лучшая идея. Сам я включаю его только после того, как программа полностью отлажена и работоспособна.

[Qwertty 0]

Но специально для этого практически всегда среда разработки представляет набор (часто инлайновых) функций, использование которых гарантирует, что все будет нормально. В используемом мною IAR-е это все есть, и насколько я могу судить по обсуждениям на этом форуме - в WinAVR(GCC) тоже.

Стандартные функции часто не устраивают и приходится делать самописные.

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

В avr-libc функции задержки при отключенной оптимизации вообще не работоспособны. Более того, при желании их использования велика вероятность превысить размер памяти программ. Особенно актуально для мелких кристаллов типа М8.

Что касается watchdog-а, то включать его на этапе хождения по программе "по шагам" - вообще не самая лучшая идея.

Это был просто абстрактный пример.

[xemul 0]

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

А модульность уже отменили? Выносите отлаженные функции в отдельные файлы и задавайте для них требуемую оптимизацию, а подлежащие отладке компилируйте без оптимизации.

[SapegoAL 0]

Я работаю в IAR, поэтому могут быть отличия. Но всё же в целом картина аналогичная.

 

Всётаки сразу включаю максимальный уровень оптимизации. Хотя при этом часто листинг не совсем удобен для просмотра. В остальном нормально. Действительно некоторые операторы как бы объединяются, но к этому быстро привыкаешь и сам начинаешь понимать, что и как делает компилятор.

 

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

 

Насчёт неудобства отладки в СИ - с точностью до наоборот. Причина проста. Уровень отладки меняется. Операторы - крупнее. Переменные - нагляднее. Результат - на одну и ту же прогу в си приходится делать меньше операций.

[_Pasha 0]

Уровень отладки меняется. Операторы - крупнее. Переменные - нагляднее.

 

В цифрах картина примерно такая:

допустим, софтина была в 10Кслов, при этом асмовая вставка была где-то 700 слов. Так на эту вставку при ее отладке ушло 70-80% времени.

[megaboy 0]

Просто для эффективной отладки, я так понимаю, необходимо неплохо знать ассемблер! Ну пускай для авр это не проблема, но

для арма это уже мучительно :)

[Foris 0]

А уже после отладки нужно все перекомпилить с оптимизацией, благо оптимизация не влияет на работоспособность ПРАВИЛЬНО написанного кода.

Ну и совет ! Это будет ДРУГОЙ код и его тоже нужно отлаживать.

[techmike 0]

Просьба ткнуть в доку/статью по правильному написанию кода для под AVRStudio+WinAVR(GCC).

Так как из своей небольшой практики сталкивался только с особенностями выполнения задержек при разных уровнях оптимизации. В остальном пока не наступал на грабли.

[Artem_Petrik 0]

Ну и совет ! Это будет ДРУГОЙ код и его тоже нужно отлаживать.

Ага, а через пару лет, после переходана на более новую версию компилятора, или вообще на другой компилятор, потребуется поправить пару констант (из-за смены кварца например) и новый компилер вообще все по другому перекомпилит. И это будет уже совсем другая программа и отлаживать все придется заново :a14: Афигеть!

Сам я как-то сталкивался с программой, которая при переходе на более новую версию компилятора работать отказывалась. Расстановка где надо volatile ей помогла. Новый компилер циклы задержки оптимизировал . Но это признак только того, что программа изначально содержала ошибки.

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

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