[DogPawlowa 0]

Использую EW AVR 411a - не нравится, что при некорректном завершении отладки закрывается среда.

EW MSP430 321A - 1. заблокировано "Go to definition of ..." 2. Постоянно лезет в директорий другого проекта при поиске и открытии файла.

 

Есть ли смысл апгрэйдить, если все остальное в принципе устраивает, и на что ?

[rezident 0]

Апгрейдить есть смысл, если что-то кардинально не устраивает или глючит и есть уверенность, что в следующей верии этого не будет.

Я пользуюсь вер. 3.30А для MSP430. Хотя сейчас, когда пошли проекты на F20xx, пробую 3.42А. Для обеих версий наблюдаю некоторые глюки при работе с переменными volatile. Если такая переменная находится в структуре, то компилятор не всегда корректно ее обрабатывает - "забывает" что она volatile. Причем проявление этого глюка зависит от положения переменной в структуре. Я писал об этом в пустыне.

Кроме того в симуляторе 3.42А (в отличие от 3.30А) перестала работать "ручная" симуляция вызова прерывания. А вот макрос, созданный для этого же дела, работает.

[IgorKossak 0]

О EWAVR могу сказать, что обновляться смело можно (в плане того, что глючности не прибавилось, а уменьшилось), но в некоторых случаях придётся корректировать проект из-за нового синтаксиса.

Последнее касается только ИАРовских расширений.

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

[zltigo 0]

Компиляторы upgrade надо делать всегда.

IAR по каждому из компиляторов ведет историю изменений - можете ознакомиться на сайте.

[BOS 1]

Компиляторы upgrade надо делать всегда.

Кстати, для AVR сегодня появился новый релиз : EW AVR 430A.

..Будем пробовать делать upgrade :)

Изменено 13 июня, 2007 пользователем zltigo

[Itch 0]

а такскать, лекарство для него где можно найти?

[rezident 0]

а такскать, лекарство для него где можно найти?

Дык оно универсальное. Концентрацию только чуть увеличить нужно. В ридми все описано. Вместо 10_WIN видимо 11_WIN нужно.

 

Кстати, для AVR сегодня появился новый релиз : EW AVR 430A.

..Будем пробовать делать upgrade :)

