jan

Я так понимаю, он не анализировал код, а просто присваивал какие-то значения и, в лучшем случае, в симуляторе смотрел результат.

Ну что, IAR ответил :smile3046: . Следует отметить, что достаточно быстро. Правда пришлось два письма посылать. В первом, или я плохо объяснил, или он не напрягся, что бы понять. Но на второе, более подробное, ответ пришел через час и представлен Вашему вниманию. Итак, кому дороги время и репутация, 5.4 в топку. Если пришлют патчи, то выложу. А пока ждем 5.5.

Может лучше записать не CRP3, а какое-нить левое, но похожее число. Тогда можно будет через ISP проверить что слетело, если прога не запустится. При перезаписи имеет смысл предвариельно стирать сектор. Так как перезапись в уже записанную память не всегда правильно работает.

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

Фундаментальный подход. Внушает. Убедился - не в моих руках дело. Сношу 5.4 и жду 5.5. Спасибо всем, кто откликнулся. KRS - персональное "БОЛЬШОЕ СПАСИБО". Мне кажется, это серьезная проблема для IAR. Странно, если они о ней ещё не знают. После скачивания Evalution на мыло пришло какое-то сообщение от IAR, можно в ответ послать им письмо с примерами от KRS (если KRS не возражает). Удачи всем.

Доброго времени суток. Посмотрел в старой копии, что генерировал 5.3. В R3 находится значение kc. \ 0000012A 83EA1342 EOR R2,R3,R3, LSR #+16 \ 0000012E 92B2 UXTH R2,R2 \ 00000130 002A CMP R2,#+0 \ 00000132 54D1 BNE.N ??__int_display_3 Немного длиннее, но, главное, все корректно. Следовательно в 5.4 "улучшили" чего-то. Учитывая, что у меня trial, писать в IAR бесполезно, а с моим знанием английского ещё и безсмысленно. Так что, любители новых версий IAR будьте осторожны - не выбрасывайте 5.3. Удачи!

Привет всем! Неожиданно проявилась проблема с IAR. После перехода на версию 5.4 Full девайс на LPC1766 стал глючить. Оптимизация - High/Balanced. Анализ выявил следующее. Заглючила строка сравнивающая старшее и младшее слово INT32U kc=key_code; // key_code тоже INT32U if(!(0xFFFF&(kc^(kc>>16)))) {...} Компилятор породил следущий код \ 0000013C 080C LSRS R0,R1,#+16 // в R1 находится kc \ 0000013E 91EA000F TEQ R1,R0 \ 00000142 4DD1 BNE.N ??__int_display_2 Очевидно, что 0xFFFF проигнорирован напрочь. Простая перестановка его в конец ничего не изменила. Однако, после некоторых манипуляций, конструкция была изменена на if((0xFFFF&kc)==(kc>>16)){...} Что породило уже рабочую последовательность \ 0000013C 88B2 UXTH R0,R1 // в R1 находится kc \ 0000013E B0EB114F CMP R0,R1, LSR #+16 \ 00000142 4DD1 BNE.N ??__int_display_2 Я, конечно, понимаю, что в IAR люди работают и ничего человеческое им не чуждо. Посмотрел на сайте и скачал Evalution версии 5.41, однако ничего не изменилось!!!! На мой взгляд, оба варианта сравнения идентичны по сути. Может быть первоначальный вариант и не столь очевиден, НО компилятора это не должно касаться. Такого рода конструкций в проге куча. Что же теперь, всё перепроверять на понятность и адекватность компилятора? Печально, но я IARу раньше доверял как родному. Суть вопроса - версию 5.4 в топку или я чего-то не не понимаю? Заранее благодарен.

За книжечку - спасибо. А проблема, что во 2-ом, что в 3-ем, следующая. Касается встроенного симулятора. Если основной файл содержит следующее: //------------------------------------------------------- #include "func_def.c" void main(void) {char i=1; do{ i = func( i ); } while( i ); } //----------------------------------------------- а файл func_def.c char func(char b ) { b<<=1; if( b )return b;else return 1; } //----------------------------------------------- то при проходе в симуляторе он никогда не входит в файл func_def.c и в дизассемблерном окне в качестве комментария к коду показывает строки из основного файла которые к этому коду отношения не имеют искал как это пофиксить, но увы. Сейчас приходится func_def.c вместо #include включать в проект, а функцию объявлять как extern в основном файле. Тогда отладчике все Ок, НО перед вызовом таких функций компилятор запихивает все переменные из регистров в память и вся регистровая оптимизация накрывается, так как на этапе компиляции неизвестно какие регистры портит функция, а портить она имеет право все регистры включая DPTR. Если писать все в одном файле, то в отладчике все хорошо и оптимизация работает, но получается такая помойка, что лучше пожертвовать оптимизацией. Вот такие, блин, непонятные проблемы. :blink: Глупость какая-то. В ИАРе с таким не сталкивался.

Н-да. Ответов обилие. :( Пришлось писать все в отдельных файлах и раздельно подключать к проекту. Сразу обнаружилась куча минусов. Если вызываетя функция и текущего файла, то сохраняются только регистры которые эта фунция использует. А если такая же из другого, то сохраняются все регистровые переменные. Поэтому оптимизация имеет печальный вид. Если бы не глючность IAR C51, то снес бы на фиг. :angry2: Вообще непонятно. Такие классные компиляторы IAR для AVR и ARM и такой отстой для C51.

Есть вопрос к знатокам uVision (8.05). При отладке проги в Кейловском симуляторе, он упорно игнорирует включенные файлы. То есть при переходе на функцию описанную во включенном файле, в окне дизассемблера вместе с правильным ассемблерным кодом отображаются соответствующие по номеру строки из главного файла. Облазил весь uVision, но ничего не нашел. В ИАРе таких проблем не было.