Ещё раз о бутлоадере, Некоторые тонкости. Опции

[SasaVitebsk]

Задумка такая.

По старту попадаем в бут. Там считаем CRC и если Ok - выходим на саму приложение. Если не Ok то переходим на сам лодырь.

В приложении по команде переходим непосредственно на лоадырь.


То есть мне надо две точки входа. По сбросу и по команде. Хотелось бы использовать незадействованные вектора бутлоадера. Например +2. Как это сделать. Если использовать pragma location, то наверняка будет linker ругаться.

Конечно можно упростить задачу и использовать какой нибудь признак в EEPROM. Или портить CRC к примеру, но что-то мне не нравится такой подход.

А кто как делает?

[singlskv]

Т.е. IAR даже "алгоритм больше подхоящий для GCC" скомпилировал лучше . Но это "ни о чем не говорит" . Жаль

Опять вырывем фразу из контекста ?
В этом Вы несомненно мастер !!!
Хотите посоревноваться в оптимизации кода ?
или просто поболтать ?

[zltigo]

Опять вырывем фразу из контекста ?

Контекста? Контекста собственно и не наблюдается вообще никакого. Только совет использовать GNU по причине того, что aes.c и GNU якобы созданы друг для друга.

Хотите посоревноваться в оптимизации кода ?

Можете начинать, если хотите. Понаблюдаю. Объект aes.c есть. Цель - достичь минимального обьема кода - поставлена.

или просто поболтать ?

Вот как раз против болтовни и хотелось выступить.

[singlskv]

Контекста? Контекста собственно и не наблюдается вообще никакого. Только совет использовать GNU по причине того, что aes.c и GNU якобы созданы друг для друга.
Можете начинать, если хотите. Понаблюдаю. Объект aes.c есть. Цель - достичь минимального обьема кода - поставлена.

Дык понаблюдаю или поучаствую ???

Вот как раз против болтовни и хотелось выступить.

Те кто только наблюдают, и высказывают свое мнение в стиле,
"а IAR все равно круче", ИМХО, как раз и занимаются болтовней...


Готовы поучаствовать ?
Кажись Вы уже этот исходник уже используете ?
Скомпилируйте его для какой-нить меги и выложите сюда.
Я соптимизрую для Gcc и тоже выложу сюда.

[zltigo]

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

Легко. Тупо без затей взял из атмеловского AN

Код

aes.c
iccavr.exe D:\ARM_WORK\0\0BACKUP\loader.9\0\Source Code\IAR\aes.c --cpu=m128 -ms -o D:\ARM_WORK\0\0BACKUP\loader.9\0\Source Code\IAR\Release\Obj\  
--diag_suppress Pe1053 -y --initializers_in_flash -z9 --no_tbaa --cross_call_passes=1 -DENABLE_BIT_DEFINITIONS -e -I D:\IAR\Embedded Workbench\avr\INC\ -I D:\
IAR\Embedded Workbench\avr\INC\CLIB\ --eeprom_size 4096  

   IAR Atmel AVR C/C++ Compiler V4.30A/W32, Evaluation Version  
   Copyright 1996-2007 IAR Systems. All rights reserved.  
  
1 096 bytes of CODE memory (+ 7 bytes shared)
   522 bytes of DATA memory

Я соптимизрую для Gcc и тоже выложу сюда.

Нет уж, для начала оставте в неприкосновенности. Потом, можете хоть ручками на ASM переписывать

Прикрепленные файлы

 aes.rar ( 3.51 килобайт ) Кол-во скачиваний: 57

 

[singlskv]

Легко. Тупо без затей взял из атмеловского AN
Нет уж, для начала оставте в неприкосновенности. Потом, можете хоть ручками на ASM переписывать

Ок,
не обещаю что очень быстро выложу результаты(работать тоже иногда нужно )
а портировать просто на Gcc без изменения кода там тоже прилично...
для адекватного сравнения предлягаю добавить минимальную прогу которая будет вызывать
aesInit() и aesDecrypt() для какого-нить буфера.

[zltigo]

а портировать просто на Gcc без изменения кода там тоже прилично...

В aes.c ничего специфичного для какого-либо компилятора. Изменения в исходнике практически не нужны.
Откомпилируйте только его - 5 минут работы.
Примеры:

