Как портабельно получить DDRx через PORTx?, Или игры с SFR-ами на IAR Опции

[osnwt]

При портировании AVR-USB драйвера с GCC на IAR вылезла небольшая проблема с точки зрения эффективности кода. Автор оригинала использует следующие конструкции, которые нормально проходят в GCC:

Код

#define USB_CFG_IOPORT          PORTD
...
#define USBIN       (*(&USB_CFG_IOPORT - 2))    /* input port for USB bits */
#define USBDDR      (*(&USB_CFG_IOPORT - 1))    /* data direction for USB bits */

Под IAR это все транслируется, но превращается вот в такой вот кошмар:

Код

// USBDDR |= 0x10;
// USB_CFG_IOPORT |= 0x10;
        IN R16, 0x11
        ORI R16, 0x10
        OUT 0x11, R16

        SBI 0x12, 0x04

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

Перепробовал несколько идей - не помогло. Изменить определение самого порта с PORTx на просто x с последующей конкатенацией префиксов с именем порта не подходит, так как автор ориентируется в первую очередь на GCC и едва ли согласится радикально менять код, конфигурируемый пользователем.

Для себя-то я могу выйти из положения. Но работая совместно с Кристианом над официальным портом для IAR, хотелось предложить что-то более-менее портабельное без ухода от выбранного им способа определения портов.

Нет у кого идей? Подходит вариант с условной компиляцией (то есть, для именно IAR можно использовать тут __io и тому подобные специфические конструкции). Важно лишь, чтобы раскрывались они в конечном итоге в SBI, а не чтение-модификацию-запись покомандно.

[andrvisht]

Нет у кого идей? Подходит вариант с условной компиляцией (то есть, для именно IAR можно использовать тут __io и тому подобные специфические конструкции). Важно лишь, чтобы раскрывались они в конечном итоге в SBI, а не чтение-модификацию-запись покомандно.

Идея впринципе одна, ASM.
Причина такого кода заключена в том что сам порт обьявлен как __io а это означает что порт обьявляется как volatile
Сделано это для того чтобы при оптимизации его (порт) не выкинули. А поскольку он может измениться неведомо компилятору то он его перед изменением и вычитывает. Вот такая вот причина....
А для того чтобы было SBI CBI используй
PORTD_Bit0 = 1; // SBI
PORTD_Bit0 = 0; // CBI
и вкл Enable Bit Difinitions в Genera/ System

[osnwt]

Идея впринципе одна, ASM.

Идеи не понял - при чем тут ASM?

Причина такого кода заключена в том что сам порт обьявлен как __io а это означает что порт обьявляется как volatile

Осмелюсь напомнить, что и PORTD объявлен точно также.

А поскольку он может измениться неведомо компилятору то он его перед изменением и вычитывает.

Рассуждения понятны, но это не из той оперы. Самое оптимальное для изменения порта - как раз использовать sbi, выполняющую все аппаратно. Я же не использую больше прочитанное значение.

А для того чтобы было SBI CBI используй
PORTD_Bit0 = 1; // SBI
PORTD_Bit0 = 0; // CBI
и вкл Enable Bit Difinitions в Genera/ System

За подсказку спасибо, но я про эти особенности IAR знаю. Однако выше я писал, что "для себя-то я могу выйти из положения." и т.п. Вопрос в том, есть ли более-менее портабельный вариант. Предложенная конструкция с PORT_Bit, к сожалению, к таковым не относится.

Тем более, что для заданного вопроса эта конструкция неприменима в принципе. Я ведь спрашивал не про замену (PORTD |= 0x10) - это как раз транслируется оптимально в sbi без всяких PORTD_Bit4 = 1 (IAR достаточно разумен для такой оптимизации). А про замену для (*(&PORTD-1) |= 0x10) как эквивалента (DDRD |= 0x10). Это к вопросу об исходной постановке задачи .

(Расшифровка: PORTD для IAR - это переменная с модификатором __io, находящаяся по фиксированному адресу (порта), являющемуся тем самым адресом этой переменной. Операция получения адреса &PORTD дает нам этот самый адрес. Вычитая из него единицу, получаем адрес DDRD. А далее используем *(адрес DDRD) для работы, собственно, с самим значением. Все формально правильно, но IAR не воспринимает полученное значение как константное выражение адреса __io порта. Добавление всяких модификаторов типа const или __io с разными приведениями типа мне не помогло. Возможно, я не всё попробовал. В этом и состоял исходный вопрос, а не в том, как избавиться от чтения-модификации-записи - где IAR считает нужным, он это делает и сам. А вот как ему помочь в данном случае?).

PS. Почему-то, когда задаются банальные вопросы типа "как объявить переменную по фиксированному адресу", сразу же следует море правильных и не очень ответов. Стоит спросить что-то менее тривиальное - и полная тишина. Почти полная, в данном случае, так как одна попытка ответить все же была (хоть и не на тот вопрос) .

PPS. Не считая мелких нюансов, связанных с оптимизацией C-кода под gcc-avr, и не столь эффективную компиляцию под IAR, официальный порт avr-usb для IAR, можно сказать, уже готов. Еще пара мелких штришков по документации, и он может появиться на официальной странице проекта.

Сообщение отредактировал osnwt - Mar 3 2006, 12:07

[andrvisht]

Идеи не понял - при чем тут ASM?

Возможно я не совсем понял вопроса.
Попробую изложить как я понял ...
конструкция типа

Код

(PORTD |= 0x10)

- это транслируется оптимально
А

Код

(*(&PORTD-1) |= 0x10)

как эквивалента

Код

(DDRD |= 0x10)

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

Код

(PORTD |= 0x30)

то это уже разложится на

Код

    000096   B302             IN      R16,PORTD
    000098   6300             ORI     R16,0x30
    00009A   BB02             OUT     PORTD,R16

когда (&PORTD-1) то он знает лишь то что PORTD у нас __io (volatile) и более ничего, поэтому поступает с ним соответственно.
собственно поэтому я и предложил решать это ASM вставкой, хотя я тоже не в восторге от такого подхода
хотя если мотреть на то что он знает что мы обращаемся к DDRD

Код

  *(&PORTD - 1) |= 0x10;
    00009C   B301             IN      R16,DDRD
    00009E   6100             ORI     R16,0x10
    0000A0   BB01             OUT     DDRD,R16

согласен что компилятор мог бы и подумать (((