[an error occurred while processing this directive]
IAR-C for PIC16: Глава 1. Первые впечатления и проблемы несовместимости с HT-PICC
(«Телесистемы»: Конференция «Микроконтроллеры и их применение»)

миниатюрный аудио-видеорекордер mAVR

Отправлено Baser 29 октября 2002 г. 11:47


Первое, что бросилось в глаза - наличие поддержки всех PIC16, даже ещё недоступных!

Попробовал откомпилировать проект на PIC16F877, написанный под HT-PICC.
Сразу столкнулся с несовместимостью расширений Си разных компиляторов.
Сходу компилер выдал около 800 ошибок. Начал продираться.

Все ключевые слова HT-PICC в IAR-е другие или слегка другие:

1. persistent - для расположения переменных в неинициализирующиеся области ОЗУ.
Заменил на __no_init __bankN, хотя не уверен, что это равнозначно, по крайней
мере компилер больше не ругается. Возможно в дальнейшем придется в ручную
редактировать линковочный файл для создания своих сегментов. Это неудобно,
но нужно сказать, что у IAR-а значительно богаче возможности и выбор ключевых
слов для размещения переменных и констант в памяти.

2. Управление банками аналогичное, нужно только добавить подчеркивания: __bankN

3. Расположение слова __interrupt в начале декларации функции, а не в середине.

Количество ошибок уменьшилось до 350 штук.

4. тип данных bit - для автоматического выделения бита и возможности функции
возвращать bit (функция типа: bit Function(char Parameter); )
Тип данных bit IAR не поддерживает, зато обнаружилось другое полезное расширение
Си, которое решает эту проблему:
"Anonymous structs and unions (similar to the C++ anonymous unions) are allowed.
An anonymous structure type defines an unnamed object (and not a type) whose
member names are promoted to the surrounding scope. The member names must be
unique in the surrounding scope. External anonymous structure types are allowed."

Заменил:

bit Flag1;
...
bit FlagN;

на:

struct {
unsigned Flag1 :1;
...
unsigned FlagN :1;
};

При этом к элементам структуры можно обращаться напрямую по их имени.

5. Догадался подключить IAR-овский header.file
Вместо #include pic.h => #include io16f877.h
Число ошибок снизилось до 145-и.

6. Следующая засада: IAR не понимает бинарные константы типа 0b01110010
Переделываю все на 0x72 и получаю 83 ошибки.

7. Переделываю имена INTRINSIC FUNCTIONS и несовпадающих имен SFR-ов и битов:
__CONFIG => __set_configuration_word + все названия другие + функция не может
лежать "в чистом поле" как допускает HT-PICC, а должна удовлетворять требованиям
Си, т.е. находится внутри блока (например в начале функции main).
#define NOP() __no_operation()
#define di() __disable_interrupt()
#define ei() __enable_interrupt()
#define SLEEP() __sleep()
#define CLRWDT() __clear_watchdog_timer()

8. Компилятор ругается на порядок расположения идентификаторов в функциях.
Такой вид, понятный HT-PICC, ему не нравится:
__bank1 unsigned int *PackingTIME(__bank1 unsigned int *tmp_ptr,char code)
Требует перестановки. Вот такой вариант проходит:
unsigned int __bank1 *PackingTIME(unsigned int __bank1 *tmp_ptr,char code)

9. Очередная проблема больше похожа на ошибку в компиляторе:
Он утверждает, что для расположения переменных во втором банке памяти не хватает
места (хотя там переменных точно на 96 байт). Проверяю конфигурационные файлы
компилятора и линковщика: 16f877.i39, I16f877.xcl - все нормально.
Ставлю опцию: Project\Options\ICCPIC\Diagnostics\Treat this as warnings - Pic028
Компиляция проходит с warning-ом вместо error-а, генерится .map файл.
Проверяю расположение переменных - всё нормально, точно ошибка в компиляторе!

10. Выяснилось, что следующую достаточно стандартную конструкцию компилятор
переварить не в состоянии (работа с 2-ым байтом unsigned long Var_Addr):
(char)(*((char*)&Var_Addr + 2)) = 0;
понимает только:
*((char*)&Var_Addr + 2) = 0;
но при этом согласно стандарту применяет косвенную адресацию с массой оверхеда
и библиотечной функцией.

Заменяем на union, это компилятор понял хорошо:
union Char4un { float F;
unsigned long L;
unsigned int I[2];
unsigned char C[4]; };
union Char4un Var_Addr;
Var_Addr.C[2] = 0; // непосредственная адресация, ничего лишнего

11. Ну и напоследок ещё одно славненькое свойство. Оказалось, что пакет от IAR-а
не умеет сам дробить большие файлы с функциями на маленькие объектные модули по
несколько функций и линковщик начинает то-ли ругаться, то-ли слезно просить
разбить файл на куски, т.к. он не может разместить все функции из файла одним
непрерывным куском!
Мне уже порядком надоело со всем этим бороться и я изменил в I16f877.xcl макси-
мальный размер памяти на 7fff - 16 кСлов.

Наконец-то!!! Прошла полная сборка проекта! Куча оставшихся warnings-ов не в счет.
Проект на PIC16F877 (много целочисленной математики с unsigned long, int, char)
Вот результаты:
HT-PICC v7.87 PL2 - 6553 bytes flash, 281 bytes SRAM, 11 секунд сборки проекта;
IAR-C v2.21A - 8894 bytes flash, 274 bytes SRAM, 30 секунд сборки проекта;

Оба компилятора в режиме максимальной оптимизации.

p.s. Пока всё. Смотреть, что там наворотил IAR с кодом буду в другой раз, надо
работать. 35% увеличение размера кода у IAR-а можно отчасти отнести на то, что
исходный текст на Си был написан с сильной оглядкой на "способности" HT-PICC.
Во многих местах применялись некрасиво выглядевшие, не сильно наглядные конструкции,
дававшие однако очень компактный код.

Продолжение, надеюсь, следует...

Составить ответ  |||  Конференция  |||  Архив

Ответы



Перейти к списку ответов  |||  Конференция  |||  Архив  |||  Главная страница  |||  Содержание  |||  Без кадра

E-mail: info@telesys.ru