Код

wcc -omsn -d0 -s aes.c
Open Watcom C16 Optimizing Compiler Version 1.7
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
aes.c: 387 lines, included 124, 0 warnings, 0 errors
Code size: 1308

Код

iccarm.exe D:\ARM_WORK\LOADER\AES\aes.c -lC D:\ARM_WORK\LOADER\Works\List\ --remarks --diag_suppress Pe1422,Pe1375 -o D:\ARM_WORK\LOADER\
Works\Obj\ --endian little --cpu ARM7TDMI-S -e --require_prototypes --fpu None --dlib_config D:\ARM_WORK\LOADER\RESOURCE\dlib_cfg.h -I D:\ARM_WORK\
LOADER\AES\ -I D:\ARM_WORK\LOADER\FLASH\ -I D:\ARM_WORK\LOADER\..\common\INCLUDE\ -I D:\ARM_WORK\LOADER\ -I D:\IAR\Embedded Workbench 5\
ARM\INC\ --cpu_mode thumb -Ohz

   IAR ARM ANSI C/C++ Compiler V5.10.2.372/W32 EVALUATION
   Copyright 1999-2007 IAR Systems. All rights reserved.  
  
1 076 bytes of CODE  memory
    36 bytes of CONST memory
   532 bytes of DATA  memory

Сообщение отредактировал zltigo - Oct 18 2007, 07:38

[singlskv]

В aes.c ничего специфичного для какого-либо компилятора. Изменения в исходнике практически не нужны.
Откомпилируйте только его - 5 минут работы.
Пример:

Код

Open Watcom C16 Optimizing Compiler Version 1.7
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
aes.c: 387 lines, included 124, 0 warnings, 0 errors
Code size: 1429

Не, тока завтра смогу, там нужно __flash на PROGMEM менять аккуратненько....
сегодня я уже не в силах этим заниматься ...

[SasaVitebsk]

Ну если Вы так оптимизируете свой код, то в 2K точно будет сложно влезть...
По расчету CRC16 опять же гляньте как это реализовано в Gcc,
там есть встроенная функция тактов на 40 (по длинне правда с циклом не сравнивал, меня
скорость обычно больше волнует).

Уважаемый. Бут оптимизируется по коду. В программе встречается 1 вызов п/п чтения EEPROM и 1 вызов записи. Библиотеки на Яре написаны на Асме. Я их смотрел, и честно говоря в 5 операторах ассемблера не нашёл ничего из ряда вон. Да и был бы очень удивлён если бы нашёл. Так ответьте мне причём здесь применение данных п/п к оптимизации. Совершенно очевидно что на этих двух вызовах можно сэкономить ну от силы пару байтов. Речь вначале шла о сотне!

То же касается и CRC16. Я не спрашивал как её написать оптимально. Я не думаю, что написанное мной на ассемблере будет хуже вашего. Во всяком случае значительно. Я просто интересовался как именно IAR генерит CRC. Я переписал на АСМ весь свой WAKE протокол и думаю всётаки влезть в 2к. Переписал потому, что всё это реализовано по прерываниям и логически вообще не связано с самим бутом.

Подытоживая всё выше сказанное, хочется чтобы вы более конкретно обдумывали свои посты.
==========================================

Теперь по существу вопроса. Пишу это, так как только на этой странице уже поднимался вопрос по генерации CRC IARом. И думаю люди будут как и я пытаться его использовать. Для тех кто интересуется сообщаю следующее.

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

Решил написать программу, которая будет считать CRC и вставлять её в нужное место прямо в HEX файле. Постораюсь написать её максимально универсально, причесать и выложить на форуме AVR для использования желающими.

Ещё один момент - прога CREATE из набора идущего к AES. В ней есть хомут. При размещении данных (CRC) в последних двух ячейках секции пользователя CREATE начинает кричать оверлапинг. При размещении CRC на две ячейки меньше, выполняет операцию, но в прошивке вы получите дополнительно два байта мусора. Исходники там приведены, но я не стал разбираться, так как всё равно не чем её откомпилить. В принципе это не страшно, просто поясняю для того, кто пойдёт по моим стопам.

