Частотомер на AVR

[dimonbest]

И еще вопрос как разрезать long в CodeVisionAVR побайтно, там для этих целей какие-то операторы типа % используются. Нужно разрезать на байты чтобы послать в USART.

Я например делаю это так:

unsigned long int a=0x12345678;
a=a & 0x000000FF //самый младший байт
a=(a››8)& 0x000000FF// следующий байт
a=(a››8)& 0x000000FF// следующий байт
a=(a››8)& 0x000000FF// последний байт

[nokazus]

Сообщение от EXIS

И еще вопрос как разрезать long в CodeVisionAVR побайтно, там для этих целей какие-то операторы типа % используются. Нужно разрезать на байты чтобы послать в USART.

Я например делаю это так:

Код:

unsigned long int a=0x12345678; a=a & 0x000000FF //самый младший байт a=(a››8)& 0x000000FF// следующий байт a=(a››8)& 0x000000FF// следующий байт a=(a››8)& 0x000000FF// последний байт

Я думаю, что Вы так не делаете. Во третей строке кода будет a=0.
Удачи.

[dimonbest]

Я думаю, что Вы так не делаете. Во третей строке кода будет a=0.
Удачи.

Я написал идею, а не кусок кода со своей программы...

unsigned long int a=0x12345678; 
unsigned char temp;
temp=a & 0x000000FF //самый младший байт 
temp=(a››8)& 0x000000FF// следующий байт 
temp=(a››8)& 0x000000FF// следующий байт 
temp=(a››8)& 0x000000FF// последний байт

Так работать будет

[nokazus]

Я написал идею, а не кусок кода со своей программы...

Код:

unsigned long int a=0x12345678; unsigned char temp; temp=a & 0x000000FF //самый младший байт temp=(a››8)& 0x000000FF// следующий байт temp=(a››8)& 0x000000FF// следующий байт temp=(a››8)& 0x000000FF// последний байт

Так работать будет

Идея хорошая, но и так работать не будет. У Вас в 4, 5 и 6 строках стоит сдвиг на 8, а само "a" не меняется, поэтому в строках 4, 5 и 6 будет одинаковое значение temp.
Удачи.

[tempora]

Идея хорошая, но и так работать не будет.

Душишь творчество на корню!

[nokazus]

Сообщение от nokazus

Идея хорошая, но и так работать не будет.

Душишь творчество на корню!

Никапельки. Просто хотел сказать, что не стоит спешить. Основные заковыристые ошибки программист (и не только) делает по невнимательности. Найти их очень трудно, т.к. "простой" участок просматриваешь бегло. Поэтому нужно воспитывать в себе внимательность.
2 EXIS
Обратите внимание на режим таймера CTC (сброс при совпадении). Тогда перезагрузку счетчика таймера вручную делать не надо.
Удачи.

[dimonbest]

Никапельки. Просто хотел сказать, что не стоит спешить. Основные заковыристые ошибки программист (и не только) делает по невнимательности. Найти их очень трудно, т.к. "простой" участок просматриваешь бегло. Поэтому нужно воспитывать в себе внимательность.

unsigned long int a=0x12345678; 
unsigned char temp; 
temp=a & 0x000000FF //самый младший байт 
temp=(a››8)& 0x000000FF// следующий байт 
temp=(a››16)& 0x000000FF// следующий байт 
temp=(a››24)& 0x000000FF// последний байт

Прошу прощения, действительно из-за спешки

[tempora]

Поэтому нужно воспитывать в себе внимательность.

То была шутка юмора.

[Panda_Y2k]

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

[nokazus]

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

Я предложил измерять частоту тайиером/счетчиком, а не программно по внешним прерываниям. И тогда максимальная частота равна половине тактовой. Если по каждому фронту уходить в прерывание, то действительно МК нужно принять запрос, среагировать на него, обработать прерывание, выйти. Еще и основной код должен когда-то отрабатываться. Об этом было написано выше в теме.
Что касается

если на время обработки прерывания запретить это же прерывание, ... , если не запретить, стек сорвать можно.

ИМХО это бред. Экспериментально на AVR такую ситуацию не пробовал. Но точно знаю, что во многих процессорах ядро не станет обрабатывать прерывание, пока обрабатывается прерывание с таким же приоритетом. Например, в MSC-51 есть скрытый регистр, запрещающий реакцию на прерывания (с таким же или низшим приоритетом) на время от начала реакции (занесения в стек адреса возврата) до исполнения команды reti. За счет этого следующее прерывание отрабатывается только после того, как закончится текущее, будет выполнен возврат к основному коду, выполнится один оператор основного кода. Такой алгоритм обработки прерываний наблюдается у многих процессоров Intel. Я не думаю, что в AVR сильно отличается. Поэтому никакого сорванного стека, если висит запрос на прерывание, быть не может. Просто прерывание будет обработано позже, или вообще не будет, если запрос на прерывание (флаг) был снят до окончания обработки текущего прерывания. Стек можно сорвать если неправильно выходить из прерывания и подпрограмм.
Удачи.