koljakh 0 11 августа, 2009 Опубликовано 11 августа, 2009 · Жалоба Добрый день, всем! Есть один вопрос. Сейчас занимаюсь оптимизацией кода под ATXMEGA128A1, и вот на что я наткнулся. Внешняя память у меня не подключена, все находится внутри. Следовательно регистры RAMPD,RAMPX,RAMPZ,RAMPY у меня всегда равны нулю. Но компилер упорно их все время обнуляет и в фоне, и в прерываниях. При этом для сохранения в прерываниях он использует обычные регистры, которые он перед этим сохраняет, а потом восстанавливает. Т.к. прерываний у меня дофига, хотелось как-то убрать лишние действия. Вопрос, кто-нить делал это? В стартапе я их обнулю, и дальше компилятор забывает об их существовании. У компилятора есть предопределенные символы __HAS_RAMPX__, ..., но отенить их #undef нельзя, к сожалению. Или на винавр переходить, как там дела с этим обстоят? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aesok 0 11 августа, 2009 Опубликовано 11 августа, 2009 · Жалоба сожалению. Или на винавр переходить, как там дела с этим обстоят? Точно также. Анатолий. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 11 августа, 2009 Опубликовано 11 августа, 2009 · Жалоба Но компилер упорно их все время обнуляет и в фоне, и в прерываниях. Более того, вывод в эти регистры он не оптимизирует совершенно. Ждем новых версий. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
koljakh 0 11 августа, 2009 Опубликовано 11 августа, 2009 · Жалоба Точно также. Анатолий. Спасибо, остается ИАР и АСМ, а жаль :( Более того, вывод в эти регистры он не оптимизирует совершенно. Ждем новых версий. Да уж, смотрю на дизассемблер и плачу :) Ща качну ДШ на более мелкие чипы, мож у них этих регистров вообще нет, там где нет возможности подключать внешнюю память. Если да, то может это решит проблему. Или у них у всех одинаковое ядро? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Xenia 45 11 августа, 2009 Опубликовано 11 августа, 2009 · Жалоба Ждем новых версий. Дык вышли давно такие версии: 5.20 и 5.30. Только последняя из них за прошлый месяц претерпела 4 патча. Последняя полная версия 5.30 со всеми своими 4-мя патчами лежит на FTP (upload/MCs/AVR/IAR-EWAVR-530-full/). Вот только исправлен ли там этот баг, я не знаю, т.к. с XMEGA дела не имела. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
koljakh 0 11 августа, 2009 Опубликовано 11 августа, 2009 · Жалоба Ядро одинаковое Дык вышли давно такие версии: 5.20 и 5.30. Только последняя из них за прошлый месяц претерпела 4 патча. Последняя полная версия 5.30 со всеми своими 4-мя патчами лежит на FTP (upload/MCs/AVR/IAR-EWAVR-530-full/). Вот только исправлен ли там этот баг, я не знаю, т.к. с XMEGA дела не имела. Спасибо, только у меня доступа к фтп нет :( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Xenia 45 11 августа, 2009 Опубликовано 11 августа, 2009 · Жалоба Ядро одинаковое Трудно сказать с уверенностью, т.к. в патче EWAVR-Patch-5.30.1.zip прислали экшенник iccavr.exe со всеми dll-библиотеками (голенькими, без инсталляции). Что там было изменено, без проверки судить нельзя. Спасибо, только у меня доступа к фтп нет :( Не страшно, я вам сейчас в личку линк брошу, где можно без доступа. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 11 августа, 2009 Опубликовано 11 августа, 2009 · Жалоба Вот только исправлен ли там этот баг, я не знаю, т.к. с XMEGA дела не имела. Это не баг, а недоделка. Не доделана. Но это не повод сильно материться. Только что глянул и придумал способ. Ставим в версии 5.30 тип проца ATxmega128A3, в ATxmega128A1.h патчим проверку модели #if TID_GUARD(6) //#error This file should only be compiled with iccavr or aavr whith processor option -v6 #endif /* TID_GUARD(6) */ И инклудим напрямик ioxm128a1.h, а не ioavr.h Результат: #include "ioxm128a1.h" #include "stdafx.h" #pragma optimize=no_inline __x_z void mcpy(UINT8 *d, UINT8 *s, UREG c) { do { *d++=*s++; } while(--c); } volatile UINT32 cnt; #pragma vector=PORTA_INT0_vect __interrupt void intproc(void) { cnt++; } int main( void ) { mcpy((UINT8*)1234,(UINT8*)5678,124); return 0; } 1 #include "ioxm128a1.h" 2 #include "stdafx.h" 3 4 #pragma optimize=no_inline \ In segment FARCODE, align 2, keep-with-next 5 __x_z void mcpy(UINT8 *d, UINT8 *s, UREG c) \ mcpy: \ ??mcpy_0: 6 { 7 do 8 { 9 *d++=*s++; \ 00000000 9111 LD R17, Z+ \ 00000002 931D ST X+, R17 10 } 11 while(--c); \ 00000004 950A DEC R16 \ 00000006 F7E1 BRNE ??mcpy_0 12 } \ 00000008 9508 RET 13 \ In segment NEAR_Z, align 1, keep-with-next \ 00000000 REQUIRE `?<Segment init: NEAR_Z>` 14 volatile UINT32 cnt; \ cnt: \ 00000000 DS8 4 15 16 #pragma vector=PORTA_INT0_vect \ In segment FARCODE, align 2, keep-with-next 17 __interrupt void intproc(void) \ intproc: 18 { \ 00000000 93FA ST -Y, R31 \ 00000002 93EA ST -Y, R30 \ 00000004 934A ST -Y, R20 \ 00000006 933A ST -Y, R19 \ 00000008 932A ST -Y, R18 \ 0000000A 931A ST -Y, R17 \ 0000000C 930A ST -Y, R16 \ 0000000E B74F IN R20, 0x3F 19 cnt++; \ 00000010 .... LDI R30, LOW(cnt) \ 00000012 .... LDI R31, (cnt) >> 8 \ 00000014 8100 LD R16, Z \ 00000016 8111 LDD R17, Z+1 \ 00000018 8122 LDD R18, Z+2 \ 0000001A 8133 LDD R19, Z+3 \ 0000001C 5F0F SUBI R16, 255 \ 0000001E 4F1F SBCI R17, 255 \ 00000020 4F2F SBCI R18, 255 \ 00000022 4F3F SBCI R19, 255 \ 00000024 8300 ST Z, R16 \ 00000026 8311 STD Z+1, R17 \ 00000028 8322 STD Z+2, R18 \ 0000002A 8333 STD Z+3, R19 20 } \ 0000002C BF4F OUT 0x3F, R20 \ 0000002E 9109 LD R16, Y+ \ 00000030 9119 LD R17, Y+ \ 00000032 9129 LD R18, Y+ \ 00000034 9139 LD R19, Y+ \ 00000036 9149 LD R20, Y+ \ 00000038 91E9 LD R30, Y+ \ 0000003A 91F9 LD R31, Y+ \ 0000003C 9518 RETI 21 \ In segment FARCODE, align 2, keep-with-next 22 int main( void ) \ main: 23 { \ 00000000 93BA ST -Y, R27 \ 00000002 93AA ST -Y, R26 24 mcpy((UINT8*)1234,(UINT8*)5678,124); \ 00000004 E70C LDI R16, 124 \ 00000006 E2EE LDI R30, LOW(5678) \ 00000008 E1F6 LDI R31, (5678) >> 8 \ 0000000A EDA2 LDI R26, LOW(1234) \ 0000000C E0B4 LDI R27, (1234) >> 8 \ 0000000E .... RCALL mcpy 25 return 0; \ 00000010 E000 LDI R16, 0 \ 00000012 E010 LDI R17, 0 \ 00000014 91A9 LD R26, Y+ \ 00000016 91B9 LD R27, Y+ \ 00000018 9508 RET 26 } \ In segment INTVEC, offset 0x108, root \ `??intproc??INTVEC 264`: \ 00000108 ........ JMP intproc Уже терпимо :) Дык вышли давно такие версии: 5.20 и 5.30. Я, кстати, имел в виду еще более новых. Я за обновлениями слежу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Xenia 45 11 августа, 2009 Опубликовано 11 августа, 2009 · Жалоба Я, кстати, имел в виду еще более новых. Я за обновлениями слежу. А какая версия еще новее, чем EWAVR-5.30 ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 11 августа, 2009 Опубликовано 11 августа, 2009 · Жалоба А какая версия еще новее, чем EWAVR-5.30 ? Ждем новых версий. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
koljakh 0 11 августа, 2009 Опубликовано 11 августа, 2009 · Жалоба Трудно сказать с уверенностью, т.к. в патче EWAVR-Patch-5.30.1.zip прислали экшенник iccavr.exe со всеми dll-библиотеками (голенькими, без инсталляции). Что там было изменено, без проверки судить нельзя. Не страшно, я вам сейчас в личку линк брошу, где можно без доступа. Огромное спасибо, буду качать Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 11 августа, 2009 Опубликовано 11 августа, 2009 · Жалоба Огромное спасибо, буду качать Можете не торопиться. Только что проверил, накатив патчи. Один хрен. Так что пока способ борьбы - это описанный мною выше. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
koljakh 0 11 августа, 2009 Опубликовано 11 августа, 2009 · Жалоба Это не баг, а недоделка. Не доделана. Но это не повод сильно материться. Только что глянул и придумал способ. Ставим в версии 5.30 тип проца ATxmega128A3, в ATxmega128A1.h патчим проверку модели #if TID_GUARD(6) //#error This file should only be compiled with iccavr or aavr whith processor option -v6 #endif /* TID_GUARD(6) */ И инклудим напрямик ioxm128a1.h, а не ioavr.h Результат: #include "ioxm128a1.h" #include "stdafx.h" #pragma optimize=no_inline __x_z void mcpy(UINT8 *d, UINT8 *s, UREG c) { do { *d++=*s++; } while(--c); } volatile UINT32 cnt; #pragma vector=PORTA_INT0_vect __interrupt void intproc(void) { cnt++; } int main( void ) { mcpy((UINT8*)1234,(UINT8*)5678,124); return 0; } 1 #include "ioxm128a1.h" 2 #include "stdafx.h" 3 4 #pragma optimize=no_inline \ In segment FARCODE, align 2, keep-with-next 5 __x_z void mcpy(UINT8 *d, UINT8 *s, UREG c) \ mcpy: \ ??mcpy_0: 6 { 7 do 8 { 9 *d++=*s++; \ 00000000 9111 LD R17, Z+ \ 00000002 931D ST X+, R17 10 } 11 while(--c); \ 00000004 950A DEC R16 \ 00000006 F7E1 BRNE ??mcpy_0 12 } \ 00000008 9508 RET 13 \ In segment NEAR_Z, align 1, keep-with-next \ 00000000 REQUIRE `?<Segment init: NEAR_Z>` 14 volatile UINT32 cnt; \ cnt: \ 00000000 DS8 4 15 16 #pragma vector=PORTA_INT0_vect \ In segment FARCODE, align 2, keep-with-next 17 __interrupt void intproc(void) \ intproc: 18 { \ 00000000 93FA ST -Y, R31 \ 00000002 93EA ST -Y, R30 \ 00000004 934A ST -Y, R20 \ 00000006 933A ST -Y, R19 \ 00000008 932A ST -Y, R18 \ 0000000A 931A ST -Y, R17 \ 0000000C 930A ST -Y, R16 \ 0000000E B74F IN R20, 0x3F 19 cnt++; \ 00000010 .... LDI R30, LOW(cnt) \ 00000012 .... LDI R31, (cnt) >> 8 \ 00000014 8100 LD R16, Z \ 00000016 8111 LDD R17, Z+1 \ 00000018 8122 LDD R18, Z+2 \ 0000001A 8133 LDD R19, Z+3 \ 0000001C 5F0F SUBI R16, 255 \ 0000001E 4F1F SBCI R17, 255 \ 00000020 4F2F SBCI R18, 255 \ 00000022 4F3F SBCI R19, 255 \ 00000024 8300 ST Z, R16 \ 00000026 8311 STD Z+1, R17 \ 00000028 8322 STD Z+2, R18 \ 0000002A 8333 STD Z+3, R19 20 } \ 0000002C BF4F OUT 0x3F, R20 \ 0000002E 9109 LD R16, Y+ \ 00000030 9119 LD R17, Y+ \ 00000032 9129 LD R18, Y+ \ 00000034 9139 LD R19, Y+ \ 00000036 9149 LD R20, Y+ \ 00000038 91E9 LD R30, Y+ \ 0000003A 91F9 LD R31, Y+ \ 0000003C 9518 RETI 21 \ In segment FARCODE, align 2, keep-with-next 22 int main( void ) \ main: 23 { \ 00000000 93BA ST -Y, R27 \ 00000002 93AA ST -Y, R26 24 mcpy((UINT8*)1234,(UINT8*)5678,124); \ 00000004 E70C LDI R16, 124 \ 00000006 E2EE LDI R30, LOW(5678) \ 00000008 E1F6 LDI R31, (5678) >> 8 \ 0000000A EDA2 LDI R26, LOW(1234) \ 0000000C E0B4 LDI R27, (1234) >> 8 \ 0000000E .... RCALL mcpy 25 return 0; \ 00000010 E000 LDI R16, 0 \ 00000012 E010 LDI R17, 0 \ 00000014 91A9 LD R26, Y+ \ 00000016 91B9 LD R27, Y+ \ 00000018 9508 RET 26 } \ In segment INTVEC, offset 0x108, root \ `??intproc??INTVEC 264`: \ 00000108 ........ JMP intproc Уже терпимо :) Я, кстати, имел в виду еще более новых. Я за обновлениями слежу. Спасибо, это уже другое дело. Люблю я напильником компиляторы шлифовать :) Можете не торопиться. Только что проверил, накатив патчи. Один хрен. Так что пока способ борьбы - это описанный мною выше. Ща попробую, получается что все-таки тип проца другой у младшего семейства, это радует :) А не скажите, где свойства проца находятся в каком-нить XML? Если добавить еще один файл, ну что-бы красиво было, типа ATXMEGA128A1_MY :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aesok 0 11 августа, 2009 Опубликовано 11 августа, 2009 · Жалоба Спасибо, это уже другое дело. Люблю я напильником компиляторы шлифовать :) Выкинте в корзину этот совет, вы получите нерабочий код, у mega и xmega разный порядок обращения к байтам в 16-битных SFR. Анатолий. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 11 августа, 2009 Опубликовано 11 августа, 2009 · Жалоба Выкинте в корзину этот совет, вы получите нерабочий код, у mega и xmega разный порядок обращения к байтам в 16-битных SFR. Да ну? Читать надо внимательнее: Ставим в версии 5.30 тип проца ATxmega128A3 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться