[rezident 0]

А прибор то работает? :)

Сегодня удалось-таки проверить в приборе прошивку, скомпилированную новой версией 4.10A. Работает! :08:

Оптимизация High-Balanсed, опция Code motion по традиции выключена. Reduce stack usage включена.

5 466 bytes of CODE memory

405 bytes of DATA memory (+ 60 absolute )

132 bytes of CONST memory (+ 176 absolute )

В 3.42a с такими же установками (только оптимизация High-Speed) было

5 730 bytes of CODE memory

405 bytes of DATA memory (+ 60 absolute )

164 bytes of CONST memory (+ 176 absolute )

Куда в 4.10a деваются константы, не пойму до сих пор :cranky:

[VAI 0]

Куда в 4.10a деваются константы, не пойму до сих пор

Кстати, я ручками посчитал по всем файлам *.lst сколько констант используется, и сравнил сколько пишет в конце и 3.30а и 4.10а.

В *.lst - количество const одинаковое в обоих версиях, и оно больше, чем то, которое написано в конце, после линковки. В обоих версиях "результат" меньше "суммы", в 4.10а просто он меньше, чем в 3.30а.

У меня, кстати, надурняка с 3.30а на 4.10а перекомпилировалось без ошибок, не заработало, но сейчас "переправа" сразу нескольких проектов, притормозил переход... хотя попробовать охота...

[diper 0]

Оптимизация High-Balanсed, опция Code motion по традиции выключена. Reduce stack usage включена.

Чем вызвана такая такая нелюбовь к Code motion ?

 

По поводу констант сложидось впечатление что он их начал активнее инлайнить. Сравнить уже не с чем моcты сожжены :)

[VAI 0]

Чем вызвана такая такая нелюбовь к Code motion ?

Глючит. У меня переменную, которая менялась в цикле, выводила за цикл...

Где-то здесь писалось.

[rezident 0]

Чем вызвана такая такая нелюбовь к Code motion ?

Исторически так сложилось. Глючит эта опция у IAR. IAR даже с volatile не всегда корректно обходится :(

[DogPawlowa 0]

1 ) В одном проекте только часовой кварц, контроль которого встроенными средствами MSP не поддерживается. Поэтому было сделано грубое сравнение таймера от кварца с программным циклом от DCO. Цикл изменился, константу пришлось менять.

 

2 ) Ага, я его сломал! Поставил оптимизацию high, balanced, снял галку Code motion.

 

Error[e46]: Undefined external "This_Function" referred in work ( D:....r43 ) 
Internal Error: In function: unknown 
Diagnostic: unexpected exception 
P0: 1    P1: 0 
Error while running Linker 

Total number of errors: 2 
Total number of warnings: 0

 

3) Поигрался с галками. Ошибка исчезает, если снять галку Function inlining. То есть функция "проинлайнена", а линковщик ищет указатель на нее и естественно не находит.

 

Вывод: реальный глюк, однако...

[rezident 0]

2) Поигрался с галками. Ошибка исчезает, если снять галку Function inlining. То есть функция "проинлайнена", а линковщик ищет указатель на нее и естественно не находит.

 

Вывод: реальный глюк, однако...

Угу. Function inlining чаще всего тоже убираю. Особенно когда в программе много работы с указателями.

[DogPawlowa 0]

Угу. Function inlining чаще всего тоже убираю. ...

Оказывается, у меня принудительно стояла "pragma inline" для этой функции.

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

[diper 0]

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

Если придерживаться правила "буть проще", видимо многих косяков можно избежать. :)

[DogPawlowa 0]

А еще в новой версии происходит контроль заполнения стека. Если на момент останова стек занят более чем на 90%, в окне сообщений выводится предупреждение.

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

[diper 0]

А еще в новой версии происходит контроль заполнения стека. Если на момент останова стек занят более чем на 90%, в окне сообщений выводится предупреждение.

В 3.42А это уже было и настраивается в опциях отладчика. При отладке в операционке вообще вещь бесполезная, т.к. стек там всегда не "там". А у меня и в main пишет что стек кончился:) Так как в качестве стека main используются буфферы таск, которые до старта таск не нужны.

[akostin 0]

Такая проблема.

У меня в Симуляторе IAR for MSP 4.10 подпрограмма длительностью примерно 1 млн. циклов выполняется порядка 1 минуты. Это при условии, что активно окно IDE, иначе еще дольше.

Вопрос: Что симулирует Pentium целую минуту в процедуре, котрую MSP должен исполнить за 125мс?

Как уменьшить это время? Может в настройках что-то не то?

 

Проверить на старых версиях IAR for MSP сейчас нет возможности, но я запихнул ту же процедуру в IAR for AVR - там симуляция занимает несколько секунд, что вполне приемлимо.

[akostin 0]

Проверить на старых версиях IAR for MSP сейчас нет возможности, но я запихнул ту же процедуру в IAR for AVR - там симуляция занимает несколько секунд, что вполне приемлимо.

Вот проверил скорость выполнения процедуры БПФ в разных версиях симулятора IAR EW430:

3.21 31 сек

3.40 55 сек

3.42 52 сек

4.10 60 сек

IAR AVR 4.20 3 сек !!!!!

Особенно удивила старая 3.21 - работает быстрее новых.

Напоминаю - число циклов процессора MSP430 в данной процедуре порядка 1млн.

Кто-нибудь сталкивался с такой ситуацией?

[rezident 0]

Вот проверил скорость выполнения процедуры БПФ в разных версиях симулятора IAR EW430:

3.21 31 сек

3.40 55 сек

3.42 52 сек

4.10 60 сек

IAR AVR 4.20 3 сек !!!!!

Особенно удивила старая 3.21 - работает быстрее новых.

Напоминаю - число циклов процессора MSP430 в данной процедуре порядка 1млн.

Кто-нибудь сталкивался с такой ситуацией?

ИМХО это особенности симуляции Фон-Неймановской архитектуры у MSP430, в отличие от Гарвардской у AVR.

[bovolk 0]

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

 

Соответствие параметров и регистров изменилось!!!

 

См. стр.93 "EW430_CompilerReference.pdf", правьте свои исходники на ассемблере, во всяком случае те, у кого в вызываемых функциях более одной переменной.