Контроллеры от ATmega8 до Atmega128, и т.д.

Есть такой массив:


Доступ к нему присходит вот так:


Все работает, более того мне даже нравится код который генерит при этом GCC,
НО, осадок остается

Собствено вопросы:

1. Есть ли в GCC другие варианты доступа к массиву PINx, без использования _SFR_IO8 ?

2. Насколько такой вариант портируем на более старые/новые реализации GCC AVR ?

3. 0x20 режет глаз, а что с этим делать ?

Во первых посмотрите в avr-libc-user-manual: FAQ - 7.3.13 "How do I pass an IO port as a parameter to a function?"

Масив я объявил так:
volatile uint8_t *ports[2] = {&PINB, &PIND};

Если не хотите инициализировать при объявении, то инициализируете так:
ports[0] = &PINB;
ports[1] = &PIND;

Доступ к порту:
uint8_t test;
test = *ports[0];

Ассемблерный код:


Вроде работает правильно, но перепроверьте.

Анатолий.

Ну это я посмотрел прежде чем задавать вопрос
Там про то как записать значение в порт.

Да, так оно работает правильно!
Cпасибо.
-----------------
НО,
На самом деле я конечно не очень точно задал свой вопрос.
Есть такой массив:


Доступ к нему присходит вот так:


Как правильно написать доступ в таком варианте ?

Я бы сделал чтото вроде этого:

1. Объявил структуру.
struct __port {
volatile uint8_t *port;
unsigned char pin;
};

2. Масив:
struct __port ports[3] = {
{&PINB, 1<<PINB5},
{&PINF, 1<<PINF2},
{&PING, 1<<PING1}
};

3. Доступ:
PIN_tmp=*(ports[0].port);
tmp=PIN_tmp & ports[0].pin;


Код я не тестировал, привожу только как идею!!!

Анатолий.

Сообщение отредактировал aesok - Nov 28 2006, 00:05

сделайте структуру


А обращаться можно, например, так:

НЕВЕРНО. pinr, port и ddr - ДОЛЖНЫ обязательно быть volatile!!!

В противном случае на высоких уровнях оптимизации компиллятор оптимизирует следующий код:
*pins[index].port = 0xAA;
*pins[index].port = 0x55;

Он выкинит первую запись в порт. Оставит только вторую. Для обычных переменых это правильная оптимизация, но доступ к портам оптимизироваться не должен.


Для 16-битных портов все намного страшнее - бутет неправильнай порядок обращения байтам.

Анатолий.

а должно ли PINx быть volatile ?

???

avr/iom128.h
...
/* Input Pins, Port D */
#define PIND _SFR_IO8(0x10)
...
/* Timer/Counter 3 Control Register C */
#define TCCR3C _SFR_MEM8(0x8C)
...

avr/port_def.h
....
#define _MMIO_BYTE(mem_addr) (*(volatile uint8_t *)(mem_addr))
#define _MMIO_WORD(mem_addr) (*(volatile uint16_t *)(mem_addr))
.....

...
#define _SFR_MEM8(mem_addr) _MMIO_BYTE(mem_addr)
#define _SFR_MEM16(mem_addr) _MMIO_WORD(mem_addr)
#define _SFR_IO8(io_addr) _MMIO_BYTE((io_addr) + 0x20)
#define _SFR_IO16(io_addr) _MMIO_WORD((io_addr) + 0x20)
.....


Как видете все SFR обявлены как volatile.

Анатолий.

чтение и запись(volatile переменных) - это две большие разницы

чтение и запись volatile и не volatile переменых ничем не отличаеться.

Модификатор volatile делает только одно - он указывае компилятору не при каких условиях и ни на каких уровнвх оптимизации не оптимизировать доступ к этой переменной!! Другими словами, везде где в тексте программы встречаеться запись или чтение из этой переменой отавлять их без изменения.

Пример:

int i;

i = 1;
i = 0;


Оптимизатор компилятора оптимизирует этот код и выкидывает первое присваивание переменной i (=1), потомучто это значение нигде не используеться и оставляет только второе i = 0.

А теперь представте что i это выходной порт и вам надо надо вывести вначале 1 затем 0. Вас устроит что компилятор удалит операцию вывода 1. НЕТ. Вот для этого и используеться volatile.

volatile int i;

i = 1;
i = 0;

Все теперь оба обращения к переменной i останутся в скомпилированом коде.


Те кто не понимают значение модификатора volatile обрекают себя на то что их программы работают только при выключеной оптимизации, а всех других на чтение топиков со словами "Глюкавый компилятор .....".

Анатолий.

PS: Если быть совсем точным то ассемблерный код для 16-битных volatile и не volatile переменных в AVR-GCC различаеться, но обьяснение этого выходит за рамки этого топика.

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

+ такое определение, как я указал выше, есть компромисс между удобством и универсальностью, с одной стороны, и произовдительностью, с другой. То есть, при разыменовывании указателей к регистрам доступ осуществляется с помощью обычных команд обращения к памяти (через общее адресное пространство), а не с помощью специальных команд для регистров ввода/вывода, что требует, если я не ошибаюсь, в два раза больше времени. Так что, работать с такими конструкциями надо осторожно, именно, в специально созданных для этого и проверенных (контролируемых на дизассемблере) функциях.

Зачем отключать оптимизацию для всей функции (или куска кода) если volatile только и предназначена для того чтобы отключить оптимизацию но только для одной переменной????

Анатолий.

Ещё более геморройное и непереносимое занятие, нежели использование стандартного средства vilatile.
С volatile как раз не нужно делать никаких преобразований типов (если написано грамотно), т. к. volatile вообще не относится к типам.

Такая структура занимает 3 байта.
Адрес порта <0x100, поэтому достаточно 2 байт.
Если массив будет большим, это серьезная экономия.

Вот еще вопросики появились:
почему
при компиляции выдает warning, а
не выдает ?

при компиляции этого кода получаем:

кто-нибудь может обьяснить зачем в lds используется r24
почему не так:

???

На первый вопрос отвечу сам себе

а потому что _SFR_MEM8(PIN_[0][0]+0) эквивалентно _SFR_MEM8((WORD)PIN_[0][0]) .

А вот со вопросом про LDS R24,... непонятно