У меня - всё работает. Спасибо всем тем кто принял участие в обсуждении. Особенное спасибо Сергей Борщ за, просто неоценимую, конкретную помощь знающего человека.

Тему не закрываю, возможно ещё что возникнет.
Влезу или не влезу, для любопытных - напишу позже. .

[Сергей Борщ]

так как всё равно не чем её откомпилить.

Dev C++В комплекте исходников идут и файлы проекта под этот компилятор.

Ещё один момент - прога CREATE из набора идущего к AES. В ней есть хомут. При размещении данных (CRC) в последних двух ячейках секции пользователя CREATE начинает кричать оверлапинг. При размещении CRC на две ячейки меньше, выполняет операцию, но в прошивке вы получите дополнительно два байта мусора.

Естественно, потому что CREATE сама считает CRC (по полиному 0x8005) и располагает его в последних двух байтах секции приложения. Поэтому меня несколько ввело в замешательство ваше желание считать CRC при помощи линкера. При этом CREATE кoрректо считает все свободные ячейки заполненными 0xFFFF, в то время как линкер считает, что все свободные места между сегментами заполнены нулями.

[zltigo]

Наверное есть опция какая-то, но я не разобрался.

Естественно CRC вполне управляемо.

Решил написать программу, которая будет....

Сергей тоже пошел по такому пути не желая разбиратся с линкером. Я пользую линкер.

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

Исходники страшноваты, но GCC компилит. Я из них многое выкинул и дополнил.

[singlskv]

To zltigo и SasaVitebsk,
признаю, погорячился насчет перевода всего бутлодера под Gcc и cравнения с IAR.
Просто после более подробного изучения кода стало понятно что его нужно переписывать
с нуля, а это займет прилично времени...

Речь вначале шла о сотне!

Ну а чтобы было понятно о чем была речь приведу небольшой пример по оптимизации этого кода:
Было:

Код

void InvMixColumn( byte * column )
{
    byte r0, r1, r2, r3;

    r0 = column[1] ^ column[2] ^ column[3];
    r1 = column[0] ^ column[2] ^ column[3];
    r2 = column[0] ^ column[1] ^ column[3];
    r3 = column[0] ^ column[1] ^ column[2];

    column[0] = (column[0] << 1) ^ (column[0] & 0x80 ? BPOLY : 0);
    column[1] = (column[1] << 1) ^ (column[1] & 0x80 ? BPOLY : 0);
       column[2] = (column[2] << 1) ^ (column[2] & 0x80 ? BPOLY : 0);
       column[3] = (column[3] << 1) ^ (column[3] & 0x80 ? BPOLY : 0);

    r0 ^= column[0] ^ column[1];
    r1 ^= column[1] ^ column[2];
    r2 ^= column[2] ^ column[3];
    r3 ^= column[0] ^ column[3];

       column[0] = (column[0] << 1) ^ (column[0] & 0x80 ? BPOLY : 0);
       column[1] = (column[1] << 1) ^ (column[1] & 0x80 ? BPOLY : 0);
       column[2] = (column[2] << 1) ^ (column[2] & 0x80 ? BPOLY : 0);
       column[3] = (column[3] << 1) ^ (column[3] & 0x80 ? BPOLY : 0);

    r0 ^= column[0] ^ column[2];
    r1 ^= column[1] ^ column[3];
    r2 ^= column[0] ^ column[2];
    r3 ^= column[1] ^ column[3];

       column[0] = (column[0] << 1) ^ (column[0] & 0x80 ? BPOLY : 0);
       column[1] = (column[1] << 1) ^ (column[1] & 0x80 ? BPOLY : 0);
       column[2] = (column[2] << 1) ^ (column[2] & 0x80 ? BPOLY : 0);
       column[3] = (column[3] << 1) ^ (column[3] & 0x80 ? BPOLY : 0);

    column[0] ^= column[1] ^ column[2] ^ column[3];
    r0 ^= column[0];
    r1 ^= column[0];
    r2 ^= column[0];
    r3 ^= column[0];

    column[0] = r0;
    column[1] = r1;
    column[2] = r2;
    column[3] = r3;
}

Стало:

Код

