Задаю благозвучное название прерывания
#define PacketReceiveComplete INT5_vect

Объявлена глобальная переменная, значение которой
uint64t_t DestMAC;

Обработчик прерывания, функция getDestMAC записывает в переменную DestMAC нужные данные
ISR(PacketReceiveComplete){
cli();
getDestMAC(&DestMAC);
sei();
}
int main(void){
...
printf("%lx",DestMAC);
}
Это не работает, печатает мусор,причем попытки изменить DestMAC main тоже неудачны, она не меняется. Что я делаю не так?

ps. мое личное IMHO, использование int такого размера на 8-мибитнике для хранения MAC адреса - не лучшая идея.

Попробуйте так

int main(void){
uint64t_t temp;
...
cli();
temp= DestMAC;
sei();
printf("%lx",temp);
}

volatile забыли. Иначе оптимизатор может выкинуть чтение перед выдачей.

Непонятно зачем cli в прерывании. Хотя смотря как вы вектор объявляли.

Так тоже не работает, если при попытке отправить в порт DestMAC выводится мусор, то как присвоив мусор другой переменной от него избавиться? Где и как нужно объявлять глобальные переменные, чтобы они были доступны всем подпрограммам?

avr-libc-user-manual FAQ#1



Уточните в avr-libc-user-manual поддерживает ли printf 64-битные типы.



Нельзя разрешать прерывания перед выходом из прерывания, они сами разрештся при выполнении инструкции RETI.

Анатолий.

Вы уверены, что функция printf выполняется после того, как в DestMAC будет что-то положено?

Ну cli это я от незнания поставил, первый раз с прерываниями работаю в этом компиляторе, до этого на асме только использовал. Я правильно понял, что компилятор сам поставит cli/sei? А volatile что-то тоже не помог. Может есть у кого пример, в котором по внешнему прерыванию изменяется какая-нибудь переменная, которая потом выводится в main?

Переменная DestMAC занимает 8 байт. Чтобы 8-мибитному контроллеру переложить её значение из одной области памяти в другую (например, в стек при выполнении printf("%lx",DestMAC)) потребуется минимум 16 команд. Если при их выполнении произайдёт прерывание и изменится значение DestMAC, то получите значение: часть байтов - новые, часть - старые, т.е. что-то похожее на "мусор".

Спасибо за ответ. Действительно принтф не поддерживает 64 бит.

Можно конечно. Не запрещено.

1) А просто printf у вас работает, если не использовать обработчиков прерываний по приему, по окончании передачи, по свободному регистру UDRn?

Принтф работает, выводит все как положено, если 64 битные данные не кормить.

Ну так может тогда вместо uint64 сделать char[8] и кормить как строку символов?

Не, погорячился. Тогда точно мусор будет.

Никто не мешает разбить 64 бита на несколько ulong, uint или даже uchar (например, через union) и в printf использовать уже их. Тем более, что автору нужно шестнадцатиричное значение (не забыть, только, что выводить нужно с лидирующими нулями - поставить в формате соответствующие числа).

В каком виде надо MAC-адрес выводить? В зависимости от задачи и решение.
Можно сделать массив на 6 байт и в него записывать побайтно соответствующие значения и при необходимости побайтно выводить.

Есть проблемы с глобальной переменной: во время работы printf (функция очень медленная при выводе в порт) произошло прерывание и данные поменялись. Что выводим?

Необходимо задать значения по умолчанию (прерывания не было, а printf наступил).

P.S. Палыч чуть опередил.

Studert, а разве приведенный мною код у Вас не работает ?

1. Лишняя инструкция SEI, прерывания все равно будут разрешенны при выполнении инструкции RETI.

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

3. Специфично для GCC. Если функции нужно место в стеке, то нужно модифицировать регистр указателя стека. Пролог и эпилог обработчика прерывиня генерируеться из предположения что прерывания отключены и в них не выполняеться временное отключение прерываний при модификации указателя стека. Разрешая прерывания до эпилога возникают условия что обработчик прерывания может быть вызван когда указатель стека модифицирован только частично (старший байт уже изменен младший еще нет), что может привести к критическим последствиям.

Анатолй.

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

Иногда просто необходимо разрешать прерывания внутри обработчика прерывания.
Выход видится такой:

Может есть другие, более изящные варианты?
Где в документации можно прочесть об этом нюансе?

Это будет работать до того момента, пока кто нибудь не напишет:
{
sei()
...
if(...)
return;
...
cli()
}



http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gc...tion-Attributes

Если компилятор ничего не будет предполагать, он будет связан по рукам при оптимизации.
А прерогатива програмиста - управлять его предположениями.
Предполагает же он, что переменная не меняется, пока он сам её не поменяет? Предполагает. Пока программиcт не отобъёт эту предполагалку при помощи слова volatile.
С прерываниями - если нужно, чтобы данное прерывание всё выполнялось при разрешённых прерываниях, то
и прерывания будут разрешены первой командой обработчика, потом будут если надо для модификаций указателя стека запрещаться на пару команд.

Если нужно разрешить на части обработчика, то других вариантов и нет. Чтобы не було проблем, обозначеннх aesok, надо глянуть <util/atomic.h>


Это сделано на gcc-шном расширении C - атрибутах, приписывающих к переменным некие функции инициализации и очистки. По сути - конструкторы и деструкторы, выражаясь языком C++
Приведенный выше код эквивалентен С++ - ному
вплоть до сгенерированного компиляторами кода
avr-gcc -std=c99 -O2 -S -mmcu=atmega88
avr-g++ -O2 -S -mmcu=atmega88