Вот же блин, а я буквально намедни для товарища 4.21A скачал. :(

[zltigo 0]

Дык оно универсальное. Концентрацию только чуть увеличить нужно

Да. Проверено.

 

 

Новенькое:

New features
Improved handling of small aggregate types (structures and unions) and registers. 

A new extended keyword __no_runtime_init has been added to the product. For more information, see manual corrections. 

Known problems
..........................


Program corrections
EW19158: struct copying, with variable clustering enabled could result in an internal error. 

EW19095: On low optimization levels a MULS could be generated instead of a FMULS. 

EW19066: A cast from a __generic pointer to a flash pointer could modify the __generic pointer. This has been corrected. 

EW19048: The files iopwm2.h, iopwm3.h, iowm2b.h, and iopwm3b.h have been updated to match revision H of Atmel's specification of these devices. 

EW18976: Nested loops with constant trip counts could be incorrectly optimized. Nested loops should now execute the correct number of iterations. 

EW18966: The files lnkm644ps.xcl and cfgm644p.xcl now have a correct interrupt vector table size. 

EW18847: The intrinsic __dgetexp did not generate correct code in all cases, this has now been corrected. 

EW18827: The alternate bit names for UCSRnA, UCSRnB and UCSRnC when the USART is in SPI master mode has beem added to the files iom2560.h and iom2561.h. 

EW18800: The erroneous transfer of a supplied memory type attribute to const parameters no longer occurrs. 

EW18719: The call stack information was broken for code located above 0x4000 on the devices ATmega640, ATmega1280, and ATmega1281. 

EW18047: A problem that could cause an internal error when the option --mfc was used has been corrected. 

Miscellaneous
The CBRA and SBRA instructions are supported.
Related command line options are:
--enable_cbra_sbra
--set_cbra_sbra_address 

__x, __z __x_z, __z_x
The compiler defines the function type attributes __x, __z __x_z, and __z_x which are used by parts of the runtime library. These attributes can give very efficient code in a local perspective, but should be used with care as they change the calling convention and may have a negative effect on the size of the entire application.

Keyword    
Description
__x    The first pointer in the parameter list is placed in register X
__z    The first pointer in the parameter list is placed in register Z
__x_z    The first pointer in the parameter list is placed in register X and the second one in register Z
__z_x    The first pointer in the parameter list is placed in register Z and the second one in register X

[Itch 0]

Дык оно универсальное. Концентрацию только чуть увеличить нужно. В ридми все описано. Вместо 10_WIN видимо 11_WIN нужно.

Спасибо! Пациент лекарство принял, теперь готов к подвигам (:

[IgorKossak 0]

Первое впечатление от теста положительное.

Проект на С++ достаточно большой (выходной код ~120kB). Всё работает. Но!

При том же уровне оптимизации (макс. по скорости) код увеличился ~2kB. стал анализировать и обнаружил в числе прочего, что компилятор позаменял вызов некоторых функций (в основном это короткие прологи/эпилоги) инлайновыми вставками. Таким образом получается даже немного быстрее.

При открытии старого (версии 4.21) воркспейса с проектами воркбенч сказал, что они старого??? формата и перевёл их на новый, хотя я в сравнении особой разницы не заметил.

Новые фичи в pdf так и не внесены, так что надо читать manuals.htm.

Наконец то легализовали __x __x_z и др., но предостерегают ими злоупотреблять.

Глюк с __eeput64_16 в eeprom.s90 (я уже писал о нём) так и не исправили, ему уже скоро пять лет исполнится B)

[BOS 1]

Первое впечатление от теста положительное.

А у меня первое впечатление отрицательное:

 

При попытке откомпилировать старый проект (максимальная оптимизация по размеру) были получены заметно различные результаты оптимизации:

Версия 4.21А:

 

7 747 bytes of CODE memory (+ 24 bytes shared)

667 bytes of DATA memory (+ 26 bytes shared)

25 bytes of XDATA memory

 

Errors: none

Warnings: none

 

Версия 4.30A

 

7 821 bytes of CODE memory (+ 24 bytes shared)

667 bytes of DATA memory (+ 26 bytes shared)

25 bytes of XDATA memory

 

Errors: none

Warnings: none

Тоесть разница составляет 74 байта.... Хотя помнится мне что в версии 4.21А чтобы получить "7 747 bytes of CODE" пришлось попотеть в битве за парочку байтов.... А тут разница в 74 байта !!!

[zltigo 0]

чтобы получить "7 747 bytes of CODE" пришлось попотеть в битве за парочку байтов....

Позвольте не поверить о пролитом поте в трудах по экономии пары байтов в 7747 байтном коде писаном на 'C' :) Ну а к к глючам оптимизации следует относиться творчески, ибо сведение их многообразия к трем IDE-шным отфонарным наборам не является хорошим подходом к делу.

[IceS 0]

А у меня первое впечатление отрицательное:

 

При попытке откомпилировать старый проект (максимальная оптимизация по размеру) были получены заметно различные результаты оптимизации:

 

Тоесть разница составляет 74 байта.... Хотя помнится мне что в версии 4.21А чтобы получить "7 747 bytes of CODE" пришлось попотеть в битве за парочку байтов.... А тут разница в 74 байта !!!

Может это связано с:

EW18976: Nested loops with constant trip counts could be incorrectly optimized. Nested loops should now execute the correct number of iterations.

Исправили глюк в оптимизации, вот код нормально стал генерироваться и как следствие стал больше.

[BOS 1]

....как следствие стал больше.

Уважаемый IceS, я что- непойму: это есть хорошо или это есть плохо ? ;)

 

Исправили глюк в оптимизации, вот код нормально стал генерироваться

 

А Вы думаете в Версии 4.21A у меня получился по Вашей логике "не нормальный" код ? А как же тогда устройство работает и успешно реализуется ?

 

Может это связано с:

 

А что тут думать и гадать - возьмите в обоих версиях включите галочку Linker -> List-> Generate linker listing и посмотрите какой код генерит одна и другая версия... Возможно у Вас еще появятся предположения и философские мысли по поводу того с какой ноги надо встать что бы IAR генерил правильный код ;)

 

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

 

В моем предыдущем посте я высказал сугубо мое субъективное мнение которое не является "словом в последней инстанции" - каждый волен выбирать сам что ему по душе и с чем ему работать.

[IgorKossak 0]

В моем предыдущем посте я высказал сугубо мое субъективное мнение которое не является "словом в последней инстанции" - каждый волен выбирать сам что ему по душе и с чем ему работать.

Ну и чего было так волноваться? Здесь не только Вы имеете право высказывать субьективное мнение.

А у IceS оно оказалось весьма правдоподобным.

 

Что касается работоспособности и продаваемости изделий, то неоднократно приходилось видеть и исправлять подобные программы, где глюк на глюке. Ибо под работоспособностью чаще понимается удовлетворительный результат, а далеко не всегда правильный. А о том, что зачастую "продают" я вообще молчу.