void InvMixColumn( byte * column )
{
    byte r0, r1, r2, r3;
    byte co0 = column[0],co1=column[1],co2=column[2],co3=column[3];
    byte bpoly = BPOLY;

    r0 = co1 ^ co2 ^ co3;
    r1 = co0 ^ co2 ^ co3;
    r2 = co0 ^ co1 ^ co3;
    r3 = co0 ^ co1 ^ co2;

    co0 = (co0 << 1) ^ (co0 & 0x80 ? bpoly : 0);
    co1 = (co1 << 1) ^ (co1 & 0x80 ? bpoly : 0);
       co2 = (co2 << 1) ^ (co2 & 0x80 ? bpoly : 0);
       co3 = (co3 << 1) ^ (co3 & 0x80 ? bpoly : 0);

    r0 ^= co0 ^ co1;
    r1 ^= co1 ^ co2;
    r2 ^= co2 ^ co3;
    r3 ^= co0 ^ co3;

       co0 = (co0 << 1) ^ (co0 & 0x80 ? bpoly : 0);
       co1 = (co1 << 1) ^ (co1 & 0x80 ? bpoly : 0);
       co2 = (co2 << 1) ^ (co2 & 0x80 ? bpoly : 0);
       co3 = (co3 << 1) ^ (co3 & 0x80 ? bpoly : 0);

    r0 ^= co0 ^ co2;
    r1 ^= co1 ^ co3;
    r2 ^= co0 ^ co2;
    r3 ^= co1 ^ co3;

       co0 = (co0 << 1) ^ (co0 & 0x80 ? bpoly : 0);
       co1 = (co1 << 1) ^ (co1 & 0x80 ? bpoly : 0);
       co2 = (co2 << 1) ^ (co2 & 0x80 ? bpoly : 0);
       co3 = (co3 << 1) ^ (co3 & 0x80 ? bpoly : 0);

    co0 ^= co1 ^ co2 ^ co3;
    r0 ^= co0;
    r1 ^= co0;
    r2 ^= co0;
    r3 ^= co0;

    column[0] = r0;
    column[1] = r1;
    column[2] = r2;
    column[3] = r3;
}

Это примерно 120байтов экономии только на одной функции

Спросите причем сдесь GCC ?
Ну если спросите, тогда и отвечу...

[zltigo]

Спросите причем сдесь GCC ?

Не спрошу, по тому, что он ни причем. Введение для данного куска @&$^*% и достаточно обширного кода явных промежуточных локальных (для AVR регистровых) переменных достаточно благотворно скажется на любом компиляторе. А вот степень благотворности уже зависит от врожденных способностей компилятора к оптимизации и платформы. Для ARM платформы эффект будет много меньше, зато замена многочисленных byte заточенных под 8-bit платфору на естественные int (или, что много более правильно uint_least8_t ) скажется потрясающе благотворно. Зато то-же действие для x86 платформы будет по барабану.

[Непомнящий Евген...]

Ну а чтобы было понятно о чем была речь приведу небольшой пример по оптимизации этого кода:
Было: ...
Стало: ...
Это примерно 120байтов экономии только на одной функции

Ради прикола взял два этих куска и откомпилил. То что было, переименовал в InvMixColumn2.
На IAR AVR с максимальной оптимизацией по скорости получил:
InvMixColumn2(unsigned char *) 320
InvMixColumn(unsigned char *) 332

Т.е., на 12 лишних байт вы соптимизировали

Мораль сей басни - оптимизировать низкоуровневые вещи должен компилятор, ему то в 95% случаев надо эту оптимизацию и доверить...

Прикрепленные файлы

 test.txt ( 24.39 килобайт ) Кол-во скачиваний: 157

 

[zltigo]

На IAR AVR с максимальной оптимизацией по скорости получил:

Попробуйте по размеру, думаю эффект будет побольше, даже для IAR.

Мораль сей басни - оптимизировать низкоуровневые вещи должен компилятор, ему то в 95% случаев надо эту оптимизацию и доверить...

Не совcем так - при этом надо ему явно НЕ мешать, что встречается очень часто, особенно при портировании.

[Непомнящий Евген...]

Если максимальная оптимизация по размеру, то первый вариант весит 312 байт, второй - 192.
Тут действительно вылезают обещанные singlskv 120 байт.